kjetilsn

Takk stigvi, Det er supert, da slipper jeg tydeligvis å bruke første delen av templaten som "sjekker" om state er "unknown"

Hei, Bruker i dag noen enkle men "stygge" templates, og noen gir meg nå feilmelding. Det er nok template syntax som er i endring og som da ikke lenger vil støttes i neste versjon. I tillegg kan nok template skrives på en mer ryddig måte? Noen som har anbefalinger? Feilmelding: Template warning: 'float' got invalid input '<template TemplateState (<state sensor.kwh_kjellerbad_today=1.5; unit_of_measurement=kWh, friendly_name=Kwh Kjellerbad Today @ 2021-12-14T01:44:14.262309+01:00>)>' when rendering template '{%- if not (is_state("sensor.kwh_bad_1etg_today","unknown") or is_state("sensor.kwh_bad_2etg_today","unknown") or is_state("sensor.kwh_kg_today","unknown") or is_state("sensor.kwh_ks_today","unknown") or is_state("sensor.kwh_n_today","unknown") or is_state("sensor.kwh_stue_today","unknown") or is_state("sensor.kwh_a_today","unknown") or is_state("sensor.kwh_drivhus_today","unknown") or is_state("sensor.kwh_s_today","unknown") or is_state("sensor.kwh_masterbedroom_today","unknown") or is_state("sensor.kwh_t_today","unknown") or is_state("sensor.kwh_kjellerbad_today","unknown") or is_state("sensor.kwh_vr_today","unknown") )-%} {{ ((states.sensor.kwh_bad_1etg_today.state | float) + (states.sensor.kwh_bad_2etg_today.state | float) + (states.sensor.kwh_kg_today.state | float) + (states.sensor.kwh_ks_today.state | float) + (states.sensor.kwh_n_today.state | float) + (states.sensor.kwh_stue_today.state | float) + (states.sensor.kwh_a_today.state | float) + (states.sensor.kwh_drivhus_today.state | float) + (states.sensor.kwh_s_today.state | float) + (states.sensor.kwh_masterbedroom_today.state | float) + (states.sensor.kwh_t_today.state | float) + (states.sensor.kwh_kjellerbad_today | float) + (states.sensor.kwh_vr_today.state | float)) |default(0)|round }} {%- endif -%}' but no default was specified. Currently 'float' will return '0', however this template will fail to render in Home Assistant core 2022.1 Template Sensor: total_kwh_heating_today: value_template: '{%- if not (is_state("sensor.kwh_bad_1etg_today","unknown") or is_state("sensor.kwh_bad_2etg_today","unknown") or is_state("sensor.kwh_kg_today","unknown") or is_state("sensor.kwh_ks_today","unknown") or is_state("sensor.kwh_n_today","unknown") or is_state("sensor.kwh_stue_today","unknown") or is_state("sensor.kwh_a_today","unknown") or is_state("sensor.kwh_drivhus_today","unknown") or is_state("sensor.kwh_s_today","unknown") or is_state("sensor.kwh_masterbedroom_today","unknown") or is_state("sensor.kwh_t_today","unknown") or is_state("sensor.kwh_kjellerbad_today","unknown") or is_state("sensor.kwh_vr_today","unknown") )-%} {{ ((states.sensor.kwh_bad_1etg_today.state | float) + (states.sensor.kwh_bad_2etg_today.state | float) + (states.sensor.kwh_kg_today.state | float) + (states.sensor.kwh_ks_today.state | float) + (states.sensor.kwh_n_today.state | float) + (states.sensor.kwh_stue_today.state | float) + (states.sensor.kwh_a_today.state | float) + (states.sensor.kwh_drivhus_today.state | float) + (states.sensor.kwh_s_today.state | float) + (states.sensor.kwh_masterbedroom_today.state | float) + (states.sensor.kwh_t_today.state | float) + (states.sensor.kwh_kjellerbad_today | float) + (states.sensor.kwh_vr_today.state | float)) |default(0)|round }} {%- endif -%}' friendly_name: "Kwh Oppvarming i dag" unit_of_measurement: 'Kwh'

Takk, det var egentlig det jeg lurte på. Da ligger jo alt til rette for å starte migrering.

Takk for svar haraldov, Det var en fin oversikt. Godt å høre at z-trm3 fungerer bra, det gjør den ikke med openzwave integrasjonen som jeg kjører i dag, og er motivasjon Jeg har ca 10 stk TF016 (første generasjon) og 2 stk Z-TRM3. Siden TF016 ikke måler energi, så bruker jeg assosiering gr0 og node automasjoner basert på node event som kommer når releet slår, det er dette jeg ikke vet om vil fungere i z-wave js, men det finner jeg ut når jeg prøver. - alias: Ovens on stue trigger: platform: event event_type: zwave.node_event event_data: entity_id: zwave.stue_thermostat basic_level: 255 action: service: homeassistant.turn_on entity_id: input_boolean.heating_stue id: b2481b651f2d4e22a53dbf787ba61dd9

Hei, Tenker det er på tide å migrere til z-wave JS. Kjører fremdeles på "gamle" openzwave integrasjonen. Har en god del førstegenerasjon heatit termostater som er assosiert på gruppe 0 tilbake til kontroller der jeg bruker "node event" for å vite om termostaten varmer eller ei, slik at det er mulig å regne ut hvor mye energi det går på hver termostat. Spørsmålet blir da, er det noen som vet om det også støtte for det i Z-wave JS? Har søket litt rundt men finner ingen helt direkte svar. Har også et par heatit v3 som jeg ikke har fått integrert i den "gamle openzwave", antar de er bedre støttet i z-wave js? Jeg vet det er bare å sette i gang, går det gale så er det bare å gå tilbake til config som virker, men ville bare sjekke om noen har erfaring. Takk.

Hei, Kan anbefale å kjøre en separat mysql eller mariadb på en maskin / docker med ssd disk, da kan du også her kjøre feks influxdb på samme maskinen om du vil bruke grafana.

Mener at 6A er laveste definert av J1772, men at noen biler kan gå under dette, men at de da er utenfor standard. se mer her fra slide 11 og utover: https://www.fveaa.org/fb/J1772_386.pdf

Hei, Har fått bygget, montert og integrert et OpenEVSE kit mot Home Assistant. Eksisterende Home Assistant integrasjon er utdatert og fungerer kun delvis. Valgte å bruke MQTT for integrering, HTTP støttes også, mer info her Sensors: - platform: mqtt state_topic: 'openevse/amp' name: 'openevse_amp' expire_after: 300 value_template: "{{ value | multiply(0.001) | round(2) }}" unit_of_measurement: 'A' unique_id: 'openevse001' - platform: mqtt state_topic: 'openevse/pilot' expire_after: 300 name: 'openevse_pilot' unit_of_measurement: 'A' unique_id: 'openevse002' - platform: mqtt state_topic: 'openevse/wh' name: 'openevse_wh' expire_after: 300 unit_of_measurement: 'Wh' unique_id: 'openevse003' - platform: mqtt state_topic: 'openevse/state' name: 'openevse_state' expire_after: 300 value_template: >- {% set values = { '1':'Klar', '2':'Tilkoblet' ,'3':'Lader','4':'Feil', '254':'Klar - Bil tilkoblet', '255':'Klar - Bil ikke tilkoblet' } %} {{ values[value] if value in values.keys() else 'Unknown' }} unique_id: 'openevse004' - platform: mqtt state_topic: 'openevse/vehicle' name: 'openevse_vehicle' expire_after: 300 unique_id: 'openevse005' - platform: mqtt state_topic: 'openevse/colour' name: 'openevse_colour' expire_after: 300 value_template: >- {% set values = { '0':'Off', '1':'Red' ,'2':'Green','3':'Yellow', '4':'Blue', '5':'Violet', '6':'Teal', '7':'White' } %} {{ values[value] if value in values.keys() else 'Unknown' }} unique_id: 'openevse006' - platform: mqtt state_topic: 'openevse/manual_override' name: 'openevse_manual_override' expire_after: 300 unique_id: 'openevse007' Automation: # Read charge level from MQTT - alias: OpenEVSE Set slider trigger: platform: mqtt topic: openevse/set_pilot action: service: input_number.set_value target: entity_id: input_number.openevse_capasity data: value: '{{ trigger.payload }}' id: 56a6f9d542174f8bbd5dbb6633fe1342 # Publish MQTT charge level - alias: OpenEVSE slider moved trigger: platform: state entity_id: input_number.openevse_capasity action: service: mqtt.publish data: topic: openevse/rapi/in/$SC retain: true payload: '{{ states(''input_number.openevse_capasity'') | int }}' id: c15be7f0051244839beef00a1ae32343 # Publish MQTT charge state on - alias: OpenEVSE charge on trigger: entity_id: input_boolean.openevse_state platform: state to: 'on' action: service: mqtt.publish data: topic: openevse/rapi/in/$FE retain: true # payload: '' id: c15be7f0051244839beef00a1a324324 # Publish MQTT charge state off - alias: OpenEVSE charge off trigger: entity_id: input_boolean.openevse_state platform: state to: 'off' action: service: mqtt.publish data: topic: openevse/rapi/in/$FD retain: true # payload: '' id: c15be7f0051244839beef00a1a345332 # Read back charge status and set input boleean - alias: OpenEVSE charge set on trigger: entity_id: sensor.openevse_state platform: state to: 'Lader' action: service: input_boolean.turn_on target: entity_id: input_boolean.openevse_state id: 56a6f9d542174f8bbd5dbb66334352 - alias: OpenEVSE charge set off trigger: - platform: template value_template: "{{ not is_state('sensor.openevse_state', 'Lader') or (is_state('sensor.openevse_vehicle', '0'))}}" action: service: input_boolean.turn_off target: entity_id: input_boolean.openevse_state id: 56a6f9d542174f8bbd5dbb663324342 # Overstyringsflagg på - alias: OpenEVSE charge override on trigger: entity_id: sensor.openevse_manual_override platform: state to: '1' condition: condition: time before: '22:00' after: '10:00' action: service: input_boolean.turn_on target: entity_id: input_boolean.openevse_override id: 56a6f9d542174f8bbd54324324258 # Overstyringsflagg av - alias: OpenEVSE charge override off trigger: entity_id: sensor.openevse_vehicle platform: state to: '0' action: service: input_boolean.turn_off target: entity_id: input_boolean.openevse_override id: 56a6f9d542174f8bbd5898654442 configuration: input_number: # OpenEVSE Kapasitet openevse_capasity: name: Ladestrøm min: 6 max: 16 step: 1 unit_of_measurement: 'A' icon: mdi:target input_boolean: openevse_state: name: Lading icon: mdi:car-battery initial: off openevse_override: name: Overstyring icon: mdi:car-battery initial: off

Du kan jo sjekke ut OpenEVSE, da har du full kontroll direkte, uten skyløsning. Her kan du kjøpe som byggesett om du liker denslags, eller du kan kjøpe ferdig for EU som er CE godkjent. Den har ESP32 ombord som du kan styre via eget web interface, eller via RAPI kommandoer over MQTT eller HTTP. Du kan også modifisere litt og sette in ethernet om det er ønskelig. Min erfaring har vert at ESP32 er meget stabil, har ikke hatt problemer med drop out, etc. Har fått den integrert ganske så greit mot Home Assistant: Ladestrøm kan settes i steg på 1A fra 6A. Bruker nå scriptet til stigvi for strømregulering som også nå styrer ladestrømmen i disse stegene. Det som var kjekt her var at utviklerene har tenkt på ofte endringer i ladestrøm, og har lagt opp for forskjellige kommandoer for endring av ladestrøm med og uten lagring til flash, slik at med for eksempel laderegulering så lagres da ikke innstillingene for å spare flash. Eneste minus er vel at den ser litt kjip ut om du bryr deg om det. Et annet spennede alternativ kan være PRISM, men tror ikke den kan kjøpes ferdig bygget.

God ide! Kanskje også ha en slags automatisk override som da sørger for at det ikke strupes ned ved dyr strøm når husets behov for energi blir større en det som blir gjort tilgjengelig?

Har etter du anbefalte å bruke D satt den til 3000 og testet litt, øket etterhvert I. Av og til gikk forbruket over 5, tyisk 5.0 eller 5.1, så jeg øket også til -0.2 etter det så har den truffet mellom 4,75 og 4,9. Kanskje den vil treffe enda mer eksakt med å øke P igjen, men er egentlig fornøyd slik: Før: pid = PID(20.0, 0.1, 1.0, setpoint=float(input_number.effekt_target)-0.15) Nå: pid = PID(20.0, 0.5, 3000.0, setpoint=float(input_number.effekt_target)-0.2) Så ble det kaldt her og 5kWh ble for lite selv med vedfyring, har satt den opp til 10kWh, redd det er det som blir gjeldende for Jan, feb, og kanskje mars. Får vel til å isolere taket:)

Kan anbefale å sjekke ut Schedy for styring av varmekildene, kan enkelt brukes sammen med scriptet til stigvi. Har brukt det selv i lang tid for nattesenking, senking ved dyr strøm, etc. støtter også vindu/dør sensor som direkte kan slå av varme i det tilhørende rommet etc. Her er et par eksempler: rooms: living: actors: climate.stue: schedule: - v: 20 rules: - rules: - x: "Add(-10) if state('sensor.energy_regulator_usage_step') < '5' 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 } Bad: actors: climate.bad: schedule: - x: "Add(-10) if state('sensor.energy_regulator_usage_step') < '9' else Next()" - x: "Add(-1) if is_on ('input_boolean.energy_cost_high') else Next()" - x: "Add(-4) if is_on ('input_boolean.ferie') else Next()" - { v: 24, start: "23:00", end: "06:00", weekdays: 1-4 } - { v: 24, start: "23:00", end: "06:00", weekdays: 5 } - { v: 24, start: "23:00", end: "06:00", weekdays: 6 } - { v: 24, start: "23:00", end: "06:00", weekdays: 7 } - { v: 22 }

Hei, Mulig et sidespor, men relevant: Snublet over dette: https://github.com/digin-energi/API-nettleie-for-styring En del nyttig info kanskje?, men sier ikke noe om hva de forskjellige strømselskapene innfører, men eksempler for hvordan de kan velge / valgt å gjøre det.

Hei stigvi, Takk for tilbakemelding. Jeg skal forøke å øke D igjen for å få redusere raske endringer. Stemmer at denne har ligget til 0 siden endringene. Grunnen til endring var at jeg leste (wikipedia) at ofte var det ikke nødvendig med D funksjonen, derfor la jeg denne ned foreløpig for det da ble mindre å holde øye med under testing. Kan nok ha misforstått eller blandet med dempning ser jeg når jeg leser dette en gang til Ellers må jeg si at scriptet ditt fungerer jo som bare det, selv med ikke optimale innstillinger treffer det som regel meget bra. Dette har motivert meg til å få integrert bedre min OpenEVSE i home assistant, slik at regulatoren kan sette laderstrømmen slik du har gjort på din lader. Legger ut konfigurasjonen i en egen tråd i tilfelle noen andre her har eller kommer til å ha en OpenEVSE sammen med home assistant.

Det stemmer nok, Den første er fra 17.11 og siste er fra forrige natt , og da var det ganske kaldt ute. Men så er skalaen også 8kW på den ene og 6kW på den andre.

Har testet litt med å endre på innstillingene for PID regulatoren da det er ganske stor treghet i mitt system, som førte til overkompensering. De fem nivåene for pådrag regulerer opp og ned settpunktemperatur på forskjellige termostater for forskjellige rom som igjen har forskjellig effekt, som gjerne allerede er av, så dette blir uansett aldri helt perfekt. På natta er det varmtvannstanken som er den store lasten, den går av om pådraget er under 2. elbil lader rusler og går på 6A uavhengig, den skal også styres av PID etter hvert. Første innstillinger (direkte fra stigvi sin konfigurasjon): pid = PID(40.0, 1.0, 1600.0, setpoint=float(input_number.effekt_target)-0.15) Nye innstillinger: Redusert P og I, lagt D til 1 (lurer på det tilsvarer av eller D da skal stå til 0) Den største endringen skjedde ved redusering av I til 0.1. pid = PID(20.0, 0.1, 1.0, setpoint=float(input_number.effekt_target)-0.15) Er fornøyd med resultatet så langt, da det blir mindre av og på av laster, og det ser ut som den treffer målet ganske så bra. Har også endre derivative sensor og satt time window ned fra 5 til 1 min. for å få den raskere, det fører til at den fort overskyter i starte av timen, men ser ut som at det går bra grunnet "treghet" som er lagt til i PID?.. Slik er da sensorer nå: ## Styring av effekt bassert på forbuk mot tariff "" ## integrere kWh fra AMS - platform: integration source: sensor.ams_forbruk name: AMS fastupdate unit_prefix: k round: 2 ## Derivere fra kWh - platform: derivative source: sensor.ams_fastupdate time_window: "00:01:00" ## Forutsi timesforbruk bassert på derivert og faktisk forbruk - platform: template sensors: estimated_fast_hourly_consumption_unfiltered: unit_of_measurement: 'kWh' device_class: power value_template: "{{ (states('sensor.ams_fast_update_meter')|float(15)+states('sensor.sensor_ams_fastupdate_derivative')|float(0) *(3600-now().minute*60-now().second)/3600) | round(3) }}" ## Filtrere vekk støy fra time overgang - platform: filter name: "estimated_fast_hourly_consumption_filtered" entity_id: sensor.estimated_fast_hourly_consumption_unfiltered filters: - filter: outlier window_size: 4 radius: 0.25 - filter: lowpass time_constant: 10 precision: 3 ## 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<=10 %}1 {% elif states.sensor.regulator_energy_usage.state | float<=30 | float>10 %}2 {% elif states.sensor.regulator_energy_usage.state | float<=60 | float>30 %}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 %} Og her er da døgnforbruk med scriptet til stigvi i bruk vs uten:

Helt enig, Dette er veldig kjekt, hjelper også på at det antageligvis resulterer i måndedlig besparelse på 100 til 200,- Her er plot fra grafana:

Mange takk stigvi, Det var - pyscript_running som skulle til. Valgte å teste nå med å skru av vvs i stedet for elbil om natta så får vi se hvordan det går utover uken. Lader med kun 12A og tanken er på 2Kw så det blir nok ikke lange perioder der tanken skrues av. Vurderer å lage til noe for å senke temp på varmepumpa også, kanskje en ESP home med ir? Men så har jeg forstått at varmpumper er mest effektiv om de får lov til å stå på en temperatur. Blir litt prøving og feiling fremover:) # VVS av om morgen - alias: Varmtvann av trigger: platform: time at: 08:00:00 action: service: switch.turn_off entity_id: switch.vvs id: 2f2b26a9d0244258a0d09b93c7016b47 # VVS på om temp under 4 grader - alias: Varmtvann på under 40c trigger: platform: numeric_state entity_id: sensor.varmtvann_temp_temperature below: '40' action: service: switch.turn_on entity_id: switch.vvs id: a09951c6a043492e87507faa6eab44b8 # VVS av ved effektregulator nivå 1 - alias: Varmtvann av effektregulator trigger: platform: numeric_state entity_id: sensor.energy_regulator_usage_step below: '2' condition: condition: state entity_id: switch.vvs state: 'on' action: service: switch.turn_off entity_id: switch.vvs id: 2f2b26a9d0244258a0d09b93c7016b46 # VVS på ved effektregulator nivå over 1 og tidsvindu - alias: Varmtvann på effektregulator og tid trigger: platform: numeric_state entity_id: sensor.energy_regulator_usage_step above: '1' condition: condition: and conditions: - condition: state entity_id: switch.vvs state: 'off' - condition: time after: '00:23:00' before: '08:00:00' action: service: switch.turn_on entity_id: switch.vvs id: 2f2b26a9d0244258a0d09b93c7016b45

@DeVille, Ja og her, side 5: @mroek Ser den, Homey er sikker veldig bra, har ikke testet, så jeg kan ikke uttale meg. Om du ombestemmer deg så kan du jo sjekke ut openmqttgateway, på den måten kan du bygge deg en billig løsning for 433Mhz, BLE, Lora osv basert på feks ESP32. Kjører en sånn på hytta som leser temp sensor og dør/vindu, samt en vannalarm i båten, har fungert veldig bra https://docs.openmqttgateway.com/

Hei stigvi, Set at scriptet logger til logbook. Har prøvd å ekskludere "sensor_ams_fast_update_meter" men hjelper ikke. Finner ikke noe i scriptet som kaller på logbook funksjonen, så det er litt merkelig. Ser du det samme? file_effektariff_new_state has been triggered by state change sensor.ams_fast_update_meter == 1.41 12:29:34 - 4 seconds ago file_effektariff_new_state has been triggered by state change sensor.ams_fast_update_meter == 1.40 12:29:24 - 14 seconds ago file_effektariff_new_state has been triggered by state change sensor.ams_fast_update_meter == 1.39 12:29:13 - 24 seconds ago file_effektariff_new_state has been triggered by state change sensor.ams_fast_update_meter == 1.38 12:29:06 - 32 seconds ago file_effektariff_new_state has been triggered by state change sensor.ams_fast_update_meter == 1.37 12:28:56 - 42 seconds ago file_effektariff_new_state has been triggered by state change sensor.ams_fast_update_meter == 1.36

Hei mroek, Er nok litt farget her da jeg kun har erfaring med home assistant og en kjipa vera sak som til slutt gikk i bosset. Men når det er sagt så vil jeg anbefale at du gir deg vi kast med home assistant, du kan jo kjøre det på en billig pi 4 med en zwave og eller zigebee dongle, og gå videre til bedre hardware etterhvert om du finner det nødvendig. USB donglene tar du da selvflølgelig med deg videre. Fordelene er mange; det er helt åpent, det er gratis, du har mulighet til å vokse systemet enkelt, om noe ryker kan du bytte det ut, stor brukergruppe som gjør at du får god støtte. Scriptet som @stigvi har laget med bruk av PID kontroller i kombinasjon med innebygde funksjoner i home assistant er veldig bra, har testet nå i noen dager og uten å justere på noe, treffer strømforbruket tett opp til 5kw/h der det ellers ville gått til rundt 8kw/h, slik at forbruket forskyves fremover i tid. Jeg er kjempefornøyd med dette. Lastene som styres her i huset er varmekabler, panelovner og til sist varmtvannstanken. Dette vil i praksis sørge for at vi i vårt hus klarer å holde oss på trinn 1 i alle fall i 8-10 av årets måneder, kanskje mer om det blir en mild vinter, uten ville det nok vært kun sommermånedene vi vill klart det, og selv da ville detr være fort gjort å overstige en time i mnd.

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.

Husker nå at jeg har lest en tidligere post fra deg ang disse bayesian sensorene. Er nå på listen over ting jeg må studere nermere:) Bruker for det meste heatit termostater her, også på noen panelovner der termostaten styrer et zwave rele direkte. Bruker så schedy i appdaemon for å senke og heve temp settpunkt basert på tidspunkt, ute temp, og strømpris. Tenker jeg prøver med dette først, da med å redusere en grad på termostatene en etter et basert på PID nivå. Igjen, takk for at du deler!

Da var PID på plass og skriptet ditt minus elbil og terassevarmer delen. Kjører du automasjoner for å skru av og på lastene basert på sensor.regulator_energy_usage eller har bruker du eget script til det? Vurderer å sette opp en liten RGB pære en plass som kan gi Grøn/gul/rød type trafikklys basert på sensor.regulator_energy_usage for enkel indikator på hvor nær settpunkt en er kommet.

Her brukes en enkel Mbus til USB adapter og plugin til HomeAssitant (hass-AMS fra turbokongen), men så var det enkelt for min del å få trekt en signal ledning fra der Home Assistant bor og inn i sikringsskapet.