stigvi

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/

En grunn til at EspHome frister er at jeg vil kjøre min egen behandling av data på esp32. Og med EspHome er det lett å oppdatere kode OTA. Støtter Silicon Labs dev kit det? Eller må du oppdatere kode ved hjelp av kabel?

Jeg har en slik. Men det virker som om de som lager den er mer opptatt av å lage et fancy web grensesnitt enn å få basisfunksjonalitet til å virke. Jeg kunne installert en gammel versjon av amsleser som jeg vet virket, men funderer også på å lage noe selv. Får se hva jeg gjør til høsten når det er kjekkere å sitte inne å mekke sammen noe enn å være ute og nyte sommeren.

Jeg liker å få varsel på telefon når noe skjer i HA som jeg bør gjøre noe med. Dette har jeg forsåvidt fint fått til i pyscript, men jeg synes det har vært litt dillete å sette opp fordi det ikke alltid er like lett å vite hva triggere inneholder av data. Nå som jeg har gått over til automasjoner i HA er det mye som er langt lettere å få til med en, etter min mening, god visuell editor. Her er et eksempel. I den visuelle editoren ser det slik ut: Koden for dette er vist nederst. Det som skjer er at når stråleovn på terrasse har stått på i 33 minutter og 10 sekunder så sendes et varsel til mobiltelefon Så venter automasjonen i opp til 6 timer på svar. Hvis ovn slås av før dette så forsvinner melding på telefon. Den forsvinner også hvis 6 timer går uten svar. Trykker jeg på "Nei" så slås ovn av. Tidligere hadde jeg dette i flere funksjoner i pyscript. Når jeg flyttet det over til HA automasjon så ble det laget flere automasjoner, en for å sende melding og en annen som ventet på svar fra telefon. I dag fant jeg ut jeg ville samle dette til en enkel automasjon som både sender melding og som venter på svar. Fordelen er å samle dette. Bakdelen er at en vent-operasjon ikke overlever en omstart av HA. Det klarer jeg å leve med på akkurat denne for stråleovnen, men i andre sammenhenger er det jo litt dumt. - id: '1712999347947' alias: Spør om terrassevarmer skal slås av description: '' trigger: - platform: state entity_id: - switch.terrassevarmer from: 'off' to: 'on' for: hours: 0 minutes: 33 seconds: 10 condition: [] action: - service: notify.mobile_app_pixel_7 metadata: {} data: message: Skal den fortsatt stå på? title: Terrassevarmer data: tag: terrassevarmer actions: - action: NO_ACTION_TERRASSEVARMER title: Ja - action: SWITCH_OFF_TERRASSEVARMER title: Nei - wait_for_trigger: - platform: event event_type: mobile_app_notification_action event_data: action: SWITCH_OFF_TERRASSEVARMER - platform: event event_type: mobile_app_notification_action event_data: action: NO_ACTION_TERRASSEVARMER - platform: state entity_id: - switch.terrassevarmer from: 'on' to: 'off' continue_on_timeout: true timeout: hours: 6 minutes: 0 seconds: 0 milliseconds: 0 - choose: - conditions: - condition: template value_template: >- {{ wait.trigger == None or (wait.trigger.platform == 'state' and wait.trigger.to_state.state == 'off')}} sequence: - service: notify.mobile_app_pixel_7 metadata: {} data: message: clear_notification data: tag: terrassevarmer - conditions: - condition: template value_template: >- {{ wait.trigger.platform == 'event' and wait.trigger.event.data.action == 'SWITCH_OFF_TERRASSEVARMER' }} sequence: - service: switch.turn_off metadata: {} data: {} target: entity_id: switch.terrassevarmer mode: restart

Men hvis dette er en offisiell plugin fra Homeseer, vil den ikke da oppdateres kun når denne plugin oppdateres?

Er det noen som har prøvd denne på norske strømmålere? https://esphome.io/components/sensor/dsmr Ser at noen stikkprøver på obis koder stemmer med de norske...... https://github.com/glmnet/arduino-dsmr/blob/master/src/dsmr/fields.h