Zendure producten in Home Assistant integreren deel 2

[Taro]

jk-d schreef op vrijdag 19 september 2025 @ 10:42:
Onder het mom van de domste vraag is de vraag die niet wordt gesteld:
Wat zijn nou de verschillen tussen fireson en gielz en wat de voordelen en/of nadelen van beide oplossingen?

Is volgens mij ook een deel doelgroep afhankelijk. Heb laatst via een ander platform mensen geholpen die op dit topic waren gestuit en nog niet eerder iets met HA hadden gedaan. Dan is de Fireson/Zendure integratie met de juiste handleiding voor mijn gevoel net even iets toegankelijker. Maar wel met meer overhead.

Daarnaast is mijn ervaring dat je met 2 of meer devices ook een out of the box betere regeling krijgt via de Fireson/Zendure integratie ivm loadbalancing, etc.

Maar wil je het lean & mean houden, heb je HA/Yaml ervaring, een beperkt aantal devices, etc. dan is denk ik de @gielz variant the way to go.

Gebruik hier bewust de Firezon/Zendure variant ivm 3x 2400AC en 4x SF800 die daarmee perfect doen wat ik wil en nodig heb, maar met bijv. 1x 2400AC was ik waarschijnlijk wel overgestapt naar @gielz zijn variant.

[jk-d]

Taro schreef op vrijdag 19 september 2025 @ 11:06:
[...]

Is volgens mij ook een deel doelgroep afhankelijk. Heb laatst via een ander platform mensen geholpen die op dit topic waren gestuit en nog niet eerder iets met HA hadden gedaan. Dan is de Fireson/Zendure integratie met de juiste handleiding voor mijn gevoel net even iets toegankelijker. Maar wel met meer overhead.

Daarnaast is mijn ervaring dat je met 2 of meer devices ook een out of the box betere regeling krijgt via de Fireson/Zendure integratie ivm loadbalancing, etc.

Maar wil je het lean & mean houden, heb je HA/Yaml ervaring, een beperkt aantal devices, etc. dan is denk ik de @gielz variant the way to go.

Gebruik hier bewust de Firezon/Zendure variant ivm 3x 2400AC en 4x SF800 die daarmee perfect doen wat ik wil en nodig heb, maar met bijv. 1x 2400AC was ik waarschijnlijk wel overgestapt naar @gielz zijn variant.

Helder. Ik heb nu tweemaal 2400ac draaien onder fireson en die worden nu netjes aangestuurd zoals ik het wil. Ik ga misschien nog een derde erbij plaatsen, dus ik laat fireson nu maar fijn het werk opknappen.

[gielz]

Ik heb even in de TS weer eens de aansturing per Tweaker een update gegeven. Mooi om te zien dat er zoveel Tweakers kiezen voor de Home Assistant sturing.

https://strawpoll.com/05ZdzxXvmn6

[c0mplex1]

Zo ziet mijn in elkaar geknutselde gebruikersinterface er uit.
De besturing draait nu zo'n 1,5 maand onafgebroken door met laden en ontladen (NOM), op zowel zonnige als bewolkte, regenachtige dagen.

[Newtonjan]

@gielz Super bijdrage!

Ik wil volledig lokaal draaien, dus ben begonnen met jouw Automatisering en Configuration.yaml in versie 20250916. Inmiddels ben ik jouw script ook aan het aanpassen. Grootste reden is dat ik grote sprongen zie in mijn avond/nachtverbruik met de data vanuit de p1 meter als ik deze met een interval 1 s uitlees (ik gebruik een kabel vanuit de p1 poort naar de USB poort in mijn HA setup).

Mijn doel: een zo strak mogelijke NOM bij ontladen waarbij de batterij zo min mogelijk levert aan het net. Mijn doel is dus om de nacht alsnog op 20 W netto verbruik te zitten vanuit het net. Daarnaast wil ik zo min mogelijk onnodige wijzigingen in het verbruik van de batterij hebben. Echter, als er een grote sprong is in het verbruik wil ik ook dat de batterij zo snel mogelijk volgt.

Even tussendoor: Een Quooker is een apparaat wat voor een korte tijd veel energie vraagt. Een batterij kan dit nooit volgen op basis van de p1 data. Vandaar dat ik een sensor heb gemaakt (sensor.electricity_meter_active_power_nom) waarin het vermogen van de Quooker niet is opgenomen. Ik draait dus NOM met uitzondering van de Quooker.

Mijn idee: het energieverbruik meten met een interval van 1 s. Bij een groot netto verbruik (in mijn geval > 100 W of < -60 W) gebruik ik de aanpak om basis van de 1 s meting direct een grote stap te maken zoals in versie 20250916. Bij een klein netto verbruik (in mijn geval tussen de 10 W en 30 W) doe ik geen aanpassing naar het vermogen van de batterij. In de tussenliggende gebieden (dus binnen het interval 30 W en 100 W of binnen het interval -60 W en 10 W) doe ik een aanpassing van +5 W of -5 W richting de gewenste 20 W.

Onderstaande code zit in mijn Automation. Hierbij is sensor.electricity_meter_active_power_nom de p1 meter data. Daarnaast gebruik ik voor een vloeiendere sturing in de tussenliggende gebieden een helper van dit signaal: gemiddelde van de laatste 10 seconden in sensor.electricity_meter_active_power_nom_avg.

code:

      - conditions:
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_vermogen_aansturing
            below: 0
          - condition: or
            conditions:
              - condition: numeric_state
                entity_id: sensor.electricity_meter_active_power_nom
                above: 100
              - condition: numeric_state
                entity_id: sensor.electricity_meter_active_power_nom
                below: -60
          - condition: or
            conditions:
              - condition: state
                entity_id: input_select.zendure_2400_ac_modus_selecteren
                state: Nul op de meter
              - condition: state
                entity_id: input_select.zendure_2400_ac_modus_selecteren
                state: Alleen slim ontladen
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            above: 10
          - condition: template
            value_template: >-
              {% set factor = 1.00 %} {% set cap = 2400 %} {% set correctie = 20
              %} {% set p1 = states('sensor.electricity_meter_active_power_nom')
              | float(0) %} {% set zendure =
              states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0) %}
              {% set totaal = (p1 - correctie - zendure) * factor %} {% set
              beperkt = [ [totaal, 0] | max, cap ] | min %} {% set target =
              beperkt | int %} {% set huidig =
              states('sensor.zendure_2400_ac_ingesteld_ontlaadvermogen') |
              int(0) %} {{ huidig != target }}
        sequence:
          - data:
              outputLimit: >-
                {% set factor = 1.00 %} {% set cap = 2400 %} {% set correctie =
                20 %} {% set p1 =
                states('sensor.electricity_meter_active_power_nom') | float(0)
                %} {% set zendure =
                states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0)
                %} {% set totaal = (p1 - correctie - zendure) * factor %} {% set
                beperkt = [ [totaal, 0] | max, cap ] | min %} {{ beperkt | int
                }}
            action: rest_command.zendure_x_ontladen_balanceren
        alias: Tijdens ontladen balanceren naar 20 watt (100% van de vraag)
      - conditions:
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_vermogen_aansturing
            below: 0
          - condition: and
            conditions:
              - condition: numeric_state
                entity_id: sensor.electricity_meter_active_power_nom_avg
                below: 100
              - condition: numeric_state
                entity_id: sensor.electricity_meter_active_power_nom_avg
                above: 30
          - condition: or
            conditions:
              - condition: state
                entity_id: input_select.zendure_2400_ac_modus_selecteren
                state: Nul op de meter
              - condition: state
                entity_id: input_select.zendure_2400_ac_modus_selecteren
                state: Alleen slim ontladen
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            above: 10
        sequence:
          - data:
              outputLimit: >-
                {% set cap = 2400 %} {% set zendure =
                states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0)
                %} {% set totaal = -zendure + 5 %} {% set beperkt = [ [totaal,
                0] | max, cap ] | min %} {{ beperkt | int }}
            action: rest_command.zendure_x_ontladen_balanceren
        alias: Tijdens ontladen balanceren langzaam boven 30 Watt
      - conditions:
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_vermogen_aansturing
            below: 0
          - condition: and
            conditions:
              - condition: numeric_state
                entity_id: sensor.electricity_meter_active_power_nom_avg
                below: 10
              - condition: numeric_state
                entity_id: sensor.electricity_meter_active_power_nom_avg
                above: -60
          - condition: or
            conditions:
              - condition: state
                entity_id: input_select.zendure_2400_ac_modus_selecteren
                state: Nul op de meter
              - condition: state
                entity_id: input_select.zendure_2400_ac_modus_selecteren
                state: Alleen slim ontladen
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            above: 10
        sequence:
          - data:
              outputLimit: >-
                {% set cap = 2400 %} {% set zendure =
                states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0)
                %} {% set totaal = -zendure - 5 %} {% set beperkt = [ [totaal,
                0] | max, cap ] | min %} {{ beperkt | int }}
            action: rest_command.zendure_x_ontladen_balanceren
        alias: Tijdens ontladen balanceren langzaam onder 10 Watt

Voor:


Na:


De rode lijn is de output van de batterij en is in intervallen van 4 s. De blauwe lijn is het ruwe p1 signaal met intervallen van 1 s. De gele lijn is de 10 s gemiddelde van de blauwe lijn.

Voor de liefhebbers - het laadpercentage kun je ook per batterij uitlezen:

code:

      - name: "Zendure 2400 AC Batterij 1 Laadpercentage"
        value_template: "{{ value_json['packData'][0]['socLevel'] }}"
        device_class: battery
        unit_of_measurement: "%"
        state_class: measurement
        unique_id: Zendure_2400_AC_Batterij_1_Laadpercentage
        
      - name: "Zendure 2400 AC Batterij 2 Laadpercentage"
        value_template: "{{ value_json['packData'][1]['socLevel'] }}"
        device_class: battery
        unit_of_measurement: "%"
        state_class: measurement
        unique_id: Zendure_2400_AC_Batterij_2_Laadpercentage
        
      - name: "Zendure 2400 AC Batterij 3 Laadpercentage"
        value_template: "{{ value_json['packData'][2]['socLevel'] }}"
        device_class: battery
        unit_of_measurement: "%"
        state_class: measurement
        unique_id: Zendure_2400_AC_Batterij_3_Laadpercentage

[Taro]

@Bikkelreal Ik kan het bericht niet terugvinden, maar volgens mij was dat van jou waarin een klein bugje was opgelost ivm wel/niet meenemen EV lader in de "fake meter" berekening. Was dat een bericht van jou en kan jij hem wel terugvinden of die code nog even delen? Thx!

[gielz]

Newtonjan schreef op zaterdag 20 september 2025 @ 12:24:
@gielz Super bijdrage!

Ik wil volledig lokaal draaien, dus ben begonnen met jouw Automatisering en Configuration.yaml in versie 20250916. Inmiddels ben ik jouw script ook aan het aanpassen. Grootste reden is dat ik grote sprongen zie in mijn avond/nachtverbruik met de data vanuit de p1 meter als ik deze met een interval 1 s uitlees (ik gebruik een kabel vanuit de p1 poort naar de USB poort in mijn HA setup).

Mijn doel: een zo strak mogelijke NOM bij ontladen waarbij de batterij zo min mogelijk levert aan het net. Mijn doel is dus om de nacht alsnog op 20 W netto verbruik te zitten vanuit het net. Daarnaast wil ik zo min mogelijk onnodige wijzigingen in het verbruik van de batterij hebben. Echter, als er een grote sprong is in het verbruik wil ik ook dat de batterij zo snel mogelijk volgt.

Even tussendoor: Een Quooker is een apparaat wat voor een korte tijd veel energie vraagt. Een batterij kan dit nooit volgen op basis van de p1 data. Vandaar dat ik een sensor heb gemaakt (sensor.electricity_meter_active_power_nom) waarin het vermogen van de Quooker niet is opgenomen. Ik draait dus NOM met uitzondering van de Quooker.

Mijn idee: het energieverbruik meten met een interval van 1 s. Bij een groot netto verbruik (in mijn geval > 100 W of < -60 W) gebruik ik de aanpak om basis van de 1 s meting direct een grote stap te maken zoals in versie 20250916. Bij een klein netto verbruik (in mijn geval tussen de 10 W en 30 W) doe ik geen aanpassing naar het vermogen van de batterij. In de tussenliggende gebieden (dus binnen het interval 30 W en 100 W of binnen het interval -60 W en 10 W) doe ik een aanpassing van +5 W of -5 W richting de gewenste 20 W.

Onderstaande code zit in mijn Automation. Hierbij is sensor.electricity_meter_active_power_nom de p1 meter data. Daarnaast gebruik ik voor een vloeiendere sturing in de tussenliggende gebieden een helper van dit signaal: gemiddelde van de laatste 10 seconden in sensor.electricity_meter_active_power_nom_avg.

code:

      - conditions:
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_vermogen_aansturing
            below: 0
          - condition: or
            conditions:
              - condition: numeric_state
                entity_id: sensor.electricity_meter_active_power_nom
                above: 100
              - condition: numeric_state
                entity_id: sensor.electricity_meter_active_power_nom
                below: -60
          - condition: or
            conditions:
              - condition: state
                entity_id: input_select.zendure_2400_ac_modus_selecteren
                state: Nul op de meter
              - condition: state
                entity_id: input_select.zendure_2400_ac_modus_selecteren
                state: Alleen slim ontladen
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            above: 10
          - condition: template
            value_template: >-
              {% set factor = 1.00 %} {% set cap = 2400 %} {% set correctie = 20
              %} {% set p1 = states('sensor.electricity_meter_active_power_nom')
              | float(0) %} {% set zendure =
              states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0) %}
              {% set totaal = (p1 - correctie - zendure) * factor %} {% set
              beperkt = [ [totaal, 0] | max, cap ] | min %} {% set target =
              beperkt | int %} {% set huidig =
              states('sensor.zendure_2400_ac_ingesteld_ontlaadvermogen') |
              int(0) %} {{ huidig != target }}
        sequence:
          - data:
              outputLimit: >-
                {% set factor = 1.00 %} {% set cap = 2400 %} {% set correctie =
                20 %} {% set p1 =
                states('sensor.electricity_meter_active_power_nom') | float(0)
                %} {% set zendure =
                states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0)
                %} {% set totaal = (p1 - correctie - zendure) * factor %} {% set
                beperkt = [ [totaal, 0] | max, cap ] | min %} {{ beperkt | int
                }}
            action: rest_command.zendure_x_ontladen_balanceren
        alias: Tijdens ontladen balanceren naar 20 watt (100% van de vraag)
      - conditions:
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_vermogen_aansturing
            below: 0
          - condition: and
            conditions:
              - condition: numeric_state
                entity_id: sensor.electricity_meter_active_power_nom_avg
                below: 100
              - condition: numeric_state
                entity_id: sensor.electricity_meter_active_power_nom_avg
                above: 30
          - condition: or
            conditions:
              - condition: state
                entity_id: input_select.zendure_2400_ac_modus_selecteren
                state: Nul op de meter
              - condition: state
                entity_id: input_select.zendure_2400_ac_modus_selecteren
                state: Alleen slim ontladen
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            above: 10
        sequence:
          - data:
              outputLimit: >-
                {% set cap = 2400 %} {% set zendure =
                states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0)
                %} {% set totaal = -zendure + 5 %} {% set beperkt = [ [totaal,
                0] | max, cap ] | min %} {{ beperkt | int }}
            action: rest_command.zendure_x_ontladen_balanceren
        alias: Tijdens ontladen balanceren langzaam boven 30 Watt
      - conditions:
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_vermogen_aansturing
            below: 0
          - condition: and
            conditions:
              - condition: numeric_state
                entity_id: sensor.electricity_meter_active_power_nom_avg
                below: 10
              - condition: numeric_state
                entity_id: sensor.electricity_meter_active_power_nom_avg
                above: -60
          - condition: or
            conditions:
              - condition: state
                entity_id: input_select.zendure_2400_ac_modus_selecteren
                state: Nul op de meter
              - condition: state
                entity_id: input_select.zendure_2400_ac_modus_selecteren
                state: Alleen slim ontladen
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            above: 10
        sequence:
          - data:
              outputLimit: >-
                {% set cap = 2400 %} {% set zendure =
                states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0)
                %} {% set totaal = -zendure - 5 %} {% set beperkt = [ [totaal,
                0] | max, cap ] | min %} {{ beperkt | int }}
            action: rest_command.zendure_x_ontladen_balanceren
        alias: Tijdens ontladen balanceren langzaam onder 10 Watt

Voor:
[Afbeelding]

Na:
[Afbeelding]

De rode lijn is de output van de batterij en is in intervallen van 4 s. De blauwe lijn is het ruwe p1 signaal met intervallen van 1 s. De gele lijn is de 10 s gemiddelde van de blauwe lijn.

Voor de liefhebbers - het laadpercentage kun je ook per batterij uitlezen:

code:

      - name: "Zendure 2400 AC Batterij 1 Laadpercentage"
        value_template: "{{ value_json['packData'][0]['socLevel'] }}"
        device_class: battery
        unit_of_measurement: "%"
        state_class: measurement
        unique_id: Zendure_2400_AC_Batterij_1_Laadpercentage
        
      - name: "Zendure 2400 AC Batterij 2 Laadpercentage"
        value_template: "{{ value_json['packData'][1]['socLevel'] }}"
        device_class: battery
        unit_of_measurement: "%"
        state_class: measurement
        unique_id: Zendure_2400_AC_Batterij_2_Laadpercentage
        
      - name: "Zendure 2400 AC Batterij 3 Laadpercentage"
        value_template: "{{ value_json['packData'][2]['socLevel'] }}"
        device_class: battery
        unit_of_measurement: "%"
        state_class: measurement
        unique_id: Zendure_2400_AC_Batterij_3_Laadpercentage

Je kunt ook nog de "Helaas Pindakaas" chart gebruiken om goed te kijken naar de nog te behalen import/export. Alleen kijken naar het P1 seconden vermogen maakt je op gegeven moment gek.

Zelf hier ook met een gemiddelde getest in Mei en daar was uiteindelijk de conclusie om gewoon zo direct mogelijk te sturen zoals de Homewizard PIB ook doet (zijn daar helemaal gek op de NOM sturing in het topic). Dit kwam naar boven bij de "Helaas Pindakaas" chart.

Maar het mooie aan eigen sturing, je kunt gewoon heerlijk naar je eigen situatie het laten sturen.

code:

type: custom:apexcharts-card
cache: true
stacked: true
update_interval: 5sec
span:
  start: day
header:
  show: true
  show_states: true
  title: Helaas pindakaas
graph_span: 1d
series:
  - entity: sensor.p1_meter_energy_import
    name: Helaas pindakaas
    group_by:
      func: diff
      duration: 1h
    type: column
    stroke_width: 0
    opacity: 1
    extend_to: now
    color: "#f1b605"
    float_precision: 5
    yaxis_id: energy
    show:
      in_header: false
  - entity: sensor.p1_meter_energy_import
    yaxis_id: header_only
    name: Vandaag (import)
    float_precision: 3
    statistics:
      period: day
      type: change
      align: start
    show:
      legend_value: true
      in_header: true
      in_chart: false
apex_config:
  toolbar:
    show: true
    tools:
      download: true
      selection: true
      zoom: true
      zoomin: true
      zoomout: true
      pan: true
  tooltip:
    x:
      format: HH:mm:ss
      show: false
  xaxis:
    labels:
      show: false
      style:
        colors: grey
    axisTicks:
      show: false
    axisBorder:
      color: "#616269"
  yaxis:
    - title:
        text: ""
      decimalsInFloat: 3
      labels:
        style:
          colors: "#7b7c83"
  grid:
    strokeDashArray: 0
    borderColor: rgb(52,52,52)
    show: true
  chart:
    height: 200px
  legend:
    show: false
  markers:
    size: 0
    hover:
      size: 0

[gielz]

Taro schreef op zaterdag 20 september 2025 @ 13:01:
@Bikkelreal Ik kan het bericht niet terugvinden, maar volgens mij was dat van jou waarin een klein bugje was opgelost ivm wel/niet meenemen EV lader in de "fake meter" berekening. Was dat een bericht van jou en kan jij hem wel terugvinden of die code nog even delen? Thx!

Bedoel je toevallig niet deze? jordyc in "Zendure producten in Home Assistant integreren deel 2"

[Taro]

gielz schreef op zaterdag 20 september 2025 @ 16:45:
[...]


Bedoel je toevallig niet deze? jordyc in "Zendure producten in Home Assistant integreren deel 2"

Volgens mij wel

[Taro]

Aangezien ik de 2400AC's en SF800's nu niet meer via HW Energy Sockets meet ivm warmte heb ik er een aantal over. Waar de NOM het meeste moeite mee heeft zijn het koffiezetapparaat en de oven. De oven accepteer ik maar, want die stekker zal waarschijnlijk ook enorm warm worden, maar het koffiezetapparaat durf ik wel aan

Nou kan je natuurlijk 2 dingen doen:

• De input van die stekker negeren in je fake meter
• De input van de stekker iets langer compenseren, dus met vertraging naar 0 afbouwen. Stel je zet 2 bakjes koffie en 2x thee, dan wil je niet 4x aan/uit, maar eigenlijk 1x aan en als dan binnen bijv. 2 minuten niet nog een keer gebruik wordt gemaakt van het apparaat de sensor pas weer naar 0 laten gaan.

Ja, micromanagement, maar gewoon leuk om op een regenachtige dag te maken.

Hoe gaan anderen met bijv. een Quooker hier mee om, los van gewoon accepteren? Ik weet dat @mrme12345 heeft ingebouwd om die te negeren. Maar zijn er ook andere oplossingsrichtingen gekozen?

[mrme12345]

Taro schreef op zaterdag 20 september 2025 @ 17:09:
Aangezien ik de 2400AC's en SF800's nu niet meer via HW Energy Sockets meet ivm warmte heb ik er een aantal over. Waar de NOM het meeste moeite mee heeft zijn het koffiezetapparaat en de oven. De oven accepteer ik maar, want die stekker zal waarschijnlijk ook enorm warm worden, maar het koffiezetapparaat durf ik wel aan

Nou kan je natuurlijk 2 dingen doen:

• De input van die stekker negeren in je fake meter
• De input van de stekker iets langer compenseren, dus met vertraging naar 0 afbouwen. Stel je zet 2 bakjes koffie en 2x thee, dan wil je niet 4x aan/uit, maar eigenlijk 1x aan en als dan binnen bijv. 2 minuten niet nog een keer gebruik wordt gemaakt van het apparaat de sensor pas weer naar 0 laten gaan.

Ja, micromanagement, maar gewoon leuk om op een regenachtige dag te maken.

Hoe gaan anderen met bijv. een Quooker hier mee om, los van gewoon accepteren? Ik weet dat @mrme12345 heeft ingebouwd om die te negeren. Maar zijn er ook andere oplossingsrichtingen gekozen?

Ik negeer het enkel in mijn script voor ev en pv overschot laden. Want bij een quooker zijn het piekjes van 10sec en dan is het weer nul, dus dat kun je niet gecompenseerd krijgen en wil ik ook niet als mijn ev aan het laden is. Dan accepteer ik die 10sec piek. Het is wat anders als je de quooker echt gebruikt. Dan moet die wel compenseren want dan staat die paar minuten aan op 1800W. Dus als de piek langer dan 10sec duurt gaat die compenseren in de scripts anders niet. En ik doe hem snachts ook uit, en dan gecontroleerd smorgens weer aan. Allemaal micro-management, maar wel leuk inderdaad ;-)

[gielz]

Hier laat ik het bewust gewoon zonder een extra instelling door gaan. Bijvoorbeeld bij de oven ziet het er dan zo uit. Bij de Homewizard PIB ging dit exact zo.



Eerst was het idee om volle bak te gaan ontladen tijdens het koken met als trigger de afzuigkap maar die stroom kan ik toch wel weer mooi in de avond/nacht gebruiken.

[mrme12345]

gielz schreef op zaterdag 20 september 2025 @ 17:50:
Hier laat ik het bewust gewoon zonder een extra instelling door gaan. Bijvoorbeeld bij de oven ziet het er dan zo uit. Bij de Homewizard PIB ging dit exact zo.

[Afbeelding]

Eerst was het idee om volle bak te gaan ontladen tijdens het koken met als trigger de afzuigkap maar die stroom kan ik toch wel weer mooi in de avond/nacht gebruiken.

Ja ik maak daar onderscheid tussen zeg maar maanden mei-aug en rest van het jaar. In de zonnige maanden met overvloed zonnestroom lever ik tijdens koken volle bak terug. Want mijn batterijen lopen dan toch wel weer vol volgende dag. In flankmaanden zal ik dat ook beheerster moeten doen, want dan is het zonde. En je krijgt er natuurlijk wel goede prijs voor bij dynamisch en rond 6 uur.

[Bikkelreal]

Taro schreef op zaterdag 20 september 2025 @ 13:01:
@Bikkelreal Ik kan het bericht niet terugvinden, maar volgens mij was dat van jou waarin een klein bugje was opgelost ivm wel/niet meenemen EV lader in de "fake meter" berekening. Was dat een bericht van jou en kan jij hem wel terugvinden of die code nog even delen? Thx!

Mm heb de ev niet meegenomen in Fake meter, ik gebruik dan een soort fake meter manuel laden.
In automation als EV aan het laden is en batterij moet laden dan spring hij naar de die fake meter, zodat de zendure intregatie gewoon op smart blijft staan.

Power Manuel Charging vorbeeld 4k laden
{{ -4000 + states('sensor.battery_input_total')|float(0) - states('sensor.p1_meter_api_v1')|float(0)/1000 }}

Heb deze voor ontladen:

Power Manuel Discharging
{{ 4000 - states('sensor.battery_output_total')|float(0) - states('sensor.p1_meter_api_v1')|float(0)/1000 }}

[R.K]

In mijn goedkoopste uren opladen automatisering heb ik geprobeerd in te stellen om niet met 2400 watt op te laden. Maar ik krijg dat niet voor elkaar. Ik heb in de app de limieten aangepast, maar HA reageert daar niet op. Blijft met 2400 watt opladen. Heb ook de gielz automatisering geprobeerd aan te passen door 2400% aan te passen naar 2000% , daar reageert ha ook niet op. Wat doe ik fout?

[gielz]

R.K schreef op zondag 21 september 2025 @ 12:39:
In mijn goedkoopste uren opladen automatisering heb ik geprobeerd in te stellen om niet met 2400 watt op te laden. Maar ik krijg dat niet voor elkaar. Ik heb in de app de limieten aangepast, maar HA reageert daar niet op. Blijft met 2400 watt opladen. Heb ook de gielz automatisering geprobeerd aan te passen door 2400% aan te passen naar 2000% , daar reageert ha ook niet op. Wat doe ik fout?

Zou je even je properties kunnen posten? En geef daar even bij aan wanneer je mijn sturing gebruikt met welke modus je gaat laden. Is dit handmatig of de snel opladen functie?

Mag ook via DM.

[DrNickB]

Goedemiddag Allen,

Ik was benieuwd of er iemand hier was die de Gielz integratie heeft draaien met een SF800Pro en aangesloten panelen?
Het gaat mij dan specifiek om de 'Nul op de Meter' of Slim Ontladen (zelfde stuk code dacht ik),
tijdens een zonnige dag, waarbij de batterij aan het laden is.


Kleine onderbouwing:
Ik heb sinds kort hier een SF800P staan, daarbij gebruik ik een aansturing via mijn USB-P1 meter.
Deze heeft alleen Positieve getallen op L1-L3 op Consumption en Production.
Hierdoor heb ik een eigen Sensor aangemaakt, die Consumption en Production van elkaar aftrekt,
waardoor ik een mooie negatieve of positieve 'stroom flow' heb gecreeerd.
Hiermee werkt NOM best goed als er geen zon is of als de zon te weinig is om ook de batterijen op te laden.

Nu komt het, wanneer er bijvoorbeeld 200w zonnestroom is op de PV, het huis heeft 150W verbruik en de accu's zijn niet vol. Zou de 'NOM' aansturing 150w moeten leveren uit de zon, en 50w de batterij moeten laten laden.
Echter lijkt het er sterk op (helaas maar paar keer gezien en niet actief kunnen opslaan!) dat de NOM intergratie deze 50w opladen ziet als daadwerkelijk opladen, waardoor hij deze in mindering brengt van de 150w levering.

Tot op een moment dat de zonneproductie zo hoog ligt, dat er zelfs uit het net (lijkt) te gaan worden geladen op moment dat deze conditie zo is.

Volgens mij komt dat door dit stukje code, maar ben er nog niet helemaal in gedoken,
was benieuwd of er toevallig iemand hier al iets over was tegen gekomen.

code:

      - name: "Zendure 800 Pro Vermogen Aansturing"
        value_template: >
          {% set opladen = value_json['properties']['outputPackPower'] | int %}
          {% set ontladen = - (value_json['properties']['packInputPower'] | int) %}
          {% if opladen != 0 %}
            {{ opladen }}
          {% else %}
            {{ ontladen }}
          {% endif %}
        unique_id: zendure_800_pro_Vermogen_Aansturing
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

*edit: ik heb volgens mij nog wel verschillende json exports van de zendure api van zo een moment

[gielz]

DrNickB schreef op zondag 21 september 2025 @ 15:08:
Goedemiddag Allen,

Ik was benieuwd of er iemand hier was die de Gielz integratie heeft draaien met een SF800Pro en aangesloten panelen?
Het gaat mij dan specifiek om de 'Nul op de Meter' of Slim Ontladen (zelfde stuk code dacht ik),
tijdens een zonnige dag, waarbij de batterij aan het laden is.


Kleine onderbouwing:
Ik heb sinds kort hier een SF800P staan, daarbij gebruik ik een aansturing via mijn USB-P1 meter.
Deze heeft alleen Positieve getallen op L1-L3 op Consumption en Production.
Hierdoor heb ik een eigen Sensor aangemaakt, die Consumption en Production van elkaar aftrekt,
waardoor ik een mooie negatieve of positieve 'stroom flow' heb gecreeerd.
Hiermee werkt NOM best goed als er geen zon is of als de zon te weinig is om ook de batterijen op te laden.

Nu komt het, wanneer er bijvoorbeeld 200w zonnestroom is op de PV, het huis heeft 150W verbruik en de accu's zijn niet vol. Zou de 'NOM' aansturing 150w moeten leveren uit de zon, en 50w de batterij moeten laten laden.
Echter lijkt het er sterk op (helaas maar paar keer gezien en niet actief kunnen opslaan!) dat de NOM intergratie deze 50w opladen ziet als daadwerkelijk opladen, waardoor hij deze in mindering brengt van de 150w levering.

Tot op een moment dat de zonneproductie zo hoog ligt, dat er zelfs uit het net (lijkt) te gaan worden geladen op moment dat deze conditie zo is.

Volgens mij komt dat door dit stukje code, maar ben er nog niet helemaal in gedoken,
was benieuwd of er toevallig iemand hier al iets over was tegen gekomen.

code:

      - name: "Zendure 800 Pro Vermogen Aansturing"
        value_template: >
          {% set opladen = value_json['properties']['outputPackPower'] | int %}
          {% set ontladen = - (value_json['properties']['packInputPower'] | int) %}
          {% if opladen != 0 %}
            {{ opladen }}
          {% else %}
            {{ ontladen }}
          {% endif %}
        unique_id: zendure_800_pro_Vermogen_Aansturing
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

*edit: ik heb volgens mij nog wel verschillende json exports van de zendure api van zo een moment

@AWEF heeft ook een 800 pro met zonnepanelen en het volledig werkend geloof ik met een simpele aanpassing.

[DrNickB]

gielz schreef op zondag 21 september 2025 @ 15:22:
[...]


@AWEF heeft ook een 800 pro met zonnepanelen en het volledig werkend geloof ik met een simpele aanpassing.

Ja volgens mij hoeft ook niet iets heel ingewikkelds te zijn, alleen mijn hoofd heeft nog even de nummers niet op een rij om deze te pakken

* net toevallig schoot de zon even omhoog, even NOM aangezet, hij zet hem wel aan het 'opladen' echter is dit niet via het net, maar hij stopt wel met leveren. dan draai ik NOM op mijn HW plug (die voor de SF800P zit)

[AWEF]

Ik heb idd een SF800Pro draaien met 2 panelen, maar het valt me op dat bij wisselende omstandigheden hij niet altijd reageert zoals ik het zo verwachten. Het lijkt er op dat de modus soms de weg kwijt is: deze staat bijv. nu op "ontladen" terwijl er 500+ watt wordt teruggeleverd aan het net. Het is me al vaker ogevallen, maar nog geen tijd voor gehad om er in te duiken.

En hetgene wat ik heb aangepast zijn de volgende zaken:
- In een apparte yaml gezet
- De naam aangepast
- De sensoren voor de zonnepanelen erbij gezet
- In de automation de 1 uur na zonsopkomst en 1 uur voor zonsondergang eruit gehaald
- De offset voor het terugleveren van -80 naar -50 gezet
- Aanpassing gedaan dat het oplaad vermogen ook de zonnepanelen mee neemt, de originele versie van @gielz zou neerkomen op max 1600 watt laden en dat vondt ik wat veel van het goede met 1 accu

[ Voor 12% gewijzigd door AWEF op 21-09-2025 16:35 ]

[DrNickB]

AWEF schreef op zondag 21 september 2025 @ 16:29:
- Aanpassing gedaan dat het oplaad vermogen ook de zonnepanelen mee neemt, de originele versie van @gielz zou neerkomen op max 1600 watt laden en dat vondt ik wat veel van het goede met 1 accu

Ik heb het meeste ook inderdaad gedaan, meer specifiek voor de 800 gemaakt ipv de 2400.
En hoe heb de laatst genoemde gedaan? (wat bedoel je hier precies meer qua aanpassingen?)

Ik zal die deel automations, voor zon opkomst en ondergang, er ook nog even uit halen, want laden via net is bij mij (vast contract) totaal niet zinvol, doe ik wel handmatig, als ik het wel een keer nodig vindt.

[AWEF]

DrNickB schreef op zondag 21 september 2025 @ 16:41:
[...]

Ik heb het meeste ook inderdaad gedaan, meer specifiek voor de 800 gemaakt ipv de 2400.
En hoe heb de laatst genoemde gedaan? (wat bedoel je hier precies meer qua aanpassingen?)

Ik zal die deel automations, voor zon opkomst en ondergang, er ook nog even uit halen, want laden via net is bij mij (vast contract) totaal niet zinvol, doe ik wel handmatig, als ik het wel een keer nodig vindt.

Ik heb een sensor voor de solare opbrengst toegevoegd en deze in de laden gedeeltes van de automation opgenomen, zie de template hieronder (de zenduresolar waarde).

code:

{% set factor = 1.00 %}
{% set cap = 800 %}
{% set correctie_export = 50 %}
{% set p1 = states('sensor.p1_aansturing_api_v1') | float(0) %}
{% set zendure = states('sensor.zendure_800_pro_vermogen_aansturing') |float(0) %}
{% set zenduresolar = states('sensor.zendure_800_pro_vermogen_solar_total') | float(0) %}
{% set verschil = zendure - zenduresolar - p1 - correctie_export %}
{% set cap = cap - zenduresolar %}
{% set beperkt = verschil * factor if verschil > 0 else 0 %}
{% set beperkt = beperkt if beperkt < cap else cap %}
{{ beperkt | int }}

[dr.trimble]

Het is me nog steeds niet helemaal duidelijk: als ik zensdk wil gebruiken, moet ik dan eerst de zendure plugin via HACS installeren of is dit niet nodig

[DrNickB]

dr.trimble schreef op maandag 22 september 2025 @ 20:19:
Het is me nog steeds niet helemaal duidelijk: als ik zensdk wil gebruiken, moet ik dan eerst de zendure plugin via HACS installeren of is dit niet nodig

Nee, voor de ZenSDK met de Gielz automatisering hoef je eigenlijk weinig te doen.
Zoek het IP adres van je Zendure apparaat,
Pak de configuratie en automation yaml bestanden uit de start post,
pas deze aan op de dingen die je hebt, nodig hebt en sla deze op.

(hiervoor moet je wel actief de hoofd configuratie en automations bestanden bewerken, maak even kopie voor je start).

Doe in Home Assistant Developer een Config check en restart HA.

[dr.trimble]

Thx DrNickB, het is me al iets duidelijker. Nog ff een vraagje: in de configuration.yaml wordt er verwezen naar het IP-adres van je homewizard P1 meter. Ik heb de Zendure P1 meter. Moet ik dan ook gewoon het ip-adres van deze ingeven of gaat dit niet werken?

[gielz]

dr.trimble schreef op maandag 22 september 2025 @ 21:02:
Thx DrNickB, het is me al iets duidelijker. Nog ff een vraagje: in de configuration.yaml wordt er verwezen naar het IP-adres van je homewizard P1 meter. Ik heb de Zendure P1 meter. Moet ik dan ook gewoon het ip-adres van deze ingeven of gaat dit niet werken?

Je kunt de P1 Homewizard regels vervangen voor deze (niet getest);

code:

- resource: http://<IP-ZENDURE-P1>/properties/report   # Zendure P1
    scan_interval: 1
    sensor:
      - name: "P1 Aansturing API v1"
        value_template: "{{ value_json['total_power'] }}"
        unique_id: P1_Aansturing_API_V1
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

[DrNickB]

@gielz @AWEF
Ik heb het aan de praat.
Lang verhaal kort, ik had al de juiste formule in gebruik na aanpassingen, maar werd door een conditie in de automation overruled/ niet uitgevoerd.
Dus nu 700w zon opwek, 200w verbruik (=200w leveren) en 500w laden.
Op dit moment voor de test ook nog terug levering uit staan in de zendure app.

[Gyrolion]

Hier nu de automation van Gielz draaiende gemaakt, nog wel barebones zoals hij in de TP staat.
Maar hij werkt zo wel prima al om de boel op nul te houden!

Nu wil ik een aantal dingen toevoegen zoals het kijken naar dynamische prijzen, maar het belangrijkste voor mij is de optie dat de accu niet gaat ontladen als de auto staat de laden, dat is voor mij momenteel het grooste pijnpunt.

Nu heb ik de volgende meting "sensor.tesla_wall_connector_status" en deze gaat naar Opladen als de auto staat op de laden.

Heeft iemand een idee hoe ik deze in de automation yaml goed krijg, of moet ik deze los er van configureren? ChatGPT en Grok helpen mij niet echt verder en maken de boel alleen maar verder kapot.

[ Voor 5% gewijzigd door Gyrolion op 23-09-2025 15:20 ]

[AWEF]

Gyrolion schreef op dinsdag 23 september 2025 @ 15:15:
Hier nu de automation van Gielz draaiende gemaakt, nog wel barebones zoals hij in de TP staat.
Maar hij werkt zo wel prima al om de boel op nul te houden!

Nu wil ik een aantal dingen toevoegen zoals het kijken naar dynamische prijzen, maar het belangrijkste voor mij is de optie dat de accu niet gaat ontladen als de auto staat de laden, dat is voor mij momenteel het grooste pijnpunt.

Nu heb ik de volgende meting "sensor.tesla_wall_connector_status" en deze gaat naar Opladen als de auto staat op de laden.

Heeft iemand een idee hoe ik deze in de automation yaml goed krijg, of moet ik deze los er van configureren? ChatGPT en Grok helpen mij niet echt verder en maken de boel alleen maar verder kapot.

Zoals hier al eerder gemeld is, het beste is om een losse automation aan te maken die de modus van @gielz z'n config aanpast. Ik heb ongeveer het zelfde, maar dan met een alfen laadpaal. In een losse automation heb ik gezegd dat als die stroom gaat gebruiken (dus de auto aan het laden is), wordt de modus naar "Standby" gezet. Zodra de auto niet meer laad, gaat die weer naar "Nul op de meter". Dit zou je ook kunnen doen met dynamische tarieven: Laag tarief modus "Vol opladen" kiezen en eventueel bij hoge tarieven "Vol ontladen"

[Gyrolion]

AWEF schreef op dinsdag 23 september 2025 @ 15:40:
[...]


Zoals hier al eerder gemeld is, het beste is om een losse automation aan te maken die de modus van @gielz z'n config aanpast. Ik heb ongeveer het zelfde, maar dan met een alfen laadpaal. In een losse automation heb ik gezegd dat als die stroom gaat gebruiken (dus de auto aan het laden is), wordt de modus naar "Standby" gezet. Zodra de auto niet meer laad, gaat die weer naar "Nul op de meter". Dit zou je ook kunnen doen met dynamische tarieven: Laag tarief modus "Vol opladen" kiezen en eventueel bij hoge tarieven "Vol ontladen"

Thanks! We hebben even off-record gecommuniceerd maar nu werkt het.
Ik kan veilig de auto laden zonder de accu te ontladen.

Het is de volgende automation geworden:

code:

alias: Tesla Laadpaal status
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.tesla_wall_connector_status
    enabled: true
conditions: []
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: sensor.tesla_wall_connector_status
            state: charging
        sequence:
          - action: input_select.select_option
            metadata: {}
            data:
              option: Standby
            target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
      - conditions:
          - condition: not
            conditions:
              - condition: state
                entity_id: sensor.tesla_wall_connector_status
                state: charging
        sequence:
          - action: input_select.select_option
            metadata: {}
            data:
              option: Nul op de meter
            target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
mode: single

Volgende stap maar dat is voor een andere dag, is gaan rommelen met dynamische tarieven. En dan ook iets wat ik een beetje set en forget kan zetten.

[ Voor 36% gewijzigd door Gyrolion op 23-09-2025 16:18 ]

[klump4u]

Gyrolion schreef op dinsdag 23 september 2025 @ 16:16:
[...]


Thanks! We hebben even off-record gecommuniceerd maar nu werkt het.
Ik kan veilig de auto laden zonder de accu te ontladen.

Het is de volgende automation geworden:

code:

alias: Tesla Laadpaal status
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.tesla_wall_connector_status
    enabled: true
conditions: []
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: sensor.tesla_wall_connector_status
            state: charging
        sequence:
          - action: input_select.select_option
            metadata: {}
            data:
              option: Standby
            target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
      - conditions:
          - condition: not
            conditions:
              - condition: state
                entity_id: sensor.tesla_wall_connector_status
                state: charging
        sequence:
          - action: input_select.select_option
            metadata: {}
            data:
              option: Nul op de meter
            target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
mode: single

Volgende stap maar dat is voor een andere dag, is gaan rommelen met dynamische tarieven. En dan ook iets wat ik een beetje set en forget kan zetten.

Hier mogen de auto’s in de avond en nacht gewoon de volle 2400kWh uit de Zendure halen, of de stroom nu naar de vaatwasser gaat of de auto in, ergens moet ik toch inkopen. Overdag mag de auto alleen zonnestroom laden net zoals de Zendure.

[Gyrolion]

Sinds kort ondersteund Tibber voor Tesla de grid rewards zonder een aparte laadpaal, dat houdt in dat de prijs dan kunstmatig naar een hele lage waarde wordt gebracht. Van bijvoorbeeld 25 cent --> 15 / 10 cent.
Om dan de accu te gaan ontladen is natuurlijk zonde, dan is het in mijn geval juist beter om de accu te gaan laden.
Maar dan kom ik als ik niet uit kijk in de knoei met overbelasting op mijn hoofdzekering.

Daarom voor nu even simpel houden.

[ Voor 5% gewijzigd door Gyrolion op 23-09-2025 16:32 ]

[Tijgerkracht]

klump4u schreef op dinsdag 23 september 2025 @ 16:28:
[...]

Hier mogen de auto’s in de avond en nacht gewoon de volle 2400kWh uit de Zendure halen, of de stroom nu naar de vaatwasser gaat of de auto in, ergens moet ik toch inkopen. Overdag mag de auto alleen zonnestroom laden net zoals de Zendure.

Hier mag de stroom niet van de accu naar de auto, je hebt dan 2x omvormer verlies, dus dat blokkeer ik zoveel mogelijk

[klump4u]

Tijgerkracht schreef op dinsdag 23 september 2025 @ 17:11:
[...]


Hier mag de stroom niet van de accu naar de auto, je hebt dan 2x omvormer verlies, dus dat blokkeer ik zoveel mogelijk

Die snap ik niet? Naar de vaatwasser is toch ook 2 keer verlies?

[gielz]

klump4u schreef op dinsdag 23 september 2025 @ 19:37:
[...]

Die snap ik niet? Naar de vaatwasser is toch ook 2 keer verlies?

Zit het niet zo?

Zon naar Batterij naar huis DC > AC > DC > AC
Zon naar Batterij naar auto DC > AC > DC > AC > DC > AC
Zon naar Batterij naar vaatwasser DC > AC > DC > AC

[klump4u]

gielz schreef op dinsdag 23 september 2025 @ 19:42:
[...]


Zit het niet zo?

Zon naar Batterij naar huis DC > AC > DC > AC
Zon naar Batterij naar auto DC > AC > DC > AC > DC > AC
Zon naar Batterij naar vaatwasser DC > AC > DC > AC

Klopt wel maar als ik de auto uit het net laadt dan heb ik ook AC>DC, dus waar zit de winst?

[gielz]

klump4u schreef op dinsdag 23 september 2025 @ 20:07:
[...]

Klopt wel maar als ik de auto uit het net laadt dan heb ik ook AC>DC, dus waar zit de winst?

Heb zelf geen EV maar ik zou zeggen je laad hem op uit de batterij is 15% extra verlies. Die heb je dan niet als je hem direct van uit het net vol knalt. Maar is wellicht meer voor een ander topic

[klump4u]

gielz schreef op dinsdag 23 september 2025 @ 20:12:
[...]


Heb zelf geen EV maar ik zou zeggen je laad hem op uit de batterij is 15% extra verlies. Die heb je dan niet als je hem direct van uit het net vol knalt. Maar is wellicht meer voor een ander topic

Het wordt regelmatig hier naar voren gebracht om er een automatiek van te maken, die extra 15% verlies is dan van de accu neem ik aan? Die heb ik toch ook als ik de accu voor het huishouden gebruik? Ik begrijp niet waar het extra verlies dan in zit.

[Tijgerkracht]

klump4u schreef op dinsdag 23 september 2025 @ 19:37:
[...]

Die snap ik niet? Naar de vaatwasser is toch ook 2 keer verlies?

Uitgaande van een AC2400 die alleen uit het net kan laden

Vaatwasser:
AC->DC-AC->Vaatwasser (2x omzetten)

Electrische auto
AC(net)->DC(accu in)->AC(accu uit)->DC(auto in) als je laad vanuit de batterij
AC(net)->DC(auto in) als je laad vanuit het net (1x omzetten)
Bij laden uit het net heb je dus minder omzet verlies.

[klump4u]

Tijgerkracht schreef op dinsdag 23 september 2025 @ 20:44:
[...]


Uitgaande van een AC2400 die alleen uit het net kan laden

Vaatwasser:
AC->DC-AC->Vaatwasser (2x omzetten)

Electrische auto
AC(net)->DC(accu in)->AC(accu uit)->DC(auto in) als je laad vanuit de batterij
AC(net)->DC(auto in) als je laad vanuit het net (1x omzetten)
Bij laden uit het net heb je dus minder omzet verlies.

Dat zeg ik ook de hele tijd maar het maakt toch niks uit of je nu 2 maal omzet voor je huishouden of 2 maal voor je auto. Die accu maakt het niet uit waaraan je hem leegmaakt de uitgaande kWh blijven toch gelijk.

[Tijgerkracht]

klump4u schreef op dinsdag 23 september 2025 @ 20:49:
[...]

Dat zeg ik ook de hele tijd maar het maakt toch niks uit of je nu 2 maal omzet voor je huishouden of 2 maal voor je auto. Die accu maakt het niet uit waaraan je hem leegmaakt de uitgaande kWh blijven toch gelijk.

Als je de nacht door kan komen met goedkope stroom uit je batterij en de auto opladen niet nee.
Ik laad de EV hier alleen overdag op overschot zonnestroom en kom de nacht dan net door met de Zendure.
Maar ja, ik heb slechts 3x AB3000X

[gielz]

Een tijd geleden had ik eens gekeken wat er in de battery packs voor vermogen voorbij komt en dan uiteindelijk uit de omvormer komt via zenSDK. Niets meer mee gedaan tot de post van @Aardedraadje dat daar wellicht de efficentie uit berekend kan worden.

Sinds gisteren begonnen met testen en dat het plug-n-play is. Dat wil zeggen configuration.yaml paar regeltjes toevoegen en lekker laten draaien.

Zie hier het voorlopige resultaat

[R.K]

Ik gebruik de laatste versie van de @gielz aansturing en automatisering. Lijkt het zelfs beter te doen dan de vorige.
In de nacht zie ik in mijn verbruiks-grafiek een keurige flatline (nom) ik zie echter een trend dat na een dag zonneladen en terugleveren dat de flatline niet automatisch terugkomt, ik schakel dan van nom naar een andere modus en weer terug naar nom, en dan werkt het weer goed. Waar kan dit aan liggen? Zie het streepje bij 18.50 uur.

[ Voor 31% gewijzigd door R.K op 24-09-2025 19:35 ]

[gielz]

R.K schreef op woensdag 24 september 2025 @ 19:31:
Ik gebruik de laatste versie van de @gielz aansturing en automatisering. Lijkt het zelfs beter te doen dan de vorige.
In de nacht zie ik in mijn verbruiks-grafiek een keurige flatline (nom) ik zie echter een trend dat na een dag zonneladen en terugleveren dat de flatline niet automatisch terugkomt, ik schakel dan van nom naar een andere modus en weer terug naar nom, en dan werkt het weer goed. Waar kan dit aan liggen? Zie het streepje bij 18.50 uur.[Afbeelding]

Ziet er heel goed uit! Wat je hier ziet is het moment dat de zon weg is en hij over moet gaan op ontladen om weer naar 0 te balanceren. Het start gedrag staat op 100 watt ingesteld en daarna zal hij naar 0 gaan balanceren.

Ik denk trouwens dat je niet de nieuwste automatisering hebt. In die van jou zit nog uitgesteld laden wat in de nieuwe versie niet meer zit. Je kunt dit zien in de automatisering description daar staat een versie datum.

[R.K]

Ik gebruik deze versie, van de week van github gehaald.

[gielz]

R.K schreef op woensdag 24 september 2025 @ 20:02:
Ik gebruik deze versie, van de week van github gehaald.[Afbeelding]

Dat is inderdaad de huidige versie, maar ziet er goed uit hoor. Heb je zelf iets gemaakt voor uitgesteld laden want ik zou dat export gedeelte in de ochtend niet verwachten alvorens hij gaat laden.

[R.K]

gielz schreef op woensdag 24 september 2025 @ 19:55:
[...]


Ziet er heel goed uit! Wat je hier ziet is het moment dat de zon weg is en hij over moet gaan op ontladen om weer naar 0 te balanceren. Het start gedrag staat op 100 watt ingesteld en daarna zal hij naar 0 gaan balanceren.

Dus als ik modus Nul op de meter draai de hele dag zou die flatline vanzelf terug moeten komen?

[R.K]

gielz schreef op woensdag 24 september 2025 @ 20:04:
[...]


Dat is inderdaad de huidige versie, maar ziet er goed uit hoor. Heb je zelf iets gemaakt voor uitgesteld laden want ik zou dat export gedeelte in de ochtend niet verwachten alvorens hij gaat laden.

Klopt, ik heb zelf iets gemaakt waardoor hij duurste uur exporteert. En dat was toevallig vanochtend.

[ Voor 4% gewijzigd door R.K op 24-09-2025 21:42 ]

[gielz]

R.K schreef op woensdag 24 september 2025 @ 20:06:
[...]


Dus als ik modus Nul op de meter draai de hele dag zou die flatline vanzelf terug moeten komen?

Klopt, zodra hij 100+ watt aanraakt gaat hij starten met ontladen en naar 0 watt toe. Mocht dit niet het geval zijn dan hoor ik dat graag dan kijken wij er even samen naar via DM. Wellicht heb je dan een bug gevonden.

Hier werkt het al maanden exact zoals een Homewizard PiB NOM draait.

[Aardedraadje]

Ik ben er nog wat mee aan het spelen maar deel graag alvast een voorlopig resultaat van een demping die ik aan het proberen ben.

Mij slimme meter (Kaifa, DSMR4) spoort niet helemaal. Ten eerste stuurt hij elke 10s een datagram, maar is de meting niet van de afgelopen 10s. Eerder een gemiddelde van de afgelopen 20-30 seconden.

Ten tweede gaat hij niet goed om met kleine schommelingen rond de nul. Het lijkt wel alsof hij soms vergeet om het teken (positief/negatief) om te wisselen en daarna met een extra grote stap de andere kant op even corrigeert. Het gevolg:



Zowel HW als Gielz aansturing hebben hier last van.

Vannacht geNOMd met de volgende wijzigingen:
- Elke regelactie wordt gedempt. De nieuw berekende stuurwaarde wordt voor slechts 50% meegenomen. De oude stuurwaarde geldt ook voor 50%.
- Wanneer ik binnen 20W van de gewenste waarde zit, geldt de nieuwe stuurwaarde voor 10%. De oude stuurwaarde voor 90%.

Vooral dat laatste helpt bij mijn meter enorm, omdat de meter dus niet lekker omgaat met het nulpunt. Dit levert het volgende plaatje op. Spot het punt waar ik overschakel naar de PiB



Ik moet deze bevindingen ook maar terugkoppelen aan HW. Maar man wat is het leuk om hier gewoon zelf mee te kunnen spelen.

[Mediacj]

Aardedraadje schreef op donderdag 25 september 2025 @ 05:55:
Mij slimme meter (Kaifa, DSMR4) spoort niet helemaal. Ten eerste stuurt hij elke 10s een datagram, maar is de meting niet van de afgelopen 10s. Eerder een gemiddelde van de afgelopen 20-30 seconden.

Ten tweede gaat hij niet goed om met kleine schommelingen rond de nul. Het lijkt wel alsof hij soms vergeet om het teken (positief/negatief) om te wisselen en daarna met een extra grote stap de andere kant op even corrigeert. Het gevolg:

Zou voor mij een reden zijn om bij de netbeheerder te zeuren voor een nieuwe DSMR5 meter

[DrNickB]

Aardedraadje schreef op donderdag 25 september 2025 @ 05:55:
Zowel HW als Gielz aansturing hebben hier last van.

Vannacht geNOMd met de volgende wijzigingen:
- Elke regelactie wordt gedempt. De nieuw berekende stuurwaarde wordt voor slechts 50% meegenomen. De oude stuurwaarde geldt ook voor 50%.
- Wanneer ik binnen 20W van de gewenste waarde zit, geldt de nieuwe stuurwaarde voor 10%. De oude stuurwaarde voor 90%.

Zou je een code snippet kunnen delen an je berekeningen(als dat hier past)?
Heb hier zelf ook last van, heb wel updates elke seconde, en al mijn sensoren updaten bij wijziging,
Alleen als bijvoorbeeld de inductie kookplaat aanstaat, op een 'warm houdt standje' dan schiet hij per seconde aan en uit, wat pieken opleverd en hij heel veel corrigeert. (Gielz update zelf elke 4 sec)

Heb zelf nog geen echte logica om echt te detecteren of het de kook plaat is en daarop weer te gaan sturen, dus een iets minder heftige op en neer zou ook cool zijn in dit geval.

[gielz]

DrNickB schreef op donderdag 25 september 2025 @ 18:57:
[...]


Zou je een code snippet kunnen delen an je berekeningen(als dat hier past)?
Heb hier zelf ook last van, heb wel updates elke seconde, en al mijn sensoren updaten bij wijziging,
Alleen als bijvoorbeeld de inductie kookplaat aanstaat, op een 'warm houdt standje' dan schiet hij per seconde aan en uit, wat pieken opleverd en hij heel veel corrigeert. (Gielz update zelf elke 4 sec)

Heb zelf nog geen echte logica om echt te detecteren of het de kook plaat is en daarop weer te gaan sturen, dus een iets minder heftige op en neer zou ook cool zijn in dit geval.

Heb je ook gekeken wat dat pingpongen kost? Hier bijvoorbeeld vanavond 0,141kwh import door inductie koken (3 pitten). Je zou dit bijvoorbeeld kunnen detecteren door een HW energysocket op de afzuigkap. Maar dan zal je waarschijnlijk wel een stuk meer gaan exporteren tijdens die kookbeurt.



Bij de Homewizard PIB zag ik exact dit zelfde gedrag.

[DrNickB]

gielz schreef op donderdag 25 september 2025 @ 19:32:
[...]
Heb je ook gekeken wat dat pingpongen kost?

Het is zeker geen verwijd op de automatisering.
Want hij werkt verder prima.

Het kost me 'niks', sf800p kan toch me kookplaat niet volledig leveren. Mag nog salderen onder de 500kwh zonder kosten (pas net 2weken panelen).
Ik weet alleen niet hoe goed het is om van 800 naar 200 en weer terug te gaan om de 4 sec. Voor de hardware.

Me led tv is ook te merken met verschillende kleuren en intensiteit, schier verbruik ook op en neer.

Ik heb geen stekker plugs over en voor ik die investeringen eruit heb, met de winst dat het zou opleveren, ben ik 50jaar verder.

Zit deze dagen nog op 98% zonnestroom gebruik, dus mijn doel is tot dusverre prima gehaald.

[Aardedraadje]

DrNickB schreef op donderdag 25 september 2025 @ 18:57:
[...]


Zou je een code snippet kunnen delen an je berekeningen(als dat hier past)?
Heb hier zelf ook last van, heb wel updates elke seconde, en al mijn sensoren updaten bij wijziging,
Alleen als bijvoorbeeld de inductie kookplaat aanstaat, op een 'warm houdt standje' dan schiet hij per seconde aan en uit, wat pieken opleverd en hij heel veel corrigeert. (Gielz update zelf elke 4 sec)

Heb zelf nog geen echte logica om echt te detecteren of het de kook plaat is en daarop weer te gaan sturen, dus een iets minder heftige op en neer zou ook cool zijn in dit geval.

Sure!

Ik heb het alleen nog toegepast voor de actie zendure_x_ontladen_balanceren:

code:

outputLimit: >-
  {% set demping = states('input_number.nulregeling_demper') | float(0) %}
  {% set regel_grens = states('input_number.nulregeling_bandbreedte') | float(0) %}
  {% set cap = 2400 %}
  {% set correctie = states('input_number.nulregeling_ontladen_correctie') | float(0) %}
  {% set p1 = states('sensor.p1_meter_active_power') | float(0) %}
  {% set huidig = states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0) %}
  {% set totaal = (p1 - huidig - correctie) %}
  {% set nieuw = [ [totaal, 0] | max, cap ] | min %}
  {% set verschil = (p1 - correctie) | abs %}
  {% if verschil <= regel_grens %}
    {{ ((0.1 * nieuw) | round(0, "floor") - (0.9 * huidig) | round(0)) | int }}
  {% else %}
    {{ ((demping * nieuw) - ((1-demping) * huidig)) | int }}
  {% endif %}

Dan heb ik de volgende input number helpers aangemaakt die ik in de UI kan aanpassen:
input_number.nulregeling_demper: Dempt de respons, in mijn geval staat die op 0.5.
input_number.nulregeling_bandbreedte: Bij hoeveel verschil vanaf de gewenste waarde sta je slechts langzame wijzigingen toe. Staat bij mij op 25W.
input_number.nulregeling_ontladen_correctie: Waar regel je naartoe. Staat in mijn geval op -5W. voegt weinig toe om in de UI te hebben, maar ik wilde er wat mee spelen.

Het werkt nog niet perfect en zoals @gielz al zegt, eigenlijk kan het schommelen weinig kwaad. Maar ik heb zo wel mijn nachtelijke import/export kunnen verbeteren van 0.02 kWh per uur import en export, naar 0.01 export en geen import. Volgens de niet-zo-slimme meter dan

[DrNickB]

Aardedraadje schreef op vrijdag 26 september 2025 @ 05:33:
[...]
Sure!

Thnx!
altijd leuk om verschillende ideeën en oplossingen te zien en kijken hoe het uitpakt.
Met me kookplaat zit er misschien wat winst in, om hem minder te laten schommelen,
terwijl misschien met grote hoge last (koffie apparaat) dat hij wat minder snel 'bij' is.

[Taro]

@FireSon Ik zie dat in 1.1.4 pre 7 de 4x SF800's op NOM constant aan het klapperen zijn:



De bypass gaat uit, export op 0. Ik heb zelf een script lopen dat dat direct weer corrigeert want ik wil immers dat de 3x2400AC met dat overschot gaan laden en zo NOM houden ipv de export van de SF800 micro-omvormers te beperken.

Ik heb hun Fuse groups al op de optie staan: Niet gebruikt, maar ze worden dus wél door de integratie aangestuurd en dit is niet de juiste manier. Ik verwacht dat de accu's gaan laden om NOM te houden ipv dat de 4xSF800's worden uitgeschakeld.

Kan je een optie opnemen om een device helemaal uit te sluiten van deelname aan de integratie?

Zo ziet dat er uit binnen 20 minuten, heb ze dus alle 4 inmiddels in een secundair account zitten om dit te voorkomen:

[ Voor 14% gewijzigd door Taro op 26-09-2025 12:18 ]

[gielz]

Hier nog geen dynamisch contract (ze willen mij wel heel graag weg hebben. huidige contract is zeer slecht voor mijn leverancier). Maar ben al wel alvast begonnen om voor 2027 Dynamisch NOM in te bouwen binnen mijn zenSDK sturing (plug-n-play).

Het idee is dat hij vol automatisch zijn NOM doet en op de goedkoopste x uren die je instelt gaat bijladen indien voldoende spread wat in de winter wel noodzakelijk is. Nu zit ik alleen even met die spread. Ik kijk nu naar het gemiddelde tarief van de ingestelde laaduurtjes en kijk vervolgens naar de overige niet goedkope uren wat dan de spread zou zijn. Dit omdat je immers in de niet goedkope uren die geladen stroom NOM gaat in zetten.

Zit ik dan zo goed als dynamische noob? En hoeveel spread wil je eigenlijk zon beetje hebben om überhaupt op te laden in de winter van 2027? Er word dus niet op de duurste uren ontladen in deze modus.

Ook moet het allemaal mooi visueel. Hier onder zie je dus heel duidelijk wat de prijzen zijn, waar je op dit moment wat betreft tijd van de dag zit en in het grijs welke uren hij voor je zal gaan laden.

[Devke]

gielz schreef op vrijdag 26 september 2025 @ 12:28:
Hier nog geen dynamisch contract (ze willen mij wel heel graag weg hebben. huidige contract is zeer slecht voor mijn leverancier). Maar ben al wel alvast begonnen om voor 2027 Dynamisch NOM in te bouwen binnen mijn zenSDK sturing (plug-n-play).

Het idee is dat hij vol automatisch zijn NOM doet en op de goedkoopste x uren die je instelt gaat bijladen indien voldoende spread wat in de winter wel noodzakelijk is. Nu zit ik alleen even met die spread. Ik kijk nu naar het gemiddelde tarief van de ingestelde laaduurtjes en kijk vervolgens naar de overige niet goedkope uren wat dan de spread zou zijn. Dit omdat je immers in de niet goedkope uren die geladen stroom NOM gaat in zetten.

Zit ik dan zo goed als dynamische noob? En hoeveel spread wil je eigenlijk zon beetje hebben om überhaupt op te laden in de winter van 2027? Er word dus niet op de duurste uren ontladen in deze modus.

Ook moet het allemaal mooi visueel. Hier onder zie je dus heel duidelijk wat de prijzen zijn, waar je op dit moment wat betreft tijd van de dag zit en in het grijs welke uren hij voor je zal gaan laden.

[Afbeelding]

Ga uit van een 80% RTE. Ga je afschrijving meenemen? Want dan zal 3 zonder te rekenen al te weinig zijn. Ik denk dat er nog wel een groot aantal mensen is die de batterijen (deels) weer legen op de duurste uren. Hier gaan ze compleet leeg nog steeds. Dit zijn 2 verschillende situaties.

[Taro]

gielz schreef op vrijdag 26 september 2025 @ 12:28:
Hier nog geen dynamisch contract (ze willen mij wel heel graag weg hebben. huidige contract is zeer slecht voor mijn leverancier). Maar ben al wel alvast begonnen om voor 2027 Dynamisch NOM in te bouwen binnen mijn zenSDK sturing (plug-n-play).

Het idee is dat hij vol automatisch zijn NOM doet en op de goedkoopste x uren die je instelt gaat bijladen indien voldoende spread wat in de winter wel noodzakelijk is. Nu zit ik alleen even met die spread. Ik kijk nu naar het gemiddelde tarief van de ingestelde laaduurtjes en kijk vervolgens naar de overige niet goedkope uren wat dan de spread zou zijn. Dit omdat je immers in de niet goedkope uren die geladen stroom NOM gaat in zetten.

Zit ik dan zo goed als dynamische noob? En hoeveel spread wil je eigenlijk zon beetje hebben om überhaupt op te laden in de winter van 2027? Er word dus niet op de duurste uren ontladen in deze modus.

Ook moet het allemaal mooi visueel. Hier onder zie je dus heel duidelijk wat de prijzen zijn, waar je op dit moment wat betreft tijd van de dag zit en in het grijs welke uren hij voor je zal gaan laden.

[Afbeelding]

Zou het een optie zijn om de input van een aantal velden of bekende waardes in de spread berekening mee te nemen?

• Gemiddelde RTE (kan invoerveld, of automatische berekening zijn)
• Afschrijving per kWh
• Minimale marge in ct/kWh

Kan mij voorstellen dat de een die minimale marge op 0 zet, de ander wil pas een cycle opofferen of stopcontacten belasten boven de 5 ct/kWh marge, etc.

Op die manier kan je kijken naar welke lage en hoge prijzen in aanmerking komen om na aftrek van RTE, afschrijving en minimale gewenste marge wel of niet in te laden en ontladen. Maar dit kan al heel snel complex worden, want neem je bijv. de volgende dag ook mee in je berekening?

[gielz]

Taro schreef op vrijdag 26 september 2025 @ 14:38:
[...]

Zou het een optie zijn om de input van een aantal velden of bekende waardes in de spread berekening mee te nemen?

• Gemiddelde RTE (kan invoerveld, of automatische berekening zijn)
• Afschrijving per kWh
• Minimale marge in ct/kWh

Kan mij voorstellen dat de een die minimale marge op 0 zet, de ander wil pas een cycle opofferen of stopcontacten belasten boven de 5 ct/kWh marge, etc.

Op die manier kan je kijken naar welke lage en hoge prijzen in aanmerking komen om na aftrek van RTE, afschrijving en minimale gewenste marge wel of niet in te laden en ontladen. Maar dit kan al heel snel complex worden, want neem je bijv. de volgende dag ook mee in je berekening?

Ik wil het eigenlijk zo simpel mogelijk houden. Bijvoorbeeld je vult in hoeveel goedkope uren je een beetje wenselijk vind. Daarna komt er een % spread uit en als deze boven een bepaald % is zal hij deze uren gaan laden. Die te behalen spread % is dan instelbaar maar onder de 25% is het zonder afschrijving al niet rendabel bij 80% rte. (of ik heb het mis?)

Voor nu kijkt hij alleen naar vandaag, dat eerst maar goed en makkelijk laten werken.

[Taro]

gielz schreef op vrijdag 26 september 2025 @ 17:29:
[...]


Ik wil het eigenlijk zo simpel mogelijk houden. Bijvoorbeeld je vult in hoeveel goedkope uren je een beetje wenselijk vind. Daarna komt er een % spread uit en als deze boven een bepaald % is zal hij deze uren gaan laden. Die te behalen spread % is dan instelbaar maar onder de 25% is het zonder afschrijving al niet rendabel bij 80% rte. (of ik heb het mis?)

Voor nu kijkt hij alleen naar vandaag, dat eerst maar goed en makkelijk laten werken.

Je moet het bedrag incl. BTW pakken (want %), daarna maal de RTE. Dan heb je waardes waar je mee kunt rekenen. Dan zit je met een issue, want dan moet je de afschrijving en gewenste marge nog verrekenen, maar eigenlijk moet je die alleen van de hoge uren afhalen, zodat je het verschil tussen laag en hoog kunt zien en kunt bepalen of het de moeite waard is. Maar welke uren bereken je dat dan mee? Misschien in een array gooien, sorteren van laag naar hoog en hoog naar laag, dan eerst voor de 1e, dan voor de 2e controleren, etc. tot het punt dat de spread negatief is en dan stop je. Andere uitdaging: Als de hoge uren voor de lage uren liggen, dan heb je niets om mee te ontladen.

Het lijkt heel simpel, maar ik heb bijv. heel bewust mijn strategie hierop ingericht:

3 duurste uren in de avond ontladen, dan NOM, dan duurste 2 uren in de ochtend ontladen, zodat ze leeg zijn, en onder een bepaald bedrag laden wat soms ook al vroeger is dan de 2 duurste uren in de ochtend, maar dat is dan dus prima aangezien daar al ruimte voor was omdat er al 3 uren + NOM was ontladen. Zo is er altijd capaciteit beschikbaar.

In de lente en zomer is dit overigens nog iets geoptimaliseerd vs herst en winter, dan wordt er minder uren ontladen en tussendoor altijd NOM ipv Smart Discharge en Smart Charge gebruikt om alle zonnestroom op te slaan. Daarnaast heb ik knopjes voor wel/niet goedkoop manueel inkopen en opties om die op 15, 17 of 20 cent in te stellen, of gewoon de goedkoopste 5 uren.

Je wil het simpel houden, begrijp ik, maar het is mogelijk complexer dan je verwacht. Hopelijk lukt het je en ik wil zeker meedenken/meehelpen, maar benieuwd welke obstakels er gaandeweg naar voren komen.

[qltel]

Goedemiddag.

Ik heb vandaag mijn Hyper 2000 met AB2000X ontvangen. App geïnstalleerd, firmware geupdate, de Fireson integratie geïnstalleerd en ik zie alle gegevens keurig in HA. Ik gebruik Firmware: 1.1.4-pre7. Er hangen geen zonnepanelen aan de Hyper, die zitten namelijk op andere inverters aangesloten.

Het lukt me echter niet om "nul op de meter" te krijgen. De accu laad niet, hij ontlaad niet. Hij doet eigenlijk niets. En ik zie vast iets over het hoofd.





Kan iemand hier me op weg helpen?

Ah, nu ik de Device fusegroup op 800 Watt heb gezet begint hij ineens te ontladen. Dat lijkt dus hetgeen te zijn wat ik over het hoofd zag.

[ Voor 9% gewijzigd door qltel op 27-09-2025 15:32 ]

[DJN]

qltel schreef op zaterdag 27 september 2025 @ 15:06:
Goedemiddag.

Ik heb vandaag mijn Hyper 2000 met AB2000X ontvangen. App geïnstalleerd, firmware geupdate, de Fireson integratie geïnstalleerd en ik zie alle gegevens keurig in HA. Ik gebruik Firmware: 1.1.4-pre7. Er hangen geen zonnepanelen aan de Hyper, die zitten namelijk op andere inverters aangesloten.

Het lukt me echter niet om "nul op de meter" te krijgen. De accu laad niet, hij ontlaad niet. Hij doet eigenlijk niets. En ik zie vast iets over het hoofd.

[Afbeelding]

[Afbeelding]

Kan iemand hier me op weg helpen?

Device fusegroep staat niet goed. Fireson integratie pakt Hyper zo niet mee. Je kunt deze bv op ‘apparaat is aangesloten op aparte groep of fase’ zetten

[qltel]

DJN schreef op zaterdag 27 september 2025 @ 15:33:
[...]


Device fusegroep staat niet goed. Fireson integratie pakt Hyper zo niet mee. Je kunt deze bv op ‘apparaat is aangesloten op aparte groep of fase’ zetten

Ik had het net gevonden. Dat was het inderdaad!

[markduffy]

Ik ben nog vrij nieuw in HA. Dus nog best wel zoekende.
Nu probeer ik uit de startpost de configuratie YAML te implementeren, maar loop beetje vast omdat ik 2 sets heb.

Kunnen jullie mij beetje opweg helpen?
Ik heb nog niet alle regels overgenomen, omdat mij op een gegeve moment op begon te vallen dat ik sommige dingen volgens mij er nu niet in kan zetten omdat ik 2 sets heb.
En loop dus o.a. vast op de unique_ids omdat ik 2 apparaten heb. En kan van bijvoorbeeld onderstaand deze niet vinden (zie t niet tussen entiteiten of statussen) Dus kan daardoor ook niet de vervangende vinden.
unique_id: Zendure_2400_AC_Batterij_1_Temperatuur

"Excuus voor de newbie vraag ;)"

code:

 Laad standaard set van integraties. Niet verwijderen.
default_config:

# Laad frontend thema's uit de themes-map
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

# ============================================================
# Input helpers (blijven hetzelfde, gelden voor beide sets)
# ============================================================
input_select:
  zendure_2400_ac_modus_selecteren:
    name: Zendure 2400 AC Modus Selecteren
    icon: mdi:battery-charging-wireless
    options:
      - Standby
      - Handmatig
      - Nul op de meter
      - Alleen slim ontladen
      - Alleen slim opladen
      - Opladen met 2400 watt
      - Ontladen met 2400 watt

input_number:
  zendure_2400_ac_handmatig_vermogen:
    name: Zendure 2400 AC Handmatig Vermogen
    min: -2400
    max: 2400
    step: 1
    mode: box
    unit_of_measurement: "W"

# ============================================================
# Zendure 1 sensoren
# ============================================================
rest:
  - resource: http://http://192.168.1.XXX/properties/report
    scan_interval: 1
    sensor:
      - name: "Zendure1 Vermogen Export"
        value_template: "{{ value_json['properties']['packInputPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure1 Vermogen Import"
        value_template: "{{ value_json['properties']['outputPackPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure1 Laadpercentage"
        value_template: "{{ value_json['properties']['electricLevel'] }}"
        unit_of_measurement: "%"
        device_class: battery
        state_class: measurement

  # ============================================================
  # Zendure 2 sensoren
  # ============================================================
  - resource: http://http://192.168.1.XX/properties/report
    scan_interval: 1
    sensor:
      - name: "Zendure2 Vermogen Export"
        value_template: "{{ value_json['properties']['packInputPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure2 Vermogen Import"
        value_template: "{{ value_json['properties']['outputPackPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure2 Laadpercentage"
        value_template: "{{ value_json['properties']['electricLevel'] }}"
        unit_of_measurement: "%"
        device_class: battery
        state_class: measurement

  # ============================================================
  # Shelly Input
  # ============================================================
  template:
  - sensor:
      - name: "Shelly Aansturing"
        state: "{{ states('sensor.shelly_total_active_power') | float(0) }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement


# ============================================================
# Rest commands Zendure 1
# ============================================================
rest_command:
  zendure1_opslaan_in_ram:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXXX","properties":{"smartMode": 1 }}'

  zendure1_snel_laden:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"acMode": 1, "inputLimit": 2400 }}'

  zendure1_stop_met_laden:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"acMode": 1, "inputLimit": 0 }}'

  zendure1_snel_ontladen:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXXX","properties":{"acMode": 2, "outputLimit": 2400 }}'

  zendure1_stop_met_ontladen:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"acMode": 2, "outputLimit": 0 }}'

  zendure1_stop_met_alles:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXXX","properties":{"outputLimit": 0, "inputLimit": 0 }}'

  zendure1_standby:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"smartMode": 0, "outputLimit": 0, "inputLimit": 0 }}'

# ============================================================
# Rest commands Zendure 2
# ============================================================
  zendure2_opslaan_in_ram:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3XXXX","properties":{"smartMode": 1 }}'

  zendure2_snel_laden:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPNXXXX","properties":{"acMode": 1, "inputLimit": 2400 }}'

  zendure2_stop_met_laden:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3NXXXX","properties":{"acMode": 1, "inputLimit": 0 }}'

  zendure2_snel_ontladen:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPXXXXX","properties":{"acMode": 2, "outputLimit": 2400 }}'

  zendure2_stop_met_ontladen:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3XXXXX","properties":{"acMode": 2, "outputLimit": 0 }}'

  zendure2_stop_met_alles:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3XXXX","properties":{"outputLimit": 0, "inputLimit": 0 }}'

  zendure2_standby:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPXXXXX","properties":{"smartMode": 0, "outputLimit": 0, "inputLimit": 0 }}'

[gielz]

markduffy schreef op zaterdag 27 september 2025 @ 19:09:
Ik ben nog vrij nieuw in HA. Dus nog best wel zoekende.
Nu probeer ik uit de startpost de configuratie YAML te implementeren, maar loop beetje vast omdat ik 2 sets heb.

Kunnen jullie mij beetje opweg helpen?
Ik heb nog niet alle regels overgenomen, omdat mij op een gegeve moment op begon te vallen dat ik sommige dingen volgens mij er nu niet in kan zetten omdat ik 2 sets heb.
En loop dus o.a. vast op de unique_ids omdat ik 2 apparaten heb. En kan van bijvoorbeeld onderstaand deze niet vinden (zie t niet tussen entiteiten of statussen) Dus kan daardoor ook niet de vervangende vinden.
unique_id: Zendure_2400_AC_Batterij_1_Temperatuur

"Excuus voor de newbie vraag ;)"

code:

 Laad standaard set van integraties. Niet verwijderen.
default_config:

# Laad frontend thema's uit de themes-map
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

# ============================================================
# Input helpers (blijven hetzelfde, gelden voor beide sets)
# ============================================================
input_select:
  zendure_2400_ac_modus_selecteren:
    name: Zendure 2400 AC Modus Selecteren
    icon: mdi:battery-charging-wireless
    options:
      - Standby
      - Handmatig
      - Nul op de meter
      - Alleen slim ontladen
      - Alleen slim opladen
      - Opladen met 2400 watt
      - Ontladen met 2400 watt

input_number:
  zendure_2400_ac_handmatig_vermogen:
    name: Zendure 2400 AC Handmatig Vermogen
    min: -2400
    max: 2400
    step: 1
    mode: box
    unit_of_measurement: "W"

# ============================================================
# Zendure 1 sensoren
# ============================================================
rest:
  - resource: http://http://192.168.1.XXX/properties/report
    scan_interval: 1
    sensor:
      - name: "Zendure1 Vermogen Export"
        value_template: "{{ value_json['properties']['packInputPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure1 Vermogen Import"
        value_template: "{{ value_json['properties']['outputPackPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure1 Laadpercentage"
        value_template: "{{ value_json['properties']['electricLevel'] }}"
        unit_of_measurement: "%"
        device_class: battery
        state_class: measurement

  # ============================================================
  # Zendure 2 sensoren
  # ============================================================
  - resource: http://http://192.168.1.XX/properties/report
    scan_interval: 1
    sensor:
      - name: "Zendure2 Vermogen Export"
        value_template: "{{ value_json['properties']['packInputPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure2 Vermogen Import"
        value_template: "{{ value_json['properties']['outputPackPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure2 Laadpercentage"
        value_template: "{{ value_json['properties']['electricLevel'] }}"
        unit_of_measurement: "%"
        device_class: battery
        state_class: measurement

  # ============================================================
  # Shelly Input
  # ============================================================
  template:
  - sensor:
      - name: "Shelly Aansturing"
        state: "{{ states('sensor.shelly_total_active_power') | float(0) }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement


# ============================================================
# Rest commands Zendure 1
# ============================================================
rest_command:
  zendure1_opslaan_in_ram:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXXX","properties":{"smartMode": 1 }}'

  zendure1_snel_laden:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"acMode": 1, "inputLimit": 2400 }}'

  zendure1_stop_met_laden:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"acMode": 1, "inputLimit": 0 }}'

  zendure1_snel_ontladen:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXXX","properties":{"acMode": 2, "outputLimit": 2400 }}'

  zendure1_stop_met_ontladen:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"acMode": 2, "outputLimit": 0 }}'

  zendure1_stop_met_alles:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXXX","properties":{"outputLimit": 0, "inputLimit": 0 }}'

  zendure1_standby:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"smartMode": 0, "outputLimit": 0, "inputLimit": 0 }}'

# ============================================================
# Rest commands Zendure 2
# ============================================================
  zendure2_opslaan_in_ram:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3XXXX","properties":{"smartMode": 1 }}'

  zendure2_snel_laden:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPNXXXX","properties":{"acMode": 1, "inputLimit": 2400 }}'

  zendure2_stop_met_laden:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3NXXXX","properties":{"acMode": 1, "inputLimit": 0 }}'

  zendure2_snel_ontladen:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPXXXXX","properties":{"acMode": 2, "outputLimit": 2400 }}'

  zendure2_stop_met_ontladen:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3XXXXX","properties":{"acMode": 2, "outputLimit": 0 }}'

  zendure2_stop_met_alles:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3XXXX","properties":{"outputLimit": 0, "inputLimit": 0 }}'

  zendure2_standby:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPXXXXX","properties":{"smartMode": 0, "outputLimit": 0, "inputLimit": 0 }}'

Wil je trouwens met 2 devices gaan NOMen? Dan is de officiële Zendure HA een betere optie omdat deze meerdere devices ondersteund.

[dr.trimble]

ik heb een P1-meter die draait op een ESP32. Hieruit krijg ik volgende waarden: power consumed en power produced. De waarden komen via wifi binnen in HA. Kan ik dit ook gebruiken om de Zendure aan te sturen? ik maak gebruik van ZENSDK.

[martinvdm]

dr.trimble schreef op zondag 28 september 2025 @ 18:52:
ik heb een P1-meter die draait op een ESP32. Hieruit krijg ik volgende waarden: power consumed en power produced. De waarden komen via wifi binnen in HA. Kan ik dit ook gebruiken om de Zendure aan te sturen? ik maak gebruik van ZENSDK.

Ja je kunt iedere p1 meter gebruiken, kun je ingeven in de integratie.

[dr.trimble]

martinvdm schreef op zondag 28 september 2025 @ 20:01:
[...]

Ja je kunt iedere p1 meter gebruiken, kun je ingeven in de integratie.

daar heb ik momenteel mijn zendure P1 meter instaan:
- resource: http://192.168.0.127/properties/report # Zendure P1
scan_interval: 1
sensor:
- name: "P1 Aansturing API v1"
value_template: "{{ value_json['total_power'] }}"
unique_id: P1_Aansturing_API_V1
unit_of_measurement: "W"
state_class: measurement
device_class: power

ik heb echter geen idee hoe ik dat moet aanpassen voor de andere P1-meter (esp32)

[gielz]

dr.trimble schreef op zondag 28 september 2025 @ 20:32:
[...]

daar heb ik momenteel mijn zendure P1 meter instaan:
- resource: http://192.168.0.127/properties/report # Zendure P1
scan_interval: 1
sensor:
- name: "P1 Aansturing API v1"
value_template: "{{ value_json['total_power'] }}"
unique_id: P1_Aansturing_API_V1
unit_of_measurement: "W"
state_class: measurement
device_class: power

ik heb echter geen idee hoe ik dat moet aanpassen voor de andere P1-meter (esp32)

Welke aansturing wil je exact gebruiken? En die P1 esp32 meter, daarvan heb je dus import (in plus wattage) en export (in min wattage) los in Home Assistant per seconden?

[dr.trimble]

gielz schreef op zondag 28 september 2025 @ 20:41:
[...]


Welke aansturing wil je exact gebruiken? En die P1 esp32 meter, daarvan heb je dus import (in plus wattage) en export (in min wattage) los in Home Assistant per seconden?

het is de bedoeling de P1 op de esp32 te gebruiken ipv de zendure P1 aangezien ik die betrouwbaarder vind. ik krijg hier 2 sensoren van: sensor.energiemeter_power_consumed en sensor.energiemeter_power_produced

[gielz]

dr.trimble schreef op zondag 28 september 2025 @ 20:54:
[...]

het is de bedoeling de P1 op de esp32 te gebruiken ipv de zendure P1 aangezien ik die betrouwbaarder vind. ik krijg hier 2 sensoren van: sensor.energiemeter_power_consumed en sensor.energiemeter_power_produced

Maar hoe zien die sensoren er uit in HA en zijn ze per seconden en + en - zoals verwacht. Nog steeds onduidelijk welke sturing je gaat gebruiken.

[dr.trimble]

gielz schreef op zondag 28 september 2025 @ 20:57:
[...]


Maar hoe zien die sensoren er uit in HA en zijn ze per seconden en + en - zoals verwacht. Nog steeds onduidelijk welke sturing je gaat gebruiken.

wat bedoel je met welke sturing?
De sensoren worden elke seconde ge-updated. Beide sensoren zijn positef

[gielz]

dr.trimble schreef op zondag 28 september 2025 @ 21:02:
[...]

wat bedoel je met welke sturing?
De sensoren worden elke seconde ge-updated. Beide sensoren zijn positef

Ga je voor Zendure HA, ZenSDK Gielz of ZenSDK Zelfbouw? Als ze beide positief zijn moet je de export sensor even een min waarde maken de import is prima en dat combineren in een template helper. Vervolgens heb je een werkende P1. ChatGPT kan dit zo voor je maken, vervolgens gooi je die in een sjabloon om te testen alvorens je een echte template aanmaakt.

[dr.trimble]

gielz schreef op zondag 28 september 2025 @ 21:07:
[...]


Ga je voor Zendure HA, ZenSDK Gielz of ZenSDK Zelfbouw? Als ze beide positief zijn moet je de export sensor even een min waarde maken de import is prima en dat combineren in een template helper. Vervolgens heb je een werkende P1. ChatGPT kan dit zo voor je maken, vervolgens gooi je die in een sjabloon om te testen alvorens je een echte template aanmaakt.

aah, ik gebruik de zensdk Gielz. ff zoeken hoe ik dit alles in een helper krijg want ben daar geen krak in ;-).

[DrNickB]

Ik had het zelfde probleem een beetje, mijn USB P1, gaf een Import en een Export waarde, beide positief.
Hiervoor een template sensor aangemaakt in configuration.yaml om deze waardes van elkaar af te trekken.
Hierdoor krijg ik mijn verschil. En deze sensor gebruik ik binnen de gielz code om bijv NOM aan te sturen.

code:

template:
  - sensor:
      - name: "Verbruik en Levering verschil"
        unique_id: verbruik_levering_verschil
        state_class: measurement
        device_class: energy
        state: "{{ states('sensor.electricity_meter_power_consumption_2') | int(0) - states('sensor.electricity_meter_power_production_2') | int(0) }}"
        unit_of_measurement: "Wh"

[dr.trimble]

het maken van de sensor "verbruik en levering verschil" is gelukt maar die blijft steeds op O staan . Enig idee hoe dit komt.
Ik heb de code volledig overgenomen en enkel de naam van de sensoren vervangen

[DrNickB]

dr.trimble schreef op zondag 28 september 2025 @ 21:43:
het maken van de sensor "verbruik en levering verschil" is gelukt maar die blijft steeds op O staan . Enig idee hoe dit komt.
Ik heb de code volledig overgenomen en enkel de naam van de sensoren vervangen

Nee zo snel niet eerlijk gezegd.
Beide waardes / states zijn goed zichtbaar in developerview? hebben een waarde?
Geen type fout gemaakt? Buiten de yaml reload, misschien een HA herstart proberen?

[dr.trimble]

ik heb copy paste gedaan en de sensor blijft op 0. Via developerview zijn waardes ok. Ook herstart gedaan.
De sensoren geven wel het vermogen weer, dus power? Via chatgpt de code veranderd naar onderstaande maar ook hier blijft de waarde van de nieuwe sensor "O"
template:
- sensor:
- name: "Verbruik en Levering verschil"
unique_id: verbruik_levering_verschil
state_class: measurement
device_class: power
unit_of_measurement: "kW"
state: >
{% set verbruik = states('sensor.electricity_meter_power_consumption_2') | float(0) %}
{% set levering = states('sensor.electricity_meter_power_production_2') | float(0) %}
{{ verbruik - levering }}

[gielz]

dr.trimble schreef op maandag 29 september 2025 @ 18:35:
ik heb copy paste gedaan en de sensor blijft op 0. Via developerview zijn waardes ok. Ook herstart gedaan.
De sensoren geven wel het vermogen weer, dus power? Via chatgpt de code veranderd naar onderstaande maar ook hier blijft de waarde van de nieuwe sensor "O"
template:
- sensor:
- name: "Verbruik en Levering verschil"
unique_id: verbruik_levering_verschil
state_class: measurement
device_class: power
unit_of_measurement: "kW"
state: >
{% set verbruik = states('sensor.electricity_meter_power_consumption_2') | float(0) %}
{% set levering = states('sensor.electricity_meter_power_production_2') | float(0) %}
{{ verbruik - levering }}

Kun je vanaf afstand niet echt helpen maar de batterij had zelf ook + bij ontladen en + bij opladen. Dit heb ik toen opgelost door de onderstaande code. Wellicht kun je dit samen met ChatGPT tot een werkende P1 ombouwen;

code:

      - name: "Zendure 2400 AC Vermogen Aansturing"
        value_template: >
          {% set opladen = value_json['properties']['outputPackPower'] | int %}
          {% set ontladen = - (value_json['properties']['packInputPower'] | int) %}
          {% if opladen != 0 %}
            {{ opladen }}
          {% else %}
            {{ ontladen }}
          {% endif %}

[DrNickB]

dr.trimble schreef op zondag 28 september 2025 @ 21:43:
het maken van de sensor "verbruik en levering verschil" is gelukt maar die blijft steeds op O staan . Enig idee hoe dit komt.
Ik heb de code volledig overgenomen en enkel de naam van de sensoren vervangen

Ik zat alleen nog te denken, dat misschien de input waardes in een andere range vallen als wat we hier verwachten.
Mijn p1 waardes heb ik zo ingesteld, dat deze in watt worden uitgestuurd. 1kw is dan ook 1000.
In mijn stukje code heb ik dan ook Wh als unit gebruikt en int (hele getallen) ipv float (komma getallen).
Omdat je wel een 0 als waardes krijgt, lijkt hij toch 'iets' te rekenen.

Wat zijn p1 sensor waardes volgens developer view -> states ?

1 van mijn inputs:

code:

state: 19.0

state_class: measurement
unit_of_measurement: W
device_class: power
friendly_name: Electricity Meter v5 Power consumption

[Bikkelreal]

Vraag Ik gebruik nu de intregatie Cheapest Energy Hours, is er ook iets voor 1 oktober als het naar 15 min gaat?

[DrNickB]

Bikkelreal schreef op maandag 29 september 2025 @ 19:46:
Vraag Ik gebruik nu de intregatie Cheapest Energy Hours, is er ook iets voor 1 oktober als het naar 15 min gaat?

Goede vraag, nog niks over gelezen.
Maar gaat hij ook echt al naar 15min prijzen bij uw leverancier, of worden het wel blokken, maar dan met 1 'uur' prijs,
was laatste wat ik een beetje las tenminste.

[dr.trimble]

[quote]DrNickB schreef op maandag 29 september 2025 @ 19:40:
[...]


Wat zijn p1 sensor waardes volgens developer view -> states ?

mijn waarden zijn uitgedrukt in kW

state: 0.224000006914139

state_class: measurement
unit_of_measurement: kW
device_class: power
friendly_name: Energie uit net

[ Voor 36% gewijzigd door dr.trimble op 29-09-2025 20:30 ]

[Jacqui]

Een paar energieleveranciers met dynamische prijzen, waaronder in ieder geval Tibber, gaan naar kwartierprijzen en volgen daarmee een Europese trend voor betere afstemming van de prijzen. Volgens de aankondiging op hun site, kunnen de prijzen écht iedere 15 minuten veranderen. Op sommige momenten zal dit voordelig voor de consument uitpakken, op andere wellicht nadelig.
Je kunt dan dus ook niet meer zomaar de x-goedkoopste uren gebruiken voor de aansturing, lijkt mij. In theorie kan de prijs zelfs binnen een uur fluctueren van hoog naar laag en weer naar hoog.

Ik hoop dat de integraties van b.v. Nordpool en Cheapest Hours deze trend zullen volgen en hierop hun aanpassingen doorvoeren...

Aan degene die dieper in de materie zitten en ook al meer met HA bezig zijn, de vraag: Is het wellicht een idee om gebruik te maken van staffels. Eigenlijk net zoals bij Zenki dyn. prijzen optie, dat je een hoog en laag kunt aangeven, waarbij moet worden ontladen cq. geladen, maar dan met meer stappen dan in de app.
Ik zou mij dan het volgende kunnen voorstellen (prijzen zonder belasting en btw):
> 0,20 dan max. ontladen (lekker verdienen )
> 0,12 en <= 0,20 dan b.v. 800W ontladen (of NOM)
> 0,05 en <= 0,12 dan NOM
> 0 en en <= 0,05 dan 800W laden
<= 0 dan max laden

Het afgelopen jaar heb ik namelijk voor het laden van de EV en van mijn 'domme' boiler ook gewoon naar de prijs gekeken en niet perse naar de zonne-opwek. De auto moet toch vol en het water warm , dus dan het liefst op de goedkope uren. Als de prijs wat hoger is 's morgens, of eind van de middag, is het terugleveren immers ook lucratiever.

Update
Blijkbaar is bij https://github.com/TheFes/cheapest-energy-hours al een fix ingebouwd voor kwartierprijzen

[ Voor 3% gewijzigd door Jacqui op 29-09-2025 20:58 ]

[martinvdm]

Jacqui schreef op maandag 29 september 2025 @ 20:42:
Een paar energieleveranciers met dynamische prijzen, waaronder in ieder geval Tibber, gaan naar kwartierprijzen en volgen daarmee een Europese trend voor betere afstemming van de prijzen. Volgens de aankondiging op hun site, kunnen de prijzen écht iedere 15 minuten veranderen. Op sommige momenten zal dit voordelig voor de consument uitpakken, op andere wellicht nadelig.
Je kunt dan dus ook niet meer zomaar de x-goedkoopste uren gebruiken voor de aansturing, lijkt mij. In theorie kan de prijs zelfs binnen een uur fluctueren van hoog naar laag en weer naar hoog.

Ik hoop dat de integraties van b.v. Nordpool en Cheapest Hours deze trend zullen volgen en hierop hun aanpassingen doorvoeren...

Aan degene die dieper in de materie zitten en ook al meer met HA bezig zijn, de vraag: Is het wellicht een idee om gebruik te maken van staffels. Eigenlijk net zoals bij Zenki dyn. prijzen optie, dat je een hoog en laag kunt aangeven, waarbij moet worden ontladen cq. geladen, maar dan met meer stappen dan in de app.
Ik zou mij dan het volgende kunnen voorstellen (prijzen zonder belasting en btw):
> 0,20 dan max. ontladen (lekker verdienen )
> 0,12 en <= 0,20 dan b.v. 800W ontladen (of NOM)
> 0,05 en <= 0,12 dan NOM
> 0 en en <= 0,05 dan 800W laden
<= 0 dan max laden

Het afgelopen jaar heb ik namelijk voor het laden van de EV en van mijn 'domme' boiler ook gewoon naar de prijs gekeken en niet perse naar de zonne-opwek. De auto moet toch vol en het water warm , dus dan het liefst op de goedkope uren. Als de prijs wat hoger is 's morgens, of eind van de middag, is het terugleveren immers ook lucratiever.

Update
Blijkbaar is bij https://github.com/TheFes/cheapest-energy-hours al een fix ingebouwd voor kwartierprijzen

Het is volgens mij nog slechts een fix als de integratie meer dan verwacht aantal data points heeft (dus per kwartier). Eigenlijk zou de integratie dan ook cheapest_quarter moeten gaan heten . Maargoed verder beetje off-topic.

[DrNickB]

dr.trimble schreef op maandag 29 september 2025 @ 20:29:mijn waarden zijn uitgedrukt in kW

state: 0.224000006914139

state_class: measurement
unit_of_measurement: kW
device_class: power
friendly_name: Energie uit net

Ik heb even snel een testje opgezet.
ik heb 2 input waardes gemaakt, deze heb ik de waarde kW mee gegeven, fictief er iets in gezet.
in de config yaml heb ik een nieuwe sensor aangemaakt.

code:

  - sensor:
      - name: "TesT verschil"
        unique_id: verbruik_levering_verschil_test
        state_class: measurement
        device_class: energy
        state: "{{ states('input_number.input_test_kwh') | float(0) - states('input_number.output_test_kwh') | float(0) }}"
        unit_of_measurement: "kWh"

Input: 0.22 ; output: 0.33 -> resultaat: -0.11
Waardes zijn uitgedrukt in kWh; geen idee of de code van gielz hier mee om kan gaan
Als je deze aanpast van kWh naar Wh wordt de waarde nog kleiner.

andere extra oplossing zou kunnen zijn om een nieuwe waarde aan te maken die weer * 1000 doet.

code:

  - sensor:
      - name: "TesT verschil - watt"
        unique_id: verbruik_levering_verschil_test_watt
        state_class: measurement
        device_class: energy
        state: "{{ (states('sensor.test_verschil') | float(0)) * 1000 | int(0) }}"
        unit_of_measurement: "Wh"

maar zoals gielz ook aangeeft, is op afstand beetje lastig kijken.

*overigens zou je dit meteen kunnen omrekenen in de eerste sensor variabele, wordt alleen iets langer commandotje.

[ Voor 3% gewijzigd door DrNickB op 29-09-2025 22:54 ]

[klump4u]

DrNickB schreef op maandag 29 september 2025 @ 22:41:
[...]


Ik heb even snel een testje opgezet.
ik heb 2 input waardes gemaakt, deze heb ik de waarde kW mee gegeven, fictief er iets in gezet.
in de config yaml heb ik een nieuwe sensor aangemaakt.

code:

  - sensor:
      - name: "TesT verschil"
        unique_id: verbruik_levering_verschil_test
        state_class: measurement
        device_class: energy
        state: "{{ states('input_number.input_test_kwh') | float(0) - states('input_number.output_test_kwh') | float(0) }}"
        unit_of_measurement: "kWh"

Input: 0.22 ; output: 0.33 -> resultaat: -0.11
Waardes zijn uitgedrukt in kWh; geen idee of de code van gielz hier mee om kan gaan
Als je deze aanpast van kWh naar Wh wordt de waarde nog kleiner.

andere extra oplossing zou kunnen zijn om een nieuwe waarde aan te maken die weer * 1000 doet.

code:

  - sensor:
      - name: "TesT verschil - watt"
        unique_id: verbruik_levering_verschil_test_watt
        state_class: measurement
        device_class: energy
        state: "{{ (states('sensor.test_verschil') | float(0)) * 1000 | int(0) }}"
        unit_of_measurement: "Wh"

maar zoals gielz ook aangeeft, is op afstand beetje lastig kijken.

*overigens zou je dit meteen kunnen omrekenen in de eerste sensor variabele, wordt alleen iets langer commandotje.

Maak gewoon een helper aan met een template sensor, hoef je niet in je configuratie te klooien.

code:

 {{ states("sensor.electricity_meter_energieverbruik") |float *1000 - states("sensor.electricity_meter_energieproductie") | float * 1000}}

[ Voor 4% gewijzigd door klump4u op 30-09-2025 09:16 ]

[DrNickB]

klump4u schreef op dinsdag 30 september 2025 @ 09:12:
[...]
Maak gewoon een helper aan met een template sensor, hoef je niet in je configuratie te klooien.

Zover ik had kunnen vinden was het niet mogelijk om via de gui een waarde te berekenen met een min som (-). vandaar uitgeweken naar configuratie.

[klump4u]

DrNickB schreef op dinsdag 30 september 2025 @ 09:15:
[...]

Zover ik had kunnen vinden was het niet mogelijk om via de gui een waarde te berekenen met een min som (-). vandaar uitgeweken naar configuratie.

Zie edit

[DrNickB]

klump4u schreef op dinsdag 30 september 2025 @ 09:16:
[...]Zie edit

Netjes, wist ik niet. Ben ook niet zo super bekend binnen HA.

[klump4u]

DrNickB schreef op dinsdag 30 september 2025 @ 09:21:
[...]

Netjes, wist ik niet. Ben ook niet zo super bekend binnen HA.

Ik ook niet, je blijft er vanalles in ontdekken maar verder prima software.

[gielz]

Nordpool is over van 1 uur naar 15 minuten. Ik zie nu bij selecteren dat het in blokjes van 15min gaat en dus geen hele uren meer.

https://dataportal-api.no...ryArea=NL&date=2025-10-01

[dennisdew16]

@gielz Hoe werkt jou berekening in de nieuwe situatie? Zou het in theorie kunnen als jij twee goedkoopste uren instelt dat ie acht losse kwartieren kiest of wel nog steeds blokken van een uur en dus gemiddeld laagste uur periode?

[gielz]

dennisdew16 schreef op dinsdag 30 september 2025 @ 14:26:
@gielz Hoe werkt jou berekening in de nieuwe situatie? Zou het in theorie kunnen als jij twee goedkoopste uren instelt dat ie acht losse kwartieren kiest of wel nog steeds blokken van een uur en dus gemiddeld laagste uur periode?

Ik heb niets veranderd hij ging opeens gewoon zo werken met de nieuwe 15 minuten data en pakt dus blokjes van 15minuten die of het goedkoopst zijn of het duurst.

ik heb nu de raw_tomorrow van Nordpool omgevormd naar 4x15 is 1 uur en daar het gemiddelde van. Conform zonneplan heb ik dan afwijkingen in de afronding van minder dan 1 cent (0,01-0,03 cent)

[ Voor 24% gewijzigd door gielz op 30-09-2025 16:24 ]

[remcoXP]

klump4u schreef op zaterdag 13 september 2025 @ 12:53:
[...]

Ik heb de SF2400AC in evcc via HA. Moet je in de evcc.yaml toevoegen als random accu

wil je vertellen hoe je dit gedaan hebt?

[Gyrolion]

[EDIT]: ivm de lage hoge prijs sturing van gielz is de onderstaande goedkope / dure uren even het archief in gegaan.


Dat ziet er wel netjes uit met die automatische goedkoopste en duurste uren!
Daar moet ik me ook eens in gaan verdiepen. Want dat scheelt zelf een hoop gepiel.
Wat ik nu heb gedaan is sliders gemaakt waar ik de ontlaad en oplaad prijs kan instellen. En dat zichtbaar gemaakt in de prijs grafiek.

De automatische oplaad en ontlaad gaat weer samen met de automatisering welke ik heb gebouwd waar het laden van de auto, zons opgang en ondergang, etc. in zit gebakken. Zodat niet de stroom van het 1 naar het andere batterijtje wordt gestuurd.

Als het bij jou een beetje werkt heb ik ook wel interesse hoe die automatisering in elkaar steekt.

[ Voor 3% gewijzigd door Gyrolion op 30-09-2025 22:08 ]

[martinvdm]

Mijn Apexchart is een beetje de weg kwijt sinds recente updates van o.a. kwartierdata en ook ha update. Lopen ook best wat bugs, oa. Met color_threshold en stroke_width. Die functioneren ook niet lekker meer bij mij. Ik wacht denk ik ff af..

[dennisdew16]

gielz schreef op dinsdag 30 september 2025 @ 14:33:
[...]


Ik heb niets veranderd hij ging opeens gewoon zo werken met de nieuwe 15 minuten data en pakt dus blokjes van 15minuten die of het goedkoopst zijn of het duurst.

ik heb nu de raw_tomorrow van Nordpool omgevormd naar 4x15 is 1 uur en daar het gemiddelde van. Conform zonneplan heb ik dan afwijkingen in de afronding van minder dan 1 cent (0,01-0,03 cent)

[Afbeelding]

Heb je van je proeftuin en dan de 15min variant misschien de yaml etc?