stigvi

Jeg har hatt såpass mange problemer med kina-varer at jeg har bestemt meg for at nå er det slutt. Det koster mer hos Elfa-Distrelec, men det er verd det.

How Home Assistant plans to transition from an enthusiast platform to a mainstream consumer product. https://www.theverge.com/24135207/home-assistant-announces-open-home-foundation

Og status i juni er at dette har gått veldig bra. Jeg synes jeg har langt bedre kontroll med automasjoner enn med skript. Når jeg flyttet over skript for brytertrykk, så brukte jeg pyscript sine definisjoner av mqtt payload direkte i automasjonen. Dette ble gjort uten at jeg tenkte så mye på dette, men i ettertid så innser jeg at det er fryktelig tungvint når en skal sette opp nye brytere. En må da bruke et eller annet verktøy og analysere mqtt pakkene som kommer i fra zigbee2mqtt. Det må vel være enklere måter å gjøre det på? Og det er det. Zigbee2mqtt anbefaler å bruke device trigger i HA istedenfor mqtt triggere. Når en bruker device trigger, er egentlig det meste automatisk ferdiganalysert av HA. Det er bare å velge i fra en liste hvilken aksjon en skal trigge på. For bryter kan det feks være knapp 2 og "press" eller "release". Skal en bruke hvilken knapp en trykket på videre i automasjonen så er det bare å definere en trigger ID på den spesifikke knappen og bruke trigger ID til å teste på. Da slipper en å teste på en spesifikk payload i mqtt pakken. Så konklusjon er at brytere er veldig lett å sette opp i HA sin automasjon i forhold til fikling med mqtt pakker i pyscript. I HA sin automasjon trenger en ikke vite noe som helst om at dette kommer via mqtt.

Du kommer ikke i mål med standard bibliotek. Du må enten modifisere kildekode eller laste ned et 3. parts bibliotek. Under forutsetning av at din årsak til feil er det samme som mange andre har slitt med siste året............ Feilen gjelder forresten esp32. Har du noen esp8266 kort liggende så kan du jo sikkert prøve de med bedre lykke.

Noen tanker? Nei, ikke så mye annet enn at slike feil er kjedelige å oppleve. Men hva med å ta utgangspunkt i faktiske opplysninger som at cpu temperatur var høy og minne var brukt max, og så lage en varsling på dette. Da slipper du i allefall at dette pågår i dagesvis uten at du merker det.

Hvis en kjører HA fra et minnekort på en Raspberry Pi så er en fordel at en får flyttet vekk fra minnekortet den prosessen som gjør flest skriveoperasjoner.

https://github.com/esphome/issues/issues/4543 https://github.com/esphome/issues/issues/3909 Det er vistnok et problem med et bibliotek i arduino og det finnes noen løsninger.

Vil bare nevne, for de som ikke har fått det med seg, at Synology slapp en oppdatering til MariaDB i går. For min del har databaseoperasjoner i Home Assistant hatt en enorm forbedring. Tidligere har uthenting av historikk tatt flere sekunder. Skifte av måned i energiforbruk feks. Nå er det uten ventetid. Ytelsen har muligens forbedret seg 10 eller 20 gangen.

Veldig lite sannsynlig. MQTT er bunnsolid på Home Assistant Da anbefaler jeg å åpne opp automasjonen og bruke "Spor" som du finner som et valg øverst. Den forteller litt om hva som skjer i en automasjon.

Tenker du da på det estetiske? I så fall finnes det små som knapt er større enn et fingerbøl. Jeg har en del kreative plasseringer av de der jeg vil at de ikke skal være synlige. Andre steder er det mindre viktig som feks bod, garasje, kontor osv. Jeg kunne ikke klart meg uten disse. Det er blitt utrolig behagelig at lyset slår seg på uten å måtte trykke på noe.

Som engelskmennene sier - I rest my case 😉 Dessverre er lithium-ion dårlige til å takle lav batterispenning. Det blir ekstra "ille" når de er slik over lang tid. En telefon eller en bil lader en som regel innenfor noen timer.

Jeg ser på mine IKEA rullegardiner at de kun sender oppdaterer batteristatus når de "ruller" inn eller ut. Men det skal være mulig å sette opp rapporteringsinterval i zigbee, men vet ikke hvordan det gjøres i Homey. Tips: Hvis du vil at batteriene skal vare i mange år så er det lurt å ikke slippe de under 40%. Det gjelder alle lithium-ion batterier, enten det er i rullegardin, kamera, mobiltelefon eller bil.

Ingen anelse om det finnes noe med zigbee. Med esphome gjør du det lett slik: - switch.turn_on: gararasjeport_opp - delay: 0.5s - switch.turn_off: gararasjeport_opp

Egentlig ikke. Om morgenen foretrekker kona å trykke på en Zigbee knapp i garasjen som åpner og lukker porten med en liten forsinkelse. Akkurat nok til å rygge ut bilen. Og på vei hjem "tæpper" hun mobilen på en NFC brikke som er skjult under dashbord. Garasjens fjernkontroll blir ikke brukt.

En stakkarslig Zigbee sensor vil vel fungerer like bra her som alle andre steder, så lenge magneten aktiverer reed-kontakten som disse har.

Jeg lagde all varmestyring i pyscript som en app. I ettertid har jeg flyttet det meste over til automasjoner, men varmestyringen er såpass komplisert at den er fortsatt i pyscript som en app. Som du ser av konfigurasjonen nedenfor, er det en lang rekke med innganger for å avgjøre om en climate skal være i "borte", "øko" eller "komfort". Tilsvarende er det for alle andre rom og gulv. Når det gjelder VVB så har jeg en automasjon som tester på tilstander. Jeg bruker template sensorer til å sette tilstander som jeg tester eller trigger på i automasjoner. Lys og gardiner er i samme situasjon som varme, jeg har app'er i pyscript som håndterer det. Det du har planlagt med å deaktivere og aktivere automasjoner etter behov, gjør jeg ikke. Alle mine automasjoner er aktive og de har fornuftige triggere og betingelser basert på at de er aktive hele tiden. Mine tilstander er hjemme, borte, besøk og ferie. Automasjoner og app'er i pyscript har tester på disse der det er aktuelt. varme: - output: climate.stue_og_kjokken delay: 1 delay_on: 0 away_mode: away prisforhold: sensor.peak_forhold prisforholdgrense: 106 nattsenkning_h: 3 nattsenkning_l: 1 default_mode: eco inputs: input1: entity_id: sensor.regulator_energy_usage below: 40 mode: away processing: stop input2: entity_id: binary_sensor.vindu_2_etg_a state: "on" mode: away processing: stop input3: entity_id: binary_sensor.vindu_2_etg_b state: "on" mode: away processing: stop input7: entity_id: input_boolean.oppvarming_med_gass_eller_ved state: "on" mode: away processing: stop input8: entity_id: sensor.pricelevel state: "EXTREMELY_EXPENSIVE" mode: away processing: stop input9: entity_id: input_select.sett_opp_temp_ved_besok state: "Overnattingsbesøk" mode: add input10: entity_id: input_select.sett_opp_temp_ved_besok state: "Dagsbesøk" mode: add input11: entity_id: binary_sensor.noen_er_hjemme state: "on" mode: add input12: entity_id: input_boolean.sleeptime state: "on" mode: eco input13: entity_id: binary_sensor.soonsleeptime state: "on" mode: eco input14: entity_id: binary_sensor.preheat_day state: "on" mode: add input15: entity_id: binary_sensor.preheat_night_weekend state: "on" mode: add input19: entity_id: sensor.pricelevel state: "VERY_EXPENSIVE" mode: dec input_heat_limit: entity_id: binary_sensor.heatlimit_morning state: "on" mode: eco input20: entity_id: binary_sensor.preheat_night_home_office state: "on" mode: add input_ferie1: entity_id: binary_sensor.soon_travelling state: "on" mode: away input_ferie2: entity_id: calendar.ferie state: "on" mode: away input_ferie3: entity_id: binary_sensor.soon_not_travelling_room state: "on" mode: comfort input_soon_home: entity_id: input_boolean.soonhome state: "on" mode: add

Dette, https://github.com/Koenkk/zigbee-herdsman-converters/pull/7470 , er et eksempel på hva jeg mener. En endring som ble tatt inn bare minutter før en release. Den kan umulig ha vært testet eller vurdert særlig grundig.

Jeg har full forståelse for at det ikke er lett å teste. Men samtidig er jeg overrasket enkelte ganger over endringer de gjør uten å tenke på risiko og konsekvenser. Uten at jeg skal påstå noe så har jeg allikevel gjort meg noen tanker. Og det er at det er noen aktive i det prosjektet som mangler erfaring og ser på zigbee2mqtt som sin egen lille sandkasse. Samtidig som de som holder i trådene er litt for lite restriktive. Det er jo et problem med mange åpne kildekode prosjekter. Men de håndterer det på forskjellige måter og i zigbee2mqtt synes jeg de er for slappe når en tenker på hvor mange som bruker den og hvilke konsekvenser en feil får.

Zigbee2mqtt slapp mai utgaven 1. mai og det virker som om den inneholder mye feil. Umiddelbart begynte det å tikke inn feilrapporter på github. Så da kan en jo begynne å lure. Tester de ikke før de slipper en ny versjon? Har de ikke lagd automatiserte tester? Github har også over 1000 registrerte og åpne problemer med zigbee2mqtt. Jeg er i allefall ekstremt forsiktig med å oppdatere zigbee2mqtt. Jeg sjekker de feilene som blir rapportert og tar en vurdering etter en uke eller to om det er trygt å oppdatere. Jeg har et stabilt system i dag så det er heller ikke spesielt viktig å oppdatere, men samtidig er det greit å ikke havne alt for langt på etterskudd også. Hva gjør dere andre mht zigbee2mqtt?

Offisiell support, ja, det må du.

Tror du ikke det kunne være et svar relatert til dette, "og lurer på hvordan en kjøper som ikke har smarthussystem kan styre den" ?

Vel, det er jo nettopp det de har, som nevnt i denne tråden.

Det tror jeg. Hvorfor blander du inn zigbee? Ja, jeg kan i teorien laste ned kildekoden og modifisere den. I praksis er det en del jobb med dette. En skal jo forstå hva som foregår i denne koden. Og som nevnt, de har lagt inn mye som har med dette web-grensesnittet å gjøre. Fordelen med esphome er at det er brukervennlig og noe jeg kjenner. Jeg holder en knapp på at det er den veien som er lettest å gå.

Jeg har allerede en esp32 tilkoblet HAN som går på strøm så dette er ikke en aktuell problemstilling for meg. Men takk for svar. Som nevnt ovenfor, jeg ønsker å prosessere data i esp32. Det kan feks være å integrere opp energi ut i fra effekt som sendes på HAN porten hvert 2,5s. Slikt er ikke mulig med pulse. Da må en i så fall integrere opp i Home Assistant og da blir resultatet feil hver gang en tar en omstart på Home Assistant.

Home Assistant virker å være populært og den har også støtte for KNX https://www.home-assistant.io/integrations/knx/