Vinnerliste

Da er den første av våre 4 Luxaflex-gardiner montert. En var ødelagt i forsendelsen, og to var for brede (så heldigvis var det ikke jeg som målte ). Har første versjon av et styringsscript klar snart.

Definitivt ingen fare for legionella. Temperaturen synker omtrent 0,4 grader i timen hvis du ikke tapper vann av den. Fra 70 til 45 grader kan den stå strømløs i ca 60 timer. 45 grader er fortsatt varmt nok til en dusj.

Håper jeg omsider har skjønt meg på kapasitetsleddet på ny nettleie. Har nå lagt inn at når jeg passerer 2.5kwh innen klokketimen så juster elbilen seg ned (samt vvb, og varme i bod, m.m.) for å unngå å komme over 5kwh. Og selvfølgelig lading på nettene (med mindre jeg trykker inn en "override" knapp på laderen). (Gul er akumulert kwh tall til høyre, blå er elbil).

Foreløpig løsning: Template sensor som deler opp i fem nivåer: ## Nivåer bassert på PID output - platform: template sensors: energy_regulator_usage_step: friendly_name: 'Energy regulator usage step' icon_template: mdi:power-standby value_template: >- {%if states.sensor.regulator_energy_usage.state | float<=20 %}1 {% elif states.sensor.regulator_energy_usage.state | float<=40 | float>20 %}2 {% elif states.sensor.regulator_energy_usage.state | float<=60 | float>40 %}3 {% elif states.sensor.regulator_energy_usage.state | float<=80 | float>60 %}4 {% elif states.sensor.regulator_energy_usage.state | float<=100 | float>80 %}5 {%- endif %} Så Endringer i Schedy: watched_entities: - sensor.energy_regulator_usage_step - input_boolean.fri - input_boolean.varmt_ute - input_boolean.ferie - input_boolean.energy_cost_high rooms: living: actors: climate.stue: schedule: - v: 20 rules: - rules: - x: "Add(-6) if state ('sensor.energy_regulator_usage_step') < '3' else Next()" - x: "Add(-1) if is_on ('input_boolean.energy_cost_high') else Next()" - x: "Add(-5) if is_on ('input_boolean.varmt_ute') else Next()" - x: "Add(-10) if is_on ('input_boolean.ferie') else Next()" - rules: - x: "Next() if state('input_boolean.fri') == 'off' else Break()" - { start: "14:00", end: "22:00", weekdays: 1-4 } - { start: "14:00", end: "23:00", weekdays: 5 } - { start: "08:00", end: "23:00", weekdays: 6 } - { start: "08:00", end: "23:00", weekdays: 7 } - { v: 19 } - rules: - x: "Next() if state('input_boolean.fri') == 'on' else Break()" - { start: "06:00", end: "22:00", weekdays: 1-4 } - { start: "06:00", end: "23:00", weekdays: 5 } - { start: "08:00", end: "23:00", weekdays: 6 } - { start: "08:00", end: "23:00", weekdays: 7 } - { v: 19 } Ser foreløpig bra ut. Skal legge til varmtvannstank og elbil etterhvert, har jo en måned på å teste.

Jeg hadde betalt prisen for Heavy Duty Switch og elektriker bare for å slippe å sjekke en gang i uka... Jeg ringte et av de større firmaene for varmtvannsberedere for å forhøre meg om legionellafaren. Han sa at så lenge man varmer opp vannet til 70 grader en gang i uka så burde det ikke være noe problem. Gjør du det daglig, så er det garantert ikke noe problem. Men han ville ikke ha navnet sitt på trykk, sikkert fordi han vet at VG garantert kommer til å ringe...

Det er en "Easy trigger" funksjon (den BURDE absolutt vært en integrert del av HS)

Jeg har tenkt å løse dette (altså å sørge for at jeg aldri passerer 5 kWh på en time) på følgende måte med HomeSeer og Tibber Pulse: Har laget en global variabel i HomeSeer som heter consumption_prev_value. Den oppretter jeg i startup.vb, siden globale variable slettes ved restart. Setter den ved oppstart til gjeldende verdi av "Realtime AccumulatedConsumption" i TibberSeer. Jeg har et script i HomeSeer som oppdaterer denne variablen hver hele time. Så har jeg laget en virtuell device i HomeSeer som heter RealTime Hourly Consumption. Den oppdaterer jeg vha et script hver gang Realtime AccumulatedConsumption endrer seg. Verdien settes til ("Realtime AccumulatedConsumption"-consumption_prev_value). Da har jeg til enhver tid en device i HS som viser hvor mye strøm jeg har brukt siste timen. Har også opprettet en virtuell device som heter Power Level. Denne bruker jeg til å styre strømforbruket. Lager et script som kjører hver time som setter Power Level avhengig av om strømmen er billig eller ikke (relativt sett til dagsprisen, litt logikk med standardavvik osv). I tillegg monitorerer jeg RealTime Hourly Consumption, og dersom jeg passerer et gitt nivå, feks 4 kWh, setter jeg Power Level i sparemodus (overstyrer da strømprisen som var utgangspunktet for innstilling denne timen). Jeg styrer også varmen via HS. I dette scriptet skrur jeg opp temperaturen ved lav Power Level, og ned varmen dersom Power Level tilsier at jeg må spare strøm. I tillegg (og viktigst) skrur jeg av varmtvannstanken og senker temperatur på varmekabler. Sender også en advarsel via pushover dersom dette ikke er tilstrekkelig så jeg kan skru av tørketrommel eller annet (men det tror jeg ikke jeg kommer til å trenge).

Har endelig somlet meg til å få bekreftet denne teorien. Eksempel på måling mottatt fra naboens måler av rtl_433 (med options "-f 868950000 -s 1200000 -M level"): { "time": "2021-11-18 17:18:55", "model": "Wireless-MBus", "mode": "C", "M": "KAM", "id": 76845462, "version": 27, "type": 22, "type_string": "Cold Water", "C": 68, "data_length": 41, "data": "2a442d2c625484761b168d2a0114b76522cbaa96817c787f3183f757807e0a2fecf5a6ac0c35e3cd19d027", "mic": "CRC", "mod": "FSK", "freq1": 868.93299, "freq2": 868.95712, "rssi": -1.52101, "snr": 12.20334, "noise": -13.7244 } Nettien poster da dette til https://agent.dd.onsmartliv.no/api/agent: Host: agent.dd.onsmartliv.no User-Agent: DeviceDrive/WRF01/5.0 Content-Type: application/json; charset=utf-8 Accept: application/json DeviceDrive-Header: {"mac":"2cf43248d7a5","firmware":"5.0","hardware":"WRF01","token":"c7fc5808155cc8d9649b042a1619858b","product_key":"1ad22182-ca0c-4087-b79b-9b7971bbc95c","version":"2.3","transfer_type":"data"} Content-Length: 411 { "smartliv.netti.system": { "alive": 423653, "batt_status": "USB", "batt_v": 3.3, "conf_water_meter": "", "hw": "1.3", "sn": "191010832", "t": 1637252085, "usb": 1, "wifi_rssi": -70 }, "smartliv.netti.water": { "raw_water_msg": "543D2C442D2C625484761B168D200114B76522CBAA96817C787F3183F757807E0A2FECF5A6AC0C35E3CD19D02786B9", "water_rssi": -86, "water_sn": "76845462", "water_status": 183, "water_t": 1637252085 } } og får innimellom en imponerende mengde 500,502 og 503 en slik ack tilbake: Cache-Control: no-cache Pragma: no-cache Content-Length: 24 Content-Type: application/json; charset=utf-8 Expires: -1 Request-Context: appId=cid-v1:283644af-6b78-4018-bd1f-5a8797ddc96b Access-Control-Expose-Headers: Request-Context Set-Cookie: ARRAffinity=3e6f5debd8a2718fff20e474e8397f908da7dc3bb3105a4dd67e2d68ff65108e;Path=/;HttpOnly;Secure;Domain=agent.dd.onsmartliv.no Set-Cookie: ARRAffinitySameSite=3e6f5debd8a2718fff20e474e8397f908da7dc3bb3105a4dd67e2d68ff65108e;Path=/;HttpOnly;SameSite=None;Secure;Domain=agent.dd.onsmartliv.no Date: Thu, 18 Nov 2021 16:21:25 GMT { "timestamp": 1637252447 } Nettiens "raw_water_msg" er nesten en tro kopi av "data" fra rtl_433. Nettien legger til 4 siffer først og sist (sjekksum+?), og lengde-byten (byte 0 fra rtl_433 eller byte 2 fra Netti) er økt med 2. Kompensasjon for de to bytene på slutten? I tillegg er to bits inne i meldingen flippet: 8d2a har blitt til 8d20. Veldig pussig. Men det er uansett i headeren før den krypterte payloaden, så det ødelegger jo ikke noe. wmbusmeters dekoder denne meldingen slik: (simulation) from file "2a442d2c625484761b168d2a0114b76522cbaa96817c787f3183f757807e0a2fecf5a6ac0c35e3cd19d027" (wmbus) ff a dll crc first (calculated ccd8) did not match (expected 8d2a) for bytes 0-10! (wmbus) parseDLL @0 43 (telegram) DLL L=2a C=44 (from meter SND_NR) M=2c2d (KAM) A=76845462 VER=1b TYPE=16 (Cold water meter) (driver multical21) DEV= RSSI=0 (wmbus) parseELL @10 33 (telegram) ELL CI=8d CC=2a (slow_resp sync prio) ACC=01 SN=14b76522 (AES_CTR session=4 time=2513777) CRC=cbaa Received telegram from: 76845462 manufacturer: (KAM) Kamstrup Energi (0x2c2d) type: Cold water meter (0x16) ver: 0x1b driver: multical21 (wmbus) 00: 2a length (42 bytes) (wmbus) 01: 44 dll-c (from meter SND_NR) (wmbus) 02: 2d2c dll-mfct (KAM) (wmbus) 04: 62548476 dll-id (76845462) (wmbus) 08: 1b dll-version (wmbus) 09: 16 dll-type (Cold water meter) (wmbus) 0a: 8d ell-ci-field (ELL: Extended Link Layer II (8 Byte)) (wmbus) 0b: 2a ell-cc (slow_resp sync prio) (wmbus) 0c: 01 ell-acc (wmbus) 0d: 14b76522 sn (AES_CTR) (wmbus) 11: cbaa payload crc (calculated e70b ERROR) telegram=||2A442D2C625484761B168D2A0114B76522CBAA96817C787F3183F757807E0A2FECF5A6AC0C35E3CD19D027|+0 (serial) stopping manager Har dessverre ikke klart å få ut nøkkelen fra hverken Asker kommune eller Smartliv (som mest sannsynlig heller ikke har den). Så det der er vel omtrent så langt jeg kommer. Når det gjellder "Netti" hardwaren så er det sikkert noen her som er interessert i å vite at den oppgir hostnavnet "ESP-48D7A5" og at mac-adressen i DeviceDrive-Header er korrekt. DeviceDrive ser ut til å være et firma som driver omtrent som Tuya - selger halvferdig dingsedesign sammen med en app-/sky-løsning. Mer info på https://devicedrive.com/download/wrf01-hardware-specification/

Ja, du dobler brannfaren i teorien. Det blir da to stikk/støpsel i stedet for én… Når vi kjøpte hus for noen år siden så var det første jeg gjorde å bestille elektriker til å fjerne støpselet på VVB - selv om det var lovlig pga ikke tilbakevirkende kraft på regelendringen…

Jeg har et veldig spesielt system for å styre ovner som er basert på Home Assistant sine bayesian sensor. En bayesian sensor styrer en varmekabel eller panelovn og hver av disse sensorene har en drøss innganger som er relatert varmestyring. En av inngangene er om pid regulatoren er under en grenseverdi. Nedenfor er en slik og den slår av ovn når pid regulator er under 32%. Du må se hva du gjør i ditt system. Det fikses jo lett med noen automasjoner eller i skriptet som jeg har gjort for bil. - platform: bayesian name: 'Panelovner stue' prior: 0.35 probability_threshold: 0.5 observations: - platform: 'numeric_state' entity_id: 'sensor.regulator_energy_usage' prob_given_true: 0.001 below: 32 - entity_id: input_boolean.travel_enabled prob_given_true: 0.001 platform: 'state' to_state: 'on' - entity_id: binary_sensor.vindu_2_etg_a prob_given_true: 0.001 platform: 'state' to_state: 'on' - entity_id: binary_sensor.vindu_2_etg_b prob_given_true: 0.001 platform: 'state' to_state: 'on' - entity_id: binary_sensor.noen_er_hjemme prob_given_true: 0.7 platform: 'state' to_state: 'on' - entity_id: input_boolean.sleeptime prob_given_true: 0.32 platform: 'state' to_state: 'on' - entity_id: binary_sensor.soonsleeptime prob_given_true: 0.32 platform: 'state' to_state: 'on' - entity_id: binary_sensor.preheat_day prob_given_true: 0.66 platform: 'state' to_state: 'on' - entity_id: binary_sensor.preheat_night_weekend prob_given_true: 0.64 platform: 'state' to_state: 'on' - entity_id: binary_sensor.heatlimit_morning prob_given_true: 0.4 platform: 'state' to_state: 'on' - entity_id: input_boolean.soonhome prob_given_true: 0.66 platform: 'state' to_state: 'on' - entity_id: input_boolean.visitors_comfort_temp prob_given_true: 0.64 platform: 'state' to_state: 'on' - entity_id: sensor.pricelevel prob_given_true: 0.48 platform: 'state' to_state: 'EXPENSIVE' - entity_id: sensor.pricelevel prob_given_true: 0.3 platform: 'state' to_state: 'VERY_EXPENSIVE' - entity_id: sensor.pricelevel prob_given_true: 0.3 platform: 'state' to_state: 'EXTREMELY_EXPENSIVE' - entity_id: binary_sensor.preheat_night_home_office prob_given_true: 0.64 platform: 'state' to_state: 'on' Skriptet mitt ang pid regulator er pr i dag som dette: from simple_pid import PID pid = PID(40.0, 1.0, 1600.0, setpoint=float(input_number.max_energy_usage)) pid.sample_time = 1.9 pid.output_limits = (0, 100) pid.proportional_on_measurement = False pid.auto_mode = True last_c = 0 turned_off_all = False turned_off_car = False @state_trigger("sensor.energy") def new_state(): global pid global last_c global turned_off_all global turned_off_car c = pid(float(sensor.estimated_hourly_consumption)) p, i, d = pid.components state.set("sensor.regulator_p", round(p,1)) state.set("sensor.regulator_i", round(i,1)) state.set("sensor.regulator_d", round(d,1)) if last_c != c: sensor.regulator_energy_usage = int(c) #, attributes = {"unit_of_measurement": "%", "friendly_name": "Pådrag varme"}) last_c = c if c < 10 and turned_off_car == False: easee.set_charger_circuit_dynamic_limit(charger_id = "EH430587", currentP1 = "0") turned_off_car = True if c > 12 and turned_off_car == True: easee.set_charger_circuit_dynamic_limit(charger_id = "EH430587", currentP1 = "6") turned_off_car = False if c < 2 and turned_off_all == False: esphome.terrassevarmer_pause() esphome.varmtvannstank_pause() persistent_notification.create(title = "Strøm", message = "Effektbegrensing slo av alt.") turned_off_all = True if c > 5 and turned_off_all == True: esphome.terrassevarmer_resume() esphome.varmtvannstank_resume() turned_off_all = False @state_trigger("input_number.max_energy_usage") def setpoint(value=None): pid.setpoint = float(value) @state_trigger("input_number.consumption_lasthour") def hourly_usage(value=None): if float(value) > float(input_number.max_energy_usage): script.turn_on(entity_id = "script.send_melding", variables = {'message': 'Strømforbruk var større enn grense', 'title': 'Strøm', 'channel': 'Info'})

Teoretisk vil den pluggen være ok men bereder på Schuko kontakt er ikke lengre lovlig da der har vært en del saker med varmgang. Schuko skal tåle 16A men det er stor forskjell på kontinuerlig last i timevis og litt mer kortvarig last. Min bereder er 2.9kW og er koblet via et slikt: https://www.tronika.no/no/smarthus/zwave-produkter/z-wave-apparatstyring/bryter-zw078.html

Vi lager alltid litt ekstra trøbbel 🙂 Men mange fordeler med å kjøre Linux på slike systemer. Setter pris på supporten her!

Hei. Har du fått konfigurert enhetene dine slik at de fungerer som Master og slave? Jeg hadde samme problem i starten men det er egentlig ganske enkelt når du har knekt koden🙂

- platform: derivative source: sensor.sensor_klepp_energi_effekt_integral name: real_time_consumption_gabriel_edlands_veg_16_integral_derivative round: 3 unit_time: h time_window: "00:02:30" Jeg har mange varmekabler som slår seg av og på innenfor 5 minutters intervaller og derfor hadde jeg tidsvindu på denne satt til 5 minutt. Men det gir en tregere respons når en større forbruker slås på så her må du se hva som passer for deg. Jeg tester litt med kortere intervall og ser om det gir bedre resultat hos meg.

Her er bil på lading og VVB påslått og da har PID regulator etterhvert havnet på 68% og to varmekabler i gulv avslått for å holde det under 4,8kWh denne timen. Jeg fant ut jeg kunne liste opp hver av komponentene P, I og D og hvor mye de bidrar på utgangens 68%. Det gjør det mye lettere å "tune" den inn. c = pid(float(sensor.estimated_hourly_consumption)) p, i, d = pid.components state.set("sensor.regulator_p", round(p,1)) state.set("sensor.regulator_i", round(i,1)) state.set("sensor.regulator_d", round(d,1))

Jeg har samme problem, og for min del virker det som noe som har kommet med en av de siste firmware-oppdateringene til låsen. Noen ganger sier den at den er lukket, men ulåst. Andre ganger åpen og ulåst. Om jeg puller verdiene eller prøver å låse (selv om den allerede er låst) så oppdateres verdien. Hadde en teori om at det var for mye trafikk på z-wave nettverket sånn at meldingen ikke kom frem, men klarte å reprodusere dette uten at det var noe som helst trafikk på nettverket da døra ble lukket. Så jeg konkluderte med firmware-bug, men har ikke gjort noe mer ut av det. Fikk også nylig en ny lås på garantien og har samme problem der. Tidligere hadde jeg trøbbel med eldre firmware-versjoner at låsen ikke alltid låste seg automatisk, selv om låsen skulle gjøre dette selv. Fiksen var å lage en automasjon som prøver å låse døra hvert 20. sekund eller noe sånt noen ganger etter at døra er lukket (låsen skal i utgangspunktet rapportere dette, men har også en egen dørsensor i backup). Dette løser problemet for meg, men bruker sikkert litt ekstra batteri som fint kunne vært unngått. Tilfeldigvis har dette vært fiksen min for dette problemet.