Vinnerliste

@kodax Socketen er ikke IPX-sertifisert, så hvis det er store temperatursvingninger mellom minusgrader og plussgrader, kan det føre til kondens som kan skade PCB-en. Den vil kunne fungere ned til -10 grader eller lavere, men hvis det er mye luftfuktighet der socketen er plassert, kan det føre til kondens over tid. Det samme kan oppstå med andre socket-typer fra andre produsenter. Men som @nle nevnte, kan du komme rundt dette ved å kalibrere sensoren inne i appen. @A.B. Vi har firmware som ikke er lagt ut ennå, men den fungerer uten problemer med Matter på alle gen3-produkter. Vi venter på at Espressif skal få offisiell godkjenning av deres lisensprogram fra CSA (for enheter som allerede er solgt). Sist jeg hørte fra dem, var den ferdig mot slutten av februar 2024. Selve Matter-sertifiseringen tar en måned, akkurat nå er bremsen Espressif. Men vi skal ha Matter støtte klart for gen3 ikke senere en sommeren 2024 Jeg kan også meddele at vi kommer med en ny variant av gen3m som vil bruke denne brikken: https://www.espressif.com/en/products/socs/esp32-c6 Den nye termostatboksen som bruker C6-brikken vil endre navn til Gen4 og rulles ut for alle panelovnmodeller. De som har en gen3m som selges nå med ESP32 S3, vil kunne oppgradere til ny toppdel som bruker C6. Du kan se på den nye gen3m v2-varianten som en "stille" utgivelse før den rulles ut til alle modeller. Gen3m v2 kommer med Matter fra starten av, med QR-kode osv. Den vil støtte Thread/WiFi. Den støtter også Zigbee, men vi venter på at Espressif skal fullføre sin Zigbee SDK før vi kan ta det i bruk. Alle gen3m v2 vil deretter få en firmwareoppdatering som vil gi Zigbee-støtte senere."

Denne lille rakkeren har gjort at smarthuset mitt har fungert svært dårlig i et par uker nå! 😞 Vi rakk å gå inn, ta av oss yttertøy og sette oss i sofaen før lyset på stua slo seg på! Utrolig irriterende, særlig når huset har fungerte relativt problemfritt i 7 år! Så hvordan fant jeg synderen, lurer du da sikkert på? 😉 Det hele startet rundt juletider. Det ble merkbart tregere respons på kommandoer, særlig på lys. Prøvde selvsagt de vanlige tingene, som å restarte HomeSeer-serveren, installere de siste Ubuntu-patchene, restarte RasberryPi som Z-wave USB-pinnen kjører på, osv, men ingenting hjalp. Noen dager kunne det fungere "ok" og andre ganger helt i sirup. Visste liksom ikke helt hvor jeg skulle begynne feilsøkingen og med lite ledig tid så ble det egentlig ikke gjort stort med det på et par uker. En dag oppdaget jeg tilfeldigvis at en "pyntelampe" ikke lyste og den lot seg verken slå på med Z-wave eller ved å trykke på bryteren. Tenkte at bryteren trolig hadde gått i stykker og det slo meg at kanskje en del Z-wave-trafikk ble forsøkt rutet via den, så jeg tok en "remove bad node" i HomeSeer, slik at den ikke lengre skulle være en del av Z-wave-nettet. Men, det hjalp ikke. 😞 Et par uker senere satte jeg med ned for å feilsøke mer grundig. Jeg hadde sjekket litt logger og sånt tidligere, uten å se noe unormalt. Jeg benyttet selvsagt også @Moskus sin debug-guide og programvare: Men, det var heller ikke noe som skilte seg ut med mye trafikk der heller. For en del år siden kjøpte jeg Z-seer på tilbud, så jeg fyrte i gang den for å feilsøke og det ble fort klart at det var noe som ikke var som det skulle! Hver gang jeg restartet programmet ble 2-4 tilfeldige noder markert utilgjengelige (rosa). Kjørte jeg en "test all", så var det også mange noder som den feilet å kommunisere med ("B=1" nederst på noden betyr at command eller respons mot noden feilet i testen): Jeg valgte en tilfeldig Fibaro Dimmer 2 (som hadde direkte rute til UZB1) og kjørte command og respons-test: Masse pakketap og utrolig lang tidsbruk! Noen noder var kjappe og ga ingen pakketap, klarte egentlig ikke å se noe mønster i hvem som funket og hvem som ikke gjorde det. Det virket også som den samme noden kunne funke fint i en ny test noen minutter etterpå. Min konklusjon var at min 7 år gamle UZB1-pinne trolig hadde begynte å feile og at jeg måtte bytte den ut. Jeg har en reserve UZB1 liggende et sted og vurderte å lete etter den og forsøke å overføre backup fra gammel til ny og se om det hjalp, evt kjøpe meg en ny USB-pinne (med 700-chipset, for å "oppgradere" litt). Jeg begynte å skrive en epost til HomeSeer-support, for å bare få en slags bekreftelse på at min teori trolig stemte og at det ikke var noe annet jeg hadde "oversett". Skulle avslutte eposten med å skrive at jeg ikke hadde gjort noen endringer i det siste, helt til jeg da kom på denne Swiid-bryteren som hadde feilet og som jeg hadde fjernet fra nettverket. Da slo det meg at jeg hadde ikke trukket ut støpslet til den lampen, så selv om den ikke lengre var en del av Z-wave nettverket mitt, så var det fortsatt "på lufta" og kanskje kunne skape støy. Før jeg sendte eposten gikk jeg derfor og trakk ut støpslet, bare for å i hvertfall ha utelukket det (og rent brannvernmessig er det sikkert også lurt å koble fra elektronikk som har sluttet å fungere som det skal, just in case...). Og vipps, så begynte lysbrytere, osv å fungere lynkjapt igjen! 😮 😄 Jeg tok en ny test med Z-seer: Og bare minutter etter jeg trakk ut kontakten så var ingen noder lengre "rosa" og bare et par termostater meldte om pakketap ("B=1")! 😄 Neste morgen slo alle lysene seg på før jeg rakk å gå ned trappa! Deilig! 😄 Så hensikten med denne posten er rett og slett og vise hvor "sårbart" et Z-wave-nett kan være. Det skal ikke mer enn én trøblete node til for å "ødelegge" for alle andre og gi en svært dårlig/elendig brukeropplevelse (og WAF!). Men å finne denne ene noden er ikke alltid så enkelt! 😞 Jeg var heldig at det var en Swiid på en lampe med støpsel, for da tok det null tid å koble den ut for å teste. Hadde det vært en dimmer-pille f.eks så hadde det vært vesentlig verre - ikke har jeg lov å koble de ut selv, det er mer knotete å komme til, og man er som regel litt mer avhengig av det lyset som drives av en slik sånn at man gjerne ikke ønsker å koble den fra heller (i hvertfall så lenge lyset fungerer da). Og å ta sikringen kurs for kurs vil også kunne gi uante følgefeil, ved at noder som mye trafikk normalt sett rutes igjennom blir koblet ut og man får andre typer feil pga rutingproblemer oppå det hele og vil få problemer med å skille det opprinnelige problemet fra evt rutingfeil pga utkobling av "friske" noder. Så har du et tregt/ustabilt Z-wave nett så ønsker jeg deg lykke til i feilsøkingen... 😛

Jepp. Mye ryddigere å ha alt som styrer en utgang på et sted synst jeg. Innganger kan gjenbrukes, men utganger bare styres "en gang". Dvs du kan ikke skru den både av og på samtidig så det forenkler litt om en samler det som styrer utgangen et sted imo for oversikten sin del. HA virker ikke for å være bygget etter min måte å løse det på men ser at det er workarounds rundt det 🙂

...og ligger disse på forskjellige steder er det veldig lett å miste oversikten. Har noen ganger endt opp med å lage lignende automasjoner på flere steder og feilsøking blir da litt krevende fordi en automasjon du har laget for lenge siden og ikke helt husker i farten kan lure deg lenge... Heldigvis er det lett å strukturere og jeg har flere gode søkeverktøy i mitt system (Node-RED)...

Jeg forstår veldig godt hva han mener, og jeg bruker samme prinsipp som Thoralex over. Eksempel: Jeg får en notifikasjon på mobilen når vaskemaskinen er ferdig. Når vaskemaskinen blir slått av (noen har hengt opp klærne til tørk), klareres notifikasjonen automatisk så man slipper å gjøre det manuelt. Da har jeg én automasjon, med to triggere (maskin ferdig, maskin slått av), med to aksjoner (lag notifikasjon, slett notifikasjon). Det er ofte jeg må løsrive meg fra tanken om et syklisk kontrollsystem som jeg er vant til fra jobb, f.eks. en PLS. Må tenke litt annerledes for et event-basert kontrollsystem som Home Assistant.

Det gjelder ikke eldre Karmstrup målere, heller

Opprinnelig var det nok tanken med en automasjon for hver handling, men det fungerer åpenbart ikke så godt lenger. Heldigvis er det ikke noe problem å samle alle funksjoner for en enhet i en automasjon, men det kan også bli uoversiktlig ettervert så det er litt personlig preferanse hvordan man gjør det. Jeg samler for eksempel alle funksjonene på en bryter i samme automasjon, men har flere for styring av varmtvannsbereder siden de er forholdsvis omfattende og har veldig ulik funksjon. For å samle flere funksjoner i en automasjon må du gi hver trigger et navn, og så bruke "choose" med condition "triggered by" for hver handling for å koble handlingen til riktig trigger. Det har kommet en god del forbedringer av den visuelle editoren i de siste oppdateringene, så det jobbes åpenbart mye med å forbedre dette. Forhåpentlig er bedre organisering av automasjoner ikke alt for langt unna...

Hvilken oversikt er det du trenger egentlig? Jeg har inndelt alle mine med prefiks for rommet hvor automasjonen utføres (så langt det lar seg gjøre). Og søkefunksjonen finner jo alt så lenge man har gode navn på automasjonene.

Er det noen grunn for at du vil gjøre det i node red og ikke direkte i HA?

Takk, fungerte bra. Aldri brukt Node-Red før, men her er flowen min. [{"id":"7ce7a7849c9c8b4e","type":"tab","label":"Flow 1","disabled":false,"info":"","env":[]},{"id":"276071b26f3e49a2","type":"inject","z":"7ce7a7849c9c8b4e","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":160,"y":220,"wires":[["fb25d94b.139e78"]]},{"id":"fb25d94b.139e78","type":"http request","z":"7ce7a7849c9c8b4e","name":"Get Token","method":"GET","ret":"txt","paytoqs":"ignore","url":"https://api.drivstoffappen.no/api/v1/authorization-sessions","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":330,"y":220,"wires":[["9b28d83a.0226d"]]},{"id":"9b28d83a.0226d","type":"function","z":"7ce7a7849c9c8b4e","name":"Process Token","func":"msg.token = JSON.parse(msg.payload).token;\nmsg.tokenBytes = Buffer.from(msg.token);\nmsg.shiftedBytes = Buffer.concat([msg.tokenBytes.slice(1), msg.tokenBytes.slice(0, 1)]);\nmsg.shiftedToken = msg.shiftedBytes.toString();\nreturn msg;","outputs":1,"timeout":"","noerr":0,"initialize":"","finalize":"","libs":[],"x":520,"y":220,"wires":[["bc5b206f4b80b029"]]},{"id":"17f2e29c.f0c2b3","type":"http request","z":"7ce7a7849c9c8b4e","name":"API Request","method":"GET","ret":"txt","paytoqs":"ignore","url":"https://api.drivstoffappen.no/api/v1/stations?stationTypeId=1","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[{"keyType":"other","keyValue":"X-API-KEY","valueType":"msg","valueValue":"md5Hash"},{"keyType":"other","keyValue":"X-CLIENT-ID","valueType":"other","valueValue":"com.raskebiler.drivstoff.appen.ios"}],"x":850,"y":220,"wires":[["77f3986f.d5f32c"]]},{"id":"77f3986f.d5f32c","type":"debug","z":"7ce7a7849c9c8b4e","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":1030,"y":220,"wires":[]},{"id":"bc5b206f4b80b029","type":"md5","z":"7ce7a7849c9c8b4e","name":"MD5","fieldToHash":"shiftedToken","fieldTypeToHash":"msg","hashField":"md5Hash","hashFieldType":"msg","x":690,"y":220,"wires":[["17f2e29c.f0c2b3"]]}]

Si at alternativet er at jeg kjører dieselbil tur/retur Åsane gjennom sentrum på en kald dag, gjerne da kuldelokket er over sentrum, mye bedre 😅 Men det går jo ikke på IKEA sitt CO2 budsjett...

Jeg personlig har ikke noe bedre svar enn at om jeg skal der kan jeg kjøpe det til deg, men er om kvarter-14 dager liksom. Men om du har prøvd i 2 år er det kanskje innafor. Bor 45 min ifra så er ikke sånn at jeg frekventerer der ofte. Men om jeg skal forbi og du ikke har fått tak i kan jeg fikse.

Da har jeg lagt inn støtte for "Bosch Sensortec BMP384 pressure sensor" for å måle atmosfærisk lufttrykk (med sensor som sitter på kretskortet):