RVM

Det er jo en nokså enkel automasjon, så det er ikke så mye som kan feile. Ville ha gått inn på show trace ("vis sporing"?) for automasjonene for å feilsøke, der får du litt mer historikk for hvert steg av automasjonen hver gang den blir triggered. Hva slags smartplugg er det?

Jeg bruker også pyscript til omtrent samme formål, og essensen hos meg er: [...] today = [e for e in pyscript.electricity_prices.today if type(e) is float] # Remove any Nones today_dict = {} for i, v in enumerate(today): today_dict[i] = v today_prices_sorted_dict = {k: v for k, v in sorted(today_dict.items(), key=lambda item: item[1])} today_prices_sorted_list = [k for k,v in today_prices_sorted_dict.items()] state.setattr("pyscript.electricity_prices.today_hours_by_price_dict", today_prices_sorted_dict) state.setattr("pyscript.electricity_prices.today_hours_by_price_list", today_prices_sorted_list) [...] Så bruker jeg de sorterte dict- eller list-objektene avhengig av hva jeg vil oppnå.

Jepp, det viser bare at automasjonen ikke er deaktivert. Automasjoner som objekt er omtrent som en switch, og kan skrus av og på med sine egne services ("automation.toggle" osv.). Ser ut som automasjonen virker ja, men det kan bli en del støy i logbook når man restarter HA ofte eller enheter dropper ut og inn.

Ja, hvis du bare vil finne de rimeligste timene er det sikkert nøyaktig nok. Og så må du kanskje legge inn et forbehold hvis det blir skikkelig kaldt ute, regner ikke med COP blir negativ...

Hvis du kan leve med antagelsen om 70 % luftfuktighet og 26°C bassengtemperatur, har du jo grafen i databladet. Med det blotte øyet ser det ut som at COP(T) ≈ 3,2+0,09*T. Deler du strømprisene på COP time-for-time for inneværende døgn, har du pris per kWh varme. Håper det er noenlunde rett fram å sortere timene etter pris i Homey.

Over HAN-porten, ja. Men ikke like hyppig over RF til nettselskapet, såvidt jeg vet. Men det må som sagt bare være en konfigurasjonssak.

Regner med det Stigvi tenker på er at smartmålerne i dag er satt opp til å sende data over forrige time noen sekunder etter at den er fullført, men regner med det ikke er en hardware-messig begrensning i at de kan rapportere oftere om man ville konfigurere dem til det.

Haha! Det er greit, jeg får gå tilbake til tegnebrettet 😀 Edit: Mente ikke noe mer komplisert enn at effektleddet kunne avhenge av timesforbruket. Hos Lnett blir effektleddet ca. 48 øre/kWh på dagtid, og 40 øre natt/helg etter 1. juli. Mitt forslag var så enkelt som at effektleddet kunne vært f.eks. 10 øre/kWh for hver time du bruker 1 kWh, 20 øre/kWh for 2 kWh, ..., 50 øre/kWh for hver time med 5 kWh, ..., 100 øre/kWh for hver time med 10 kWh osv. for å ta noen tilfeldige tall. Forutsigbart for sluttkunden, men kanskje ikke forutsigbart nok for netteier.

Jeg forstår at de må finne en middelvei som er lett å forstå og forholde seg til for folk flest, men jeg syns de har bommet litt med forenklingen. Det hadde vært mye lettere å forholde seg til et konstant fastledd, og et variabelt effektledd som skalerte lineært med timesforbruk. Effektleddet over en måned hadde da blitt tidsintegralet av p(t)*k(p), der p(t) er forbruket hver time, og k(p) er kostnaden som funksjon av effekt. Da er det så enkelt som at du belønnes jo mer du klarer å spre ut forbruket, og blir kun straffet for hver enkelttime du har "overforbruk". Veldig forutsigbart. Nå blir fastleddet variabelt og effektleddet konstant (med unntak av dag/natt/helg variasjonen på 8 øre), forstå det den som kan...

Ser ut som jeg må trikse mer med gains, men må nok leve med at regulatoren ikke nødvendigvis går mot en steady state så lenge jeg ikke kan gi trinnløst pådrag (bare av/på laster). Tenker å fortsette med en soft PI kontroller for å unngå veldig mye switching, og heller ha litt headroom mot effekttrinnsgrensa.

Nettopp, premissene for optimaliseringsproblemet er ukjent på forhånd.

Jeg har vært innom samme tankerekke som deg, og syns det er ufint at systemet har blitt et optimaliseringsproblem som er uløselig uten en matematisk modell over energibehov som funksjon av tid. Hvis du har elbiler i flertall, tror jeg ikke det kommer til å lønne seg å konsekvent styre mot nederste effekttrinn, av årsakene du nevner over. Jeg kjører fortsatt på fossilt (og betaler i dyre dommer for det), og bikker 5 kWh omtrent 1-3 ganger i måneden. Da skal det ikke mye triksing til med gulvvarme/VVB for å klare å komme under grensa. I ditt tilfelle ville jeg også valgt å regulere mot f.eks. 10 kWh i stedet, så lenge døgnvariasjonen på strømprisene fortsetter.

Jeg forsto ikke helt hvorfor du dro inn enda et IIR lavpassfilter her, så jeg fjernet det hos meg og justerte ned gains for å kompensere. Tenker det holder å filtrere effekt og ekstrapolert timesforbruk for mitt bruk.

Jeg har lagt merke til en "uvane" jeg har når jeg lager automasjoner, og vil høre om det er noen som kjenner seg igjen. Jeg ender ofte opp med å måtte duplisere alle conditions i automasjonene som triggers, slik at jeg er sikker på at automasjonene trigger uavhengig av rekkefølge. Enkelt eksempel fra nå nettopp med nytt tariffsystem for nettleie: Jeg vil varsles om ekstrapolert timesforbruk nærmer seg 5 kWh, men bare om det er mindre enn 30 minutter igjen av timen. Begge deler kan jo inntreffe først, så for å være sikker på at den trigger ender jeg opp med triggers som conditions og motsatt: trigger: - platform: numeric_state entity_id: pyscript.electricity_estimated_hour_consumption above: '4.75' - platform: template value_template: '{{ now().minute > 30}}' condition: - condition: numeric_state entity_id: pyscript.electricity_estimated_hour_consumption above: '4.75' - condition: template value_template: '{{ now().minute > 30}}' Dette mønsteret går igjen i sikkert 10-15 automasjoner hos meg, uavhengig av om de er i yaml eller pyscript. Det er strengt tatt ikke et problem så lenge det funker, men det blir ofte litt rotete for mer avanserte automasjoner. Jeg er sikkert litt miljøskadd av å tenke sekvensielt fra PLS-programmering i structured text, mens Home Assistant er mer event-basert. Noen som har vært fastlåst i samme mønster og klart å bryte ut av det? Har Home Assistant en mer elegant løsning for å oppnå samme funksjonalitet?

@stigvi, jeg gikk i gang med å skamløst kopiere pyscript-koden din over, men har ikke lagt inn terskelverdier for å slå av forbrukere ennå. Ser umiddelbart at PID-regulatoren kommer til å reagere litt vel hardt for min smak, og tipper det er på grunn av verdien for derivatleddet. Alle kontrollerbare laster kommer til å slå seg av hver gang VVB slår inn (hopp på 3 kW). Hvordan gikk du fram for å stille inn gains til PID-regulatoren din? Tror jeg kommer til å gå for en mykere PI-regulator (uten D-ledd). Husker du har en SSR-løsning til din VVB, så du får nok styrt det mer trinnløst enn meg. Liker heller ikke hoppene i estimert timesforbruk fra Tibber når man trekker mye strøm akkurat i timeskiftet, så jeg legger også på en lineært økende glattekonstant av estimatet de første 15 minuttene hver time. Da får jeg en nokså myk overgang i estimert timesforbruk mellom hver time.

Her også, men appen får tydeligvis kontakt.

Min elektriker valgte, etter å ha ringt kontoret for råd, å sette inn en "servicebryter" i sikringsskapet rett ved siden av sikringen for å være sikker på å være innafor regelverket. Fibaro Dimmer 2 koblet til LED-lampe uten utskiftbar pære. Jeg har enn så lenge godt med plass i sikringsskapet, så jeg kranglet ikke.

Jeg har én sånn HZC dimmer, og den fungerer bra så langt gjennom Zigbee2MQTT (der dukker den opp som "Eco-Dim.07/Eco-Dim.10"). Den likte ikke helt lyspærer med for lav effekt (2-3 W), så jeg måtte bytte pæra også. Men den virker veldig billig, og jeg er ikke sikker på om jeg ville hatt den på ei lampe der ungene kunne ha lekt med den. Enn så lenge får den leve et beskytta liv høyt oppe i ei bokhylle, den er tross alt CE-merka og solgt gjennom norsk distributør, uten at det trenger å bety all verden.

Har ikke prøvd Ubuntu Desktop på sikkert 10 år (jeg bruker som sagt Ubuntu Server, så "brukergrensesnittet" mitt er SSH gjennom MobaXterm), men syns jo Gnome 42 som vel brukes i Ubuntu Desktop 22.04 ser lovende ut. Har såvidt prøvd Linux Mint med Cinnamon, og det virka også bra. Ja, har ikke prøvd å oppgradere fra en LTS til neste LTS ennå, håper det går smertefritt. Bortsett fra Docker og Docker-compose tror jeg den eneste pakken jeg måtte installere selv var zip, og jeg syns det var rart det ikke var en del av basis-installasjonen ja.

Er det noen spesiell grunn til at folk velger Debian som OS å kjøre docker på? Gikk selv for Ubuntu Server til min NUC for noen år siden, uten at det var en spesielt nøye overveid beslutning den gang. Har nå fungert greit likevel, men blir nysgjerrig når "alle andre" velger Debian.

Her er første iterasjon av mitt prøveprosjekt med Pyscript: https://pastebin.com/sdS1VtZ0 Syns også mye av styrken med Pyscript er at man kan eksperimentere i sanntid vha. Jupyter. Når det sitter litt mer i fingrene tenker jeg å gå i gang med en skikkelig state machine for temperaturstyring, som ivaretar auto/manuell, hjemme/borte status, nattsenking, varmepumpe oppvarming/kjøling, settpunkt for varmegjenvinning i balansert ventilasjon, gulvvarme, osv.

Enig. Jeg kunne nok gjort det samme med tradisjonelle automasjoner, men ville fort trengt 5-6 automasjoner for ett rom for å erstatte logikken som jeg har i ei enkel lettlest .py fil. Det blir det fort mange automasjoner av for et helt hus.

Har eksperimentert med Pyscript i Home Assistant for å kunne implementere auto/manuell modus på diverse enheter. Tanken er at det skal gjøre hjemmeautomasjonen litt mer gjeste- og familievennlig. Først ut er lys på badet. Fungerer omtrent slik: Bevegelsesdeteksjon på badet OG auto modus -> Skru på lys, med lysstyrke som funksjon av solhøyde. Ingen bevegelse på 30 minutter OG auto modus -> Skru av lys Bruk av fysisk lysbryter -> Gå over til manuell modus Midnatt -> Gå over til auto modus. Kan også settes tilbake til auto med en toggle i interfacet. Lysstyrkefunksjonen gir max lysstyrke ved solhøyde > 0°, min lysstyrke ved solhøyde < -6°, og kontinuerlig dimming av lyset for -6° < solhøyde < 0°. Veldig fornøyd med Pyscript så langt, jeg synes i alle fall det virker enklere å implementere litt mer avanserte automasjoner i Pyscript enn om jeg skulle gjort det samme med f.eks. Jinja2 templating. Kunne selvfølgelig brukt Node-RED, men tror jeg foretrekker tekstbasert koding.

Vi fikk installert varmepumpe nylig, og da ble det en Daikin Perfera (innedel: FVXM35A, utedel: RXM35R) utelukkende basert på WAF. Tenkte denne skulle være enkel å få opp og gå i Home Assistant med Daikin-integrasjonen, men fant ut etter installasjon at det ikke var helt rett fram på grunn av nye WiFi-adaptere (BRP069C4x) og skyløsning hos Daikin som ikke er støttet av den offisielle integrasjonen. Var innom tanken på å få satt inn en Modbus gateway mot S21-porten på innedelen, men før jeg kom så langt (takk og pris!) var det noen som hadde laget en custom component for Daikin Residential Controller: https://github.com/rospogrigio/daikin_residential . Prosjektet er ennå nokså ferskt, men det funker allerede tålelig bra for min bruk. Jeg har heller ingen andre varmepumpereferanser, men syns så langt den fungerer bra på både kjøling og oppvarming.