RVM

Lurt!

Husker ikke detaljene, skal sjekke koden seinere. Men det må ha vært kontinuerlig ja, og alltid nedad begrensa mot forrige verdi. Edit: Men jeg har ikke elbil, så for min del gjør det ingenting om absolutt alt er på de første 15 minuttene, jeg klarer ikke å bryte 5 kWh-grensa på 15 minutter.

Det er i alle fall en veldig enkel løsning. Har ikke koden foran meg her nå, men tror det var noe sånt som: pid.output_limits = (last_c, 1.0) ... i de første 15 minuttene, og så (0.0, 1.0) etterpå. Bruker normaliserte verdier 0-1 for PID output.

Jeg hadde samme problemstilling etter hver hele time. Har prøvd litt forskjellig, bl.a: Nokså "myke" verdier for PID gains. Gir treigere respons, men ikke nok til at det forhindrer prematur avslåing. Ønsker uansett rask nok respons senere i timen. Eksponensiell glatting av estimert timesforbruk første 15 minutter etter hel time, med lineært økende glattekonstant fra 0-1 mellom 0-15 minutter. Da unngår man i alle fall plutselige hopp i estimert timesforbruk. I praksis ser estimert forbruk penere ut på grafen, men det løste ikke problemet helt. En konfigurerbar verdi for tidligste tillatte avslåing per enhet (f.eks. bare tillate å skru av VVB 30 minutter etter hel time). Det fungerer, men ser litt rart ut når PID outputen går mot 0 mens alle enheter forblir påslått. Og så den endelige løsningen min: Bare tillatte at PID output øker i verdi første 15 minutter etter hel time. Dersom PID synker, forkast verdien.

Da jeg hadde tilsvarende feil var det fordi jeg beregnet månedssnitt til inneværende time, mens strømselskapet inkluderte kjente fremtidige timer. Verdt å sjekke.

Synes generelt også at timer helper er nyttig til sånne formål. De ivaretar state etter en reboot, sånn at automasjoner ikke påvirkes av at man restarter HA underveis.

Ja, det er en manuell bryter under dekselet, men man må skru ut en skrue for å komme til bryteren. Når dekselet er av er også terminalene eksponert, så det er bare i nødstilfeller du vil ta det av.

Ok, du kan jo sjekke om du allerede har tilgang til beregnet effektivitet og/eller temperatur i avkast over Modbus-interfacet, det er i alle fall tilgjengelig på VTR300. Edit: Ser du la til at du har sjekket allerede...

Ser riktig ut dette, når jeg sjekker opp mot Engineering Toolbox. Av nysgjerrighet, hva slags type varmeveksler er det? Min VTR300 har en roterende varmeveksler, og jeg ser den går inn i "Moisture Transfer control" når utetemperaturen synker. Har inntrykk av at den kompenserer for beregnet fukt i eksoslufta. Fra parameterlista på min: Det er også en kjempegod post på Home Assistant-forumet om ulike beregninger, og Systemair har en teknisk håndbok om ventilasjon som også forklarer en del konsepter uavhengig av produsent/modell.

Mitt adapter er nesten helt likt som @stigvisitt, men jeg bestilte fra en tysk butikk gjennom Ebay for en stund siden. Kostet ikke mange kronene selv med frakt og moms, men hadde valgt norsk nettbutikk hvis jeg visste det var mulig å få kjøpt innenlands. Her er linken. De fleste ESP32-variantene er støttet av ESPHome, men det kan være verdt å sjekke før man bestiller. Jeg hadde tilfeldigvis en ESP32dev, og det var helt uproblematisk. Bruker forresten throttle_average istedenfor throttle i de fleste sensor filtrene, det er en del målestøy på noen av temperatursensorene i mitt anlegg.

Takk for info! Jeg har en Systemair VTR300, og har til nå brukt deres Internet Access Module som en Modbus TCP gateway, men det har bare fungert sånn passe fram til nå. Hadde egentlig tenkt å prøve meg på gskjold sitt mqtt adapter, men da måtte jeg først ha satt meg inn i en del om PlatformIO som er nytt for meg. ESPHome er jo ganske plug & play, så det tok bare en time eller to å koble opp og flytte Modbus-konfigurasjon fra HA til en ESP32 med hjelp fra posten over. Fin bonus å kunne bruke ESPHome sitt sensor filter for å unngå å spamme HA med repeterende verdier. Ang. egnet boks så bruker jeg bare en liten koblingsboks fra Biltema til 30-40 kroner, med noen monteringsplater til strips for å feste elektronikken inni. På teknisk rom trenger det ikke være allverdens pent for min del.

Ja, min har også bare en toggle for opp/ned, så jeg berga opprinnelig en Pepperl+Fuchs proximity switch fra søpla på jobb for å få feedback. Ble veldig letta da jeg så i manualen til portåpneren at det var mulig å konfigurere et TAM-signal.

Det fungerer sikkert supert, men du kunne vel kanskje gjort det med en template cover direkte i Home Assistant tidligere også? Hos meg er det konfigurert sånn i HA, da er det value_template som gir feedback basert på et 24-volts signal fra portåpneren (en "Tür Auf Meldung" som Tormatic kaller det) til min ESPHome: cover: - platform: template covers: garage_door: device_class: garage friendly_name: "Garage door" value_template: "{{ is_state('binary_sensor.garage_door', 'on')}}" open_cover: service: script.garage_open_door close_cover: service: script.garage_close_door

Det var akkurat det jeg søkte om i april, og jeg mener jeg oppfylte alle kravene slik de var formulert da (av en eller annen grunn var kravene litt annerledes i selve søknadsskjemaet enn i veilederen i forkant uten at jeg husker detaljene). Men det virker som det er lang behandlingstid, min søknad er fremdeles ikke behandlet etter 4 måneder.

Jeg tror Philips Hue sin utendørssensor måler illuminans, du kan jo sjekke den. Men hvis det uansett bare skal følge sola, kan du kanskje bruke tidspunkt for soloppgang/solnedgang som trigger for å skru av og på utelys?

I rom med lysstyring fra bevegelsessensor bruker jeg bare en off-delay timer sånn at lyset ikke går av for raskt hvis det er litt tid uten bevegelse. Med LED er jo strømbruken neglisjerbar, så det er ikke så farlig om de er på 15 minutter for lenge. For meg er det viktigst å enkelt kunne skifte mellom en slags auto/manuell modus. Hos meg går lyset over i manuell modus med en gang man bruker lysbryteren, og så går den over i auto etter et par timer. Men du kan jo undersøke om du kan bruke en faktisk presence sensor (altså ikke motion sensor) som Aqara FP1 eller evt. wasp-in-a-box logikk: https://github.com/dlashua/hass-wasp_sensor

Jeg også, har vært veldig fornøyd med mine. Ironisk nok synes jeg den mye dyrere Aqara TVOC-sensoren med temperatur og luftfuktighet er mye verre. Kjøpte en sånn for å ha display og TVOC-måling, men den oppdaterer bare hver 0.5°C (tror ikke jeg kunne endre det i Zigbee2MQTT) og henger seg opp i ny og ne. De små sensorene oppdaterer hver 0.1°C og reagerer rimelig raskt.

Kjenner bare til det alarmsystemet jeg har sjøl: Eufy Security. Alt fungerer trådløst, ingen månedspris, menneskegjenkjenning, og integrerer fint med Home Assistant. Alarm kan kobles inn og ut basert på tid eller lokasjon, eller overstyres fra HA. Lokal lagring, men avhengig av sky for kommunikasjon mellom mobil og gateway. Systemet kan utvides med sensorer, men ikke integreres direkte med brannalarm eller dørlås så vidt jeg vet, men jeg tenker det ikke er så nøye så lenge det snakker med resten av smarthuset. Jeg har hatt mitt Eufy-system med videoringeklokke og kameraer i litt over 1 år, og er fornøyd så langt, men man finner ymse meninger om det på nett. Svakheten er jo at gatewayen går ned om kjeltringen tar strømmen eller nettforbindelsen, så hvis det skal være et fullgodt alarmsystem må man kanskje ha UPS og 4G failover.

Jeg har en 2,5 år gammel Høiax 300L VVB. Den kom med ei sjekkliste for kontroll av ekspansjonskar, med trusselen om at garantien frafaller om det ikke blir kontrollert årlig. Jeg oppdaget ved en tilfeldighet at den lakk litt fra sikkerhetsventilen under oppvarming for noen måneder siden, og fikk rørleggeren til å justere trykket (heldigvis under garanti, til tross for påstanden over). Har et vagt minne av at rørleggeren nevnte at Høiax hadde endret på ekspansjonskarene i ettertid. Hos oss var det ikke et stort problem, men jeg tror ikke det har noen sammenheng med styring av VVB etter strømpris.

Jeg har en Aqara temp- og fuktighetssensor på andre siden av rommet fra dusjen, og det er ingen problem å fange opp nokså raskt at det dusjes. Jeg sammenligner sanntidsverdien mot et moving average filter av siste fuktmålinger, og hvis sanntidsverdien er f.eks. over 5 RH% høyere enn MA vet jeg at dusjen er i bruk. Eksempel fra i dag tidlig, der spratt fuktigheten opp ca 15 RH%: Edit: Men jeg er ikke så interessert i når man er ferdig å dusje, bare at dusjing har begynt, sånn at det skrur opp avtrekket fra badet til fuktigheten er tilstrekkelig nær MA igjen.

Vet ikke helt hva du er ute etter, men på hev/senk-pultene på gammeljobben var det mulig å koble på egne brytere for hev og senk, f.eks. med en Arduino og et relé, så det blei en fin aprilsnarr et år. Vil en usmart pult med en Fibaro Smart Implant være godt nok?

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.)