Vinnerliste

Her ser dere litt bilder av hybridstripa til Yuji-led i aksjon. Noen bilder med bare 2700k diodene og noen med både 2700k og 5000k diodene. Stripa er montert i aluminiumskanaler som henger i klips skrudd fast under skapene. Da kommer det luft mellom kanal og skap og det gir enda bedre kjøling. I flexit-ventilatoren satt det 2 stk E27-pærer, disse har jeg byttet ut med 2x 8W Cob-led fra ebay montert på kjøleribber. Disse gir sykt mye lys, men jeg tenker å bytte dem ut med noe cree-greier med høyere cri. Her skimtes elkobryteren jeg bytter mellom fargetemp med. Ganske primitivt i denne kretsen.

DEAL, du får det - som takk for utmerket innsats her inne. Sender PM ang. logistikk. ?

Dette stemmer ikke, kommunikasjon mellom panel og aggregatet er modbus. Det skal absolutt være mulig å gjøre akkurat samme jobben som adapteret med egen hardware. Jeg kjøpte selv CI66, og la det sporet ligge på hylla for ei stund tilbake. En PC med RS485 kan enkelt erstatte adapteret, men den må stå å svare på meldinger fra aggregatet kontinuerlig. Den beste løsningen hadde nok vært en arduino med RS485 adapter. Jeg har nettopp tatt en offisiell fork av home-assitant med støtte for Flexit/CI66, tilgjengelig her: GitHub Planen er å legge inn en PR snart. Et ekstremt irriterende problem med CI66, som man helt sikkert kan komme rundt med egen løsning, er at varmeelementet skrus av/på med en dip-switch i kontrollpanelet (CI60) og kan derfor ikke styres via CI66. Jeg vurderer derfor å se på en løsning uten CI66. Før jeg visste om CI66, probet jeg en del på kommunikasjon mellom styringspanel (jeg har CI60 / UNi2), jeg husker ikke detaljene, men jeg har noen notater: - Aggregatet er master - Master sender write_holding_register 0x00BE-0x0113 som broadcast (skriver til alle slaver) flere ganger i sekundet, disse registrene inneholder status - Master poller "coils" 0x0000-0x0160 fra slaver. Om noen av slavene sier at en coil er True, prøver master å lese holding register med samme offset fra slaven (coil 0x0005 = 1, les holding register 0x0005). Disse registrene vil da være feks viftehastighet 0-4. Master leser "coils" fra 1-3 forskjellige slaveadresser, jeg husker ikke detaljene, men jeg tror dette har noe med det faktum at man kan ha flere paneler per aggregat (0-1 CI600, samt 0-2 CI60 paneler). Da jeg skrev disse notatene hadde jeg ikke registerbeskrivelsen til CI66, heller ikke muligheten til å sammenlikne registrene aggregatet sender som broadcast med registrene som er tilgjengelige via CI66, jeg tror nok dette blir enklere nå. Jeg fant eksempelvis ut dette i sin tid: Coils: 0x0000 ( 0): Fan speed 0x0003 ( 3): Fan speed Supply 0x0008 ( 8): Fan speed Exhaust 0x000C ( 12): Setpoint temperature 0x008C (140): Heater on/off Holding registers (Changed by the slaves, pulled by the master when coil changed) 0x0000 ( 0): Setpoint Fan speed 1,2,3 ... 0x0003 ( 3): Setpoint Fan Speed Supply 0-100 ... 0x0008 ( 8): Setpoint Fan Speed Exhaust 0-100 ... 0x0012 ( 18): Setpoint Temperature x-30 ... 0x0140 (320): Heater On/Off 0,1 Broadcasted Holding Registers: 0x00BE (190): Setpoint Supply Air Temperature 0x00BF (191): Fan speed [1,2,3] Det eneste som mangler nå er å finne korrelasjon mellom "holding" register i CI66, "coils" og "holding" i CI60/600. Om noen er interessert i dette kan jeg hjelpe med mapping.

kan jo ta en liten oppdatering. Kjøpte inn en ny uzb1 bare for å være sikker på at det ikke var den som var årsak til noe av problemene. Det hjalp ikke i det hele tatt så da var den sjekket ut. Jeg har derimot oppdaget to Qubino v1 dimmere som nå ikke lar seg slå av via knappe trykk lenger. jeg kan slå de på men ikke dimme eller slå av. De har jeg nå fjernet fra z-wave nettet og tatt strømmen på for å se om de skapte noen flere problemer. Et spørsmål om z-health sånn på tampen er skal ikke den liksom optimalisere nettet? jeg tenkte det kunne være greit (og enkelt) å la den kjøre litt optimalisering mens jeg var på jobb men det ser ut til at alt den gjør er å sende no-op til nodene. status etter z-health har kjørt er no-op success på alle noder men 0 av 0 optimaliseringer kjørt??

Jeg trenger et billig utendørskamera, tar gjerne Wanscam-kameraet.

Har du spec eller typebetegnelse på de Panasonic kameraene? Det du har oppgitt (BB-HNP11CE) er recording software.

Jeg kjøpte USB-vifter og griller: http://s.aliexpress.com/nqUrYZ7B http://s.aliexpress.com/AJRNzmuM Tok hull i bunn av TV-benken og monterte vifte der. På siden av TV-benken tok jeg hull og bare grill. Har en NodeMCU med DHT22 som tempgiver og styrer vifta via en vanlig Nexa On/off-plugin. Har bestilt et relé jeg tenkte koble vifta til i stedet (og NodeMCU): http://s.aliexpress.com/b6vymYze Node MCU og relé går (forhåpentligvis) i denne boksen: http://s.aliexpress.com/bERFfQbM Sammen med disse (strøm inn via microusb og strøm ut til vifta via en vanlig USB-hunn (slik at jeg enkelt kan koble den fra)): http://s.aliexpress.com/Yja6RnEz http://s.aliexpress.com/mMV7ZbUJ (disse klippes selvsagt og setter på dupont-connectors) Relé og NodeMCU festes med slike: http://s.aliexpress.com/VVFFrmYV ...er i hvertfall min plan.

Har gjort dette med Fibaro wallplugs og HS3, beskrevet i lenken under. Vet ikke om det er nyttig for deg med Fibaro, men...

Har satt Fibaro PowerMeter's på både vaskemaskin og tørketrommel. Det er flere formål her; 1) Varsling når vaskemaskin/tørketrommel er ferdig. Begge står litt bortgjemt i en etasje vi normalt ikke befinner oss i. 2) Varsling dersom vi drar fra huset når enten tørketrommel eller vaskemaskin går 3) Varsling dersom huset settes i nattmodus mens tørketrommel eller vaskemaskin fortsatt går. Egentlig mye det samme som GeneralVirus tidligere har beskrevet. Utstyr 2 x Fibaro PowerMeter HS3 med HStouch på ekstern klient (nettbrett på vegg) Siden verken vaskemaskin eller tørketrommel kommuniserer med noe, er tanken å derivere status via strømforbruket. Dermed starter hele øvelsen med en kjapp analyse av strømforbruket på en typisk syklus. Dette logges lett med PowerMeter. Brukte opprinnelig et script som skrev tidspunkt og forbruk til en tekstfil, men oppdaget kjapt at det var enklere å bare hente informasjonen rett fra loggen i HS3. Slik ser forbruket ut for vaskemaskinen på to tilfeldige programmer: Vaskemaskinen har ganske varierende forbruk, inkludert noen "spikes" opp til like over 2000 W. Forbruket vises derfor best på logaritmisk skala. Det er en utfordring at forbruket varierer såpass mye. Det som imidlertid er klart er at et ultralavt forbruk over tid er en god indikasjon på at programmet er ferdig. Slik ser samme grafen ut zoomet inn på de siste minuttene: Jeg legger derfor opp til å detektere den flate linjen etter at vasken er ferdig. For tørketrommelen ser forbruket litt annerledes ut (vist på lineær skala): Tørketrommelen har en funksjon som gjør at den vender (ikke "vente" slik det står i grafikken...) tøyet litt ca hvert 30 sekund etter at den er ferdig. Samme type forbruk kan ses flere ganger langs syklusen, så det i seg selv er ikke diagnostisk. Forbruket i pausene på slutten er imidlertid bittelitt lavere enn forbruket ellers, og fungerer som diagnose. Slik ser Fibaro PowerMeter ut i HS3. Det er subdevice "Power" som brukes i dette oppsettet: I HS3 setter jeg opp virtuelle devicer for å kategorisere strømforbruket. Det er nyttig, fordi man da får et ledd mellom statusen og selve forbruket. Da kan man legge inn krav om en viss varighet på forbruk osv, og man kan dermed fjerne effekten av de ultrakorte spikene i forbruk. Statusen er også en virtuell device. Som dere ser hadde jeg opprinnelig en plan om å detektere sentrifugering, men den kjappe dataanalysen viser at det blir vanskelig. Teksten i status-devicene er laget for å gi grammatisk mening når den vises i HStouch. Eventer endrer proxyene basert på avlest forbruk, og andre eventer (vist under) fanger opp endringene i proxyene, og setter selve statusene. Her er eventen som fanger opp om vaskemaskinen er ferdig med et program. Her har jeg valgt å bake inn varslingen i samme event. En litt mer ryddig måte å gjøre det på vil være å ha en egen event som styrer kommunikasjonen basert på om statusen endres til "er ferdig". Smak og behag, I guess. Verdiene for "lav" og andre forbrukskategorier justeres etter forbruket og signaturen til de ulike programmene. Utfordringen er å finne noe som er diagnostisk på tvers av alle ulike programmer. Her er det også viktig å bruke "has been XX for exactly", i stedet for "at least". Sistnevnte vil fortsette å trigge eventen i all evighet, mens førstnevnte kriterier oppfylles bare 1 gang. I praksis ble det ganske mange eventer ut av dette, og det hadde nok vært best med et script. Det får bli på sikt. Etter at screenshot ble tatt har jeg lagt inn en sjekk i disse eventene for om statusen er noe annet enn "er ferdig".