Gå til innhold
  • Bli medlem
Støtt hjemmeautomasjon! 🥇🥈🥉

kjetilsn

Medlemmer
  • Innlegg

    183
  • Ble med

  • Besøkte siden sist

  • Dager vunnet

    3

Alt skrevet av kjetilsn

  1. Hei, Endelig har mine TF016 termostater tilstandsinfo i climate entity: For å få "heating" og "idle" kommer fra attribute "hvac_action". Fant et script som setter attribute basert på andre entities: https://community.home-assistant.io/t/how-to-manually-set-state-value-of-sensor/43975/2 Automasjon som setter input_boolean bassert på releets tistand fra number entity: (grunnen til at jeg ikke bruker number entity direkte i neste automasjon er at den veksler mellom '0' som er av, '99' som jeg ikke hvet hva betyr, og '255' som betyr på.) ## Stue - alias: Ovens on stue trigger: entity_id: number.stue_basic platform: numeric_state above: '200' action: service: input_boolean.turn_on target: entity_id: input_boolean.heating_stue id: b2481b651f2d4e22a53dbf787ba61dd9 - alias: Ovens off stue trigger: entity_id: number.stue_basic platform: numeric_state below: '10' action: service: input_boolean.turn_off target: entity_id: input_boolean.heating_stue id: f1f928cac90a4573878d5344a0de716f Og så automasjon som setter attribute ved hjelp av scriptet: ## Heating_stue - id: set attribute thermostat stue alias: 'set attribute thermostat stue' trigger: platform: state entity_id: - climate.stue - input_boolean.heating_stue condition: condition: template value_template: >- {% if state_attr('climate.stue', 'hvac_action') == none %} true {% elif "input_boolean" in trigger.entity_id %} true {% else %} false {% endif %} action: service: python_script.set_state data_template: entity_id: 'climate.stue' hvac_action: >- {% if is_state('input_boolean.heating_stue', 'on') %}heating{% else %}idle{% endif %}
  2. Hei, Noen som bruker TF016 termostatene med FW1.92 og zwavejs integrasjonen her? Jeg endte med å gå tilbake til FW1.8 på disse da det var en dårlig kombo med ozwave integrasjonen. Vurdere å flashe en av de til FW1.92 for å teste.
  3. Utålmodig som jeg er så postet jeg samme spørsmålet på Home Assistant forumet, og som det ofte er så viste det seg at dette er enklere en først antatt. Viser seg at det blir generert en disablet number entity for hver climate entity. denne enity korresponderer med 'Basic set' og gir info som trengs direkte. https://community.home-assistant.io/t/zwavejs-automation-trigger-on-node-event/376267 Så da er alt i orden. Det hadde vert veldig kjekt å få denne tilstandsinformasjonen inn i climate entity slik at den kan rapportere 'heating' og 'idle' samt endre farge bassert på tilstand slik som andre termostater som faktisk rapportere dette tilbake eller for eksempel generic thermostat gjør. Noen som vet hvordan dette kan gjøres? Første tanke er å modifisere zwave config fil i zwavejs.
  4. Hei, Da var tiden inne for zwavejs Siden jeg kjører Home Assistant i docker gikk jeg for zwavejs2mqtt docker installasjon. Deaktivert MQTT delen og snakker med home assistant over Z-Wave JS websocket server. Har prøvd å lytte etter "zwave_js_notification", "zwave_js_value_notification" og " zwave_js_value_updated" gjennom "devtools" -> "Events" uten å få noe som helst. Har sjekket i logge til zwave2mqtt at info blir motatt: 2022-01-06T19:37:52.574Z DRIVER « [Node 005] [REQ] [ApplicationCommand] └─[BasicCCSet] target value: 0 2022-01-06T19:37:52.577Z CNTRLR [Node 005] treating BasicCC::Set as a report 2022-01-06T19:37:52.577Z CNTRLR [Node 005] [~] [Basic] currentValue: 255 => 0 [Endpoint 0] 2022-01-06T19:37:07.831Z DRIVER « [Node 005] [REQ] [ApplicationCommand] └─[BasicCCSet] target value: 255 2022-01-06T19:37:07.834Z CNTRLR [Node 005] treating BasicCC::Set as a report 2022-01-06T19:37:07.834Z CNTRLR [Node 005] [~] [Basic] currentValue: 0 => 255 [Endpoint 0] CurrentValue til 0 er rele av og 255 er rele på. Lurer på om dett blir sendt som event delen i home assistant i det hele tatt?.
  5. Hei, emonEVSE er OpenEVSE i EU utgave, har selv et kit av OpenEVSE og er godt fornøyd med det. Lett å integrere da det har eget API og også MQTT støtte. Kildekode er selvfølgelig åpen, så her kan du da også gjøre endringer om du vil det. Nå er det vel bare WIFI støtte på disse, men du kan installere eget kort for å få Ethernet: https://shop.openenergymonitor.com/openevse-etherent-gateway-esp32/
  6. Noen som har oversikt på hvor mye tap det er i disse kablene? Vil tro det er betydelig mengde energi som går tapt over dammen, ca. 30% kanskje? I dag handler jo ting om å være kortreist, det gjelder jo for energi også. Lurt med solceller på taket osv, problemet er da lagring, der det ikke finnes noen god løsning (og nei litium batteripakker er ikke løsningen). Med vannkraft er ikke dette et problem, dammene er batterier som vi kan bruke til å "lagre strøm" til den kalde vinteren kommer, men ikke når dammene begynner å bli tomme på vei in i vinteren for noen har solgt strømmen. Helt enig med deg SveinHa, dette er forkastelig. At vi finner oss i det uten kamp er også nesten litt uforståelig, men vi som folk har det vel kanskje litt for godt, og finner oss i det meste. Noen mener det er helt ok at vi skal ha en strømpris lik den i EU, det er feil. Vi kan ikke som resten av EU velge om vi skal varme opp med gass eller elektrisitet, de aller fleste av oss er låst på sistnevnte, mange har ikke engang mulighet til å fyre med ved.
  7. Ikke dumt, tenker du selv eier en del skog også da:)? Vi lurer på å gå for denne: https://www.hetastoves.com/scanlineaqua Sammen med en 600 - 1000 liter tank og radiatorer, slik det er i dag ville det fort ha lønnet seg, selv med kjøpt ved.
  8. Ble nesten litt skuffet nå.. Men men, tror ikke det i praksis var så mye en hadde klart å spare i forhold til dagens tariff. Det som er helt sikkert er at det skal hogges mye ved fremover:)
  9. Takk stigvi, Det er supert, da slipper jeg tydeligvis å bruke første delen av templaten som "sjekker" om state er "unknown"
  10. 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'
  11. Takk, det var egentlig det jeg lurte på. Da ligger jo alt til rette for å starte migrering.
  12. 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
  13. 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.
  14. 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.
  15. 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
  16. 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
  17. 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.
  18. 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?
  19. 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:)
  20. 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 }
  21. 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.
  22. 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.
  23. 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.
  24. 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:
  25. 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:
×
×
  • Opprett ny...

Viktig informasjon

Vi har plassert informasjonskapsler/cookies på din enhet for å gjøre denne siden bedre. Du kan justere dine innstillinger for informasjonskapsler, ellers vil vi anta at dette er ok for deg.