All aktivitet

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

Jeg gjør det samme som du. Viktigst med et stabilt system.

Hei, Samme her. Byttet til ny dimmer forrige helg. Foreløpig ser det veldig bra ut, men tenkte å drøye en liten uke til før jeg oppdaterte forumet - for å være helt sikker. 🙂 -MariusL

Hei! Jeg har en HA installasjon som, basert på ulike statuser, aktiverer / deaktivere ulike automasjoner og slår på/av ulike varslinger og releer. Strever litt med å finne en god metode for å sette opp dette, som gir meg god oversikt og sikre at det er enkelt å vedlikeholde. Et alternativ er å legge all logikk inn i Automations knyttet opp til drop-down list i "Helper", men det gjør hver automasjon unødvendig komplisert. Behov: - Aktivere / deaktivere automasjoner basert på statuser - Når en status endres skal ulike brytere aktiveres / deaktiveres - Få god oversikt over hvilke automasjoner som aktiveres / deaktiveres ved hvilke statuser - Sikre at statusendringene er "robuste nok", feks når varmtvannsberederen er aktivert (gjennom en automasjon hvor den er aktiv bare på de 8 billigste strømtimene), og status settes til "borte" deaktivers automasjonen. Da må også switch til VVB deaktiveres i tilfelle VVB-switch er aktiv når automasjonen deaktiveres. Hvordan har dere andre løst dette? Det jeg gjerne skulle hatt tips om er hvilke funksjonsområder som burde brukes her og hvordan disse burde samspille. Feks, templates i configuration.yaml, scence, automations etc.

Jeg har nå fått nye dimmere fra MicroMatic. De gamle hadde firmware 0x00000036. De nye har 0x0000003a. Etter byttet har jeg ikke opplevd problemet med at lyset har blitt skrudd av og på igjen, slik det tidvis var med de gamle. Ut fra den informasjonen jeg fikk kan de ikke oppgraderes over Zigbee.

Da jeg for en god tid tilbake oppgraderte til 1.34.0 begynte der å dukke opp en masse feilmeldinger i UI uten at de ser ut til å påvirke noe stort. OWON CB432 sluttet samtidig å oppdatere energidata men de har jeg funnet en hack på slik at de gjør jobben nå (et shellscript henter data hvert 10 sek). Har prøvd å oppgradere uten suksess... Husker ikke nøyaktig hva som skjedde men den oppgraderte versjonen virket i alle fall ikke... Zigbee2mqtt er jo en super byggeklosse i et hjemmeautomasjonssystem men den MÅ jo virke for at det skal være noe stas... Har også en 1.36.1 installasjon som ikke oppdaterer "Last seen". Litt småirriterende men ikke noe kritisk, virker fint ellers...

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.

Eg fekk problemer med versjonen etter 1.35.2 så eg gjekk tilbake til 1.35.2 og kjører på den fortsatt 🙂 Veit ikkje hvor mange som jobber på Zigbee2mqtt men er nok vanskelig å få testet på alle kombinasjoner av hardware/software som er der ute...

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?

Hei alle sammen, i det siste er jeg interessert i å studere og utvide kunnskapen min innen hele feltet fornybar energi. Jeg leter etter et fjernundervisningsalternativ, og jeg har sett flere komplementære kurs om emnet på et universitet som heter TECH, og det har fanget oppmerksomheten min. Jeg liker spesielt godt at de er nettbaserte og ikke har faste timeplaner. Dette ville være til stor hjelp for meg. Er det noen som har erfaring med dette universitetet, og kan du fortelle meg om det er verdt det for de som jobber ved siden av studiene? Tusen takk skal dere ha.

Googlet raskt dette så ein gang og er du uheldig to ganger, eg tenker for mitt eget regnskap at dette er noko eg fører opp når det eventuelt skjer 🙂

Nei, jeg har ikke tatt med vedlikeholdskostnader. Solcellene som sådan trenger ikke annet en en vask i ny og ne for å holde effekten oppe men det er ikke påkrevd for levetiden sin del. At en MC4 connector kanskje må skiftes en eller annen gang kan vel skje men det vil regnes som reparasjon og ikke vedlikehold. Vil nok gå over og teite alle skruforbindelser en gang, det skal holde for all evighet. Inverter skal vel litt til at varer lengre enn 10 år men det vil nå vise seg. Det er en relativt liten kostnad i den store sammenhengen. Der er jo litt andre småting med begrenset levetid som RPi og ESP32 men heller ikke her noe vedlikehold annet enn en backup i ny og ne... Nå er det heller ikke noe poeng for meg at regnskapet skal være nøyaktig og riktig men det er nå litt gøy å se hvilken vei tallene peker og ikke minst akkurat nå at utvidelsen av solcellene i stedet for reparasjon av varmepumpe viser seg å være riktig (og kanskje til og med riktigere enn antatt).

Hei Svein, har du lagt inn vedlikeholdskostnader i kalkylen, antar at det bør være relevant. Jeg vet at et solcelleanlegg har nesten ingen vedlikeholdskostnader i løpet av levetiden, og anlegget har en levetid mellom 25 og 30 år. Skal man være helt sikker på at regnestykket blir så riktig som det er mulig å anslå, kan man legge inn at man må bytte inverteren to ganger i løpet av levetiden. Hva tenker du om dette? /Helge

Looking good... Men der var noe uventet og litt heftig snøvær i begynnelsen av måneden... Etter jeg la inn kostnadene med solcelleutvidelsen flyttet D-Dagen (datoen anlegget vil være nedbetalt) seg fram til 28.02.2031 men er allerede nå tilbake til 20.01.2031. Skal bli spennende å se hvor datoen havner om noen måneder... Selv i dag, med "gratis" strøm som koster rundt 75 øre inkl avgifter og slikt, vil nok inntjeningen bli ganske akseptabel.

Du la den altså ikke til der den skulle være? Kanskje du må heale noden eller noe sånn da?

Ok, takker. Fikk det vekk, og lagt inn DanaLock inn i min Homey 🙂 Men når jeg har satt opp Danalock i garasje døren igjen, skal teste den via Homey så får jeg "time out". Kan det ha noe å si at Secure er satt til S2?(Access) i Advanceed Setting? Har DanaLock V3 Z-Wave, med siste firmware oppdatering, og Homey er og oppdatert.

Ja er oftest passeringer tror jeg. I alle fall dukker de opp i Homely app men ikke i HA. Skjer egentlig ganske ofte, har kikket litt på dette i dag.

Uten at jeg har oppdaget dette selv, er det typisk korte aktiviteter? Noen api'er har ofte en delay på status-oppdateringer i sanntid, så er ikke umulig at det er en (kortvarig) forsinkelse, som fjerner aktiviteten før den sendes på homely sin side.

Må jo se litt på hva alternativene koster nå også. Men joja en Namron ZigBee koster jo 600 ny så kanskje jeg er litt for høyt. Men Takk for tips, da senker jeg prisen 🙂

Har disse selv, og hatt de siden 2019 ca. Nypris var rundt 1000kr den gang. Hadde nok ikke siktet høyere enn 100-200kr per termostat om jeg skulle solgt mine. Mulig jeg bommer på markedet 🙂

For høy? Hva synes du er riktig pris da?

Hei igjen, jeg ser at i homely-app så vises det aktivitet på bevegelsesensor som ikke er rapportert i HA via homely-mqtt, men jeg har ikke sett i loggene enda. Flere som opplever dette? Jeg kan bidra med logger ønskelig, har forsøkt restart av både proxmox host, portainer, HA VM osv. Takk takk 🙂

Fantastipris eller?

https://www.finn.no/bap/forsale/ad.html?finnkode=350706262 Bytter til ZigBee og selger mine gamle Z-Wave Thermostater. Dette er av de første Z-wave termostatene (Z-TRM1) som kom på det Norske markedet men funker helt fint. Så lenge de kan skru seg av og på over Z-wave kan jo all funksjonalitet lages i SW 🙂