RVM

Det funka bra det, har oppdatert scriptet over.

Synes også det har skjedd veldig mye i Home Assistant de siste par årene for å gjøre det lettvint å komme i gang, samtidig som man har (uendelig?) fleksibilitet dersom man ønsker det. Men vi er vel alle partiske i favør av vårt eget system her inne Jeg ville ventet med Z-wave hvis jeg var deg, det kan jo hende at Zigbee dekker dine behov. Det er gatewayen som må være kompatibel med enhetene (Hue, Trådfri, ...). Zigbee2MQTT støtter det meste, du finner ei komplett liste her: https://www.zigbee2mqtt.io/supported-devices/ Og ja, det går direkte via f.eks. Sonoff Zigbee 3.0 uten en hub fra IKEA/Phillips.

Aha, det hadde jeg ikke fanga opp, så ingenting om det i dokumentasjon. Skal prøve seinere Edit: Fant det nå...

Tenkte jeg skulle poste min variant av @stigvisin PID-kontroller for mangfoldets skyld. I korte trekk har jeg en skrevet en klasse som jeg har i /pyscript/modules som ivaretar alt av terskelverdier for av/på og timere. Opplever i blant at PID-regulatoren er litt vel trigger-happy i begynnelsen av timen siden timeestimatet er veldig følsomt for (filtrert) sanntidseffekt etter timeskift, så for laster som jeg ikke vil skru av og på så ofte venter jeg til slutten av timen (f.eks. minutt 40), og har timeout til timen er omme. from datetime import datetime registered_triggers = [] class Device(): def __init__(self, threshold, state_entity, timer_entity, timeout, earliest_shutoff = 0): self.state_entity = state_entity self.timer_entity = timer_entity self.timeout = timeout # Timeout in seconds. If -1, timeout until next hour self.earliest_shutoff = earliest_shutoff # Minute of earliest shutoff state.setattr(f"{self.state_entity}.threshold", threshold) state.setattr(f"{self.state_entity}.timeout", timeout) state.setattr(f"{self.state_entity}.earliest_shutoff", earliest_shutoff) @state_trigger(f"{self.timer_entity}") def check_timer(value = None): '''Turn back on when timer elapsed after upcrossing threshold''' thr = state.getattr(self.state_entity)["threshold"] s = state.get(self.state_entity) t = state.get(self.timer_entity) c = float(pyscript.regulator_electric_power) if c > thr and t == 'idle' and s == 'off': self.turn_on() registered_triggers.append(check_timer) def turn_on(self): state.set(self.state_entity, "on") def turn_off(self): state.set(self.state_entity, "off") def check_threshold(self): thr = state.getattr(self.state_entity)["threshold"] s = state.get(self.state_entity) c = float(pyscript.regulator_electric_power) t = state.get(self.timer_entity) # Turn device off if c <= thr and s == 'on' and self.check_earliest_shutoff(): self.turn_off() if self.timeout != 0: self.start_timer() # Turn device back on if above threshold and timer elapsed if c > thr and t == 'idle' and s == 'off': self.turn_on() def start_timer(self): t = self.timeout if t == -1: # Timeout rest of hour t = self.calculate_timeout_until_next_hour() timer.start(entity_id = self.timer_entity, duration = t) def check_earliest_shutoff(self): '''Check if minute count is high enough to turn off device''' m = datetime.now().minute return m >= self.earliest_shutoff def calculate_timeout_until_next_hour(self): '''For devices with timeout == -1''' now = datetime.now() m, s = now. minute, now.second return 3600 - (m*60+s) Så har jeg et python-script der jeg instansierer Device-objektene og oppdaterer regulatoren. Klipper ned litt her for å unngå unødvendig repetisjon: # [...Setup of simple_pid...] laundry = Device(threshold = 0.9, state_entity="pyscript.laundry_floor_pid_output", timer_entity="timer.laundry_floor_timer", timeout = 5*60) # [...repeat for other devices...] @state_trigger("pyscript.electricity_estimated_hour_consumption") def update_regulator(): global pid global laundry, toilet, bath, entrance, dehumidifier, water_heater last_c = float(pyscript.regulator_electric_power) c = pid(float(pyscript.electricity_estimated_hour_consumption)) if round(c, 2) != last_c: pyscript.regulator_electric_power.old = last_c pyscript.regulator_electric_power = round(c, 2) laundry.check_threshold() # [...repeat for other devices...] Dessverre støtter ikke Pyscript @state_trigger inni en klasse ennå såvidt jeg vet, så @state_trigger(laundry.timer_entity) må dessverre gjentas for hver timer utenfor klassen som vist over. "Outputen" fra alt dette er egentlig state_entity (altså pyscript.laundry_floor_pid_output), som jeg bruker der jeg ivaretar andre betingelser for av/på (basert på strømpris osv.)

Det gir mening, PB står ofte for pushbutton.

Jeg brukte home-feed-card i kombinasjon med persistent notifications for å lage en slags alarmliste à la SCADA-systemet på jobb, men jeg tok det bort da det gikk opp for meg at jeg ikke orka å følge med på det i praksis (notify til mobilen var enklere). https://github.com/gadgetchnnel/lovelace-home-feed-card

Du har ikke nevnt Docker ennå, så jeg bare nevner det i tilfelle det er den brikken du trenger for å forstå hvordan ting kan henge sammen. Håper ikke det bare bidrar til forvirring Et vanlig oppsett er å ha Home Assistant eller Node-red i én docker container, og en container hver for f.eks. Mosquitto, Zwavejs2MQTT, Zigbee2MQTT osv. Da lever hver tjeneste i sitt eget lukkede miljø på samme datamaskin, og er uavhengig av alle de andre tjenestene. Home Assistant / Node-Red får da alle signalene inn over enten en websocket eller MQTT klient. Det er veldig fleksibelt, men ikke nødvendigvis nybegynner-vennlig. Den mest brukervennlige varianten av Home Assistant (Home Assistant OS eller Supervised) håndterer Docker-delen for deg, i form av add-ons. I så fall er både MQTT brokeren og klienten "inni" Home Assistant. Det skal ikke være problematisk å ha to zigbee-nettverk under samme tak, men jeg har ikke prøvd det selv. Ja. For Z-wave er forresten Aeotec Z-Stick Gen5+ sikkert den vanligste kontrolleren, men det er ganske mye å velge i for Zigbee. I Home Assistant finnes det flere måter å få inn Zigbee, så man må bare passe på at gatewayen (f.eks. Zigbee2MQTT eller ZHA) du vil bruke er kompatibel med kontrolleren (f.eks. Sonoff Zigbee 3.0 eller Conbee II). For Home Assistant OS og Supervised tror jeg det finnes en egen add-on som tar backup av hele oppsettet. Jeg bruker Home Assistant Container, og lar Linux lage en zip av hele /home/ directory hver midnatt, som automatisk kopieres over til en nettverksdisk. Da har jeg kontinuerlig backup av alle konfigurasjonene til HA/ZwaveJS2MQTT/Zigbee2MQTT osv. for hver dag 2 uker tilbake i tid.

Har ikke sett eller oppsøkt noen tall på det, men slik jeg forstår veilederen til FHI er de største farene i private hjem dusjen (etter ferie), boblebad, og luftfuktere.

Jeg har min VVB på 70°C, men det er i et rom som har oppvarming to tredjedeler av året, så varmetapet fra VVB bidrar uansett bare til oppvarmingen av rommet. 60°C skal vel også klare å holde legionellaen i sjakk ifølge FHI:

Jeg henger meg litt på denne, for jeg har en sorpsjonsavfukter til garasjen, som jeg bare antar er en nokså induktiv last. Den har vært koblet på en Fibaro smartplugg i 2 år uten problemer. Vil tippe pluggen har blitt skrudd av/på i snitt en gang om dagen, så ca 500-1000 ganger. Pluggen oppgir ca. 500 watt når den er aktiv, så det skal jo være godt innafor, men jeg aner ikke om det er true power eller apparent power den oppgir. Er det noen smartplugger på markedet som kan anbefales evt. må unngås til induktive laster? Har noen andre induktive laster som jeg også har smartplugg til (vifter, kjøkkenventilator...) I ditt tilfelle oppgis startstrømmen til 4,3A, så jeg kan ikke tro at det skulle være direkte utrygt for en 16A smartplugg. Om det er sunt for avfukteren vet jeg ikke, men da jeg åpnet innmaten i min så det ut som bare passiv elektronikk, ville kanskje vært mer forsiktig med å kutte strømmen jevnlig om det var fullt av aktive komponenter?

Nei, hvis du uansett tenker å varme opp fullstendig (over 70°C) hver dag, trenger du ikke temperaturmåling for legionellaen sin del.

Mener å huske en artikkel fra Teknisk Ukeblad for noen år tilbake, fant igjen denne nå men jeg får ikke lest uten abonnement: Link: https://www.tu.no/artikler/na-kommer-sensorene-som-maler-fukt-inne-i-gulv-og-vegger-tradlost-br/455374

Hm, men det står også: Link: https://bkk.no/artikkel/b6e3df43-e183-41bd-8f43-88701cfd99e4

Ja, jeg ville ikke tenkt så mye på det før du er kommet i gang. En Raspberry Pi 4 har mer enn nok "umf" til å kjøre et alminnelig smarthus-system (med et lite forbehold om skrivesykluser på SD-minne, som du har fått med deg). Jeg har en NUC fra 2014 som sikkert er passé på alle vis, men den har aldri hatt problem med å kjøre Home Assistant + 5-6 andre tjenester. Zwave-sticken min (Z-Stick Gen5+) er mobil, men Zigbee-sticken (Sonoff ZigBee 3.0 USB dongle) er det ikke. I praksis er det nokså lang rekkevidde for paring, så jeg har aldri hatt behov for det, men den dagen det evt. blir et problem finnes det jo USB-over-Ethernet forlengere slik at du kan ha en "USB-kabel" på 30+ meter.

Dette kan vi kanskje ta i en annen tråd, men del gjerne hvis du også har noe vi andre kan bruke i /pyscript/modules/ og /apps/ også

I prinsippet skal det ikke mer til, med noen forbehold. Sjekk aller først at du har satt opp konfigurasjonen iht. dokumentasjonen: https://hacs-pyscript.readthedocs.io/en/latest/reference.html Jeg har brukt funksjonen count_nonzero fra numpy siden jeg uansett har numpy i requirements.txt (ref. dokumentasjon), så den linja kan du enten skrive om eller legge til numpy i requirements og deretter importere i .py-fila di: from numpy import count_nonzero Bruker også state.persist for alle pyscript-variabler så de ikke forsvinner ved neste reboot: state.persist('pyscript.electricity_monthly_peak_average') state.persist('pyscript.electricity_consumption_last_hour') state.persist('pyscript.electricity_daily_peak') Disse entitiene (med sine attributer, hvis de leses før de skrives) må deklareres først en-eller-annen plass, jeg gjør det typisk i Jupyter mens jeg skriver koden. Du kan gjøre det i scriptet ved første gjennomkjøring, og evt. fjerne det etterpå. Vil likevel anbefale å sette opp Jupyter mot Pyscript, det gjør det mye lettere å feilsøke og skrive ny kode. Både import og state.persist må kjøre før resten av scriptet, enten bare i toppen i .py-fila eller i en startup-funksjon med @time_trigger som decorator. Edit: Scriptet har fungert bra til nå, har sjekka at alle verdiene stemmer:

Kanskje du bare kan tilpasse noe som allerede er laget, f.eks. https://github.com/balmli/com.nordpoolspot ?

Da blir det fort smalhans resten av måneden

Ja, men mange smarthus-systemer kan også fylle alle de fire rollene på figuren din (mellomtjener, smarthusmiljø, database, UI). For Home Assistant som du nevner er det kun MQTT du må sette opp i tillegg, og det kan være så lett som at du velger det inn som en add-on i en add-on store inni Home Assistant. Jeg tenker at de færreste klarer å prosjektere hele smarthuset sitt bare ved å google; man må nesten bare komme i gang et sted, og da er det så mye lettere å forstå sammenhengen og terminologien når man har et eget system å utforske. Hvis du har en gammel laptop e.l. liggende hjemme kan du jo prøve å installere det du ser for deg på den, bare for å prøve det ut. Ellers må du nok uansett ta kostnaden med å kjøpe en Pi eller NUC eller lignende. De små frustasjonene tror jeg ikke du slipper unna dessverre, men det skal litt til å gå på noen store fadeser hvis du bare kjøper en Pi for utforskingens skyld Lykke til!

Det finnes noen varianter rundt omkring på forumet. I Home Assistant er det nokså greit å bruke Nordpool-integrasjonen og sortere prisene i enten today eller raw_today attributtene. Eksempel:

Kan du se i Homey når VVB er "på" uten at den trekker strøm? Da vet du når den ferdig oppvarmet. Hvis du følger med noen døgn med varierende varmtvannforbruk klarer du sikkert danne deg et bilde over hvor mange timer i døgnet den må være på. Vi er en familie på 4 med et badekar som brukes jevnt og trutt. VVB er 300L/3kW, og den har ennå aldri vært aktiv i mer enn 4 timer i døgnet, så jeg lar den være på de billigste 6 timene.

Ja jeg vet, men forskjellen mellom nettleie dag/natt/helg er omtrent neglisjerbar (8 øre/kWh hos Lnett) sammenlignet med døgnvariasjonen for spotprisen, så det ligger langt nede på prioriteringslista.

Interessant! Jeg gjør noe lignende, men har ikke lagt like mye arbeid i det. Følger bare med på at snittprisen for mitt forbruk ligger under tidsgjennomsnittet av strømprisen i inneværende døgn (fra midnatt til nåtid). Det er mest fordi det går litt "sport" i det, men jeg har sjekket noen ganger at snittprisen på fakturaene er lavere enn det snittet strømstøtten tar utgangspunkt i.

Det er vel akkurat det de skriver på nettsida også? De mener nok implisitt at de er billigst på spotpris (dvs. 0,01 øre/kWh billigere). Men ja, da er vel Tibber billigst totalt sett om man har et månedlig forbruk på over 390 000 kWh eller noe sånt...

Sånn har jeg det også, så jeg ser fram til hva du kommer opp med. Ser at jeg akkurat klarte å tyne meg under 5 kWh-grensa da strømprisen var på sitt laveste i går (med vaskemaskin/oppvaskmaskin/VVB gående samtidig), takket være en variant av PID-regulatoren fra forumet, men en uforutsett last fra kjøkkenet e.l. kunne veltet hele lasset