DiderikFrom

Ups. Tenkte jeg skulle hjelpe rask før jeg løp på jobb. Beklager. Det har du sagt en stund... Jeg har tenkt det samme, men de nye produktene deres ser så fine ut på papiret -- dog er det alltid et eller annet. Funker det med 10 sekunder på parameter 3? Problemet løst?

Du skriver ikke at du har assosiert den til HS? Det må du. Gruppe 1 skal være nok (det er det i hvert fall hos meg).

Den er da støttet i JowiHue. http://www.vuyk.info/hs/jowihue/motionsensor Sitat: "Be aware that motion sensor updates are retrieved by polling. The speed of updates - and because of that response - will be limited by that. I have been testing with a refreshrate of 2 seconds, which could be quite fast in some bridge configurations. In this case, the motion sensor updates fast enough towards HomeSeer to switch on zwave lights in a time that is 'half a step into a room“ to “one full step into a room”. For me this is very acceptable as my old x10 sensors were regularly slower then that." Dog, ikke dermed sagt at dette er det beste valget av sesor -- jeg har ikke prøvd den. Jeg ville valgt Fibaro sin dersom jeg hadde rikelig med annen z-wave, men (jeg sier det igjen) Hues pærer har i hvert fall det beste lyset på markedet.

Jeg har lagt til RGBW-strips i speil tidligere. Det er ikke spesielt vanskelig hokus pokus. Hos oss var det et Villeroy og Boch speil med en vannvittig kraftig "ikke-dimbar" ledstripe. Jeg beholdt den, brukte samme strømforsyning (den var kraftig nok), koblet på en ekstra RGBW-stripe og en gammel Fibaro 2x1.5kW modul samt en Fibaro RGBW-modul til å styre/dimme RGBW-stripen. Da står RGBW på med moderat, varm belysning hele tiden, og så kan man skru på flombelysning i form av den opprinnelige stripen dersom man skal gjøre noe som trenger ekstra godt lys (Alexa, turn on Task Light). Den kunne jeg forsåvidt også ha dimmet dersom jeg hadde hatt behov, men jeg hadde kun on/off mikromodul og ikke RGBW-liggende. (Den kunne brukes på 24V.) Jeg kan ikke helt se hvorfor man ikke skal kunne dimme den eksisterende leddstripen i IKEA-saken? Dersom den får 12/224V dc kan man jo bare kope på en Ribaro RGBW? Edit: Et alternativ, dersom du kun har relativt lyssvake eBay-RGB(W) strips liggende, er å beholde den opprinnelige stripen, koble til en Fibaro RGBW-modul, men også koble til en ekstra RGB(W) til samme modul, men da droppe W på RGBW-stripen (dersom du bruker det og ikke en RGB-stripe. Dersom strømforsyningen ikke er godt nok overdimensjonert, kan du endre parametrene i RGBW-modulen som justerer maks dim. Da får du dimbart originallys med mulighet for å tone det med RGB.

OK, greit å kunne lime noe inn i scriptboksen i en event. Jeg har skrevet om det originale skriptet enda en gang... Nå gjør jeg alt i lua i ett skript, og bruker curl fra lua-skriptet til å hente ut gammel octa-verdi samt oppdatere devicene. (curl til HomeSeer for å stye med JSON). Tenkte teste litt videre, men ser ut til å funke utmerket (dog er jo solen så mye nede på denne tiden av året).

Det gjorde jeg først, men da oppdateres heller ikke LUX igjen (man får Nan: not a number) basert på nye verdier for altitude og azimuth, og ev. annen data fra wunderground. Derfor henter jeg (og det opprinnelige lua-skriptet) den sist lagrede verdien for octa i (domoticz) HomeSeer slik at den kan brukes i beregningen. Ja, hvorfor ikke. Man kunne kanskje lage eller opprette et sted her der man kunne samarbeide om et prosjekt. En ting for denne saken er å få rådata ut av wunderground, ogimet &c, en annen å få regnestykkene å plass i klartekst, en annen ting å få dem skrevet i .NET/bash/lua, og til sist å få det hele satt sammen som et skript eller plugin. Jeg har så mye annet på tapetet at jeg ikke klarer å skrive om hele skriptet fra lua til et annet språk alene, men tar gjerne deler av oppgaven (og er godt i gang). Og jeg har jo noe som funker for meg.

@Moskus Det skal ganske lite til (nå som jeg har skjønt hva man må gjøre) for å endre lua-skriptet til å fungere uten domoticz. Det eneste jeg slet med, var å finne en måte å laste inn siste octa-verdi til bruk dersom ny verdi ikke er tilgjengelig (dvs. ogimet svarer med "/"). Dette skriptet vedlikeholdes på domoticz' wiki, og jeg tenker det er litt undøvedig å finne opp hjulet to ganger, men heller gjøre enkle tilpassinger for HomeSeer. Det er i hvert fall veldig mye mindre arbeid, men forutsetter at man kan/vil kjøre lua. Dersom man ikke kan kjøre lua, må man oversette skriptet helt. Hva har du tenkt å gjøre? Dersom du vil oversette helt eller delvis (bare det jeg har skrevet i bash) til .NET, eller lage plugin, er jeg gjerne med (med min begrensede kunnskap om .NET og plugins). Sender gjerne en PM senere i dag nå rjeg har tilgang til scriptet.

Jeg har delvis skrevet om lua-skriptet slik at det ikke krever domoticz. Og så var det noe som ble for vanskelig til å skrive i lua. Jeg kunne nok oppdatert HomeSeer-devicene rett fra skriptet, men "octa" trenger en del prosessering, og det ble for vanskelig... For å oppdatere hver av de virtuelle devicene starter jeg fra lua-skriptet et annet program med verdien som devicen skal ha som input. Jeg starter ett bash script (men det er bare å angi path til os.execute dersom man vil bruke noen annet enn bash) med to input: device og verdi. Dette gjør jeg fordi octa ikke oppdateres korrekt hver gang skriptet kjøres, men ofte bare returnerer "/". Da bruker jeg forrige octa-verdi, som i det opprinnelige skriptet hentes fra domoticz' uservariables lua-array. Tilsvarende fikk jeg ikke til i lua., men måtte ta en omvei om et språk jeg kan. Det som er skrevet i bash er vedlig begrenset og sikkert enkelt å kovertere til .NET.

Så bra noen andre synes dette er gøy! Enda mer lua, men nå skal siste octa (skydekketetthet) lastes inn som lua-variabel ved starten av scriptet. Og så har jeg også lagt til direct, indirect (scattered) og total solar radiation. Nå er jo solen gått ned, så det meste er "0". Plugin aner jeg ikke hvordan man lager, men kjører man HS3 på linux er det bare å konfigurere høyde over havet, by, land, lengde- og breddgrad samt nærmeste Ogimet-stasjon (for skydekkedata), samt få en konto hos weather underground, og så funker det. Jeg kjører dette jevnlig sammen med de andre skriptene mine, men man kan bare lage en event i HS der man "Run another program or process" hvert kvarter eller hvert femte min. Dog er det ganske lite som er linux-spesifikt av det jeg har gjort, så det skulle være ganske lett å portere til Windows/.NET. Og sikkert til gjennomført lua også, men da må man kunne lua bedre enn meg...

Hm, ja. Det hadde vært greit å få det til, men bluetooth er nok ikke den beste protokollen for HS-integrasjon, dessverre. Det går nok an, men antakelig ganske mye arbeid.

Tja. Kjenner ikke blockly, men > 22:35 OR < 06:35 kan vel fungere. Dersom du er uheldig, kan du måtte lage to forskjellige, ett > 22:35 og ett < 06:35. Mulig dette er irrelevant for blockly, men debugging blir vanskelig når du har så konvolutert logikk. Jeg ville droppet alle 'elseif', og lagd flere forskjellige eventer. I hvert fall til å begynne med slik at du kan se hva som fungerer.

Hva som helst, nesten. Posten har sendt min en liten rundtur i Norge så jeg har ikke fått den enda, men jeg tenkte bruke en Fibaro dørsensor, ev. en Fibaro Universal Sensor.

Jeg kjenner ikke blockly, men en feil ser jeg umiddelbart. Er det alt som ikke funker, eller bare "mellom 06:30 og 22:30"? --> Time kan ikke være BÅDE > 22:35 OG <06:35. Det tidspunktet fins ikke.

Jeg måtte visst kode litt mer lua. Det viser seg at ogimet ofte sender tom octa-data, og da kan ikke lux beregnes. Det er tatt høyde for i det opprinnelige skriptet ved at forrige octa-verdi hentes fra domoticz -- jeg måtte finne en alternativ måte å hente forrige verdi, men nå håper jeg det blir stabilt. Jeg legger så til (når jeg gidder) "direct" og "scattered solar radiation" i W/m2.

Den nye nespressomaskinen ser vedig fin ut, men automatsieringen virker mer som en gimmick. Som Moskus påpeker er Bluetooth ikke noe særlig for automatisering. Også jeg har nespresso, men jeg har aldri savnet automatisering. Jeg har dog vurdert en plug-in modul for å få den til være på og ferdig oppvarmet når jeg trenger den, men det går uansett så fort at nå som jeg har plug-in moduler liggende, har jeg ikke fått somlet meg til å bruke dem.

Da har jeg endelig fått dette i opp og i gang! Det er ikke pent, for jeg kan ikke lua, men jeg har knotet meg til en slags bash/lua-hybrid som gjør at jeg hvert femte minutt får oppdatert fire virtuelle devicer i HS: Octa (skylagets tykkelse 0-8) basert på data fra Ogimet-stasjoner Solens høyde (nå er den 40 grader under horisonten) Azimuth (noe greier med solens vinkel mot nord, trengs for den siste devicen) Lux eller utendørs lysintensitet (estimert ut fra de foregående) nokså nøyaktig, virker det som så langt. Jeg har ikke vært så fornøyd med mine lux-sensorer fordi de er så avhengig av å plasseres riktig, og jeg har ikke villet la dem oppdatere seg så ofte pga. batterilevetid. I tillegg kan man legge til alskens devicer som angir "Solar Radiation" og lignende, men jeg nøyer meg med dette foreløpig. Jeg følger litt med på verdiene i HomeSeer før jeg tar dette i bruk, men planen er å la dette overta for lux-sensorene som måler belysning utenfra og styrer dimmere og fargetemperatur. Når man i tillegg får solens høyde, kan det være nyttig å kombinere med lux (ev. "Solar Radiation") for å stye rullegardiner &c.

Gode argumenter for Popp, men jeg liker Fibaro sin. Den kan ikke seriekobles, ikke brukes som sirene, og kan ikke tilkobles fast strøm... Den er dog liten, pen og har god batterikapasitet. Men må du ha noen av funksjonene som Popp har, er jo valget enkelt.

Det kan være mange grunner. Enheten kan være uten strøm eller utenfor rekkevidde? Er det en batterienhet? Dersom du går på Plug-Ins:Z-Wave:Node Information, og skroller ned til noden. Har den en last working route? Dersom du klikker på den, og velger Test Connectivity, hva skjer da?

Nest Learning Thermostat er det eneste smarthuseksempelet jeg kommer på,men jeg har ikke prøvd den, og jeg vet ikke hvor bra jeg tro den er? Jeg spør litt fordi jeg lurer på om jeg skal bruke tid på å sette meg inn i dette i jobbsammenheng. Jeg har allerede tett samarbeid med et utenlandsk senter for "kunstig intelligens" der vi utvikler software/algoritmer basert på maskinlæring for bruk med MR. Nå har døgnet som kjent 24 timer og man må prioritere hva man selv skal gjøre. Så langt er min erfaring at når det gjelder maskinlæring, må man velge problemstillinger nøye -- (det høres åpenbart ut) men dersom man ikke har relevant rådata inn, får man intet nyttig ut. Jeg er litt redd det er slik med smarthus per i dag -- sensorene kan ikke plukke opp alle unntakene, man hadde trengt noen utførlige maler i bunn.

Dette er veldig spennende i ( ihvertfall i teorien). Men adaptiv læring kommer ofte litt kort i praksis, men det er sikkert noen som vokser. Hva slags software for adaptiv læring kan dte være snakk om?

Har du riktig «size»? Tror ikke det er en bug i HS, men WallC2 er ikke akkurat det beste produktet. Her er dog en miniguide for oppsett av WALLC-2 jeg lagde på det gamle forumet: http://www.diskusjon.no/index.php?showtopic=1191806&p=22970470

Takk! Fargetemperatur er selvfølgelig en smakssak (og en lang diskusjon), men jeg vil hevde de hadde kommet mye lenger med 2200-6000K enn 2700K-6500K. Sistnevnte er ubrukelig dersom man skal emulere varmt kveldslys eller soloppgang, og det vil mange enten for å hjelpe på søvnen eller bare fordi de synes det er fint eller behagelig. 3200K er utmerket på høylys dag når man jobber. Men jeg skjønner jeg er over gjennomsnittet interessert. Til spørsmålet: Synes du det har fungert bra med Lightify på Hue? Jeg har så mange ganger tenkt å hoppe i det, men hver gang kommer jeg over en eller annen som advarer om at det ikke blir stabilt selv om man oppdaterer firmware.

Når jeg leser nøyere det jeg selv har linket til, ser jeg at Philips nettopp har sagt følgende: "Philips Hue has been designed as an open system. This is why the Philips Hue bridge implements the ZigBee Light Link standard, that makes it possible for ZigBee Light Link compliant third party bulbs to connect to the Philips Hue bridge. The new IKEA Smart Lighting bulbs do not respond in the way we expect from a ZigBee Light Link compatible product and can therefore not be connected to the Philips Hue bridge." Muligens kan dette fikses i en TRÅDFRI firmwareoppdatering? Dog skal IKEA komme med en egen bridge før sommeren, MEN den vil ikke ha åpen API. Må man da ha en Lightify base? Vurderer å krype til korset å kjøpe noen Lightify E14-pærer, men kan ikke skjønne hva Osram tenkte på da de gjorde dem tunable fra 2700K til 6500K? Da kunne de like gjerne ha hatt dem konstant på 2700K, men smaken er vel delt. Og "feilen" fikses ved å oppdatere firmware? Det lønner seg nok å begrense brukerens frihet, men da skal du også ha et veldig bra produkt -- ellers gidder ingen bruke det. Philips har veldig godt lys i pærene sine, og det er jo faktisk det viktigste, spør du meg. Jeg mener de der ikke har noen reelle konkurrenter -- det måtte være den gamle glødepæren (som jo av andre årsaker ikke er aktuell). Pærene deres er dog klumpete, og de mangler E14!

Takk! Nei, mente jo om man kunne stoppe uling utløst fra HomeSeer.

Dette er supert! Men kan du bekrefte at man kan stoppe ulingen fra HomeSeer også?