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."

Har laget en AMS HAN-port leser med Matter over Thread. Da dukker strømmåleren opp som et Matter device i kontrolleren min og jeg får inn målerverdiene: Har benyttet følgende hardware: EFR32xG24 Explorer Kit - Silicon Labs (silabs.com) M-Bus Slave Click (mikroe.com) Koden som kjører på devicet og som leser og parser data fra HAN-porten er skrevet i C++. En utfordring er at Matter 1.2 standarden enda ikke støtter strømmåling. Måtte derfor trikse litt med hvor verdiene rapporteres. Håper Matter 1.3 kommer med støtte for dette, slik at det kan gjøres i henhold til standard. Spiller ikke så mye rolle for mind del siden jeg har skrevet min egen Matter kontroller, men ville vært fint om standarden støttet dette. Som det egentlig er overraskende at den ikke gjør.

Flott prosjekt! For oss som foreløpig ikke vet så mye om Matter og Thread - kunne du skrevet litt (kanskje en egen tråd) om hva det er og hvorfor man bør bruke det?

Da har jeg fått laget min egen Z-Wave End Device basert på Silicon Labs ZGM230-DK2603A. Har lagt til en CO2 sensor i tillegg til temperatur, fuktighet og lys som finnes på ZGM230. CO2-verdien vises som AccelerationXAxis til jeg får endret koden til å oppfatte den som en CO2-sensor.

Når det gjelder Home Assistant så er det neppe snakk om "hvis", men "når" de får en bedre måte å organisere dette på så kommer jeg selv til å gjøre om mange av mine python skript til Home Assistant automasjon. Dette er typisk å slå på radio via Sonos når noen kommer hjem etter at huset har stått tomt. Det er en python funksjon på 4 linjer @state_trigger("binary_sensor.noen_er_hjemme == 'on' and binary_sensor.noen_er_hjemme.old == 'off'") def somebodygothome(): media_player.stue.select_source(source = "NRK P1 Rogaland") media_player.volume_set(volume_level = 0.3, entity_id = "all") og lages like enkelt i HA sin automasjon. Grunnen til at jeg ikke har gjort det er altså at det blir for mange slik små snutter. I pyscript kan jeg organisere det i mapper. Ja, navneprefiks vil sannsynligvis løse det for meg også. Men jeg har tid til å vente enda litt til for å se om det kommer en grei måte å organisere det på.

Jeg kjøpte aksesspunkt og noen mindre skjermer fra NIC i Nederland: https://www.tindie.com/products/electronics-by-nic/openepaperlink-mini-ap-v3-zigbee-wifi-gateway/ Og den store skjermen kjøpte jeg ved å sende melding til personen ATC1441 på Discord-kanalen med samme navn: https://discord.gg/9bs5BEtp Merk at den store skjermen mangler støtte for en del av den nyere funksjonaliteten som er omtalt på https://github.com/jjwbruijn/OpenEPaperLink/wiki eller på Discord, men den fungerer fint for meg pga at jeg genererer bildet selv og laster opp til skjermen fremfor å benytte innebygget funksjonalitet eller json-format på tegning av grensesnitt.

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

Ah, ikke dårlig å ha kundeservice direkte på forumet, bra service👍 I bruksanvisningen står det at pluggen har driftstemperatur ned til -5, så da burde det vel være ok at jeg lurer den ned dit før den trigger vifteovnene 🙂

Garasjeport er populært å automatisere. Her er min løsning og kanskje kan noen bruke det videre. Min åpner er av den enkle typen. Den har to innganger, en for nødstopp og en for å veksle opp eller ned. Til denne har jeg koblet til et esp32 kort som jeg kjører esphome på. I esphome har jeg definert en "cover" som er tidsbasert og med endebrytere. cover: - platform: feedback name: "${devicename}" id: garasjeport has_built_in_endstop: true assumed_state: false direction_change_wait_time: 5s close_endstop: status_lukket open_endstop: status_aapen open_duration: 15s close_duration: 18s Endebrytere trenger en strengt tatt ikke, men uten de så er det vanskelig for Home Assistant å vite om port er åpen eller lukket. Jeg hadde i land tid en zigbee dørsensor som viste om port var lukket og status på den ble sendt til esp32 slik at jeg kunne sette status på "cover" at porten var igjen. Etterhvert har jeg byttet ut zigbee sensor med brytere koblet til esp32 direkte. Ikke fordi det virker bedre, men fordi jeg hadde lyst. I tillegg har jeg definert noen binære sensorer i esphome som forteller om status på port. Det er lukket, åpen og i bevegelse. I tillegg noen trykknapper for å starte en sekvens og å avbryte denne sekvensen. Til slutt noen innverdier for å sette antall sekunder til port åpnes og lukkes. I og med at denne er synlig i Home Assistant som en "cover", har jeg full kontroll på port. Jeg kan dra i en skyvekontroll og settte porten til en vilkårlig posisjon. Ikke så mye brukt til annet enn å sette i luftestilling eller åpne en halvmeter for å ta i mot en pakkelevering når jeg selv er på jobb. Jeg har et kamera inne i garasjen så jeg kan følge med på at pakken er kommet innenfor. Til porten fulgte det med to fjernkontroller og disse var årsaken til at jeg lagde min egen styring. Fjernkontrollene har tydeligvis dagshumør og noen dager må en helt inntil garasjeportåpnerens antenne før de reagerer. Det var veldig frustrerende. Det første jeg lagde, var en NFC brikke på en lur og usynlig plass i bilen. Når jeg holder telefon over denne, så åpnes port. Etterhvert er det kommet zigbee-brytere inne i hus ved utgangsdør og inne i garasje ved port. Med disse kan jeg åpne og lukke, samt slå på nødstopp. Jeg har også lagd det slik at hvis bakluke på bil er åpen så slås nødstopp på. Da kan ikke port betjenes fra annet enn innside av garasje ved å slå av nødstopp først. Og så har jeg en trykknapp i garasje som setter i gang en sekvens med å vente-åpne-vente-lukke. Da får en tid til å sette seg inn i bil og port går ned automatisk etter å ha kjørt ut. Sekvensen avbrytes hvis en trykker på knapp en gang til eller åpner garasjedør. Kona har en egen evne til å finne ut at hun ikke har bilnøkkel med seg og da må hun inn igjen i huset. Da er det dumt at port går opp og ned i mellomtiden. Sensorer som esphome sender til Home Assistant, brukes til alarm og å trigge lys i garasje. Jeg setter også farge på en lyslist over port som viser om den er i bevegelse eller helt oppe.

Hjemme hos oss spør fruen ofte "kan jeg sette på vask nå?" (strømpris) eller "hvilket søppel er det som hentes denne uken" eller kommenterer "når ser det ut som at det er høy sjø!" (vi bor ved sjø), mens jeg selv ofte lurer på om det var i dag eller i morgen det er postlevering, og hva blir været? Så for å få denne informasjonen lett tilgjengelig og oppdatert så lot jeg meg friste og hev meg på denne nye trenden med bruk av epapir-skjermer for smarthus (https://github.com/jjwbruijn/OpenEPaperLink) En epapir-skjerm er lettlest i alt lys, er lett å plassere siden den bruker batteri, men egner seg ikke til live-data som oppdateres ofte. Det eksisterer en integrasjon med Home Assistand, men jeg bruker Homeseer så måtte løse dette på egenhånd. Man sender data til skjermenes aksesspunkt med HTTP Post. Må si meg ganske fornøyd med resultatet. Dette er en 7.5" skjerm. Planen var å bruke prosjektet til å lære meg Python, men jeg feiget ut når jeg skjønte rekkevidden av integrasjonene og trøbbelet med å feilsøke dette i ukjent språk. Jeg valgte derfor å bruke PowerShell, som er noe jeg kan men som er uvanlig brukt for slike behov. Det gjorde API-er enkelt for meg, men gav meg noen utfordringer rundt å generere bildet som ble sendt til skjermen. Skjermen har kun fargene hvit, sort og rød, så bildedata som sendes kan ikke ha noen form for aliasing rundt fonter eller grafikk. Det var krevende å finne en font som passet i lite format uten aliasing. Data som vises er. Strømpris for dagen i dag, eller dagen i dag + 8 timer dersom neste dags priser er tilgjengelig. Data fra Moskus sin Tibberseer i Homeseer. Grafen tilpasses også dersom det er negative strømpriser. Dager for levering av post fra Bring sitt API: https://developer.bring.com/ Varslet tidevann fra Kartverket sitt API: https://www.kartverket.no/api-og-data/tidevann-og-vannstandsdata Søppeltømming fra Norkart. Her er det ikke fritt publisert API med med hjelp fra innlegg her på forumet fra Moskus og Clio75 så kom jeg et stykke på vei, men det var endringer i både URL og annet som gjorde at jeg måtte grave en del selv for å finne ut av dette. Vær neste halve dag og data om soloppgang, solnedgang og elevasjon fra Yr.no: https://api.met.no/ Strømforbruk fra Homeseer. Her har jeg enheter som logger forbruk, og med events og scripts i Homeseer mellomlagrer jeg informasjon i virtuelle devicer og lagrer daglig informasjon til CSV-filer. Disse CSV-filene benyttes som grunnlag for å beregne siste 30 dagers forbruk. Data fra eksterne API som bare trenger daglige oppdateringer blir cachet, slik at jeg ikke kaller disse API-ene mange ganger per dag. Kun Yr, havnivå og Tibberseer kalles hver time. Scriptet som gjør alt dette er per nå ganske tilpasset Homeseer og mitt oppsett der. Plan fremover nå er å oversette dette til Python slik at det er mer aktuelt å dele scriptet. Dersom noen lurer på noe spesifikt om bruk av API kan jeg delen denne delen av scriptet, kanskje i en annen diskusjon 🙂

Litt sent i denne tråden, men produktet er fremdeles relevant... Hvis noen er interessert har jeg laget en trådløs MQTT gateway for Housegard Origo røkvarslerne. Denne kan pushe notifikasjoner som ditt foretrukne hjemmeautomatiseringssystem enkelt kan plukke opp og sende videre til mobil, eller trigge andre aksjoner som blinking med lys etc etter smak og behag. Se https://github.com/fredilarsen/OrigoSmokeDetector Med en ESP8266 (jeg bruker den kompakte Wemos D1 mini) og en SRX882 RF receiver er det kjapt å lage en liten og svært billig enhet som plukker opp alarmer og sender en notifikasjon til en MQTT broker inneholdende ID-nummeret (1-255) for den detektoren som har utløst. Du trenger Arduino-programvaren for å programmere enheten. Disse røkvarslerne har vært gode og uten falske alarmer, så jeg kjøpte inn flere og laget gatewayen for å integrere dem i Home Assistant og få notifikasjoner på familiens mobiler. Et for meg langt mer tiltrekkende alternativ enn å kjøpe 10 nye og dyrere varslere, som kanskje ikke har et åpent grensesnitt men er avhengig av produsenten sin skyløsning.