Zendure producten in Home Assistant integreren deel 2

[gast777]

Het P1 meter interval en het Aansturing interval zijn twee verschillende dingen.

De P1 meter moet gewoon zo snel mogelijk zijn (bijv elke seconde de huidige data sturen). Als die elke seconde verse data levert, zal de Aansturing bij elke opdracht aan de batterij dit op basis doen van zo vers mogelijke data (max 1 seconde oud).

Het optimale interval van de Aansturing hangt vooral af van de reactietijd van de batterij. Blijkbaar 4 of 5 seconden.

[gielz]

Voor de Gielz zal er een plug-n-play dasbhoard gemaakt worden waar je direct lekker mee aan de slag kunt zonder zelf het wiel uit te vinden. Deze bestaat nu uit 3 tabbladen, de vraag is alleen of er nog leuke ideeën zijn. Graag via DM

Uiteraard kun je ook gewoon data er uit pakken en in je eigen dashboard plakken/aanpassen.

Grafiek batterij;
- Realtime zien wat er gedaan word.
- Zoom functie.
- NOM doel zichtbaar, waar moet de batterij naar toe.
- Via legenda inzichtelijk welke oplaad/ontlaad start ingesteld staat.


Tabblad Zendure
- Grafiek hoeveel NOM uren per dag
- Batterij grafiek


Tabblad extra informatie
- Efficiëntie grafiek van de dag


Tabblad configuratie

[gast777]

Ter info voor de Gielz gebruikers met twee Zendures:

Met de Gielz Maart versie en de nieuwste Proxy versie is het toevoegen van de Proxy weer een stuk simpeler geworden.

- Aan de Proxy Node-RED kant:
* Enkel de IP adressen van de Zendures hoeven ingevuld te worden in de Proxy. Serienummers hoeven niet meer ingevuld te worden.

- Aan de HA kant:
* Om de proxy aan het werk te krijgen zijn alleen twee simpele settings via het HA Dashboard nodig. Geen edits in Gielz bestanden meer nodig daarvoor.
*Om de optionele extra HA sensoren eenvoudig toe te voegen in de Gielz configuratie staan er duidelijke markeringen in het bestand waar je de sensoren simpel via copy-paste kunt inplakken.



Mochten er nog suggesties zijn, stuur gerust een DM.

[hapklaar]

Devke schreef op zaterdag 14 februari 2026 @ 14:49:
[...]

Ik heb deze bug al eens gemeld bij Zendure. Zie deze post https://gathering.tweakers.net/forum/view_message/83214288

Weet je zeker dat dit om hetzelfde gaat? Bij mij is het ca 50W verbruik bij smartmode=1, jouw post lijkt te gaan over 25 W verbruik na het in standby gaan.

[DrNickB]

gielz schreef op zaterdag 14 februari 2026 @ 19:54:
[...]
Ik zou graag nog de zendures met zonnepalen in de basis opnemen. Alleen nog niemand gevonden die exact kan vertellen wat er ander is aan de commands

@gielz
Het probleem zat hem volgens mij in het beginsel in 1 van de configuratie waardes (Originele gielz config uit 20250826):

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 %}

Deze waarde wordt gebruikt in de automatisering (Origineel uit de 20250826 autmatisering):

code:

- conditions:
          - 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 = -5 %}
              {% set p1 = states('sensor.p1_aansturing_api_v1') | float(0) %}
              {% set zendure = states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0) %}
              {% set totaal = (p1 - zendure - correctie) * 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 }}
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_vermogen_aansturing
            below: 0
          - 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
        sequence:
          - data:
              outputLimit: >-
                {% set factor = 1.00 %}
                {% set cap = 2400 %}
                {% set correctie = -5 %}
                {% set p1 = states('sensor.p1_aansturing_api_v1') | float(0) %} 
                {% set zendure =  states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0) %}
                {% set totaal = (p1 - zendure - correctie) * factor %}
                {% set beperkt = [[totaal, 0] | max, cap ] | min %}
                {{ beperkt | int }}
            action: rest_command.zendure_x_ontladen_balanceren
        alias: Tijdens ontladen balanceren naar 0 watt (100% van de vraag)

Mijn aanpassing is geweest op de automatisering om de sensor.zendure_2400_ac_vermogen_aansturing te vervangen door mijn HW-Plug (en 1 condition uit te zetten):

code:

- conditions:
          - condition: numeric_state
            entity_id: sensor.zendure_800_pro_laadpercentage
            above: 10
          - condition: template
            value_template: >-
              {% set factor = 1.00 %} 
              {% set cap = 800 %} 
              {% set correctie = 10 %}
              {% set p1 = states('sensor.verbruik_en_levering_verschil') | float(0) %}
              {% set zendure = states('sensor.homewizard_active_power') | float(0) %}
              {% set totaal = (p1 - zendure - correctie) * factor %} 
              {% set beperkt = [[totaal, 0] | max, cap ] | min %} 
              {% set target = beperkt | int %} 
              {% set huidig = states('sensor.zendure_800_pro_ingesteld_ontlaadvermogen') | int(0) %} 
              {{ huidig != target }}
          - condition: numeric_state
            entity_id: sensor.zendure_800_pro_vermogen_aansturing
            below: 0
            enabled: false
          - condition: or
            conditions:
              - condition: state
                entity_id: input_select.zendure_800_pro_modus_selecteren
                state: Nul op de meter
              - condition: state
                entity_id: input_select.zendure_800_pro_modus_selecteren
                state: Alleen slim ontladen
        sequence:
          - data:
              outputLimit: >-
                {% set factor = 1.00 %}
                {% set cap = 800 %}
                {% set correctie = 10 %}
                {% set p1 = states('sensor.verbruik_en_levering_verschil') | float(0) %}
                {% set zendure = states('sensor.homewizard_active_power') | float(0) %}
                {% set totaal = (p1 - zendure - correctie) * factor %}
                {% set beperkt = [[totaal, 0] | max, cap ] | min %}
                {{ beperkt | int }}
            action: rest_command.zendure_x_ontladen_balanceren
        alias: Tijdens ontladen balanceren naar 0 watt (100% van de vraag)

Een voorbeeld /report tijdens ontlading (handmatig) inclusief zonne opwek die hoger is dan ontlading, dus overvloed van energie gaat richting batt.

code:

# zonne kracht 400, handmatig 150w ontladen; 250w overschot Richting Accu
        "packInputPower": 0,
        "outputPackPower": 249,
        "outputHomePower": 149,
        "packState": 1,
        "electricLevel": 29,
        "gridInputPower": 0,
        "solarInputPower": 398,
        "solarPower1": 138,
        "solarPower2": 136,
        "solarPower3": 124,
        "solarPower4": 0,
        "outputLimit": 150,

outputPackPower staat hier op 250, dit betekend voor een sf800pro in dit geval 'opladen'; terwijl hij ook aan het leveren is. OutputHomePower zou in dit geval een goede waarde kunnen geven.
Zonder panelen zou de outputPackPower op 0 moeten staan en zal de packInputPower naar 150 gaan.


Live voorbeeld van dit moment 'slim ontladen', met heeel weinig zon en dus de rest uit de batterij:

code:

"heatState": 0,
        "packInputPower": 258,
        "outputPackPower": 0,
        "outputHomePower": 296,
        "packState": 2,
        "electricLevel": 47,
        "gridInputPower": 0,
        "solarInputPower": 38,
        "solarPower1": 13,
        "solarPower2": 12,
        "solarPower3": 13,
        "solarPower4": 0,
        "outputLimit": 296,

Ik had een begin gemaakt om 'outputHomePower' te gaan gebruiken, echter ben ik op de HW-Plug blijven hangen, iets met gemeten waarde vs wat het apparaat zegt wat hij zou moeten doen.

Hoop dat je hier iets aan hebt, vragen stil gerust, kan meer dingen aanleveren des gewenst.

[ppaulv]

hapklaar schreef op zondag 15 februari 2026 @ 15:09:
[...]


Weet je zeker dat dit om hetzelfde gaat? Bij mij is het ca 50W verbruik bij smartmode=1, jouw post lijkt te gaan over 25 W verbruik na het in standby gaan.

wellicht om alles nog wat 'leuker' te maken. Ik had/heb vandaag 'alleen slim opladen' aan staan en wat uurtjes zon gehad. En ik heb 2 diepvriesjes permanent aan het off-grid stopcontact hangen.
Ik merkte vandaag dat, tot enig tijd na het op standby gaan, de energie voor de diepvriesjes uit de accu gehaald wordt en niet uit het grid, althans, dat is zichtbaar in de Zendure app. Terwijl dat buiten de drukke periodes van opladen/ontladen de energie rechtstreeks uit het grid gehaald wordt.
@gielz wordt dat gedicteerd door de standby vertraging die je recent hebt toegevoegd?
En in HA zie ik op diezelfde momenten als hierboven aangegeven dat de diepvries energie uit de accu komt, dat de accu met dat aantal watts staat te ontladen (terwijl de Zendure app zegt dat ie niet aan het ontladen is maar daarentegen energie aan de diepvriesjes levert.
Ik zie door de bomen het bos niet meer betreffende of dit al besproken is of niet. Indien dat is gedaan, excuses.

[ppaulv]

En getriggerd door het laatste bericht van @gielz , ik vind persoonlijk het standaard bewegende plaatje van de energieflows erg mooi 'bekken' als eye-catcher. En zou graag weten of ik dat ding zelf ergens in een dashboard kan zetten (en hoe). Meen dat ik dat een tijd geleden al gezien heb maar ben niet zeker.

[gielz]

ppaulv schreef op zondag 15 februari 2026 @ 16:47:
En getriggerd door het laatste bericht van @gielz , ik vind persoonlijk het standaard bewegende plaatje van de energieflows erg mooi 'bekken' als eye-catcher. En zou graag weten of ik dat ding zelf ergens in een dashboard kan zetten (en hoe). Meen dat ik dat een tijd geleden al gezien heb maar ben niet zeker.

[Afbeelding]

Deze kaarten zijn gewoon toe te voegen aan een eigen dashboard en staan hier beschreven;
https://www.home-assistant.io/dashboards/energy/

[gielz]

ppaulv schreef op zondag 15 februari 2026 @ 16:45:
[...]

wellicht om alles nog wat 'leuker' te maken. Ik had/heb vandaag 'alleen slim opladen' aan staan en wat uurtjes zon gehad. En ik heb 2 diepvriesjes permanent aan het off-grid stopcontact hangen.
Ik merkte vandaag dat, tot enig tijd na het op standby gaan, de energie voor de diepvriesjes uit de accu gehaald wordt en niet uit het grid, althans, dat is zichtbaar in de Zendure app. Terwijl dat buiten de drukke periodes van opladen/ontladen de energie rechtstreeks uit het grid gehaald wordt.
@gielz wordt dat gedicteerd door de standby vertraging die je recent hebt toegevoegd?
En in HA zie ik op diezelfde momenten als hierboven aangegeven dat de diepvries energie uit de accu komt, dat de accu met dat aantal watts staat te ontladen (terwijl de Zendure app zegt dat ie niet aan het ontladen is maar daarentegen energie aan de diepvriesjes levert.
Ik zie door de bomen het bos niet meer betreffende of dit al besproken is of niet. Indien dat is gedaan, excuses.

Standby vertraging doet niets anders dan Smartmode = 1 omzetten naar = 0 na de ingestelde tijd. Zal dus niets aan je offgrid of sturing veranderen buiten dat het flashgeheugen ingezet word bij = 0;

1: The setting parameter is not written to flash. After an unexpected power loss and restart, the device will use the value stored in flash. 0: The setting parameter is written to flash. If you frequently set device properties, set this to 1.

[ppaulv]

gielz schreef op zondag 15 februari 2026 @ 16:51:
[...]


Deze kaarten zijn gewoon toe te voegen aan een eigen dashboard en staan hier beschreven;
https://www.home-assistant.io/dashboards/energy/

Hi @gielz , bedankt voor je reactie. Nou ben ik enigzins blond natuurlijk, maar die link die je stuurt verwijst naar een pagina waarop staat dat het mogelijk is maar op geen enkele manier wordt gesuggereerd 'hoe'. Met alle respect voor de HA makers van deze pagina's, maar dat vind ik nogal irritant, eigenijk.
Gelukkig wist ChatGPT me in 10 seconden tot het gewenste resultaat te leiden ....

[Devke]

hapklaar schreef op zondag 15 februari 2026 @ 15:09:
[...]


Weet je zeker dat dit om hetzelfde gaat? Bij mij is het ca 50W verbruik bij smartmode=1, jouw post lijkt te gaan over 25 W verbruik na het in standby gaan.

25 W is per set. Totaal hier dus ook 50W. Opslaan in RAM is actief dan.

[ben]

dit topic gaat specifiek over Zendure producten in Home Assistant integreren.

[ Voor 80% gewijzigd door teacher op 16-02-2026 07:46 ]

[Doggieman]

dit topic gaat specifiek over Zendure producten in Home Assistant integreren.

[ Voor 102% gewijzigd door teacher op 16-02-2026 07:47 ]

[mutsaards]

Hoi Gielz, ik worstel nog steeds met een SF2400 op een 4.2 meter.
Ik heb inmiddels je automatisering in HA geplaatst en werkend.
Eerst met tijd op standaard 4 sec. gelijk oscilatie.
Vervolgens met geadviseerde 11 sec, beter maar onstabiel.
Laatst met 20 sec.

Maar ik mis een belangrijke instelling in je automatisering en zie deze ook niet terug in de Entiteiten lijst: max laad en ontlaad instelling is wel belangrijk als unit niet op een eindgroep zit.

Uit scherm afdruk van externe energie meter blijkt dat bij de oscilatie met de 4 sec instelling unit ook gelijk doorschiet naar 2400 W = trikkie

Parameter beschikbare energie lijkt mij maar de weergave van 1 batterij

[mutsaards]

Oeps foto niet meegekomen.

[ppaulv]

mutsaards schreef op maandag 16 februari 2026 @ 14:15:
Hoi Gielz, ik worstel nog steeds met een SF2400 op een 4.2 meter.
Ik heb inmiddels je automatisering in HA geplaatst en werkend.
Eerst met tijd op standaard 4 sec. gelijk oscilatie.
Vervolgens met geadviseerde 11 sec, beter maar onstabiel.
Laatst met 20 sec.

Maar ik mis een belangrijke instelling in je automatisering en zie deze ook niet terug in de Entiteiten lijst: max laad en ontlaad instelling is wel belangrijk als unit niet op een eindgroep zit.

Uit scherm afdruk van externe energie meter blijkt dat bij de oscilatie met de 4 sec instelling unit ook gelijk doorschiet naar 2400 W = trikkie

Parameter beschikbare energie lijkt mij maar de weergave van 1 batterij

Ik heb dezelfde issues gehad maar draai nu op 25 seconden omdat m'n P1 meter af en toe wat overslaat.
Maar je bedoelt deze denk ik? Die zitten er standaard in (laatste versie).

[ppaulv]

(behalve het Zendure P1 adres, die heb ik er zelf bij gemaakt)

[hapklaar]

Devke schreef op zondag 15 februari 2026 @ 19:53:
[...]

25 W is per set. Totaal hier dus ook 50W. Opslaan in RAM is actief dan.

Ik heb maar 1 set en toch 50W verbruik bij smartmode=1

[gielz]

hapklaar schreef op dinsdag 17 februari 2026 @ 14:08:
[...]


Ik heb maar 1 set en toch 50W verbruik bij smartmode=1

Welke integratie gebruik je in Home Assistant?

[hapklaar]

gielz schreef op dinsdag 17 februari 2026 @ 15:04:
[...]


Welke integratie gebruik je in Home Assistant?

Ik gebruik jouw scripts via configuration.yaml. Heb de officiële integratie (1.2.5) ook geïnstalleerd, maar die staat op Operation mode=Off

[gielz]

hapklaar schreef op dinsdag 17 februari 2026 @ 15:21:
[...]


Ik gebruik jouw scripts via configuration.yaml. Heb de officiële integratie (1.2.5) ook geïnstalleerd, maar die staat op Operation mode=Off

Oké dus je draait de Gielz en draait hier volledig de batterij op via de automatisering? Het probleem wat je beschrijft bestaat namelijk niet meer sinds versie v20260115.

[hapklaar]

@gielz Ik had de versie van 20260114. Heb nu de de laatste automation en configuration.yaml van github gepakt en ga weer testen. Thanks!

[ Voor 3% gewijzigd door hapklaar op 17-02-2026 16:38 ]

[hapklaar]

@gielz Ik zie geen verschil, nog steeds 47W verbruik als opslaan in RAM actief is.

[gielz]

hapklaar schreef op dinsdag 17 februari 2026 @ 16:45:
@gielz Ik zie geen verschil, nog steeds 47W verbruik als opslaan in RAM actief is.

- Interessant, die 47 watt zie je die op een energysocket of daadwerkelijk bij de batterij?

- Staat de offgrid aan? Hangt er iets aan de offgrid?

- In welke modus staat de batterij met 47 watt te draaien?

- Heb je wat schermafbeeldingen van de log en wat je nu exact ziet?

Leuke uitdaging iig

[TopOne01]

Ik draai al enige tijd op de "dynamisch handelen" modus van Gielz. 10x een kwartier opladen met 2400w en 8x ontladen op 2400w. Werkt perfect maar we krijgen nu steeds meer dagen waarbij de prijzen 's middags goedkoper zijn dan 's nachts. Voor morgen staat nu dit gepland:

Kan ik op een manier forceren dat er eerst geladen moet worden voordat hij kan ontladen? Of is dit toevallig al in de laatste updates verwerkt?
Nu wilt hij morgen eerst ontladen terwijl de SOC 10%, m.a.w. nu eindig ik morgen aan het einde van de dag met een volle accu. Als overmorgen de prijzen vergelijkbaar zijn met morgen zit de accu "in het goede ritme" alleen is de berekening van de spread niet correct.
Zie ik wat over het hoofd of begrijp ik iets niet goed of moet ik het handmatig instellen voor een dag als morgen?

[gielz]

TopOne01 schreef op dinsdag 17 februari 2026 @ 18:14:
Ik draai al enige tijd op de "dynamisch handelen" modus van Gielz. 10x een kwartier opladen met 2400w en 8x ontladen op 2400w. Werkt perfect maar we krijgen nu steeds meer dagen waarbij de prijzen 's middags goedkoper zijn dan 's nachts. Voor morgen staat nu dit gepland:
[Afbeelding]
Kan ik op een manier forceren dat er eerst geladen moet worden voordat hij kan ontladen? Of is dit toevallig al in de laatste updates verwerkt?
Nu wilt hij morgen eerst ontladen terwijl de SOC 10%, m.a.w. nu eindig ik morgen aan het einde van de dag met een volle accu. Als overmorgen de prijzen vergelijkbaar zijn met morgen zit de accu "in het goede ritme" alleen is de berekening van de spread niet correct.
Zie ik wat over het hoofd of begrijp ik iets niet goed of moet ik het handmatig instellen voor een dag als morgen?

Bij dit soort dagen via de handmatige periode. Blijkt dit nou vaak voor te maken dan zal ik het gaan aanpassen bijvoorbeeld een vinkje "Goedkope uren voor duurdere uren"

[lars1986]

Vandaag de maart release "geinstalleerd" top dat het nu via een package kan!
Houdt de config netjes schoon... Top werk weer!!!

[hapklaar]

gielz schreef op dinsdag 17 februari 2026 @ 16:56:
[...]


- Interessant, die 47 watt zie je die op een energysocket of daadwerkelijk bij de batterij?

- Staat de offgrid aan? Hangt er iets aan de offgrid?

- In welke modus staat de batterij met 47 watt te draaien?

- Heb je wat schermafbeeldingen van de log en wat je nu exact ziet?

Leuke uitdaging iig

Ik kan het niet meer reproduceren, lijkt nu inderdaad toch opgelost!

[Devke]

hapklaar schreef op woensdag 18 februari 2026 @ 20:47:
[...]


Ik kan het niet meer reproduceren, lijkt nu inderdaad toch opgelost!

Je kunt het denk ik reproduceren door even de batterij aan het werk te zetten. Dat weer te stoppen. Je sensor waar je de standby vertraging hebt ingesteld (hier 5 min) bepaald de tijd van verbruik nog. Na die tijd klapt het om naar 0.

[hapklaar]

Devke schreef op woensdag 18 februari 2026 @ 20:53:
[...]

Je kunt het denk ik reproduceren door even de batterij aan het werk te zetten. Dat weer te stoppen. Je sensor waar je de standby vertraging hebt ingesteld (hier 5 min) bepaald de tijd van verbruik nog. Na die tijd klapt het om naar 0.

Zo test ik het inderdaad ook, maar nu gaat hij als ik dit doe en opslaan in RAM nog actief is niet naar 47W, maar naar 7W. Zodra de standby vertraging over is, gaat de meter naar 1W.

[denneappel]

Ik zat gisteren avond in de problemen met het aanpassen van unique_id's. Tot nu toe kom ik er niet uit maar net stuitte ik op een post in het HA topic: TheFes in "Home Assistant: Open source Python3 home automation - deel 5"

In de Gielz config wordt gebruik gemaakt van name en unique_id... Ik krijg de unique_id's niet aangepast.
Iedere keer als ik die aanpas komt er een _2 sensor in HA. Hebben meer mensen hier last van? Ik zie echt door "de bomen het bos niet meer". Zelfs als ik een verse Home Assistant in Docker start krijg ik het niet voor elkaar. Het blijft gebasseerd op de name. Ik heb het idee dat unique_id hier niet zo veel doet.

[denneappel]

Ik heb ook nog even gekeken wat ik nu had aangepast om mijn 800 pros (met PV) aan te sturen in HA met Gielz zijn code.

Het verschil zit hem in de grid vs pack power. In @gielz zijn aansturing wordt packpower als aansturing gezien terwijl dit ook een waarde geeft als er DC PV geladen wordt.
Zodra er dus PV geladen wordt faalt de aansturing.

ZenSDK biedt gelukkig ook grid power. Deze neemt enkele de AC power mee en verstoort de boel niet. Ik vermoed dat dit op de AC2400 ook beschikbaar is en net zo goed werkt.

Ik ben nog even aan het grasduinen, wellicht had ik nog een aanpassing gedaan.

YAML:

# uit de Github repo
      - name: "Zendure 2400 AC Vermogen Aansturing"
        value_template: >
          {% set opladen = value_json['properties']['outputPackPower'] | int %}
          {% set ontladen = - (value_json['properties']['packInputPower'] | int) %}



# mijn huidige config
      - name: "Zendure 800 pro 1 Vermogen Aansturing"
        value_template: >
          {% set opladen = value_json['properties']['gridInputPower'] | int %}
          {% set ontladen = - (value_json['properties']['outputHomePower'] | int) %}

[gielz]

denneappel schreef op donderdag 19 februari 2026 @ 10:28:
Ik zat gisteren avond in de problemen met het aanpassen van unique_id's. Tot nu toe kom ik er niet uit maar net stuitte ik op een post in het HA topic: TheFes in "Home Assistant: Open source Python3 home automation - deel 5"

In de Gielz config wordt gebruik gemaakt van name en unique_id... Ik krijg de unique_id's niet aangepast.
Iedere keer als ik die aanpas komt er een _2 sensor in HA. Hebben meer mensen hier last van? Ik zie echt door "de bomen het bos niet meer". Zelfs als ik een verse Home Assistant in Docker start krijg ik het niet voor elkaar. Het blijft gebasseerd op de name. Ik heb het idee dat unique_id hier niet zo veel doet.

Heb je wat voorbeelden van _2? Ik heb toevallig dit laatst opgelost bij een probleem met mijn zwarte bak sensor.

[gast777]

Zo te zien zijn er inderdaad andere attributen die dezelfde waarde geven: outputHomePower en gridInputPower

In Node-RED kun je de messages mooi bekijken.

1000 Watt laden:


1000 Watt ontladen:

[Pakhaas]

Ik zat een beetje na te denken over de situatie na het salderen tijdperk.

Graag zou ik iets willen in HA dat ik kan zien of het financieel verstandig is om nachts de auto te laden van zonnestroom of juist de batterij op non-actief en van het stroomnet de stroom halen, rekening houdend met laadverliezen van 85%.

Dus stel:
Overdag laadt ik de batterij met pv stroom waar ik bij terugleveren 9ct voor krijg. Nachts kost laden 20ct incl btw en eb. Daarmee bespaar ik 11ct per kwh, maar gaat nog 15% vanaf ivm laadverliezen. Dus het levert mij 9.35 op. Zodra dat bedrag onder de 9 duikt, kan ik beter rechtstreeks van het stroomnet laden.

(ik heb het stukje afschrijving per laadsessie, niet meegenomen)

Zit ik goed qua gedachte, of is dit te kort door de bocht?

[DrNickB]

denneappel schreef op donderdag 19 februari 2026 @ 10:30:Ik ben nog even aan het grasduinen, wellicht had ik nog een aanpassing gedaan.

YAML:

# uit de Github repo
      - name: "Zendure 2400 AC Vermogen Aansturing"
        value_template: >
          {% set opladen = value_json['properties']['outputPackPower'] | int %}
          {% set ontladen = - (value_json['properties']['packInputPower'] | int) %}


# mijn huidige config
      - name: "Zendure 800 pro 1 Vermogen Aansturing"
        value_template: >
          {% set opladen = value_json['properties']['gridInputPower'] | int %}
          {% set ontladen = - (value_json['properties']['outputHomePower'] | int) %}

Inderdaad een goede, denk dat dit mogelijk het hele probleem op lost, net zoals @gast777 hierboven ook beschrijft.

Met PV opbrengst blijven die waardes gelijk, ongeacht wat de zon doet.
met 1 grote maar, als je 'Teruglevering' op aan hebt staan, je batterij vol zit, er (veel) zon is en de vraag in huis is laag. Dan gaat de output Home omhoog, P1 ziet terug levering, waardoor hij zou willen gaan opladen (Bij NOM) maar dat gaat niet want batt vol

[gielz]

Ik zou het graag willen oplossen dat zonnepanelen ook gewoon out of the box ondersteund worden en dat je ook netjes de opwek in een grafiek ziet. Helaas heb ik niet de beschikking tot een Zendure waar ik even een paar zonnepanelen aan kan prikken van de schuur.

Zendure wel meerdere keren geprobeerd te contacten maar de deur zit daar op slot en voor nu met meerdere sloten. Elke vraag word direct afgesloten met "We value your feedback". Des te meer motivatie om ervoor te zorgen dat de Gielz altijd 100% lokaal zonder inbreng van Zendure blijft werken en dat je deze altijd 100% zelf nog kunt aanpassen.

Zal ze vandaag nog eens een mailtje sturen.

[DrNickB]

gielz schreef op donderdag 19 februari 2026 @ 15:44:
Ik zou het graag willen oplossen dat zonnepanelen ook gewoon out of the box ondersteund worden en dat je ook netjes de opwek in een grafiek ziet. Helaas heb ik niet de beschikking tot een Zendure waar ik even een paar zonnepanelen aan kan prikken van de schuur.

Zendure wel meerdere keren geprobeerd te contacten maar de deur zit daar op slot en voor nu met meerdere sloten. Elke vraag word direct afgesloten met "We value your feedback". Des te meer motivatie om ervoor te zorgen dat de Gielz altijd 100% lokaal zonder inbreng van Zendure blijft werken en dat je deze altijd 100% zelf nog kunt aanpassen.

Zal ze vandaag nog eens een mailtje sturen.

Wat wil je testen? geef me wat scenarios en ik zal kijken of ik dat kan realiseren d.m.v. /reports en eventueel wat aanpassingen aan de code, met kant tekening dat ik wel op een oude versie draai en niks doen met handelen doe, wat het testen van alle scenarios wat moeilijker maakt

[gielz]

DrNickB schreef op donderdag 19 februari 2026 @ 15:58:
[...]


Wat wil je testen? geef me wat scenarios en ik zal kijken of ik dat kan realiseren d.m.v. /reports en eventueel wat aanpassingen aan de code, met kant tekening dat ik wel op een oude versie draai en niks doen met handelen doe, wat het testen van alle scenarios wat moeilijker maakt

Ik vraag me dus af hoe het exact werkt. Stel de zonnepanelen leveren stroom. Hoe regelt hij dan dat hij deze stroom direct aan je huis levert en niet eerst via je batterij en dan pas naar je huis stuurt? Reageer anders even via DM anders vervuilt het hier zo.

[denneappel]

PV laad standaard de batterij op.
PV gaat enkel direct naar het net als batterij 100% is en gridReverse 1

Daarnaast kan PV uiteraard direct naar grid gaan als je meer stroom vraagt over AC dan er DC wordt geleverd.

Ik sta trouwens ook open om zaken te testen op 1 van mijn 800 pro's. Heb nog een vast xontract de komende periode dus geen financiele drang om het perfect te laten lopen.

[avdwerf]

denneappel schreef op donderdag 19 februari 2026 @ 10:28:
Ik zat gisteren avond in de problemen met het aanpassen van unique_id's. Tot nu toe kom ik er niet uit maar net stuitte ik op een post in het HA topic: TheFes in "Home Assistant: Open source Python3 home automation - deel 5"

In de Gielz config wordt gebruik gemaakt van name en unique_id... Ik krijg de unique_id's niet aangepast.
Iedere keer als ik die aanpas komt er een _2 sensor in HA.

Dat met die _2 heb ik eerder gehad met een andere integratie. Bleek dat de entities nog niet bestonden, maar als ik in de ontwikkeltools bij statistieken keek bleek er nog historische data te zijn die onder dat specifieke entity ID stond. Na het verwijderen van de statistieken daar kreeg bij het opnieuw aanmaken de entities geen _2 meer in de naam.

[denneappel]

Ik heb nog even een nieuwe Home Assistant in Docker gestart met de Gielz aansturing van maart (20260214).
Onderstaande 2 wijzigingen zijn nodig om het correct werkend te krijgen op een 800 pro + DC PV.
Wel denk ik dat de RTE berekening nog niet goed werkt omdat deze dezelfde variabelen gebruikt. Deze RTE meting gebruik ik niet maar is toch wel interessant om eens naar te gaan kijken. Dus wellicht kunnen we daar binnenkort eens naar kijken.

Bij deze in elk geval het verzoek om onmderstaande te gaan testen zodat @gielz dit mee kan nemen in de April release.
Dit zou ook op een 2400 AC moeten werken dus test het vooral zowel met/zonder DC PV.

1. Om te bepalen met hoevel vermogen er wordt aangestuurd gebruiken ik nu gridinputPower en outputHomePower
https://github.com/Gielz1...nsdk_gielz1986.yaml#L1529

YAML:

- name: "Zendure 2400 AC Vermogen Aansturing"
        value_template: >
          {% set opladen = value_json['properties']['gridInputPower'] | int %}
          {% set ontladen = - (value_json['properties']['outputHomePower'] | int) %}
          {% if opladen != 0 %}
            {{ opladen }}
          {% else %}
            {{ ontladen }}
          {% endif %}
        unique_id: zendure_1_Vermogen_Aansturing
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

2. Datzelfe om te bepalen of de AC omvormer aan het laden of ontladen is.
https://github.com/Gielz1...nsdk_gielz1986.yaml#L1612

YAML:

- name: "Zendure 2400 AC Modus"
        value_template: >
          {% set ac_mode = value_json['properties']['acMode'] | int %}
          {% set input_power = value_json['properties']['gridInputPower'] | int %}
          {% set output_power = value_json['properties']['outputHomePower'] | int %}

          {% if ac_mode == 1 and input_power > 0 %}
           Opladen
          {% elif ac_mode == 2 and output_power > 0 %}
           Ontladen
          {% else %}
           Standby
          {% endif %}

Daarnaast gebruik ik onderstaande om de PV productie ook in Home Assistant te krijgen. Dit neemt gielz nvooralsnog niet mee volgens mij maar wellicht maak ik er nog iemand blij mee. (Ik gebruik zelf andere namen voor de batterijen ;-) )

YAML:

- name: "Zendure 800 pro 1 Vermogen PV totaal"
        value_template: "{{ value_json['properties']['solarInputPower'] | int }}"
        unique_id: Zendure_800_pro_1_Vermogen_PV_totaal
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

      - name: "Zendure 800 pro 1 Vermogen PV 1"
        value_template: "{{ value_json['properties']['solarPower1'] | int }}"
        unique_id: Zendure_800_pro_1_Vermogen_PV_1
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

      - name: "Zendure 800 pro 1 Vermogen PV 2"
        value_template: "{{ value_json['properties']['solarPower2'] | int }}"
        unique_id: Zendure_800_pro_1_Vermogen_PV_2
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

      - name: "Zendure 800 pro 1 Vermogen PV 3"
        value_template: "{{ value_json['properties']['solarPower3'] | int }}"
        unique_id: Zendure_800_pro_1_Vermogen_PV_3
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

      - name: "Zendure 800 pro 1 Vermogen PV 4"
        value_template: "{{ value_json['properties']['solarPower4'] | int }}"
        unique_id: Zendure_800_pro_1_Vermogen_PV_4
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

[gielz]

denneappel schreef op vrijdag 20 februari 2026 @ 11:16:
Ik heb nog even een nieuwe Home Assistant in Docker gestart met de Gielz aansturing van maart (20260214).
Onderstaande 2 wijzigingen zijn nodig om het correct werkend te krijgen op een 800 pro + DC PV.
Wel denk ik dat de RTE berekening nog niet goed werkt omdat deze dezelfde variabelen gebruikt. Deze RTE meting gebruik ik niet maar is toch wel interessant om eens naar te gaan kijken. Dus wellicht kunnen we daar binnenkort eens naar kijken.

Bij deze in elk geval het verzoek om onmderstaande te gaan testen zodat @gielz dit mee kan nemen in de April release.
Dit zou ook op een 2400 AC moeten werken dus test het vooral zowel met/zonder DC PV.

1. Om te bepalen met hoevel vermogen er wordt aangestuurd gebruiken ik nu gridinputPower en outputHomePower
https://github.com/Gielz1...nsdk_gielz1986.yaml#L1529

YAML:

- name: "Zendure 2400 AC Vermogen Aansturing"
        value_template: >
          {% set opladen = value_json['properties']['gridInputPower'] | int %}
          {% set ontladen = - (value_json['properties']['outputHomePower'] | int) %}
          {% if opladen != 0 %}
            {{ opladen }}
          {% else %}
            {{ ontladen }}
          {% endif %}
        unique_id: zendure_1_Vermogen_Aansturing
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

2. Datzelfe om te bepalen of de AC omvormer aan het laden of ontladen is.
https://github.com/Gielz1...nsdk_gielz1986.yaml#L1612

YAML:

- name: "Zendure 2400 AC Modus"
        value_template: >
          {% set ac_mode = value_json['properties']['acMode'] | int %}
          {% set input_power = value_json['properties']['gridInputPower'] | int %}
          {% set output_power = value_json['properties']['outputHomePower'] | int %}

          {% if ac_mode == 1 and input_power > 0 %}
           Opladen
          {% elif ac_mode == 2 and output_power > 0 %}
           Ontladen
          {% else %}
           Standby
          {% endif %}

Daarnaast gebruik ik onderstaande om de PV productie ook in Home Assistant te krijgen. Dit neemt gielz nvooralsnog niet mee volgens mij maar wellicht maak ik er nog iemand blij mee. (Ik gebruik zelf andere namen voor de batterijen ;-) )

YAML:

- name: "Zendure 800 pro 1 Vermogen PV totaal"
        value_template: "{{ value_json['properties']['solarInputPower'] | int }}"
        unique_id: Zendure_800_pro_1_Vermogen_PV_totaal
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

      - name: "Zendure 800 pro 1 Vermogen PV 1"
        value_template: "{{ value_json['properties']['solarPower1'] | int }}"
        unique_id: Zendure_800_pro_1_Vermogen_PV_1
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

      - name: "Zendure 800 pro 1 Vermogen PV 2"
        value_template: "{{ value_json['properties']['solarPower2'] | int }}"
        unique_id: Zendure_800_pro_1_Vermogen_PV_2
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

      - name: "Zendure 800 pro 1 Vermogen PV 3"
        value_template: "{{ value_json['properties']['solarPower3'] | int }}"
        unique_id: Zendure_800_pro_1_Vermogen_PV_3
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

      - name: "Zendure 800 pro 1 Vermogen PV 4"
        value_template: "{{ value_json['properties']['solarPower4'] | int }}"
        unique_id: Zendure_800_pro_1_Vermogen_PV_4
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

Thanks, ik heb dit hier nu intern aangepast om te zien of de 2400 AC gewoon netjes zijn werk blijft doet. Ben benieuwd naar de resultaten met de 800 pro/plus en wellicht een 2400 pro

[AWEF]

@gielz Misschien is het een idee om de namen van de entities uniform of zelf-invulbaar te maken? Als je hem nu 1-op-1 kopieert, dan is het altijd "Zendure 2400" en ik heb helemaal geen 2400, ik heb de 800 Pro....

(Ik weet het, je kan de namen aanpassen in de yaml, maar dat moet dan bij elke release)

[gielz]

AWEF schreef op vrijdag 20 februari 2026 @ 12:24:
@gielz Misschien is het een idee om de namen van de entities uniform of zelf-invulbaar te maken? Als je hem nu 1-op-1 kopieert, dan is het altijd "Zendure 2400" en ik heb helemaal geen 2400, ik heb de 800 Pro....

(Ik weet het, je kan de namen aanpassen in de yaml, maar dat moet dan bij elke release)

Het idee was om dit aan te passen van zendure_2400_ac naar zendure. Alleen wanneer je daarna de update installeert ben je al je geschiedenis kwijt en moet je alles opnieuw opbouwen.

Daarom is er gekozen om het nu zo te houden. Dit omdat je de ids niet gebruikt voor dashboards en daar je eigen naam aan geeft.

En alle tijd die daardoor vrij komt te investeren in een betere aansturing/meer opties.

Je bent trouwens niet verplicht om hem te gebruiken.

[AWEF]

gielz schreef op vrijdag 20 februari 2026 @ 13:05:
[...]


Het idee was om dit aan te passen van zendure_2400_ac naar zendure. Alleen wanneer je daarna de update installeert ben je al je geschiedenis kwijt en moet je alles opnieuw opbouwen.

Daarom is er gekozen om het nu zo te houden. Dit omdat je de ids niet gebruikt voor dashboards en daar je eigen naam aan geeft.

En alle tijd die daardoor vrij komt te investeren in een betere aansturing/meer opties.

Je bent trouwens niet verplicht om hem te gebruiken.

Ik heb hem een poosje gebruikt maar bij mij werkte het niet lekker (met de 800 Pro). Ik gebruik nu de yaml wel voor het uitlezen, verder staat die in HEMS

Neemt niet weg dat je een heel goed stuk werk geleverd heb (en nog steeds doet)

[JSven]

@gielz Een kleine typo in de uitleg van de configuratie 😅

[GoSolarFlow]

Hoe staan jullie eigenlijk tegenover het bijwerken van HA, Hacs, Zendure integration en firmware updates?
Ik heb mijn eigen automatisering klaar en het loopt precies zoals ik wil en wil dit natuurlijk ook zo houden.
Bijwerken en firmware updates kunnen dingen die nu werken slopen en vroeg mij af of het dat wel waard is om uit te voeren of lopen laten zolang het loopt.
Wat is jullie mening hierover?

[Devke]

GoSolarFlow schreef op zaterdag 21 februari 2026 @ 12:09:
Hoe staan jullie eigenlijk tegenover het bijwerken van HA, Hacs, Zendure integration en firmware updates?
Ik heb mijn eigen automatisering klaar en het loopt precies zoals ik wil en wil dit natuurlijk ook zo houden.
Bijwerken en firmware updates kunnen dingen die nu werken slopen en vroeg mij af of het dat wel waard is om uit te voeren of lopen laten zolang het loopt.
Wat is jullie mening hierover?

Ik loop met HA altijd een paar slagen achter en draai de stable versie. Van te voren even goede backup maken. Ik kan met een scriptje eventueel een oudere versie weer terugzetten mocht het toch niet lekker werken. Draai HA in docker op een NAS. Tot nu toe gaat dat eigenlijk altijd wel goed op deze manier.

Ik draai de integratie van @gielz en @gast777 inzake aansturing van de Zendure sets.. Voordat ik die bijwerk maak ik van de config dir even een backup zodat deze ook weer terug te zetten is. Ook dat gaat eigenlijk wel goed. Paar gedaan nu. Firmware updates van Zendure doe ik altijd wel netjes. Ook daar geen issues die de boel in de war schoppen. Goede ervaringen dus in mijn setting.

[GoSolarFlow]

Devke schreef op zaterdag 21 februari 2026 @ 12:14:
[...]

Ik loop met HA altijd een paar slagen achter en draai de stable versie. Van te voren even goede backup maken. Ik kan met een scriptje eventueel een oudere versie weer terugzetten mocht het toch niet lekker werken. Draai HA in docker op een NAS. Tot nu toe gaat dat eigenlijk altijd wel goed op deze manier.

Ik draai de integratie van @gielz en @gast777 inzake aansturing van de Zendure sets.. Voordat ik die bijwerk maak ik van de config dir even een backup zodat deze ook weer terug te zetten is. Ook dat gaat eigenlijk wel goed. Paar gedaan nu. Firmware updates van Zendure doe ik altijd wel netjes. Ook daar geen issues die de boel in de war schoppen. Goede ervaringen dus in mijn setting.

Oké dat is fijn om te horen maar wat als je een firmware update te pakken hebt die wel roet in het eten gooit?
Volgens mij heeft Zendure geen rollback.
Of entiteiten die van naam veranderen, moet je dan alles handmatig weer nalopen of kun je dit met een script aanpassen zoals je aangaf?

[Devke]

GoSolarFlow schreef op zaterdag 21 februari 2026 @ 12:33:
[...]

Oké dat is fijn om te horen maar wat als je een firmware update te pakken hebt die wel roet in het eten gooit?
Volgens mij heeft Zendure geen rollback.
Of entiteiten die van naam veranderen, moet je dan alles handmatig weer nalopen of kun je dit met een script aanpassen zoals je aangaf?

Als je bedoeld aansturing middels de Zendure Integratie (Fireson) die gebruik ik niet. Ook geen ervaring mee. Ik gebruik de eerder aangegeven integratie. Sensornaam wijzigingen zie ik daar ook niet.

HA zelf zal de sensornamen natuurlijk ook niet aanpassen na een upgrade van HA zelf. Het scriptje dat ik gebruik is voor upgraden van HA. Rollback kan ook in dat scriptje door een versienummer van HA daarin te veranderen.

[gielz]

GoSolarFlow schreef op zaterdag 21 februari 2026 @ 12:33:
[...]
Of entiteiten die van naam veranderen, moet je dan alles handmatig weer nalopen of kun je dit met een script aanpassen zoals je aangaf?

Ik weet niet exact hoe de Zendure HA hiermee om gaat dat zou je even op Github moeten navragen. De Gielz variant geeft dit bij een update altijd groot aan. Dit is tot nu toe sinds Mei 2025 1x voorgekomen; https://github.com/Gielz1...DK/releases/tag/v20260214 en valt dan onder ⚠️Brekende wijziging ⚠️

[edjes]

Hebben jullie wel eens nagedacht hoe je kan berekenen hoeveel je nu daadwerkelijk bespaart?
Iemand al eens iets gefabriceerd?
Iets van
- voor x ingekocht, ingezet terwijl de stroom y kostte
- met de zonnepanelen p opgeslagen, ingezet terwijl de stroom y kostte
Het vrees dat het complexer is dan dit én het valt wsl beetje tegen, maar toch leuk om mee te nemen in alle getallenbrei?

[GoSolarFlow]

gielz schreef op zaterdag 21 februari 2026 @ 13:35:
[...]


Ik weet niet exact hoe de Zendure HA hiermee om gaat dat zou je even op Github moeten navragen. De Gielz variant geeft dit bij een update altijd groot aan. Dit is tot nu toe sinds Mei 2025 1x voorgekomen; https://github.com/Gielz1...DK/releases/tag/v20260214 en valt dan onder ⚠️Brekende wijziging ⚠️

Ik neem het zekere voor het onzekere en blijf van de updates af zolang het stabiel draait en ga pas wat ondernemen mocht ik iets vreemds tegenkomen.
Ik heb het lopen middels fireson btw.

[ Voor 3% gewijzigd door GoSolarFlow op 21-02-2026 14:13 ]

[GoSolarFlow]

edjes schreef op zaterdag 21 februari 2026 @ 14:04:
Hebben jullie wel eens nagedacht hoe je kan berekenen hoeveel je nu daadwerkelijk bespaart?
Iemand al eens iets gefabriceerd?
Iets van
- voor x ingekocht, ingezet terwijl de stroom y kostte
- met de zonnepanelen p opgeslagen, ingezet terwijl de stroom y kostte
Het vrees dat het complexer is dan dit én het valt wsl beetje tegen, maar toch leuk om mee te nemen in alle getallenbrei?

Hoeft niet dat kan chatgpt al.

[Devke]

edjes schreef op zaterdag 21 februari 2026 @ 14:04:
Hebben jullie wel eens nagedacht hoe je kan berekenen hoeveel je nu daadwerkelijk bespaart?
Iemand al eens iets gefabriceerd?
Iets van
- voor x ingekocht, ingezet terwijl de stroom y kostte
- met de zonnepanelen p opgeslagen, ingezet terwijl de stroom y kostte
Het vrees dat het complexer is dan dit én het valt wsl beetje tegen, maar toch leuk om mee te nemen in alle getallenbrei?

Ik heb wat tellertjes lopen. Nustmeters icm een prijs sensor. Dat is puur tegen welke kosten is er geladen en welke opbrengsten stonden daar tegenover. Dit is zonder zonnepanelen. Deels zal de batterij ingaan. Deels het net op. Ben NOM aan het testen op eerder genoemde integraties. Door de lage spread kost dat geld. Geen schokkende bedragen. Met dayahead zijn wel plusjes te halen.

[DrNickB]

edjes schreef op zaterdag 21 februari 2026 @ 14:04:
Hebben jullie wel eens nagedacht hoe je kan berekenen hoeveel je nu daadwerkelijk bespaart?
Iemand al eens iets gefabriceerd?
Iets van
- voor x ingekocht, ingezet terwijl de stroom y kostte
- met de zonnepanelen p opgeslagen, ingezet terwijl de stroom y kostte
Het vrees dat het complexer is dan dit én het valt wsl beetje tegen, maar toch leuk om mee te nemen in alle getallenbrei?

Spreadsheet? voor mijn situatie niet zo moeilijk hehe. Vast tarief en maar 3 paneeltjes direct op mijn SF800Pro. Dus makkelijk rekenen.

Waardes per dag uit HA gehaald, per maand in een tab, opsomming in dit tabblad.

[edjes]

GoSolarFlow schreef op zaterdag 21 februari 2026 @ 14:10:
[...]

Hoeft niet dat kan chatgpt al.

Leg uit ajb?

@spreadsheet: het is toch veel leuker als dat ook in HA kan? Daar is alle data al. Hoe haal je de dagdata op in excel??

[ Voor 6% gewijzigd door edjes op 21-02-2026 16:10 ]

[DrNickB]

@spreadsheet: het is toch veel leuker als dat ook in HA kan? Daar is alle data al. Hoe haal je de dagdata op in excel??

Ga op dag 2 naar HA -> energy Dasboard, schrijf alle gegevens op van Dag1 in Excel

[GoSolarFlow]

edjes schreef op zaterdag 21 februari 2026 @ 16:09:
[...]

Leg uit aub

Vul daar alle relevante informatie in en het wordt uitgerekend voor je.

[ Voor 4% gewijzigd door GoSolarFlow op 21-02-2026 18:16 ]

[Taro]

FireSon/Zendure 1.2.6 pre1 uit, maar let goed op de opmerkingen voordat je gaat upgraden: https://github.com/Zendur...A/releases/tag/1.2.6-pre1.

Ik wacht nog heel even

[ Voor 4% gewijzigd door Taro op 21-02-2026 18:40 ]

[Taro]

edjes schreef op zaterdag 21 februari 2026 @ 14:04:
Hebben jullie wel eens nagedacht hoe je kan berekenen hoeveel je nu daadwerkelijk bespaart?
Iemand al eens iets gefabriceerd?
Iets van
- voor x ingekocht, ingezet terwijl de stroom y kostte
- met de zonnepanelen p opgeslagen, ingezet terwijl de stroom y kostte
Het vrees dat het complexer is dan dit én het valt wsl beetje tegen, maar toch leuk om mee te nemen in alle getallenbrei?

Gebruik hier een HomeWizard 3-fase kWh-meter met daar achter de vaste thuisaccu opstelling. Die berekent dit automatisch icm dynamische tarieven. Overzicht van vorig jaar, zonder moeilijke scripts etc.:

[gielz]

Taro schreef op zaterdag 21 februari 2026 @ 18:46:
[...]

Gebruik hier een HomeWizard 3-fase kWh-meter met daar achter de vaste thuisaccu opstelling. Die berekent dit automatisch icm dynamische tarieven. Overzicht van vorig jaar, zonder moeilijke scripts etc.:
[Afbeelding]

Heb je wat meer info hoe dit loopt? Bereken je het bedrag met een template helper (sensor)?

[Taro]

gielz schreef op zaterdag 21 februari 2026 @ 19:17:
[...]


Heb je wat meer info hoe dit loopt? Bereken je het bedrag met een template helper (sensor)?

Nee, hoort ook niet in dit topic, maar de vraag waarop ik reageerde wel. De berekening wordt gewoon native door de HomeWizard App gedaan.

[Taro]

Ik heb trouwens wel een aantal soortgelijke zaken in HA zitten, zoals bijv. de kosten van het laden van de auto's. Daarvoor gebruik ik de Dynamic Energy Cost integratie. Daar kan je heel simpel stroomverbruik mee omzetten naar een bedrag dmv een sensor met dynamische prijzen.

[PeaceNlove]

Taro schreef op zaterdag 21 februari 2026 @ 19:18:
[...]

Nee, hoort ook niet in dit topic, maar de vraag waarop ik reageerde wel. De berekening wordt gewoon native door de HomeWizard App gedaan.

offtopic:
Zat nog te twijfelen of ik niet ook nog een HW socket er tussen zou zetten, maar dit trekt me wel over de streep.

[edjes]

[b]Taro in "Zendure producten in Home Assistant integreren deel 2"

Dynamic Energy Cost integratie.

Daar ga ik eens naar kijken, dank

[gielz]

April 2026 TEST (definitieve release laatste week Maart)

Test configuratie. Bij issues graag via Github (beste weg) of DM.
https://github.com/Gielz1...elz1986-April-2026-Update

Melding van release krijgen

1) Zet een Star bij de Github pagina https://github.com/Gielz1986/Zendure-HA-zenSDK (dan volg je hem wat altijd handig is)
2) Klik op Watch en kies waar je exact een melding van wilt krijgen. Bij Custom kun je specifiek alleen releases aanvinken.
3) Bij je profiel onder Notifications kun je aangeven of het via github zelf gaat of naar je mailbox

Intro

Deze release draait vooral om verfijning. De automatisering is overgestapt van braaf wachten in de rij naar parallel werken. Daardoor reageert de aansturing sneller en kun je instellingen aanpassen terwijl alles gewoon door blijft draaien. De batterij is dus officieel van “even wachten tot ik klaar ben” naar “komt goed, ik regel het tegelijk wel”.

Daarnaast hebben we de batterij 1 seconde extra tijd gegeven om na te denken. Klinkt klein, maar dit voorkomt dat hij zenuwachtig gaat pendelen op de P1-meter. Minder golfbewegingen, rustiger gedrag en stiekem zelfs een iets betere NOM-score. Soms zit vooruitgang dus gewoon in een beetje geduld.

Ook het dashboard heeft een flinke opfrisbeurt gekregen. Het oude dashboard was eigenlijk vooral een enthousiaste testomgeving. Tijd voor iets beters: een nieuw, overzichtelijk dashboard met drie tabbladen waarin je alles vindt wat je over de batterij wilt weten. Minder scrollen, sneller inzicht, en alles blijft volledig aanpasbaar voor wie graag zelf knutselt of eigen dashboards bouwt.

Verder is er een nieuwe dynamische modus toegevoegd die automatisch schakelt tussen handelen en Nul-op-de-Meter.

Kortom: geen revolutie, maar wel een update die de batterij en het dashboard duidelijk soepeler, slimmer en prettiger in gebruik maakt. Precies wat nu noodzakelijk is aangezien het opwekseizoen is begonnen. 🌞🌞🌞

Plug-N-Play Dashboard 2.0 – Alles in één

Overzichtelijk, compleet en verdeeld over 3 tabbladen, zodat je alles over je thuisbatterij in één oogopslag hebt. Gebruik ‘m zoals hij is, of haal er handige onderdelen uit voor je eigen dashboard. Zoals gebruikelijk ook weer 100% zelf aan te passen. In stap 1 van de installatie zit nu uitleg om deze in gebruik te nemen.

⚠️ Grote aanpassing ⚠️

Automatisering van queued naar parallel
De automatisering draait nu in parallel modus. Hierdoor is het mogelijk om tijdens een lopende modus ook meteen instellingen aan te passen of andere wijzigingen te doen wat de sturing snelheid ten goede komt.
https://www.home-assistant.io/docs/automation/modes/

NOM interval
Uit veel NOM uren data is gebleken dat de batterij regelmatig iets meer dan 4 seconden nodig heeft waardoor je een golfbeweging kreeg op de P1 die minuten aanhield. Hierdoor is de interval nu op 5 seconden gezet. Met deze nieuwe interval kwam er gek genoeg een betere NOM uit. Dit wil niet zeggen dat wanneer je de waterkoker aanzet de batterij pas na 5 seconden reageert. Het is een 5 seconden interval, de batterij kan hierdoor ook binnen 1 seconde reageren.

Mocht dit niet wenselijk zijn dan kan dit aangepast worden in de automatisering door /5 naar /4 te zetten:

code:

alias: Zendure zenSDK (Gielz)
description: Configuratie Versie April 2026 (20260216)
triggers:
  - seconds: /5
    id: aansturing_trigger
    trigger: time_pattern

Nieuwe modus optie

Dynamisch Handelen + NOM modus toegevoegd
Deze modus volgt het patroon goedkoopste en duurste uren die ingesteld zijn. Daarbuiten is het altijd Nul op de Meter.

Extra sensoren toegevoegd

⚠️Zendure-HA-Zensdk Github Releasecheck ⚠️
Er wordt nu verbinding gemaakt met de API van GitHub waardoor deze sensor aangeeft of je up-to-date bent.


Wil je de releasenotes standaard in HA dan kan dit via;

code:

type: markdown
content: "  {{ state_attr('sensor.github_zendure_ha_zensdk_gielz1986', 'body') | replace('\\r\\n','\\n') | replace('<br>','\\n') }}"

Dynamisch Ontladen Loopt en Dynamisch Laden Loopt
Er wordt nu exact bijgehouden wanneer er een dynamisch ontlaad- of laadcyclus loopt.

Omvormer Max. Oplaadvermogen en Omvormer Max. Ontlaadvermogen
Vanaf nu kun je zien wat er daadwerkelijk op de omvormer (API) is ingesteld. Dit wordt ook gebruikt om te controleren of deze afwijkend is ten opzichte van je eigen ingestelde maximum oplaad- en ontlaadvermogen.

Help Tonen Op Dashboard
Ten behoeve van het plug-n-play dashboard waardoor het nu mogelijk is om bij de meeste onderdelen direct een helptekst te tonen.


*let niet op de 2 dagen hoge schakelingen door zeer agressief testen

Dynamisch Tonen Op Dashboard
Ten behoeve van het plug-n-play dashboard waardoor je het dynamische gedeelte kunt uitzetten als je hier geen gebruik van wilt maken.

Wijzigingen in bestaande onderdelen

sensor.zendure_2400_ac_modus en sensor.zendure_2400_ac_vermogen_aansturing
Aangepast om de aansturing te kunnen gebruiken met direct aangesloten zonnepanelen op de daarvoor bestemde MC4-connectoren.

sensor.dynamisch_nordpool
Heeft nu 4 extra attributen gekregen: min_today, max_today, min_tomorrow en max_tomorrow.

sensor.dynamisch_spread_indicatie en sensor.dynamisch_spread_indicatie_nom (inclusief morgen)
Beide hebben nu het attribuut verschil_waarde erbij gekregen. Hierdoor is te zien wat de spread uitgedrukt in geld is.

input_number.zendure_2400_ac_max_oplaadvermogen en input_number.zendure_2400_ac_max_ontlaadvermogen
Wanneer via de Zendure app of buiten Home Assistant het maximaal ontlaad- of oplaadvermogen werd ingesteld ontstond er een synchronisatiefout. Vanaf nu wordt dit constant gecontroleerd en zo nodig gecorrigeerd. De ingestelde waarde in Home Assistant is altijd leidend.

Bugfixes

SOC Kalibratie
Zodra de geforceerde SOC-kalibratie gestart werd door de batterij zelf buiten de aansturing om, wilde de batterij in standby gaan wat uiteraard niet kan tot de kalibratie is afgerond. Dit is nu opgelost.

Dynamisch laad- en ontlaadgedrag
Tijdens het dynamisch laden en ontladen op hoog vermogen (handelen) was het mogelijk om het vermogen omlaag te zetten via de instellingen maar niet meer omhoog. Dit is vanaf nu wel mogelijk.

Snel laad- en ontlaadgedrag
Tijdens het snel laden en ontladen was het mogelijk om het vermogen omlaag te zetten via de instellingen maar niet meer omhoog. Dit is vanaf nu wel mogelijk.

Spread_Indicatie_NOM en Spread_Indicatie_NOM_Morgen
Beide hadden moeite met handmatig ingevulde periodes. Dit is nu opgelost.

[ Voor 5% gewijzigd door gielz op 22-02-2026 21:08 ]

[sjnelle]

Taro schreef op donderdag 13 november 2025 @ 19:35:
[...]

Gebruik hier de volgende YAML:

YAML:

- platform: nordpool
    VAT: False
    currency: "EUR"
    price_in_cents: false
    low_price_cutoff: 0.9
    region: "NL"
    precision: 3
    price_type: kWh
    additional_costs: >
      {% set VAT = 0.21 %}
      {% set tax_kWh = 0.10154 %}
      {% set opslag = 0.0165 %}
      {{ (current_price * VAT ) + (tax_kWh + opslag) * (1 + VAT)|float }}

En in de Cheapest Hours helpers Jinja:

Django/Jinja:

use_hourly_avg=true

De grafieken tonen dan nog steeds kwartieren, maar je automatisering draait op uren icm Zonneplan tarieven.

@Taro wat bedoel je precies met dit stukje?
use_hourly_avg=true
waar moet dt gebruikt worden?

[Taro]

sjnelle schreef op zondag 22 februari 2026 @ 20:59:
[...]


@Taro wat bedoel je precies met dit stukje?
use_hourly_avg=true
waar moet dt gebruikt worden?

use_hourly_avg=true kan je in de Cheapest Hours Jinja code gebruiken als je dynamische provider uurprijzen ondersteunt, maar nog geen kwartierprijzen. Die variabele combineert dan de 4 kwartieren van dat uur tot een gemiddeld uurtarief. En op basis van de andere variabelen krijg je dan True of False terug voor dat uur, dat kan je weer in je Automatisering gebruiken.

[gast777]

gielz schreef op zondag 22 februari 2026 @ 20:41:

April 2026 TEST (definitieve release laatste week Maart)

Voor wie de Proxy gebruikt voor de Gielz met 2 Zendure devices: De Gielz April release heeft minimaal de huidige versie 20260220 van de Proxy nodig.

Reden is dat Gielz nu de Zendure attributen outputHomePower en gridInputPower gebruikt. Deze worden nu door de Proxy doorgegeven.

[DrNickB]

@gielz wederom bedankt voor alle moeite die je erin steekt om zo de community te helpen

[Devke]

DrNickB schreef op zondag 22 februari 2026 @ 21:32:
@gielz wederom bedankt voor alle moeite die je erin steekt om zo de community te helpen

Dit geldt natuurlijk ook voor @gast777 die met name voor de aansturing van 2 omvormers zorgt m.b.v. een proxy. Aan de basis ligt de integratie van @gielz.

[koboy]

Zo, vanmiddag eindelijk kunnen knutselen. April-test van Gielz staat geïnstalleerd, en als de accu leeg is vanavond laat gaat de Gielz aan en HEMS uit.

@gielz : bedankt voor al je werk, een pak goede koffie is als het goed is al binnen.

[Bakko]

Bedankt @Gielz weer voor de mooie update, ik heb hem net draaien en ga er eens even mee spelen.
Ook fijn om te lezen dat er nog tweaks mogelijk waren m.b.t. de frequentie waarop de automation draait. Ik dacht namelijk al een tijd gek te worden omdat ik erg veel last had van het pendelen van de accu, het achterna jagen van de p1 meter. Eerst dacht ik dat mijn P1 meter te langzaam was, dat verbeterd (ook hier gepost) maar dat maakte het alleen maar erger. Toen dacht ik dat het mijn 3D-printer lag (PID heaters zorgen voor schommelend verbruik), dus een smoothing toegepast op mijn P1 meter met NodeRED, hielp eigenlijk ook weinig tot niks. Toen zag ik zelf ook wat jij nu ook meld, dat de batterij zelf eigenlijk best een paar seconde later pas doorgeeft wat ie aan het doen is. Dus toen bedacht om dan maar mijn P1 meter 2 seconde te bufferen en dus 2 sec. oude waarde te gebruiken voor de aansturing van de batterij. Dat leek eigenlijk wel nog enigszins te werken ook. Maar nu ga ik zeker eerst jouw nieuwe code proberen met de 5 sec. frequentie.

[gielz]

Bakko schreef op maandag 23 februari 2026 @ 17:46:
Bedankt @Gielz weer voor de mooie update, ik heb hem net draaien en ga er eens even mee spelen.
Ook fijn om te lezen dat er nog tweaks mogelijk waren m.b.t. de frequentie waarop de automation draait. Ik dacht namelijk al een tijd gek te worden omdat ik erg veel last had van het pendelen van de accu, het achterna jagen van de p1 meter. Eerst dacht ik dat mijn P1 meter te langzaam was, dat verbeterd (ook hier gepost) maar dat maakte het alleen maar erger. Toen dacht ik dat het mijn 3D-printer lag (PID heaters zorgen voor schommelend verbruik), dus een smoothing toegepast op mijn P1 meter met NodeRED, hielp eigenlijk ook weinig tot niks. Toen zag ik zelf ook wat jij nu ook meld, dat de batterij zelf eigenlijk best een paar seconde later pas doorgeeft wat ie aan het doen is. Dus toen bedacht om dan maar mijn P1 meter 2 seconde te bufferen en dus 2 sec. oude waarde te gebruiken voor de aansturing van de batterij. Dat leek eigenlijk wel nog enigszins te werken ook. Maar nu ga ik zeker eerst jouw nieuwe code proberen met de 5 sec. frequentie.

Het idee is "staat hier op een kladje" om wellicht nog P1 profielen te kunnen selecteren in de toekomst. Maar wat hier uit tests is gebleken dat die 5 seconden sturing precies de sweetspot is bij een p1 (1sec)

[Taro]

gielz schreef op maandag 23 februari 2026 @ 18:52:
[...]


Het idee is "staat hier op een kladje" om wellicht nog P1 profielen te kunnen selecteren in de toekomst. Maar wat hier uit tests is gebleken dat die 5 seconden sturing precies de sweetspot is bij een p1 (1sec)

Wat ik hierbij wel interessant vind: Stel dat de P1-meter op 00:00:05 een bericht verstuurt en de accu op 00:00:06 bijstuurt, dan werkt die interval anders dan als de P1-meter op 00:00:07 een bericht verstuurd nadat de accu net heeft bijgestuurd en weer tot 00:00:11 wacht met de volgende correctie.

Kan het dan zijn dat je afhankelijk van het huishouden andere resultaten krijgt met een hogere interval? Of stuur je direct bij na het ontvangen van een P1-waarde en pakt de accu die dan direct op omdat er een soort time-out actief is? Want dan speelt dit natuurlijk niet.

[ Voor 10% gewijzigd door Taro op 23-02-2026 21:01 ]

[DrNickB]

Van het weekend eindelijk wat tijd gehad om mijn configuratie om te gooien.
Vanaf de oude 202508** configuratie + automatisering, overgestapt naar de package versie (April release).
Volledig gelukt met slechts aanpassing van de entiteitnamen (find+replace all).

Gister eerste deel NOM/Slim ontladen gedraaid en dat ging goed.
Vandaag was er (boven verwachting) wat zon, dus kon ik NOM/Slim Ontladen draaien, terwijl de zon ook de batterij oplaadde.
Heb alleen PV Input vanaf de direct aangesloten panelen op mijn SF800Pro, dus geen andere omvormers o.i.d. maar het beeld ziet er netjes uit!

Paar screens:

[gielz]

Taro schreef op maandag 23 februari 2026 @ 21:00:
[...]

Wat ik hierbij wel interessant vind: Stel dat de P1-meter op 00:00:05 een bericht verstuurt en de accu op 00:00:06 bijstuurt, dan werkt die interval anders dan als de P1-meter op 00:00:07 een bericht verstuurd nadat de accu net heeft bijgestuurd en weer tot 00:00:11 wacht met de volgende correctie.

Kan het dan zijn dat je afhankelijk van het huishouden andere resultaten krijgt met een hogere interval? Of stuur je direct bij na het ontvangen van een P1-waarde en pakt de accu die dan direct op omdat er een soort time-out actief is? Want dan speelt dit natuurlijk niet.

Zoals het nu werkt is dat de gekoppelde p1 elke seconden data geeft zodat je die direct beschikbaar hebt. Vervolgens pakt de automatisering dit elke 5 seconden op en is de waarde altijd van "nu". De batterij heeft daarna bij hoge verschillen soms wel 4,5 seconden nodig om dit te verwerken.

Wat je vaak ziet bij een interval van 4 of zelf 3 dat je een golf krijgt op de p1 die minuten lang aanhoud voordat hij hier uit komt.

Resultaat met 5s interval / 1s p1;


Het idee is om eens te gaan testen met een afwijkend P1 profiel zodra er voldoende zon is. Hierbij kijkt hij dan naar de laatste 4-5 waarde en als deze meer dan xxx watt opeens afwijkt skipt hij deze totdat hij hem bij de volgende interval weer ziet. Dit kan heel slecht uitpakken maar wellicht ook heel goed.

De NOM werkt hier nu al boven verwachting goed met 0,009 kwh in een nacht van 00:00 t/m 08:00.

[gielz]

DrNickB schreef op maandag 23 februari 2026 @ 21:21:
Van het weekend eindelijk wat tijd gehad om mijn configuratie om te gooien.
Vanaf de oude 202508** configuratie + automatisering, overgestapt naar de package versie (April release).
Volledig gelukt met slechts aanpassing van de entiteitnamen (find+replace all).

Gister eerste deel NOM/Slim ontladen gedraaid en dat ging goed.
Vandaag was er (boven verwachting) wat zon, dus kon ik NOM/Slim Ontladen draaien, terwijl de zon ook de batterij oplaadde.
Heb alleen PV Input vanaf de direct aangesloten panelen op mijn SF800Pro, dus geen andere omvormers o.i.d. maar het beeld ziet er netjes uit!

Paar screens:

[Afbeelding]

[Afbeelding]

[Afbeelding]

De RTE berekening is nog foutief met zonnepanelen maar de NOM zou helemaal goed moeten gaan @denneappel is zijn hersens aan het kraken.

[Pakhaas]

Hoe doet de batterij met de @gielz integratie bij een quooker? Wij gebruiken de quooker ook voor warm water en dan springt hij regelmatig even naar 2200w voor 5sec. Meen gelezen te hebben dat de batterij daar steeds te laat op reageert. We hebben een dsmr 5.0 meter.

[DrNickB]

gielz schreef op maandag 23 februari 2026 @ 21:29:
[...]De RTE berekening is nog foutief met zonnepanelen maar de NOM zou helemaal goed moeten gaan @denneappel is zijn hersens aan het kraken.

Ja ik had het door, echter ze kloppen wel, het zijn de grafieken m.b.t. de batterij en niet voor de zon
waarbij de DC Input in dit geval wel de Efficiëntie was van Zon naar Batterij.
Maar met zon wordt het een aardige berekening

Dus @denneappel mocht je nog wat test voer hebben, geef maar gil.

[gielz]

Pakhaas schreef op maandag 23 februari 2026 @ 22:01:
Hoe doet de batterij met de @gielz integratie bij een quooker? Wij gebruiken de quooker ook voor warm water en dan springt hij regelmatig even naar 2200w voor 5sec. Meen gelezen te hebben dat de batterij daar steeds te laat op reageert. We hebben een dsmr 5.0 meter.

Elke thuisbatterij heeft hier issues mee. Eigenlijk is het gewoon een kwestie van proberen en ben vooral benieuwd naar je P1 data in de nacht bij NOM en de Quooker.

Er zijn Tweakers die de Quooker snachts uitzetten waardoor hij in de ochtend gewoon langer vermogen pakt wat opgevangen kan worden door de batterij.

Wat ook kan is als de Quooker aan een slimme stekker hangt die in HA uitgelezen word per seconden deze aftrekken van je P1. Dan valt de Quooker volledig buiten je aansturing maar heb je wel meer import.

[hapklaar]

gielz schreef op dinsdag 17 februari 2026 @ 16:56:
[...]


- Interessant, die 47 watt zie je die op een energysocket of daadwerkelijk bij de batterij?

- Staat de offgrid aan? Hangt er iets aan de offgrid?

- In welke modus staat de batterij met 47 watt te draaien?

- Heb je wat schermafbeeldingen van de log en wat je nu exact ziet?

Leuke uitdaging iig

Gebeurt nu toch weer, nu alleen 43W ipv 47W. Ik zie het nu gebeuren bij 'alleen slim opladen' als de zon even schijnt en de automation de meter op 0 probeert te houden en het overschot naar de Zendure stuurt. Als de zon dan even weg is, blijft er 43W naar de Zendure gaan. Na de 5 mins timeout gaat dit naar 0.

Om op je vragen terug te komen:
1. Ik zie deze 43W op een inline Shelly 4PM
2. Offgrid staat uit.
3. Draait in de 'Alleen slim opladen' modus
4. Deze grafiek geeft het goed weer:

[gielz]

hapklaar schreef op dinsdag 24 februari 2026 @ 11:49:
[...]


Gebeurt nu toch weer, nu alleen 43W ipv 47W. Ik zie het nu gebeuren bij 'alleen slim opladen' als de zon even schijnt en de automation de meter op 0 probeert te houden en het overschot naar de Zendure stuurt. Als de zon dan even weg is, blijft er 43W naar de Zendure gaan. Na de 5 mins timeout gaat dit naar 0.

Om op je vragen terug te komen:
1. Ik zie deze 43W op een inline Shelly 4PM
2. Offgrid staat uit.
3. Draait in de 'Alleen slim opladen' modus
4. Deze grafiek geeft het goed weer:
[Afbeelding]

Fijn dat het dus precies werkt zoals het nu in de software zit. Waarom het dan bij jou een stuk hoger is wat betreft vermogen is eigenlijk een raadsel. Hier is het 19 watt met een KWH MID meter en een 2400 AC.

[R.K]

gielz schreef op zondag 22 februari 2026 @ 20:41:

April 2026 TEST (definitieve release laatste week Maart)

Test configuratie. Bij issues graag via Github (beste weg) of DM.
https://github.com/Gielz1...elz1986-April-2026-Update

Melding van release krijgen

1) Zet een Star bij de Github pagina https://github.com/Gielz1986/Zendure-HA-zenSDK (dan volg je hem wat altijd handig is)
2) Klik op Watch en kies waar je exact een melding van wilt krijgen. Bij Custom kun je specifiek alleen releases aanvinken.
3) Bij je profiel onder Notifications kun je aangeven of het via github zelf gaat of naar je mailbox

[Afbeelding]

Intro

Deze release draait vooral om verfijning. De automatisering is overgestapt van braaf wachten in de rij naar parallel werken. Daardoor reageert de aansturing sneller en kun je instellingen aanpassen terwijl alles gewoon door blijft draaien. De batterij is dus officieel van “even wachten tot ik klaar ben” naar “komt goed, ik regel het tegelijk wel”.

Daarnaast hebben we de batterij 1 seconde extra tijd gegeven om na te denken. Klinkt klein, maar dit voorkomt dat hij zenuwachtig gaat pendelen op de P1-meter. Minder golfbewegingen, rustiger gedrag en stiekem zelfs een iets betere NOM-score. Soms zit vooruitgang dus gewoon in een beetje geduld.

Ook het dashboard heeft een flinke opfrisbeurt gekregen. Het oude dashboard was eigenlijk vooral een enthousiaste testomgeving. Tijd voor iets beters: een nieuw, overzichtelijk dashboard met drie tabbladen waarin je alles vindt wat je over de batterij wilt weten. Minder scrollen, sneller inzicht, en alles blijft volledig aanpasbaar voor wie graag zelf knutselt of eigen dashboards bouwt.

Verder is er een nieuwe dynamische modus toegevoegd die automatisch schakelt tussen handelen en Nul-op-de-Meter.

Kortom: geen revolutie, maar wel een update die de batterij en het dashboard duidelijk soepeler, slimmer en prettiger in gebruik maakt. Precies wat nu noodzakelijk is aangezien het opwekseizoen is begonnen. 🌞🌞🌞

Plug-N-Play Dashboard 2.0 – Alles in één

Overzichtelijk, compleet en verdeeld over 3 tabbladen, zodat je alles over je thuisbatterij in één oogopslag hebt. Gebruik ‘m zoals hij is, of haal er handige onderdelen uit voor je eigen dashboard. Zoals gebruikelijk ook weer 100% zelf aan te passen. In stap 1 van de installatie zit nu uitleg om deze in gebruik te nemen.

[Afbeelding]

[Afbeelding]

[Afbeelding]

⚠️ Grote aanpassing ⚠️

Automatisering van queued naar parallel
De automatisering draait nu in parallel modus. Hierdoor is het mogelijk om tijdens een lopende modus ook meteen instellingen aan te passen of andere wijzigingen te doen wat de sturing snelheid ten goede komt.
https://www.home-assistant.io/docs/automation/modes/

NOM interval
Uit veel NOM uren data is gebleken dat de batterij regelmatig iets meer dan 4 seconden nodig heeft waardoor je een golfbeweging kreeg op de P1 die minuten aanhield. Hierdoor is de interval nu op 5 seconden gezet. Met deze nieuwe interval kwam er gek genoeg een betere NOM uit. Dit wil niet zeggen dat wanneer je de waterkoker aanzet de batterij pas na 5 seconden reageert. Het is een 5 seconden interval, de batterij kan hierdoor ook binnen 1 seconde reageren.

Mocht dit niet wenselijk zijn dan kan dit aangepast worden in de automatisering door /5 naar /4 te zetten:

code:

alias: Zendure zenSDK (Gielz)
description: Configuratie Versie April 2026 (20260216)
triggers:
  - seconds: /5
    id: aansturing_trigger
    trigger: time_pattern

Nieuwe modus optie

Dynamisch Handelen + NOM modus toegevoegd
Deze modus volgt het patroon goedkoopste en duurste uren die ingesteld zijn. Daarbuiten is het altijd Nul op de Meter.

Extra sensoren toegevoegd

⚠️Zendure-HA-Zensdk Github Releasecheck ⚠️
Er wordt nu verbinding gemaakt met de API van GitHub waardoor deze sensor aangeeft of je up-to-date bent.
[Afbeelding]

Wil je de releasenotes standaard in HA dan kan dit via;

code:

type: markdown
content: "  {{ state_attr('sensor.github_zendure_ha_zensdk_gielz1986', 'body') | replace('\\r\\n','\\n') | replace('<br>','\\n') }}"

Dynamisch Ontladen Loopt en Dynamisch Laden Loopt
Er wordt nu exact bijgehouden wanneer er een dynamisch ontlaad- of laadcyclus loopt.

Omvormer Max. Oplaadvermogen en Omvormer Max. Ontlaadvermogen
Vanaf nu kun je zien wat er daadwerkelijk op de omvormer (API) is ingesteld. Dit wordt ook gebruikt om te controleren of deze afwijkend is ten opzichte van je eigen ingestelde maximum oplaad- en ontlaadvermogen.

Help Tonen Op Dashboard
Ten behoeve van het plug-n-play dashboard waardoor het nu mogelijk is om bij de meeste onderdelen direct een helptekst te tonen.

[Afbeelding]
*let niet op de 2 dagen hoge schakelingen door zeer agressief testen

Dynamisch Tonen Op Dashboard
Ten behoeve van het plug-n-play dashboard waardoor je het dynamische gedeelte kunt uitzetten als je hier geen gebruik van wilt maken.

Wijzigingen in bestaande onderdelen

sensor.zendure_2400_ac_modus en sensor.zendure_2400_ac_vermogen_aansturing
Aangepast om de aansturing te kunnen gebruiken met direct aangesloten zonnepanelen op de daarvoor bestemde MC4-connectoren.

sensor.dynamisch_nordpool
Heeft nu 4 extra attributen gekregen: min_today, max_today, min_tomorrow en max_tomorrow.

sensor.dynamisch_spread_indicatie en sensor.dynamisch_spread_indicatie_nom (inclusief morgen)
Beide hebben nu het attribuut verschil_waarde erbij gekregen. Hierdoor is te zien wat de spread uitgedrukt in geld is.

input_number.zendure_2400_ac_max_oplaadvermogen en input_number.zendure_2400_ac_max_ontlaadvermogen
Wanneer via de Zendure app of buiten Home Assistant het maximaal ontlaad- of oplaadvermogen werd ingesteld ontstond er een synchronisatiefout. Vanaf nu wordt dit constant gecontroleerd en zo nodig gecorrigeerd. De ingestelde waarde in Home Assistant is altijd leidend.

Bugfixes

SOC Kalibratie
Zodra de geforceerde SOC-kalibratie gestart werd door de batterij zelf buiten de aansturing om, wilde de batterij in standby gaan wat uiteraard niet kan tot de kalibratie is afgerond. Dit is nu opgelost.

Dynamisch laad- en ontlaadgedrag
Tijdens het dynamisch laden en ontladen op hoog vermogen (handelen) was het mogelijk om het vermogen omlaag te zetten via de instellingen maar niet meer omhoog. Dit is vanaf nu wel mogelijk.

Snel laad- en ontlaadgedrag
Tijdens het snel laden en ontladen was het mogelijk om het vermogen omlaag te zetten via de instellingen maar niet meer omhoog. Dit is vanaf nu wel mogelijk.

Spread_Indicatie_NOM en Spread_Indicatie_NOM_Morgen
Beide hadden moeite met handmatig ingevulde periodes. Dit is nu opgelost.

Vandaag naar deze versie geupgrade, wow, wat ziet het er gaaf uit. Knap staaltje werk.Vooral het dashboard ziet er gaaf uit, Dat is een koffie waard mensen.

Ik moet alleen nog even uitvogelen hoe het dynamisch NOM/ handelen werkt. dat is mij niet helemaal duidelijk. Misschien kan iemand mij op weg helpen.

[koboy]

R.K schreef op dinsdag 24 februari 2026 @ 13:56:
[...]


Vandaag naar deze versie geupgrade, wow, wat ziet het er gaaf uit. Knap staaltje werk.Vooral het dashboard ziet er gaaf uit, Dat is een koffie waard mensen.

Ik moet alleen nog even uitvogelen hoe het dynamisch NOM/ handelen werkt. dat is mij niet helemaal duidelijk. Misschien kan iemand mij op weg helpen.

Maakt voor dit jaar nog niet uit. Vol op de handel draaien levert het meest op.
Vannacht keurig geladen, en de eerste twee dure uurtjes zijn ook al weer teruggeleverd.

Dynamisch/NOM doet wat ik begreep op/ontladen op de goedkoopste/duurste uren en daartussen NOM ipv standby. Voor volgend jaar geef je dan het aantal van 2 dure uren op, en dan gaat een 11.5 kWh systeem ongeveer half leeg in die tijd. Heb je de rest nog over voor NOM in de nacht.
Maar ik denk dat qua financiële optimalisatie nog een hoop te halen is met een "slimmere" aansturing. Wil hier best over meedenken, maar denk dat we daar een ander plekje voor moeten vinden.

[wesley2004]

Met de extra accu op komst dacht ik dat het tijd werd Zendure toch in home assistant te zetten. Lijkt me de integratie van @gielz mooi voor! Ik maak gebruik van een everhome ecotracker. Voor ik alles installeer enzo, hoe krijg ik die in home assistant? Zie daar niets voor. Iemand ervaring mee?

[gielz]

wesley2004 schreef op dinsdag 24 februari 2026 @ 17:41:
Met de extra accu op komst dacht ik dat het tijd werd Zendure toch in home assistant te zetten. Lijkt me de integratie van @gielz mooi voor! Ik maak gebruik van een everhome ecotracker. Voor ik alles installeer enzo, hoe krijg ik die in home assistant? Zie daar niets voor. Iemand ervaring mee?

Ik heb deze zelf niet maar is dat niet gewoon deze;
https://github.com/Selbst...ain/Ecotracker%20Code.txt

Zou eerst even kijken of je hier reply op krijgt; http://[IP-Everhome]/v1/json en zou scan interval op 1s zetten.

[denneappel]

Hieronder wat bevindingen van de verschllende stromen bij de 800 pro. Ik wil morgen nog even een grafiekje krijgen van wat er gebeurt als soc 100% + DC PV input + export niet toegestaan. Dat is een situatie die ik deze zomer veel ga zien.


pack.power[]:
Vermogen van de batterij(en)

solarinputpower:
PV vermogen van de mppt.
Dit is DC want bij export van PV bij batterij soc 100% is outputhome een stuk lager.
(morgen hoop ik een grafiekje te krijgen


packin/outputpower:
vermogen tussen AC omvormer en batterij. Gemeten aan de AC kant van de omvormer. Dit zou bij een AC2400 altijd gelijk moeten zijn aan outputhome/gridinput mits het offgrid wcd niet wordt gebruikt denk ik.

Het vreemde is (zie screenshot hieronder) wel dat bijvorbeeld bij een outputhomepower=799W / inputpackpower=105W / solarinputpower=694W er geen conversieverlies van DC > AC zichtbaar is. Die zie je enkel tussen inputpakpower en pack.power[] (207 - 105 = 102W verlies). Het is mogelijk dat dit deels toegeschreven moet worden aan PV input.
Terwijl bij outputhomepower=100W / inputpackpower=0w / solarinputpower=120w er wel conversieverlies tussen solarinputpower en outputhomepower te zien is. Deze situatie komt voor bij standby / soc 100% / PV export toegestaan. Wellicht dat ik dit morgen ook even kan laten zien.



outputhomepower:
AC vermogen export naar huis

gridinputpower:
AC vermogen import van huis

[denneappel]

Zit ik net te schrijven dat packin/outputpower het vermogen tussen AC omvormer en batterij is. Zie ik dit moment voorbij komen vanwege het andere Zendure topic. Het resterend stukje PV input is zichtbaar bij outputpackpower...

[wesley2004]

Oh dit ga ik proberen!
Gewoon in je config zetten lijkt het!
Ik heb ook nog een HomeWizard p1 meter maar zonde als deze dan niets doet.

gielz schreef op dinsdag 24 februari 2026 @ 19:33:
[...]


Ik heb deze zelf niet maar is dat niet gewoon deze;
https://github.com/Selbst...ain/Ecotracker%20Code.txt

Zou eerst even kijken of je hier reply op krijgt; http://[IP-Everhome]/v1/json en zou scan interval op 1s zetten.

[DrNickB]

@denneappel Meet hier ook wat verschillen met stroom opwek -> invoer in de batterijen.
Er zit eigenlijk altijd wat verschil tussen, heb geen hele specifieke grafiek hiervoor, maar reken
zo nu en dan wel wat uit en dat klopt nooit echt. Ene keer is 20w, andere keer is het bijna 50w verschil.

[martinvdm]

R.K schreef op dinsdag 24 februari 2026 @ 13:56:
[...]

Ik moet alleen nog even uitvogelen hoe het dynamisch NOM/ handelen werkt. dat is mij niet helemaal duidelijk. Misschien kan iemand mij op weg helpen.

Betekent gewoonweg maximaal ont- of opladen tijdens goedkope of dure uren. Naast eventueel nom igv “dynamisch handelen + nom”. Op de GitHub vind je bij de diverse standen in de tabel in de rechterkolom uitleg.

[sjnelle]

Ik heb wat uitdagingen.
Ik heb geupgrade naar de april code en krijg onderstaande foutmeldingen in mijn home assistant log.

Daarnaast heb ik wat issues met het verkrijgen van juiste tarieven van Zonneplan. Heeft iemand zijn config online staan waar ik kan spieken?

Tevens als ik de package versie gebruik wordt er niks geladen. In de configuration.yaml werkt het wel

code:

homeassistant:
  packages: !include_dir_named packages

code:

2026-02-25 07:24:30.165 ERROR (MainThread) [homeassistant.helpers.event] Error while processing template: Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=2>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 461, in async_render
    render_result = render_with_context(self.template, compiled, **kwargs)
  File "/usr/src/homeassistant/homeassistant/helpers/template/context.py", line 45, in render_with_context
    return template.render(**kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 1295, in render
    self.environment.handle_exception()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 942, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<template>", line 1, in top-level template code
  File "/usr/local/lib/python3.13/site-packages/jinja2/filters.py", line 438, in do_sort
    return sorted(value, key=key_func, reverse=reverse)
TypeError: 'NoneType' object is not iterable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 579, in async_render_to_info
    render_info._result = self.async_render(  # noqa: SLF001
                          ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
        variables, strict=strict, log_fn=log_fn, **kwargs
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 463, in async_render
    raise TemplateError(err) from err
homeassistant.exceptions.TemplateError: TypeError: 'NoneType' object is not iterable
2026-02-25 07:24:30.170 ERROR (MainThread) [homeassistant.components.template.template_entity] TemplateError('TypeError: 'NoneType' object is not iterable') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=4>' for attribute 'duurste_periode' in entity 'sensor.dynamisch_spread_indicatie_nom'
2026-02-25 07:24:30.172 ERROR (MainThread) [homeassistant.helpers.event] Error while processing template: Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope_morgen') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=2>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 461, in async_render
    render_result = render_with_context(self.template, compiled, **kwargs)
  File "/usr/src/homeassistant/homeassistant/helpers/template/context.py", line 45, in render_with_context
    return template.render(**kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 1295, in render
    self.environment.handle_exception()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 942, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<template>", line 1, in top-level template code
  File "/usr/local/lib/python3.13/site-packages/jinja2/filters.py", line 438, in do_sort
    return sorted(value, key=key_func, reverse=reverse)
TypeError: 'NoneType' object is not iterable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 579, in async_render_to_info
    render_info._result = self.async_render(  # noqa: SLF001
                          ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
        variables, strict=strict, log_fn=log_fn, **kwargs
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 463, in async_render
    raise TemplateError(err) from err
homeassistant.exceptions.TemplateError: TypeError: 'NoneType' object is not iterable
2026-02-25 07:24:30.174 ERROR (MainThread) [homeassistant.components.template.template_entity] TemplateError('TypeError: 'NoneType' object is not iterable') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope_morgen') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=4>' for attribute 'duurste_periode' in entity 'sensor.dynamisch_spread_indicatie_nom_morgen'

[YvonneVP]

Taro schreef op woensdag 9 juli 2025 @ 17:41:
Hierbij de YAML om de Zendure P1-meter in Home Assistant te integreren:

YAML:

- resource: http://192.168.1.X/properties/report   # Zendure P1
    scan_interval: 1
    sensor:
      - name: "Zendure P1 Vermogen Fase A"
        value_template: "{{ value_json['a_aprt_power'] }}"
        unique_id: Zendure_P1_Vermogen_Fase_A
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure P1 Vermogen Fase B"
        value_template: "{{ value_json['b_aprt_power'] }}"
        unique_id: Zendure_P1_Vermogen_Fase_B
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure P1 Vermogen Fase C"
        value_template: "{{ value_json['c_aprt_power'] }}"
        unique_id: Zendure_P1_Vermogen_Fase_C
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure P1 Vermogen Totaal"
        value_template: "{{ value_json['total_power'] }}"
        unique_id: Zendure_P1_Vermogen_Totaal
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

Moet dit in de configuration.yaml opgeslagen worden? Ik heb namelijk ook een Zendure P1 meter, en ook een van Powerbaas, Powerbaas ben ik niet zeker van of die elke seconde uitleest. Aangezien ik een Zendure 2400AC heb lijkt het me misschien handiger om dan ook die P1 meter te integreren in HA zodat ik die in Gielz mooie HA overzicht kan gebruiken.

[YvonneVP]

martinvdm schreef op woensdag 25 februari 2026 @ 07:20:
[...]

Betekent gewoonweg maximaal ont- of opladen tijdens goedkope of dure uren. Naast eventueel nom igv “dynamisch handelen + nom”. Op de GitHub vind je bij de diverse standen in de tabel in de rechterkolom uitleg.

Die uitleg is mij soms ook niet helemaal duidelijk. Vooral voor mensen die wat minder technisch aangelegd zijn is het soms even achter de oren krabben wat iets nu precies inhoud, of betekend, zodat de instellingen ook correct kunnen worden ingevoerd. Waar Gielz een advies geeft neem ik die meestal over, maar sommige begrippen zijn een beetje abacadabra voor me.

[Pakhaas]

YvonneVP schreef op woensdag 25 februari 2026 @ 12:51:
[...]

Moet dit in de configuration.yaml opgeslagen worden? Ik heb namelijk ook een Zendure P1 meter, en ook een van Powerbaas, Powerbaas ben ik niet zeker van of die elke seconde uitleest. Aangezien ik een Zendure 2400AC heb lijkt het me misschien handiger om dan ook die P1 meter te integreren in HA zodat ik die in Gielz mooie HA overzicht kan gebruiken.

Is dat ook nodig als je naast de Zendure P1 meter ook de Homewizard P1 meter hebt?

[gielz]

sjnelle schreef op woensdag 25 februari 2026 @ 09:00:
Ik heb wat uitdagingen.
Ik heb geupgrade naar de april code en krijg onderstaande foutmeldingen in mijn home assistant log.

Daarnaast heb ik wat issues met het verkrijgen van juiste tarieven van Zonneplan. Heeft iemand zijn config online staan waar ik kan spieken?

Tevens als ik de package versie gebruik wordt er niks geladen. In de configuration.yaml werkt het wel

code:

homeassistant:
  packages: !include_dir_named packages

code:

2026-02-25 07:24:30.165 ERROR (MainThread) [homeassistant.helpers.event] Error while processing template: Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=2>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 461, in async_render
    render_result = render_with_context(self.template, compiled, **kwargs)
  File "/usr/src/homeassistant/homeassistant/helpers/template/context.py", line 45, in render_with_context
    return template.render(**kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 1295, in render
    self.environment.handle_exception()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 942, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<template>", line 1, in top-level template code
  File "/usr/local/lib/python3.13/site-packages/jinja2/filters.py", line 438, in do_sort
    return sorted(value, key=key_func, reverse=reverse)
TypeError: 'NoneType' object is not iterable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 579, in async_render_to_info
    render_info._result = self.async_render(  # noqa: SLF001
                          ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
        variables, strict=strict, log_fn=log_fn, **kwargs
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 463, in async_render
    raise TemplateError(err) from err
homeassistant.exceptions.TemplateError: TypeError: 'NoneType' object is not iterable
2026-02-25 07:24:30.170 ERROR (MainThread) [homeassistant.components.template.template_entity] TemplateError('TypeError: 'NoneType' object is not iterable') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=4>' for attribute 'duurste_periode' in entity 'sensor.dynamisch_spread_indicatie_nom'
2026-02-25 07:24:30.172 ERROR (MainThread) [homeassistant.helpers.event] Error while processing template: Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope_morgen') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=2>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 461, in async_render
    render_result = render_with_context(self.template, compiled, **kwargs)
  File "/usr/src/homeassistant/homeassistant/helpers/template/context.py", line 45, in render_with_context
    return template.render(**kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 1295, in render
    self.environment.handle_exception()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 942, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<template>", line 1, in top-level template code
  File "/usr/local/lib/python3.13/site-packages/jinja2/filters.py", line 438, in do_sort
    return sorted(value, key=key_func, reverse=reverse)
TypeError: 'NoneType' object is not iterable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 579, in async_render_to_info
    render_info._result = self.async_render(  # noqa: SLF001
                          ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
        variables, strict=strict, log_fn=log_fn, **kwargs
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 463, in async_render
    raise TemplateError(err) from err
homeassistant.exceptions.TemplateError: TypeError: 'NoneType' object is not iterable
2026-02-25 07:24:30.174 ERROR (MainThread) [homeassistant.components.template.template_entity] TemplateError('TypeError: 'NoneType' object is not iterable') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope_morgen') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=4>' for attribute 'duurste_periode' in entity 'sensor.dynamisch_spread_indicatie_nom_morgen'

Ik heb dit één keer gezien bij een andere gebruiker @Devke . Hier was de oplossing om eerst terug te gaan naar de basis configuration.yaml +package

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

homeassistant:
  packages: !include_dir_named packages

[YvonneVP]

Pakhaas schreef op woensdag 25 februari 2026 @ 12:58:
[...]

Is dat ook nodig als je naast de Zendure P1 meter ook de Homewizard P1 meter hebt?

De P1 van Zendure heeft, voor zover ik heb kunnen zien, geen eigen entiteit in HA, ook niet via de Zendure-HA integratie. En zonder entiteit kun je die dan dus ook nergens aan koppelen of specifiek uitlezen.

Ik had de REST: code in de configuration.yaml gezet, maar kreeg een foutmelding over 'REST:' toen ik HA wilde herstarten. Ik heb het er dus weer even uit gehaald.