Zendure producten in Home Assistant integreren deel 2

[Polvo176]

martinvdm schreef op dinsdag 28 oktober 2025 @ 17:18:
[...]

Zolang je alleen sensoren aanmaakt zal er weinig gebeuren. Of stuur je ook de rest_commands?

Ik heb alleen de zendure integratie met HACS in HA gezet.
Verder er niks aan veranderd.
Maar de Hypers gaan regelmatig hun eigenweg omdat ze kennelijk vanuit HA iets gestuurd krijgen. (SF800Pro niet)
Zonder HA heb ik dat niet, dan werkt alles normaal met NOM.

[martinvdm]

Polvo176 schreef op dinsdag 28 oktober 2025 @ 17:50:
[...]

Ik heb alleen de zendure integratie met HACS in HA gezet.
Verder er niks aan veranderd.
Maar de Hypers gaan regelmatig hun eigenweg omdat ze kennelijk vanuit HA iets gestuurd krijgen. (SF800Pro niet)
Zonder HA heb ik dat niet, dan werkt alles normaal met NOM.

Ik heb deze ook even gebruikt en bij mij deed het niks zonder daadwerkelijk iets aan te sturen. Wellicht anders gewoon de sensoren aanmaken met @gielz oplossing in ha?

[gielz]

remcoXP schreef op dinsdag 28 oktober 2025 @ 17:42:
@gielz Zou je aub ook je mooie dashboard code willen delen of op je github willen zetten?

Dit is meer een presentatie van wat er beschikbaar is voor je eigen dashboards. Maar mocht je deze willen DM mij dan even dan deel ik het stukje code.

[Polvo176]

martinvdm schreef op dinsdag 28 oktober 2025 @ 18:21:
[...]

Ik heb deze ook even gebruikt en bij mij deed het niks zonder daadwerkelijk iets aan te sturen. Wellicht anders gewoon de sensoren aanmaken met @gielz oplossing in ha?

Kennelijk is het wel een bekent issue.
Het volgende kreeg ik van chatgpt als antwoord:

De officiële Zendure-integratie in Home Assistant gebruikt de Zendure Cloud API, waarmee je:
Data kunt uitlezen (batterijniveau, stroomrichting, PV, grid, etc.)
Maar óók commando’s kunt sturen (zoals opladen, ontladen, energiemodus wijzigen, enz.)
Zelfs als je niets actief “stuurt”, worden er soms instellingen gesynchroniseerd of overschreven door de integratie:
De API-query’s kunnen triggers veroorzaken waardoor de Hyper-instellingen (zoals NOM) tijdelijk overschakelen of herberekend worden.
Vooral bij systemen met meerdere Hypers + een SF800Pro reageert het systeem alsof er een “extern beheer” is, wat NOM-regeling kan ontregelen.

[Polvo176]

Er is kennelijk geen eenvoudige oplossing voor.

[martinvdm]

Polvo176 schreef op woensdag 29 oktober 2025 @ 00:25:
Er is kennelijk geen eenvoudige oplossing voor.

Kun je niet binnen je integratie de cloud manager device uitschakelen ?

[Taro]

Of de Smart mode op Off zetten? En ze geen fuse groups toekennen, dan zouden ze niets moeten doen.

[Polvo176]

Taro schreef op woensdag 29 oktober 2025 @ 08:34:
Of de Smart mode op Off zetten? En ze geen fuse groups toekennen, dan zouden ze niets moeten doen.

Hoe zou ik smartmode op off moeten zetten?
Onder bediening heb ik maar 4 dingen die ik kan instellen.
1 AC in of uitvoer modes.
2 bypass mode aan of uit of automatisch.
3 connection mode op cloud of local voor de hypers en voor de SF880p cloud of zenSDK
4 device fusegroup, geen idee wat dat doet, heb wel wat verschillende geprovbeerd maar tot nu maakt dat niks uit.

[geert1992]

Polvo176 schreef op woensdag 29 oktober 2025 @ 11:46:
[...]

Hoe zou ik smartmode op off moeten zetten?
Onder bediening heb ik maar 4 dingen die ik kan instellen.
1 AC in of uitvoer modes.
2 bypass mode aan of uit of automatisch.
3 connection mode op cloud of local voor de hypers en voor de SF880p cloud of zenSDK
4 device fusegroup, geen idee wat dat doet, heb wel wat verschillende geprovbeerd maar tot nu maakt dat niks uit.

Als het goed is heb je een zendure manager, daar kan je off kiezen.

[Taro]

@Polvo176 Zoals @geert1992 inderdaad zegt: Bij het Zendure Manager "apparaat":

Naar Apparaten -> Zendure integratie en dan:


En daarna deze op Off zetten:

[Polvo176]

Taro schreef op woensdag 29 oktober 2025 @ 12:33:
@Polvo176 Zoals @geert1992 inderdaad zegt: Bij het Zendure Manager "apparaat":

Naar Apparaten -> Zendure integratie en dan:
[Afbeelding]

En daarna deze op Off zetten:
[Afbeelding]

Dank je, dat ga ik eerst doen, dan even afwachten wat er gebeurd.

[N3OREJ]

Ik heb inmiddels de Gielz integratie een weekje lopen, en tot nu toe valt mij op dat mijn AC2400 slechts 1 uurtje per dag oplaadt. Ik heb de dynamisch minimale spread op 30% staan.

Is het toeval dat er maar 1 uur geladen wordt omdat er maar 1 uur de spread gehaald wordt, of is dit een bekend issue? Ik heb 8,6 kwh aan capaciteit, dus zou graag iets meer laden.

[Taro]

N3OREJ schreef op woensdag 29 oktober 2025 @ 13:54:
Ik heb inmiddels de Gielz integratie een weekje lopen, en tot nu toe valt mij op dat mijn AC2400 slechts 1 uurtje per dag oplaadt. Ik heb de dynamisch minimale spread op 30% staan.

Is het toeval dat er maar 1 uur geladen wordt omdat er maar 1 uur de spread gehaald wordt, of is dit een bekend issue? Ik heb 8,6 kwh aan capaciteit, dus zou graag iets meer laden.

Waarom heb je de spread zo hoog staan? 21 cent laden en vanavond met 29-30 cent ontladen kan met een RTE van +-85% en wat afschrijving nog wel iets opleveren.

Kijk even goed welke componenten je in de spread meeneemt en wanneer het wel/niet voor je loont.

[gielz]

N3OREJ schreef op woensdag 29 oktober 2025 @ 13:54:
Ik heb inmiddels de Gielz integratie een weekje lopen, en tot nu toe valt mij op dat mijn AC2400 slechts 1 uurtje per dag oplaadt. Ik heb de dynamisch minimale spread op 30% staan.

Is het toeval dat er maar 1 uur geladen wordt omdat er maar 1 uur de spread gehaald wordt, of is dit een bekend issue? Ik heb 8,6 kwh aan capaciteit, dus zou graag iets meer laden.

Heb je ook aangegeven dat je bijvoorbeeld 1-3 uur goedkoop wilt opladen iedere dag en daarna de overige uren als duur gemarkeerd voor een NOM spread berekening? Zo niet dan heb je vandaag van 04:00 t/m 05:00 een uurtje opgeladen.

[mcurlym]

Kan je nog iets meer uitleg geven bij de Dynamisch NOM? Ik heb (nog) geen dynamisch contract, maar ben een beetje aan het kijken wat er precies gebeurt. Met name de interactie tussen op/ontladen en Goedkoopste/Duurste periode is me nog niet helemaal helder. In je voorbeeld hierboven (5+19=24) heb je de hele dag afgedekt. Maar dat hoeft niet zie ik, je kan ook goedkoopste 5 en duurste 5 doen bv. De andere uren zijn dan niet gemarkeerd. Wat gebeurt er dan tijdens die uren?

Wat ik ook zie is dat als Goedkoopste Periode = Ja, dat de batterij dan meteen vol vermogen begint te laden. In mijn optiek zou ik liever hebben dat die tijdens daglichturen rustig laadt op de overproductie van de zonnepanelen, en als ie om bv. 14:00 nog niet vol is, om dan nog snel vol te laden om de avonduren door te komen. Het is me nog niet duidelijk hoe dat te bereiken. MAAR - misschien maak ik hier een denkfout omdat ik geen dynamisch contract heb. Op dit moment wil ik in feite: Zon > Opladen > Ontladen. Maar als ik voor een dynamisch contract zou gaan wil ik vermoedelijk goedkoop opladen > Zon > duur ontladen? Of mis ik toch nog iets?

[ Voor 7% gewijzigd door mcurlym op 30-10-2025 10:08 ]

[Gyrolion]

mcurlym schreef op donderdag 30 oktober 2025 @ 09:40:
Kan je nog iets meer uitleg geven bij de Dynamisch NOM? Ik heb (nog) geen dynamisch contract, maar ben een beetje aan het kijken wat er precies gebeurt. Met name de interactie tussen op/ontladen en Goedkoopste/Duurste periode is me nog niet helemaal helder. In je voorbeeld hierboven (5+19=24) heb je de hele dag afgedekt. Maar dat hoeft niet zie ik, je kan ook goedkoopste 5 en duurste 5 doen bv. De andere uren zijn dan niet gemarkeerd. Wat gebeurt er dan tijdens die uren?

Wat ik ook zie is dat als Goedkoopste Periode = Ja, dat de batterij dan meteen vol vermogen begint te laden. In mijn optiek zou ik liever hebben dat die tijdens daglichturen rustig laadt op de overproductie van de zonnepanelen, en als ie om bv. 14:00 nog niet vol is, om dan nog snel vol te laden om de avonduren door te komen. Het is me nog niet duidelijk hoe dat te bereiken. MAAR - misschien maak ik hier een denkfout omdat ik geen dynamisch contract heb. Op dit moment wil ik in feite: Zon > Opladen > Ontladen. Maar als ik voor een dynamisch contract zou gaan wil ik vermoedelijk goedkoop opladen > Zon > duur ontladen? Of mis ik toch nog iets?

Ik denk dat je dan al snel zelf een automation moet bouwen die er bijvoorbeeld zo uit ziet.

Tussen 00:00 -- 06:59 uur = zet input select zendure AC2400 op Dynamisch NOM
Tussen 07:00 -- 14:00 uur = zet input select zendure AC2400 op Nul op de meter
Tussen 14:00 -- 23:59 uur = zet input select zendure AC2400 op Dynamisch NOM

Dan zal hij dus tussen 7 en 14:00 uur altijd nul op de meter houden en niet dynamisch gaan bijladen.

Hoe volgens mij nu het dynamische NOM werkt is dat je dus bijvoorbeeld 5 uur goedkoop pakt en de rest duur dat hij dan tijdens die 5 uur goedkoop gaat bijladen,
Dat je duren invult is om de spread te berkenen en deze wordt dan weer gebruikt om wel of niet te laden, is de spread te weinig, bijvoorbeeld 10% en je hebt de minimale spread op 25% staan dan gebeurd er niks en blijft hij gewoon nommen.

[ Voor 14% gewijzigd door Gyrolion op 30-10-2025 12:01 ]

[mcurlym]

I see, volgens mij wil ik net het omgekeerde schema: Overdag dynamisch NOM (met max input vermogen op 1200W) omdat dan vermoedelijk de prijs laag is/ik kan bijladen met overproductie van de panelen. Dan vanaf 16:00 overschakelen naar NOM om de opgeslagen stroom te gebruiken.

Gaat hij in de Dynamisch NOM tijdens de dure uren ook aan de grid leveren? Of levert hij enkel binnen je systeem? Als hij niet aan de grid gaat leveren (wat ik zou willen, te weinig capaciteit om te handelen), dan kan ik inderdaad gewoon 5u goedkoop instellen en het input vermogen wat beperken en dan het systeem de rest laten doen...

Kan ik een tweede automation instellen die de 'zendure gielz automation' aanstuurt (zoals bv in je schema)?

Aanvulling: als ik het max input vermogen tijdens de dag op (1200W + Solar production = input (met max van 2400 uiteraard)) zet dan zorg ik ervoor dat ik steeds de maximale zonnestroom kan benutten, ook als er geen apparaten aan staan. Als ik hem op een vast W zet en er is overproductie boven dat aantal, dan kan de batterij die extra W niet opnemen en zal er teruglevering zijn...

[ Voor 20% gewijzigd door mcurlym op 30-10-2025 13:08 ]

[N3OREJ]

Nog niet aangegeven nee, maar het valt me nu op dat de spread indicatie op 166% staat, dus ik heb ergens anders nog iets niet goed zitten😅

gielz schreef op woensdag 29 oktober 2025 @ 21:30:
[...]


Heb je ook aangegeven dat je bijvoorbeeld 1-3 uur goedkoop wilt opladen iedere dag en daarna de overige uren als duur gemarkeerd voor een NOM spread berekening? Zo niet dan heb je vandaag van 04:00 t/m 05:00 een uurtje opgeladen.

[Afbeelding]

[iwanovich]

mcurlym schreef op donderdag 30 oktober 2025 @ 13:00:
I see, volgens mij wil ik net het omgekeerde schema: Overdag dynamisch NOM (met max input vermogen op 1200W) omdat dan vermoedelijk de prijs laag is/ik kan bijladen met overproductie van de panelen. Dan vanaf 16:00 overschakelen naar NOM om de opgeslagen stroom te gebruiken.

Gaat hij in de Dynamisch NOM tijdens de dure uren ook aan de grid leveren? Of levert hij enkel binnen je systeem? Als hij niet aan de grid gaat leveren (wat ik zou willen, te weinig capaciteit om te handelen), dan kan ik inderdaad gewoon 5u goedkoop instellen en het input vermogen wat beperken en dan het systeem de rest laten doen...

Kan ik een tweede automation instellen die de 'zendure gielz automation' aanstuurt (zoals bv in je schema)?

Aanvulling: als ik het max input vermogen tijdens de dag op (1200W + Solar production = input (met max van 2400 uiteraard)) zet dan zorg ik ervoor dat ik steeds de maximale zonnestroom kan benutten, ook als er geen apparaten aan staan. Als ik hem op een vast W zet en er is overproductie boven dat aantal, dan kan de batterij die extra W niet opnemen en zal er teruglevering zijn...

Aanvulling: correct, maar ik stel voor dat je de max input lekker op 2400W laat staan en kiest voor slim opladen waarbij simpelweg jouw opwekoverschot de accu in gaat.
Ja, je kan een (tweede, derde etc.) automation maken die entiteiten beïnvloed die door Gielz' automation gebruikt worden.
Volgens mij had Gielz aangegeven dat zijn oplossing zich richt op optimaal eigen zonnestroomopwek gebruiken. Daarom denk ik dat zijn dynamisch NOM algoritme zich voornamelijk richt op prijsbewust opladen (omdat de zon niet altijd voldoende schijnt op de zonnepanelen, zoals op een grauwe winterdag met veel wind). Terugleveren aan het net, ligt dan niet zo voor de hand. Je moet je laadverliezen terugverdienen, het gebruik van je accu(cycles) en over een jaar ook je btw en energiebelasting. Mijn 'educated guess' is daarom dat dynamisch NOM niet terug gaat leveren aan het net, maar jebkan dit natuurlijk relatief makkelijk aanpassen in Gielz' zijn config óf met een eigen automation de standen van Gielz' automation beïnvloeden. Dat laatste lijkt mij het meest makkelijk.

[gielz]

mcurlym schreef op donderdag 30 oktober 2025 @ 13:00:
I see, volgens mij wil ik net het omgekeerde schema: Overdag dynamisch NOM (met max input vermogen op 1200W) omdat dan vermoedelijk de prijs laag is/ik kan bijladen met overproductie van de panelen. Dan vanaf 16:00 overschakelen naar NOM om de opgeslagen stroom te gebruiken.

Gaat hij in de Dynamisch NOM tijdens de dure uren ook aan de grid leveren? Of levert hij enkel binnen je systeem? Als hij niet aan de grid gaat leveren (wat ik zou willen, te weinig capaciteit om te handelen), dan kan ik inderdaad gewoon 5u goedkoop instellen en het input vermogen wat beperken en dan het systeem de rest laten doen...

Kan ik een tweede automation instellen die de 'zendure gielz automation' aanstuurt (zoals bv in je schema)?

Aanvulling: als ik het max input vermogen tijdens de dag op (1200W + Solar production = input (met max van 2400 uiteraard)) zet dan zorg ik ervoor dat ik steeds de maximale zonnestroom kan benutten, ook als er geen apparaten aan staan. Als ik hem op een vast W zet en er is overproductie boven dat aantal, dan kan de batterij die extra W niet opnemen en zal er teruglevering zijn...

Dit zijn op dit moment de opties. Mijn advies is om deze te gebruiken en indien je een extra eigen sturing erbij wilt deze de modus te laten aanpassen. Bijvoorbeeld @CopyCatz gebruikt de DAO integratie en hierbij de Handmatig modus. Zo zijn er ook meerdere die bijvoorbeeld tijdens het opladen van de EV een Standby modus of Alleen Slim Opladen modus gebruiken en ook weer gebruikers die bij de duurste uren een stukje terugleveren.

Een handel optie zit er iig niet in, de batterij zal nooit zelf geforceerd gaan terugleveren in de modus Dynamisch NOM. Deze is specifiek bedoelt voor bijladen in de goedkoopste berekende uren. Maar dit wil niet zeggen dat dit niet kan want sensor.dynamisch_duurste_periode geeft aan of het een dure periode is.

De automatisering kan hierdoor altijd aan blijven staan wat ook wel wenselijk is om het flashgeheugen te controleren, dynamisch overschakeling van morgen naar vandaag en de minimale SOC bescherming.

[Aardedraadje]

gielz schreef op vrijdag 31 oktober 2025 @ 09:06:
[...]

De automatisering kan hierdoor altijd aan blijven staan wat ook wel wenselijk is om het flashgeheugen te controleren, dynamisch overschakeling van morgen naar vandaag en de minimale SOC bescherming.

Dit triggert trouwens iets bij mij, dat laatste.

Het feit dat dezelfde automation de sturing doet én de dynamisch overschakeling doet van morgen naar vandaag gaf bij mij een probleem. jprecies om 00:00:00 liep al een automation voor de aansturing. De dynamische periodes waren niet overgezet en in de HA log stond iets in de trant van "automation already running"

Heb het overzetten om 00:00:00 een aparte automation gemaakt en niet meer teruggezien

Sorry, had dit eerder moeten melden, maar druk met een verbouwing

[gielz]

Aardedraadje schreef op vrijdag 31 oktober 2025 @ 13:09:
[...]

Dit triggert trouwens iets bij mij, dat laatste.

Het feit dat dezelfde automation de sturing doet én de dynamisch overschakeling doet van morgen naar vandaag gaf bij mij een probleem. jprecies om 00:00:00 liep al een automation voor de aansturing. De dynamische periodes waren niet overgezet en in de HA log stond iets in de trant van "automation already running"

Heb het overzetten om 00:00:00 een aparte automation gemaakt en niet meer teruggezien

Sorry, had dit eerder moeten melden, maar druk met een verbouwing

Draai je de laatste versie? Want die zou dit probleem niet moeten hebben omdat er altijd 2 parallel mogen lopen.

code:

mode: queued
max: 2

[Aardedraadje]

gielz schreef op vrijdag 31 oktober 2025 @ 13:12:
[...]


Draai je de laatste versie? Want die zou dit probleem niet moeten hebben omdat er altijd 2 parallel mogen lopen.

Ah dan is dat het denk ik, ik heb de versie van vóór november maar wel met de toevoeging van HA-dynamisch

[gielz]

Aardedraadje schreef op vrijdag 31 oktober 2025 @ 13:13:
[...]

Ah dan is dat het denk ik, ik heb de versie van vóór november maar wel met de toevoeging van HA-dynamisch

Ja dat is bij de laatste versie niet meer het geval. Maand geleden had ik hier een DM over gehad dat dit in uitzonderlijke situaties niet goed ging.

[Aardedraadje]

gielz schreef op vrijdag 31 oktober 2025 @ 13:14:
[...]


Ja dat is bij de laatste versie niet meer het geval. Maand geleden had ik hier een DM over gehad dat dit in uitzonderlijke situaties niet goed ging.

Nog een reden om tijd te maken voor het bijwerken dus. Nou excuses voor de loze melding dan

[gielz]

ZenSDK (Gielz) - December releasetest

Voor de December release een aantal kleine wijzigingen die nu te testen zijn en over 4 weken naar release gaan. Draait hier al inmiddels een week zonder problemen.

Configuration en Automatisering; https://github.com/Gielz1.../Gielz1986-December-patch
Wijzigingen; https://github.com/Gielz1....Gielz1986-December-patch

Nieuwe sensors

Ooit gemaakt voor de Homewizard batterij en nu ook in deze sturing standaard beschikbaar. Vooral leuk om te zien hoeveel uren je nou echt nul import had per dag;

sensor.zendure_2400_ac_modus aangepast

Deze toont nu ook Standby en niet alleen Ontladen en Laden. Dit word berekend en zit niet standaard in de API.

Handmatig modus bugfix

In uitzonderlijke gevallen bij het invullen van 0 watt bleef de batterij toch ontladen in de laatst ingestelde waarde. Dit zou nu niet meer voor moeten komen.

Releasenotes November - niet vermeld

Wanneer de automatisering NOM wilt gaan bijsturen en de dynamische instelling wilt gaan overzetten dan gebeurde dit laatste niet. De automatisering heeft sinds deze release een wachtrij van 2 om dit te voorkomen.

[ Voor 6% gewijzigd door gielz op 31-10-2025 13:32 ]

[Taro]

jordyc schreef op dinsdag 24 juni 2025 @ 19:34:
@Taro ik heb de sensors gefixed en getest. De sensoren doen nu ook wat ik verwacht.

Wat is er anders:
- De wallbox gaf in kWh het vermogen, dit wordt nu maal 1000 gedaan om naar watts om te rekenen
- De input boolean op "off" betekent dat de auto NIET met de batterij opgeladen moet worden. Dit voelt iets intuitiever.

Negatieve sensor

code:

{% set vermogen = states('<sensor.p1_meter_vermogen>') | float(0) %}
{% set ev_vermogen = states('<sensor.EV_laadvermogen>')| float(0) * 1000 %}
{% set batterij_input = states('sensor.battery_input_total') | float(0) %}
{% set include_ev = is_state('<input_boolean.ev_laden_met_batterij_stroom>', 'off') %}

{% set netto_vermogen = vermogen - (ev_vermogen if include_ev else 0) %}

{% if netto_vermogen < 0 %}
  {{ netto_vermogen + 1 }}
{% elif netto_vermogen >0 and batterij_input != 0 %}
  {{ netto_vermogen + 1 }}
{% elif netto_vermogen > 0 and batterij_input == 0 %}
  {{ [netto_vermogen, 0] | max }}
{% else %}
  0
{% endif %}

Positieve sensor

code:

{% set vermogen = states('<sensor.p1_meter_vermogen>') | float(0) %}
{% set ev_vermogen = states('<sensor.EV_laadvermogen>') | float(0) * 1000 %}
{% set batterij_output = states('sensor.battery_output_total') | float(0) %}
{% set include_ev = is_state('<input_boolean.ev_laden_met_batterij_stroom>', 'off') %}

{% set netto_vermogen = vermogen - (ev_vermogen if include_ev else 0) %}

{% if netto_vermogen > 0 %}
  {{ netto_vermogen + 1 }}
{% elif netto_vermogen < 0 and batterij_output != 0 %}
  {{ netto_vermogen + 1 }}
{% elif netto_vermogen < 0 and batterij_output == 0 %}
  {{ [netto_vermogen, 0] | max }}
{% else %}
  0
{% endif %}

negative and positive sensor

code:

{% set vermogen = states('<sensor.p1_meter_vermogen>') | float(0) %}
{% set ev_vermogen = states('<sensor.EV_laadvermogen>') | float(0) * 1000 %}
{% set include_ev = is_state('<input_boolean.ev_laden_met_batterij_stroom>', 'off') %}

{{ (vermogen - (ev_vermogen if include_ev else 0)) + 1 }}

Op dit moment zie ik dat Power Negative zowel positief als negatief kan zijn, waardoor bij Smart Charging er wel door de accu's wordt teruggeleverd. Ik wil onder de 20 ct/kWh niet terugleveren, wel laden, dus de accu's mogen nu met overschot laden, maar niet ontladen. Dan kies ik toch voor Smart Charging, waardoor Power Negative wordt gebruikt? Klopt het dan dat deze nu ook boven 0 kan uitkomen met bovenstaande code?

Is dit een evt. betere versie?

YAML:

{% set vermogen = states('sensor.ecotracker_actueel_verbruik') | float(0) %}
{% set ev_vermogen = states('sensor.myenergi_zappi_SN_power_ct_internal_load') | float(0) %}
{% set batterij_input = states('sensor.battery_input_total') | float(0) %}
{% set include_ev = is_state('input_boolean.ev_uit_accu_s_laden', 'off') %}

{% set netto_vermogen = vermogen - (ev_vermogen if include_ev else 0) %}

{{ [netto_vermogen, 0] | min }}

[ Voor 32% gewijzigd door Taro op 01-11-2025 10:14 ]

[jordyc]

Taro schreef op zaterdag 1 november 2025 @ 09:47:
[...]

Op dit moment zie ik dat Power Negative zowel positief als negatief kan zijn, waardoor bij Smart Charging er wel door de accu's wordt teruggeleverd. Ik wil onder de 20 ct/kWh niet terugleveren, wel laden, dus de accu's mogen nu met overschot laden, maar niet ontladen. Dan kies ik toch voor Smart Charging, waardoor Power Negative wordt gebruikt? Klopt het dan dat deze nu ook boven 0 kan uitkomen met bovenstaande code?

Is dit een evt. betere versie?

YAML:

{% set vermogen = states('sensor.ecotracker_actueel_verbruik') | float(0) %}
{% set ev_vermogen = states('sensor.myenergi_zappi_SN_power_ct_internal_load') | float(0) %}
{% set batterij_input = states('sensor.battery_input_total') | float(0) %}
{% set include_ev = is_state('input_boolean.ev_uit_accu_s_laden', 'off') %}

{% set netto_vermogen = vermogen - (ev_vermogen if include_ev else 0) %}

{{ [netto_vermogen, 0] | min }}

Dit zou inderdaad een verbetering zijn. Ik ben zelf afgestapt van de Zendure aansturing en naar de Gielz aansturing gegaan dus durf niet te zeggen of dat het hebben van een positieve waarde in combinatie met Smart Charging een issue is.
Als dat niet zo is dan kun je ook er voor kiezen om gebruik te maken van alleen nog maar de Power Positive and Negative en dan met de verschillende Smart settings bepaal ik wat de batterij mag doen. Dit scheelt 3 sensoren en dan in de automatisering bepaal ik per uur welke strategie ik wil hanteren.

Als je dan wel wilt laden gebruik je inderdaad de Smart Charging en bij ontladen Smart Discharging.

[martinvdm]

gielz schreef op vrijdag 31 oktober 2025 @ 13:32:

ZenSDK (Gielz) - December releasetest

Voor de December release een aantal kleine wijzigingen die nu te testen zijn en over 4 weken naar release gaan. Draait hier al inmiddels een week zonder problemen.

Configuration en Automatisering; https://github.com/Gielz1.../Gielz1986-December-patch
Wijzigingen; https://github.com/Gielz1....Gielz1986-December-patch

Nieuwe sensors

Ooit gemaakt voor de Homewizard batterij en nu ook in deze sturing standaard beschikbaar. Vooral leuk om te zien hoeveel uren je nou echt nul import had per dag;
[Afbeelding]

sensor.zendure_2400_ac_modus aangepast

Deze toont nu ook Standby en niet alleen Ontladen en Laden. Dit word berekend en zit niet standaard in de API.
[Afbeelding]

Handmatig modus bugfix

In uitzonderlijke gevallen bij het invullen van 0 watt bleef de batterij toch ontladen in de laatst ingestelde waarde. Dit zou nu niet meer voor moeten komen.

Releasenotes November - niet vermeld

Wanneer de automatisering NOM wilt gaan bijsturen en de dynamische instelling wilt gaan overzetten dan gebeurde dit laatste niet. De automatisering heeft sinds deze release een wachtrij van 2 om dit te voorkomen.

Getest. Alles lijkt goed te werken. De Standby waarde voor de modus is zeer welkom en erg fijn. Ik heb wel het idee dat het wat langer duurt om het export vermogen bij te stellen, is niet veranderd in de automation, maar dat viel me wel op. Enigszins traagheid in het bijstellen van het vermogen bij het gebruik van NOM ondanks dat p1 per sec update.

[dennisdew16]

martinvdm schreef op zaterdag 1 november 2025 @ 17:50:
[...]

Getest. Alles lijkt goed te werken. De Standby waarde voor de modus is zeer welkom en erg fijn. Ik heb wel het idee dat het wat langer duurt om het export vermogen bij te stellen, is niet veranderd in de automation, maar dat viel me wel op. Enigszins traagheid in het bijstellen van het vermogen bij het gebruik van NOM ondanks dat p1 per sec update.

Exact dit merk ik ook na de update van 2510 naar laatste versie 3110. Door dit tragere proces ook veel meer 'jojo' gedrag te zien en dus ook minder nauwkeurige NOM. Nog niet kunnen ontdekken waar in de automatisering dit nou mis gaat.

[gielz]

@martinvdm @dennisdew16 Zouden jullie de onderstaande apexchart eens kunnen gebruiken. Die geeft een duidelijker beeld voor het import gedeelte. Deze gebruik ik zelf ook en in de aankomende update zie ik nog geen problemen in HA zelf. Wel dat het verschrikkelijk weer is waardoor hij dus constant moet bijsturen maar dat zag ik ook bij Homewizard terug en dat is gewoon het neveneffect bij NOM met wolkje zon wolkje wolkje.

Ik zal zelf nog even de veranderingen bekijken tov de huidige versie.

code:

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

[ Voor 4% gewijzigd door gielz op 03-11-2025 08:07 ]

[iwanovich]

Ik heb regelmatig met zensdk-gielz dat data unavailable (vermoedelijk vanwege een timeout) is, omdat de omvormer te laat of geen http response geeft. Deze state change wordt meegenomen in het aantal "relaisschakelingen", naar mijn idee is dat niet het gewenste gedrag van de meting, zien jullie dit ook zo?

Ik filter nu de unavailables uit de telling van de relaisschakelingen en ben daar zeer tevreden over.

[gielz]

iwanovich schreef op maandag 3 november 2025 @ 09:52:
Ik heb regelmatig met zensdk-gielz dat data unavailable (vermoedelijk vanwege een timeout) is, omdat de omvormer te laat of geen http response geeft. Deze state change wordt meegenomen in het aantal "relaisschakelingen", naar mijn idee is dat niet het gewenste gedrag van de meting, zien jullie dit ook zo?

Ik filter nu de unavailables uit de telling van de relaisschakelingen en ben daar zeer tevreden over.

Ik zou eerder eerst even naar je timeouts kijken want dat komt je aansturing niet ten goede. Wat zegt sensor.zendure_2400_ac_signaalsterkte?

[dennisdew16]

@gielz Ik gebruik die apexchart ook al maanden en werkt goed alleen vandaag heb ik er niks aan. Lege accu, weinig zon en teveel eigen gebruik dus NOM doet vandaag niet veel. Maar onderstaande afbeelding spreekt wel voorzich denk ik. Rond 22:24 heb ik de wijziging van de automatisering gedaan. De zon was toen natuurlijk al onder dus weersinvloeden spelen hier niet in mee.

[gielz]

dennisdew16 schreef op maandag 3 november 2025 @ 10:40:
@gielz Ik gebruik die apexchart ook al maanden en werkt goed alleen vandaag heb ik er niks aan. Lege accu, weinig zon en teveel eigen gebruik dus NOM doet vandaag niet veel. Maar onderstaande afbeelding spreekt wel voorzich denk ik. Rond 22:24 heb ik de wijziging van de automatisering gedaan. De zon was toen natuurlijk al onder dus weersinvloeden spelen hier niet in mee.
[Afbeelding]

Loopt inderdaad iets niet lekker. Is er niet iets veranderd in huis (bijvoorbeeld ontvochter is killing) of iemand met een warmtedeken?

In de automatisering zie ik geen veranderingen die dit zouden kunnen veroorzaken. Bij het opstarten van het ontladen wacht hij iets langer maar daarna gaat hij gewoon door pruttelen binnen de standaard NOM zoals wij gewend zijn.

Je zou wellicht even kunnen kijken of dit ook gebeurd bij de huidige versie. Paar weken geleden zag ik namelijk hier ook vreemd gedrag. Maar iemand had een warmtedeken aan.

[dennisdew16]

@gielz Voor zo ver ik weet is er gisteravond niks veranderd. Alleen dus nieuwe automatisering Ik ga anders vanmiddag nog wel eens kijken of ik handmatig wat kan laden en dan nog eens kijken wat ie vanavond doet met NOM.

[iwanovich]

gielz schreef op maandag 3 november 2025 @ 10:36:
[...]


Ik zou eerder eerst even naar je timeouts kijken want dat komt je aansturing niet ten goede. Wat zegt sensor.zendure_2400_ac_signaalsterkte?

Een zeer constante "uitstekend", sinds ik de omvormer gepint heb op het accesspoint dat schuinboven het apparaat hangt. Kan ik afleiden uit jouw tip, dat jij (en eventueel anderen) geen last hebben van regelmatige "unavailable" meldingen?

[gielz]

iwanovich schreef op maandag 3 november 2025 @ 11:17:
[...]


Een zeer constante "uitstekend", sinds ik de omvormer gepint heb op het accesspoint dat schuinboven het apparaat hangt. Kan ik afleiden uit jouw tip, dat jij (en eventueel anderen) geen last hebben van regelmatige "unavailable" meldingen?

Ik zie het hier alleen bij een herstart van HA zelf. En heel sporadisch als er ergens in het netwerk iets niet goed gaat. Dan is de batterijj een paar seconden niet bereikbaar.

[gielz]

dennisdew16 schreef op maandag 3 november 2025 @ 10:55:
@gielz Voor zo ver ik weet is er gisteravond niks veranderd. Alleen dus nieuwe automatisering Ik ga anders vanmiddag nog wel eens kijken of ik handmatig wat kan laden en dan nog eens kijken wat ie vanavond doet met NOM.

Hier net een test afgerond, even 2 uur lang 2400 watt geladen en daarna NOM. Op de P1 per seconden zie ik inderdaad schommelingen maar ik had eigenlijk niet anders verwacht met zonnepanelen die wat prik geven en een infraroodpaneel. De uiteindelijk stand was 0,004 kwh import zonder infraroodpaneel (uurtje). en 0,013 kwh import met een infraroodpaneel (uurtje).

Ik zal hem voor vanavond weer even volledig opladen en kijken hoe de avond en nacht verloopt met de release van december.

[tantesok]

Ik weet niet of dit het juiste topic voor mijn vraag is maar ik stel hem hier toch maar even.
Mocht ik het ergens anders moeten vragen hoor ik dat graag.
Ik ben recent in HA aan de slag gegaan met de integratie van Gielz. Ik wil hiervoor mijn bestaande homewizard p1 meter gebruiken als bron voor de sturing. Nu krijg ik alleen mijn p1 data in HA maar eens per 5 seconden binnen en zou dit graag naar elke seconde hebben, maar krijg dit maar niet voor elkaar. Ik heb wel een DSMR 5 meter en in de homewizard app zie ik de data ook iedere seconden veranderen. Maar ik zie dit dus niet terug in HA. Ik heb al geprobeerd om de stadaard polling uit te schakelen en heb met de hand een nieuwe automation gebouwd om elke seconde de entiteit te updaten maar dit had niet het geweste effect. Heeft iemand van jullie iets aan moeten passen om de data per seconden zichtbaar te krijgen?

[dennisdew16]

tantesok schreef op maandag 3 november 2025 @ 16:28:
Ik weet niet of dit het juiste topic voor mijn vraag is maar ik stel hem hier toch maar even.
Mocht ik het ergens anders moeten vragen hoor ik dat graag.
Ik ben recent in HA aan de slag gegaan met de integratie van Gielz. Ik wil hiervoor mijn bestaande homewizard p1 meter gebruiken als bron voor de sturing. Nu krijg ik alleen mijn p1 data in HA maar eens per 5 seconden binnen en zou dit graag naar elke seconde hebben, maar krijg dit maar niet voor elkaar. Ik heb wel een DSMR 5 meter en in de homewizard app zie ik de data ook iedere seconden veranderen. Maar ik zie dit dus niet terug in HA. Ik heb al geprobeerd om de stadaard polling uit te schakelen en heb met de hand een nieuwe automation gebouwd om elke seconde de entiteit te updaten maar dit had niet het geweste effect. Heeft iemand van jullie iets aan moeten passen om de data per seconden zichtbaar te krijgen?

De officiële HW integratie doet volgens mij inderdaad elke 5 seconde updaten in home assistant. Je moet in de HW app ergens lokale API aanzetten voor je P1-meter. Als je alle gielz config goed hebt gedaan heb je ook een entity in home assistant genaamd "Homewizard P1 Vermogen". Deze update als het goed is wel elke seconde.

[remcoXP]

ik zit in mijn database te kijken en probeer deze wat kleiner te krijgen.
ik ga dus vandaag met de recorder aan de slag om het een en ander te excluden.
maar ook bij activities zie ik om de secode dat automation.zendure_zensdk_gielz start wat goed is.
maar hierdoor wordt het activiteiten blad wel minder goed bruikbaar.

hebben jullie zaken die je niet logt ergens exclude om alles wat overzichtelijker en meer performant te houden?

[martinvdm]

remcoXP schreef op dinsdag 4 november 2025 @ 08:02:
ik zit in mijn database te kijken en probeer deze wat kleiner te krijgen.
ik ga dus vandaag met de recorder aan de slag om het een en ander te excluden.
maar ook bij activities zie ik om de secode dat automation.zendure_zensdk_gielz start wat goed is.
maar hierdoor wordt het activiteiten blad wel minder goed bruikbaar.

hebben jullie zaken die je niet logt ergens exclude om alles wat overzichtelijker en meer performant te houden?

Heb ik ook en om die reden deze automatisering uitgesloten van het logboek/activities

[Polvo176]

Polvo176 schreef op woensdag 29 oktober 2025 @ 12:57:
[...]

Dank je, dat ga ik eerst doen, dan even afwachten wat er gebeurd.

Even een update:
Eerst HA uitgezet, maar op een of andere manier regelde het niet goed meer, de batterijen werden maar voor een deel met zonnestroom geladen, de rest van de zonnestroom werd terug geleverd.
Er was dus geen NOM meer.
Dus alles uit gezet en opnieuw in de app.
Ik moest wel een paar dagen wachten omdat de zonnepanelen bijna niks deden bij die grijze dagen.
Maar uiteindelijk werkte het weer normaal.
Daarna HA weer aangezet met de Manager uit, ook weer een aantal dagen gevolgd.
Lijkt nu inderdaad goed te gaan met HA.

[jordyc]

Er is momenteel een storing bij Home wizard, nu gebruik ik de lokale API en de code die uit de Gielz automation komt. Dus ik dacht dat ik wel goed zat en dat de data alsnog in HA beschikbaar was. Blijkbaar is dat dus niet zo, de batterij staat dus al sinds vanmiddag niks meer te doen. Zijn er hier andere die hetzelfde probleem hebben met hun batterij aansturing? Zo ja, gebruiken jullie nu andere methodes om de aansturing te doen?

[gielz]

jordyc schreef op woensdag 5 november 2025 @ 21:18:
Er is momenteel een storing bij Home wizard, nu gebruik ik de lokale API en de code die uit de Gielz automation komt. Dus ik dacht dat ik wel goed zat en dat de data alsnog in HA beschikbaar was. Blijkbaar is dat dus niet zo, de batterij staat dus al sinds vanmiddag niks meer te doen. Zijn er hier andere die hetzelfde probleem hebben met hun batterij aansturing? Zo ja, gebruiken jullie nu andere methodes om de aansturing te doen?

Alle Homewizard producten hebben een lokale api en werken dus lokaal altijd door. Waarschijnlijk moet je dus het probleem elders zoeken en niet dat er een storing is bij Homewizard.

Heb je niet door de storing de Homewizard P1 volledig uit je netwerk verwijderd wat ik veel mensen zie doen in het Homewizard batterij topic.

[jordyc]

gielz schreef op woensdag 5 november 2025 @ 21:32:
[...]


Alle Homewizard producten hebben een lokale api en werken dus lokaal altijd door. Waarschijnlijk moet je dus het probleem elders zoeken en niet dat er een storing is bij Homewizard.

Heb je niet door de storing de Homewizard P1 volledig uit je netwerk verwijderd wat ik veel mensen zie doen in het Homewizard batterij topic.

Ik was het vergeten te vermelden, maar ik krijg alle data vanuit de P1 meter wel binnen, maar niet de aangepaste 1 seconde update van de P1 meter. Belangrijk stukje info lijkt het me.

Ik had inderdaad gezien in de HW app dat je nu geen nieuwe apparaten kan koppelen, dus verwijderen is inderdaad geen optie. Voor nu heb ik een back up gebouwd waardoor als de 1 seconde sensor unavailable is hij de 5 seconde sensor gebruikt.

NVM, ik heb de fout gevonden. Om een of andere reden heeft de router bedacht dat de P1 meter een nieuw IP adres moest krijgen.

[ Voor 6% gewijzigd door jordyc op 05-11-2025 21:46 ]

[denneappel]

@jordyc Je router kan als het goed is statische adressen geven aan bepaalde apparaten. Ik zou dit direct doen als ik je was. Niet enkel je P1 meter maar ook de batterij en Home-assistant.

[Isdatzo]

Ik heb recent hier een Zendure 2400AC met een stapeltje batterijen draaien. Nu ben voornemens om dit op enig moment uit te breiden met een tweede 2400AC, dus ik heb gekozen voor de Zendure (non-Gielz) integratie in HA. Ik heb een eigen logica gebouwd om het (ont)laden aan te sturen.

Momenteel gebruik ik nog de Homewizard P1-meter, maar ik heb ook een Zendure P1-meter. Heeft iemand enig idee hoe ik die met een 1s updatefrequentie in Home Assistant krijg? Hij verschijnt niet in de Zendure integratie. Ik kan wel zijn MQTT-berichten ontvangen, maar slechts elke 10s.

[jordyc]

denneappel schreef op donderdag 6 november 2025 @ 08:21:
@jordyc Je router kan als het goed is statische adressen geven aan bepaalde apparaten. Ik zou dit direct doen als ik je was. Niet enkel je P1 meter maar ook de batterij en Home-assistant.

Dat weet ik, ik loop er alleen tegenaan dat ik van mijn Nokia router niet hetzelfde IP adres permanent mag geven als wat ie nu al heeft. Dan loopt ie vast op het feit dat het IP adres al is vergeven.

Normaal is dat geen issue omdat een device 24+ uur offline moet zijn voordat het IP adres weer wordt vrijgegeven, iets wat dus alleen bij een hele langdure en heftige stroomstoring het geval zal zijn en wat ik in Nederland nog niet meegemaakt heb.

Dat ie nu wel bedacht om een ander IP adres te geven is me dus ook wel een raadsel.

[jordyc]

Isdatzo schreef op donderdag 6 november 2025 @ 09:36:
Ik heb recent hier een Zendure 2400AC met een stapeltje batterijen draaien. Nu ben voornemens om dit op enig moment uit te breiden met een tweede 2400AC, dus ik heb gekozen voor de Zendure (non-Gielz) integratie in HA. Ik heb een eigen logica gebouwd om het (ont)laden aan te sturen.

Momenteel gebruik ik nog de Homewizard P1-meter, maar ik heb ook een Zendure P1-meter. Heeft iemand enig idee hoe ik die met een 1s updatefrequentie in Home Assistant krijg? Hij verschijnt niet in de Zendure integratie. Ik kan wel zijn MQTT-berichten ontvangen, maar slechts elke 10s.

Als je naar een tweede set batterijen wilt dan is de Gielz aansturing niet geschikt, die stuurt maar 1 device aan. Dan zul je echt naar de Zendure aansturing in HA zelf moeten gaan kijken als je alles als 1 geheel wilt aansturing.

De 1 seconde aansturing zit ook in de Gielz aansturing en als je even zoekt in dit topic dan is de code ook al ergens gedeeld. Let wel op dat ie dan als RESTful entity in HA wordt weggezet.

[c0mplex1]

jordyc schreef op donderdag 6 november 2025 @ 14:27:
[...]


Dat weet ik, ik loop er alleen tegenaan dat ik van mijn Nokia router niet hetzelfde IP adres permanent mag geven als wat ie nu al heeft. Dan loopt ie vast op het feit dat het IP adres al is vergeven.

Normaal is dat geen issue omdat een device 24+ uur offline moet zijn voordat het IP adres weer wordt vrijgegeven, iets wat dus alleen bij een hele langdure en heftige stroomstoring het geval zal zijn en wat ik in Nederland nog niet meegemaakt heb.

Dat ie nu wel bedacht om een ander IP adres te geven is me dus ook wel een raadsel.

Ligt het IP-adres buiten je DHCP range? Dan zou dit niet mogen gebeuren.
Anders is het als het IP-adres binnen de range valt, dan zou je een adres conflict kunnen krijgen.

[jordyc]

c0mplex1 schreef op donderdag 6 november 2025 @ 16:28:
[...]

Ligt het IP-adres buiten je DHCP range? Dan zou dit niet mogen gebeuren.
Anders is het als het IP-adres binnen de range valt, dan zou je een adres conflict kunnen krijgen.

Nee dit is gewoon een issue met de Nokia router die ik vanuit Delta heb gekregen. Die geeft een foutmelding als je het IP adres wat toegewezen is aan bijv de P1 meter wilt vast zetten op dat IP adres. Dan zegt ie dat het adres op dat moment al in gebruik is.

[c0mplex1]

Dan zou ik Delta om een andere router vragen, want dit mag niet gebeuren.

[mcurlym]

de truc bij die Delta routers is dat je de P1 meter aansluit op je netwerk, dan krijgt die een IP adres van de router, dan ga je in de router en zet je dat IP adres vast. Je kan dus niet zelf kiezen welk ip adres je geeft. Eens je het toegewezen ip-adres vastzet, blijft het ook vast is mijn ervaring.

aanvulling: en voor je dat doet eerst even de router resetten (van de stroom af), dan heb je geen last van eventuele eerdere leases. Echt een crime die routers...

[ Voor 21% gewijzigd door mcurlym op 06-11-2025 16:50 ]

[c0mplex1]

Wat een bagger ding.
Dan kun je dus nooit een adres vast zetten zonder het risico te lopen dat je een foutmelding krijg of dat de router vastloopt.

[mcurlym]

kan wel, maar als je veel spul op je netwerk hebt, kan het zijn dat je wel even bezig bent met proberen

[c0mplex1]

Wow, ik heb ze net geteld.
Ik heb 56 vaste IP-adressen op mijn netwerk zitten.
Nu maak ik wel gebruik van VLAN's en veel IoT devices.
Ik gebruik geen Delta router, maar heb ooit een eigen router aangeschaft.

[Isdatzo]

jordyc schreef op donderdag 6 november 2025 @ 14:33:
[...]


Als je naar een tweede set batterijen wilt dan is de Gielz aansturing niet geschikt, die stuurt maar 1 device aan. Dan zul je echt naar de Zendure aansturing in HA zelf moeten gaan kijken als je alles als 1 geheel wilt aansturing.

De 1 seconde aansturing zit ook in de Gielz aansturing en als je even zoekt in dit topic dan is de code ook al ergens gedeeld. Let wel op dat ie dan als RESTful entity in HA wordt weggezet.

Precies daarom gebruik ik dan ook niet de Gielz integration .

[gielz]

Isdatzo schreef op donderdag 6 november 2025 @ 18:01:
[...]


Precies daarom gebruik ik dan ook niet de Gielz integration .

Waarschijnlijk zoekt je deze pinned post;
Taro in "Zendure producten in Home Assistant integreren deel 2"

[gast777]

Isdatzo schreef op donderdag 6 november 2025 @ 18:01:
[...]
Precies daarom gebruik ik dan ook niet de Gielz integration .

Mocht iemand geïnteresseerd zijn, ik heb een Node-Red flow gemaakt die als een proxy werkt tussen de HA Gielz integratie en 2x SF2400AC. Vanuit Gielz integratie gezien praat hij met een enkel "SF4800AC" device.

Die flow (met instructies hoe te installeren) kan ik wel delen, stuur maar een DM. Getest met versie Zendure-HA-zenSDK-20251026 en draait nu al een week zonder enig probleem. Werkt heel mooi, zelfde als voorheen zoals we het van de Gielz kennen met 1 device, maar nu met twee keer het max vermogen.

[MartinMid]

Goedenavond

Net terug van vakantie, net voor de vakantie (3 weken terug) nokte de integratie (fietsongeluk) ermee.

Geprobeerd te deïnstalleren, ging niet helemaal goed, kom hem niet opnieuw installeren
- in .storage-entries de Zendure weggehaald
- opnieuw geïnstalleerd (nu de ‘officiële. Dit is geloof ik de nieuwste variant van fireson eigenlijk
- homeassistant p1 sensor aangegeven

Ik zie nu in HA via de Zendure integratie alle data weer tot in detail

Als ik via de Zendure manager hemnim smart mode of een andere mode wil zetten gebeurt er niets.
Geprobeerd op local en cloud connectie

Via de Zendure app reageert hij wel op handmatig vermogen.
Hyper 2000

Iemand idee?

Martin

[Taro]

MartinMid schreef op vrijdag 7 november 2025 @ 18:00:
Goedenavond

Net terug van vakantie, net voor de vakantie (3 weken terug) nokte de integratie (fietsongeluk) ermee.

Geprobeerd te deïnstalleren, ging niet helemaal goed, kom hem niet opnieuw installeren
- in .storage-entries de Zendure weggehaald
- opnieuw geïnstalleerd (nu de ‘officiële. Dit is geloof ik de nieuwste variant van fireson eigenlijk
- homeassistant p1 sensor aangegeven

Ik zie nu in HA via de Zendure integratie alle data weer tot in detail

Als ik via de Zendure manager hemnim smart mode of een andere mode wil zetten gebeurt er niets.
Geprobeerd op local en cloud connectie

Via de Zendure app reageert hij wel op handmatig vermogen.
Hyper 2000

Iemand idee?

Martin

Heb je HACS gebruikt? Want dan hoef je niet handmatig mappen te verwijderen of toe te voegen, hier staat een handleiding.

[ Voor 6% gewijzigd door Taro op 07-11-2025 19:59 ]

[MartinMid]

@Taro inderdaad via Hacs geïnstalleerd. Het stukje over de fuse group niet gezien bij de upgrade. Werkt nu weer. Thanks voor de hint.
Kijken of hij nu weer blijft draaien.

[Taro]

MartinMid schreef op vrijdag 7 november 2025 @ 22:06:
@Taro inderdaad via Hacs geïnstalleerd. Het stukje over de fuse group niet gezien bij de upgrade. Werkt nu weer. Thanks voor de hint.
Kijken of hij nu weer blijft draaien.

Ja, die fuse group is een belangrijke om in te stellen en ook logisch dat ie standaard op niets staat om problemen te voorkomen. Maar zou natuurlijk wel mooi zijn als die tijdens de installatieprocedure even langs kwam om een waarde in te vullen. Wordt een hoop onduidelijkheid mee voorkomen.

[iwanovich]

gast777 schreef op donderdag 6 november 2025 @ 23:23:
[...]


Mocht iemand geïnteresseerd zijn, ik heb een Node-Red flow gemaakt die als een proxy werkt tussen de HA Gielz integratie en 2x SF2400AC. Vanuit Gielz integratie gezien praat hij met een enkel "SF4800AC" device.

Die flow (met instructies hoe te installeren) kan ik wel delen, stuur maar een DM. Getest met versie Zendure-HA-zenSDK-20251026 en draait nu al een week zonder enig probleem. Werkt heel mooi, zelfde als voorheen zoals we het van de Gielz kennen met 1 device, maar nu met twee keer het max vermogen.

Wat was jouw motivatie, of welke redenen zijn te bedenken, om voor deze oplossing te kiezen t.o.v. de Fireson integratie?

[martinvdm]

iwanovich schreef op zaterdag 8 november 2025 @ 08:43:
[...]

Wat was jouw motivatie, of welke redenen zijn te bedenken, om voor deze oplossing te kiezen t.o.v. de Fireson integratie?

Ik heb ze beide gebruikt en hoewel de vraag niet aan mij gesteld was geef ik toch antwoord
Ik heb maar 1x 2400 en wilde meer flexibiliteit hebben. Waar de Zendure Fireson (HACS) integratie een mooie shoot en go versie is, kun je er weinig aan tweaken. De ZenSDK Gielz versie is volledig in yaml en geeft dus een veel hogere tweakability.

[gast777]

iwanovich schreef op zaterdag 8 november 2025 @ 08:43:
[...]
Wat was jouw motivatie, of welke redenen zijn te bedenken, om voor deze oplossing te kiezen t.o.v. de Fireson integratie?

Ik gebruikte al de Gielz oplossing met 1 Zendure, naar grote tevredenheid. Ik heb er echter een tweede omvormer bijgekocht (voor een mooi prijsje bij marcmax.de toen) zodat ik meer vermogen heb. Voorheen 1 stapel van 6 batterijen, nu twee stapels van 3. Nu kan ik de pieken van de zonnepanelen mooi meepikken in plaats van terug te leveren.

Aangezien ik het leuk vind om te knutselen met Node-Red ben ik eens gaan kijken of een proxy van 1 naar 2 Zendures te maken was. Dat bleek goed te kunnen en werkt nu prima. Het vermogen wordt gelijk verdeeld over de twee Zendures. Als de SoC percentages niet gelijk zijn, zal degene die achterloopt een groter aandeel van het vermogen toegewezen krijgen. Mooi om te zien hoe goed ze gelijk blijven lopen. En ook nog steeds dezelfde mooie NOM van de Gielz aansturing realizeren.

Wat ik nu nog wil toevoegen is dat bij lage vermogens slechts 1 van de 2 Zendures tegelijk gaat laden/ontladen en de andere op 0 Watt blijft (en omwisselen als de SoC percentages niet meer gelijk zijn). Dat zou beter voor de RTE moeten zijn bij lage vermogens. Leuke uitdaging waar ik vandaag eens mee ga beginnen.

Ik kan je de huidige versie geven als je wilt. Zo'n flow kun je importeren in Node-Red, even de juiste IP adressen en serienummers invullen, een paar kleine aanpassingen in de Gielz aanbrengen en klaar.

[gielz]

gast777 schreef op zaterdag 8 november 2025 @ 09:27:
[...]

Ik gebruikte al de Gielz oplossing met 1 Zendure, naar grote tevredenheid. Ik heb er echter een tweede omvormer bijgekocht (voor een mooi prijsje bij marcmax.de toen) zodat ik meer vermogen heb. Voorheen 1 stapel van 6 batterijen, nu twee stapels van 3. Nu kan ik de pieken van de zonnepanelen mooi meepikken in plaats van terug te leveren.

Aangezien ik het leuk vind om te knutselen met Node-Red ben ik eens gaan kijken of een proxy van 1 naar 2 Zendures te maken was. Dat bleek goed te kunnen en werkt nu prima. Het vermogen wordt gelijk verdeeld over de twee Zendures. Als de SoC percentages niet gelijk zijn, zal degene die achterloopt een groter aandeel van het vermogen toegewezen krijgen. Mooi om te zien hoe goed ze gelijk blijven lopen. En ook nog steeds dezelfde mooie NOM van de Gielz aansturing realizeren.

Wat ik nu nog wil toevoegen is dat bij lage vermogens slechts 1 van de 2 Zendures tegelijk gaat laden/ontladen en de andere op 0 Watt blijft (en omwisselen als de SoC percentages niet meer gelijk zijn). Dat zou beter voor de RTE moeten zijn bij lage vermogens. Leuke uitdaging waar ik vandaag eens mee ga beginnen.

Ik kan je de huidige versie geven als je wilt. Zo'n flow kun je importeren in Node-Red, even de juiste IP adressen en serienummers invullen, een paar kleine aanpassingen in de Gielz aanbrengen en klaar.

Wellicht een mooie aanvulling voor de TS. Is dit iets wat je op github kunt plaatsen met een stappenplan?

Altijd gaaf om te zien dat de mogelijkheden eigenlijk eindeloos zijn met deze batterij.

[gast777]

gielz schreef op zaterdag 8 november 2025 @ 09:32:
[...]
Wellicht een mooie aanvulling voor de TS. Is dit iets wat je op github kunt plaatsen met een stappenplan?

Zeker, goed idee. Ik zal je de link sturen wanneer hij op github staat.

[Taro]

gielz schreef op zaterdag 8 november 2025 @ 09:32:
[...]
Altijd gaaf om te zien dat de mogelijkheden eigenlijk eindeloos zijn met deze batterij.

Eens, doordat eigenlijk alles* mooi aan te sturen is blijft Zendure wat mij betreft boven vele andere merken uitspringen. Draai hier nu al maanden stabiel met Fireson/Zendure integratie icm 3x 2400AC waarbij de omvormer met hoogste/laagste SoC meer vermogen krijgt of minder vermogen levert zodat ze eigenlijk altijd gelijk opgaan. Durf gerust op vakantie te gaan wetende dat het bijv. 2-3 weken stabiel blijft draaien. Had ik met eerdere versies van de integratie icm Hypers helaas niet, maar met de huidige versie en 2400AC's wel.

Kijk je naar andere merken PiB's, dan hebben die nog grote stappen te zetten en pas als je daar een tijdje mee hebt gestoeid weet je echt te waarderen hoe belangrijk goede externe aansturing is. Sommige mensen moeten nu bijv. nog hun thuisaccu's op pauze zetten om de EV te kunnen laden, daar wil je echt niet iedere dag aan moeten denken, heerlijk

* Op helaas de ventilator na, maar ooit gaat het ons lukken die ook beschikbaar te krijgen

[tweetyvogel]

@gielz

Vraagje: ik zou graag de mogelijkheid hebben om via "dynamische Nom" een mogelijk hebben om alleen dynamisch te laden en verder Nom te draaien.
Misschien zit dat er wel in, maar heb ik dat dan niet begrepen.
Kan altijd wel een automatisering maken die dit kan regelen maar heb het liever binnen de standaard automatisering.

[ Voor 21% gewijzigd door tweetyvogel op 09-11-2025 11:19 ]

[Taro]

Ik zie dat als de Fake Power Meter van een bepaalde mode naar Smart Charging gaat dat de omvormers dan in hun vorige/oude vermogen blijven hangen. Zet ik de Fireson/Zendure integratie even op Off vanuit Smart NOM, wacht ik totdat alle omvormers weer op 0 staan en daarna weer op Smart Matching, dan gaat het goed.

Gebruik dus deze 2 naast elkaar, de linker wisselt, de rechter (Fireson) staat eigenlijk altijd op Slimme Matching.


Vermoedelijk kan ik dit oplossen door bij Smart Charging (Fake meter, niet Fireson) nooit meer dan 0 als uitkomst te hebben voor de Fake Meter, maar moet ik daar nog wel het huidige Zendure Manager Power mee verrekenen om die weer op 0 te krijgen, eens? Dus 0 + Zendure Manager Power, maar krijg ik dan geen loopje? Loop heel even vast in de denkwijze....

Edit: Wat ik ook kan doen is Slim opladen op de Fireson integratie aanzetten, die neemt automatisch het Zendure Manager Vermogen mee, heb ik voorheen bewust voorkomen ivm extra relaisschakelingen maar weet niet eens of dat daadwerkelijk zo is.

[ Voor 30% gewijzigd door Taro op 08-11-2025 13:41 ]

[gast777]

gielz schreef op zaterdag 8 november 2025 @ 09:32:
[...]

Wellicht een mooie aanvulling voor de TS. Is dit iets wat je op github kunt plaatsen met een stappenplan?

Altijd gaaf om te zien dat de mogelijkheden eigenlijk eindeloos zijn met deze batterij.

Zie hier de github locatie van de proxy: https://github.com/gast777/Zendure-zenSDK-proxy

[Taro]

Nieuwe Fireson/Zendure 1.1.4 pre8-release beschikbaar: https://github.com/Zendur...A/releases/tag/1.1.4-pre8.

Improved power distribution in combination with solar panels, thanks to Rene
Improved bypass handling
Improved solaronly discharge
Optimize inverter working range
Added AB2000X model identifier by @tmhrzgr in #857
Added fan entities for SolarFlow 800 Pro and friendly names by @tmhrzgr in #853
Fix and add aggr total sensors by @tmhrzgr in #855
Added gridOffMode translations by @blaubaer in #859
Fix: Improve exception handling to prevent silent failures by @swissky in #870
Add support for SuperBase v4600 by @harrymayr in #881

[geert1992]

Taro schreef op zondag 9 november 2025 @ 21:24:
Nieuwe Fireson/Zendure 1.1.4 pre8-release beschikbaar: https://github.com/Zendur...A/releases/tag/1.1.4-pre8.


[...]

Zelf al geupdate? Is hij veilig te downloaden?

[Taro]

geert1992 schreef op zondag 9 november 2025 @ 22:18:
[...]

Zelf al geupdate? Is hij veilig te downloaden?

The eagle has landed.

[geert1992]

Taro schreef op zondag 9 november 2025 @ 22:18:
[...]

The eagle has landed.

Please tell me the eagle didn’t shit on your Intel NUC?

[pulsarz]

Smart charge only is weer kaput in 1.1.4 pre8.. 🙃

[Korvaag]

Een beetje een gekke vraag voor in dit topic, maar ik ga het toch proberen. Wat zijn fijne apps voor het kunnen zien van de energieprijzen voor op een iPhone. Het is hierbij even niet belangrijk dat het een API heeft, maar ik wil graag op de telefoon een makkelijk snel overzicht van de prijzen zodat ik dit in de gaten kan houden. Ik heb nu "EnergyPricing" maar die geeft maar 1 dag weer. Ik heb er een paar geprobeerd maar nog niets handigs kunnen ontdekken. Voor veel apps moet je klant zijn. Dat wil ik juist niet. Ik zoek iets universeels waarbij de exacte prijzen niet van belang zijn maar het verloop van de prijzen wel.

Iemand suggesties?

[Acidrain]

Korvaag schreef op maandag 10 november 2025 @ 13:04:
Een beetje een gekke vraag voor in dit topic, maar ik ga het toch proberen. Wat zijn fijne apps voor het kunnen zien van de energieprijzen voor op een iPhone. Het is hierbij even niet belangrijk dat het een API heeft, maar ik wil graag op de telefoon een makkelijk snel overzicht van de prijzen zodat ik dit in de gaten kan houden. Ik heb nu "EnergyPricing" maar die geeft maar 1 dag weer. Ik heb er een paar geprobeerd maar nog niets handigs kunnen ontdekken. Voor veel apps moet je klant zijn. Dat wil ik juist niet. Ik zoek iets universeels waarbij de exacte prijzen niet van belang zijn maar het verloop van de prijzen wel.

Iemand suggesties?

Als je al Home Assistant hebt kun je Nordpool integratie installeren via HACS, die geeft de huidige en de volgende dag weer.

[Korvaag]

Acidrain schreef op maandag 10 november 2025 @ 13:19:
[...]

Als je al Home Assistant hebt kun je Nordpool integratie installeren via HACS, die geeft de huidige en de volgende dag weer.

Die heb ik, maar ik wil een makkelijke app op m'n telefoon en niet telkens een VPN starten om bij m'n HA te komen. Die HA is voor de automation. Ik wil op m'n telefoon een app waarmee ik snel een overzicht heb, bij voorkeur met een widget.

[ Voor 3% gewijzigd door Korvaag op 10-11-2025 13:33 ]

[Acidrain]

Ik denk dat je je vraag beter kan stellen in 1 van de energie topics dan. Hier gaat het eigenlijk specifiek over Zendure icm HA.

[denneappel]

Korvaag schreef op maandag 10 november 2025 @ 13:32:
[...]


Die heb ik, maar ik wil een makkelijke app op m'n telefoon en niet telkens een VPN starten om bij m'n HA te komen. Die HA is voor de automation. Ik wil op m'n telefoon een app waarmee ik snel een overzicht heb, bij voorkeur met een widget.

Of overweeg het Opensource project eens te steunen en maak gebruik van de nabu.casa proxy. Die 70 euro per jaar vind ik een goede deal als je het gebruikt om onder andere je thuisbatterij aan te sturen.

[Korvaag]

denneappel schreef op maandag 10 november 2025 @ 15:11:
[...]


Of overweeg het Opensource project eens te steunen en maak gebruik van de nabu.casa proxy. Die 70 euro per jaar vind ik een goede deal als je het gebruikt om onder andere je thuisbatterij aan te sturen.

Bedankt voor de suggestie, maar ik heb geen behoefte aan cloud access van HA vanuit principeoverwegingen. Ik wil het juist expliciet niet ontsloten hebben via Cloud

Edit: mocht iemand nog suggesties hebben. Ik heb inmiddels hier gepost (algemeen topic day ahead en dynamische prijzen):
Korvaag in "Het grote day ahead / dynamische energieprijzen topic."

[ Voor 17% gewijzigd door Korvaag op 10-11-2025 17:21 ]

[Sander]

Korvaag schreef op maandag 10 november 2025 @ 13:32:
[...]


Die heb ik, maar ik wil een makkelijke app op m'n telefoon en niet telkens een VPN starten om bij m'n HA te komen. Die HA is voor de automation. Ik wil op m'n telefoon een app waarmee ik snel een overzicht heb, bij voorkeur met een widget.

Mijn iPhone verbind automatisch met VPN als ie niet op thuis wifi zit en pakt alleen bepaalde routes (lees home assistant etc) via die VPN tenzij ik dat zelf aanpas. Werkt super soepel en veilig ongeacht waar ik ben

[Korvaag]

Sander schreef op dinsdag 11 november 2025 @ 21:38:
[...]


Mijn iPhone verbind automatisch met VPN als ie niet op thuis wifi zit en pakt alleen bepaalde routes (lees home assistant etc) via die VPN tenzij ik dat zelf aanpas. Werkt super soepel en veilig ongeacht waar ik ben

Goed punt. Dat in ieder geval ook ingesteld. Ik ga overigens verder met de app EnergyPricing na een flinke update. Stuk overzichtelijker dan HA om snel even de prijs te checken.

[Tijgerkracht]

Korvaag schreef op woensdag 12 november 2025 @ 05:51:
[...]


Goed punt. Dat in ieder geval ook ingesteld. Ik ga overigens verder met de app EnergyPricing na een flinke update. Stuk overzichtelijker dan HA om snel even de prijs te checken.

Wat biedt EnergyPricing meer dan de Zonneplan app?

[Korvaag]

Tijgerkracht schreef op woensdag 12 november 2025 @ 11:19:
[...]


Wat biedt EnergyPricing meer dan de Zonneplan app?

Inzicht zonder aan een leverancier gebonden te zijn. Gemaakt door een Tweaker trouwens zag ik gisteren:
Korvaag in "(ios) App gebouwd voor dynamische energie tarieven widgets"

Goed hij weigert ook na aanpassing van de URL naar de top van dat topic te gaan maar je snapt de verwijzing hoop ik wel

[ Voor 65% gewijzigd door Korvaag op 12-11-2025 12:54 ]

[fabudop]

Sinds een paar weken heb ik een SF2400AC met 2xAB3000X. Over een tijdje verhuizen ze naar de garage op aparte groep, maar nu staat ie binnen in een gewoon stopcontact geprikt.

Ik wil daarom de laad/ontlaad vermogens beperken tot 800W ontladen (veiligheid) en 1200W laden (2400W is wat veel voor 2 batterijen, ben van plan er later nog 2 bij te kopen). Dat gaat via de Zendure App natuurlijk prima. Veiligheidsinstellingen goed zetten en klaar.

Maar, ik ben begonnen te spelen met HA en de Gielz oplossing. Heb het nu prima draaiend met een P1 USB kabel naar raspberry Pi5 en DSMR smart meter integratie. (wel de Gielz versie van december, de versie ervoor deed het niet). Met Nordpool en mijn eigen automation die Gielz weer aanstuurt ziet het er vandaag zo uit:


Erg leuk!

Ik liep wel tegen een probleempje aan, vandaar deze post. De eerste keer dat ik Gielz aanzette ging hij doodleuk met 2400W laden/ontladen. Ondanks de veiligheidsinstellingen van de batterij zelf. Kennelijk zit die beperking niet in de batterij maar in de Zendure App gebakken? En wordt die met de RestAPI omzeilt?

Ik heb nu in de automation van Gielz op heel veel (10 of meer?) plekken de "cap=2400" vervangen door "cap=800". (of 1200). Dat werkt, maar is niet erg onderhoudsvriendelijk. Bij elke update moet ik weer al die waardes vervangen.

Bovendien lijkt het mij voor de veiligheid beter als HA zich standaard aan de veiligheidsinstellingen houd.

Dus een vraagje aan @gielz : kan dit op een elegantere manier opgelost worden? Zijn die grenswaardes uit te lezen uit de batterij? Ik zie ze nergens als entiteiten staan verder.

[gielz]

fabudop schreef op woensdag 12 november 2025 @ 21:28:
Sinds een paar weken heb ik een SF2400AC met 2xAB3000X. Over een tijdje verhuizen ze naar de garage op aparte groep, maar nu staat ie binnen in een gewoon stopcontact geprikt.

Ik wil daarom de laad/ontlaad vermogens beperken tot 800W ontladen (veiligheid) en 1200W laden (2400W is wat veel voor 2 batterijen, ben van plan er later nog 2 bij te kopen). Dat gaat via de Zendure App natuurlijk prima. Veiligheidsinstellingen goed zetten en klaar.

Maar, ik ben begonnen te spelen met HA en de Gielz oplossing. Heb het nu prima draaiend met een P1 USB kabel naar raspberry Pi5 en DSMR smart meter integratie. (wel de Gielz versie van december, de versie ervoor deed het niet). Met Nordpool en mijn eigen automation die Gielz weer aanstuurt ziet het er vandaag zo uit:

[Afbeelding]
Erg leuk!

Ik liep wel tegen een probleempje aan, vandaar deze post. De eerste keer dat ik Gielz aanzette ging hij doodleuk met 2400W laden/ontladen. Ondanks de veiligheidsinstellingen van de batterij zelf. Kennelijk zit die beperking niet in de batterij maar in de Zendure App gebakken? En wordt die met de RestAPI omzeilt?

Ik heb nu in de automation van Gielz op heel veel (10 of meer?) plekken de "cap=2400" vervangen door "cap=800". (of 1200). Dat werkt, maar is niet erg onderhoudsvriendelijk. Bij elke update moet ik weer al die waardes vervangen.

Bovendien lijkt het mij voor de veiligheid beter als HA zich standaard aan de veiligheidsinstellingen houd.

Dus een vraagje aan @gielz : kan dit op een elegantere manier opgelost worden? Zijn die grenswaardes uit te lezen uit de batterij? Ik zie ze nergens als entiteiten staan verder.

Je stelt de waardes bij het installeren van de batterij eenmalig hard in via de app. Dit zit dus niet in de app maar op de api van de batterij zelf via "chargeMaxLimit":2400 en "inverseMaxPower":2400

Bewust heb ik dit niet in de automatisering zelf opgenomen als instelbaar omdat het veiliger is om dit niet aan HA over te laten maar aan de batterij zelf. Vandaar dus 2400 (zou ik ook niet aanpassen) in de automatisering waarbij hij hanteert wat je zelf hebt geconfigureerd.

Wat zegt http://<IP>/properties/report ? Dan kun je exact zien wat je hebt ingesteld toen hij uit de doos kwam.

[fabudop]

gielz schreef op woensdag 12 november 2025 @ 22:06:
[...]

Wat zegt http://<IP>/properties/report ? Dan kun je exact zien wat je hebt ingesteld toen hij uit de doos kwam.

Inderdaad staat daar "inverseMaxPower":800 en chargeMaxLimit":2400. Bedankt, dat maakt het weer duidelijker.

Dus eigenlijk moet ik die chargeMaxLimit naar 1200 zetten, maar kan dat niet via de App. Misschien laat ik het maar even zo, maar hoe zou je dat kunnen doen?

[gielz]

fabudop schreef op woensdag 12 november 2025 @ 23:05:
[...]


Inderdaad staat daar "inverseMaxPower":800 en chargeMaxLimit":2400. Bedankt, dat maakt het weer duidelijker.

Dus eigenlijk moet ik die chargeMaxLimit naar 1200 zetten, maar kan dat niet via de App. Misschien laat ik het maar even zo, maar hoe zou je dat kunnen doen?

Het zit in de app alleen weet ik niet exact waar want ik gebruik deze niet maar je kunt ook een opdracht sturen naar de API; gielz in "Zendure producten in Home Assistant integreren deel 2"

[mcurlym]

Ik liep hier ook tegen aan en hebt het opgelost zodat ik het vanuit de Gielz app kan instellen.
Ik heb volgende input bijgemaakt:

code:

zendure_2400_ac_handmatig_oplaad_vermogen:
  name: Zendure 2400 AC Handmatig Oplaad Vermogen
  min: 0
  max: 2400
  step: 1
  mode: box
  unit_of_measurement: "W"

en volgende regel aangepast in de rest_commands:

code:

zendure_snel_laden:
  url: http://{{ states('input_text.zendure_2400_ac_ip_adres') }}/properties/write
  method: POST
  payload: '{"sn":"{{sn}}","properties":{"acMode": 1, "inputLimit": {{states("input_number.zendure_2400_ac_handmatig_oplaad_vermogen")}} }}'

Aanvulling: net gekeken, mijn chargeMaxLimit staat op 2400. Maar door handmatig de inputLimit in te stellen kan ik kijken wat ik fijn vind om de batterij te laden.

[ Voor 11% gewijzigd door mcurlym op 12-11-2025 23:46 ]

[gielz]

mcurlym schreef op woensdag 12 november 2025 @ 23:41:
Ik liep hier ook tegen aan en hebt het opgelost zodat ik het vanuit de Gielz app kan instellen.
Ik heb volgende input bijgemaakt:

code:

zendure_2400_ac_handmatig_oplaad_vermogen:
  name: Zendure 2400 AC Handmatig Oplaad Vermogen
  min: 0
  max: 2400
  step: 1
  mode: box
  unit_of_measurement: "W"

en volgende regel aangepast in de rest_commands:

code:

zendure_snel_laden:
  url: http://{{ states('input_text.zendure_2400_ac_ip_adres') }}/properties/write
  method: POST
  payload: '{"sn":"{{sn}}","properties":{"acMode": 1, "inputLimit": {{states("input_number.zendure_2400_ac_handmatig_oplaad_vermogen")}} }}'

Aanvulling: net gekeken, mijn chargeMaxLimit staat op 2400. Maar door handmatig de inputLimit in te stellen kan ik kijken wat ik fijn vind om de batterij te laden.

Bovenstaande is niet nodig. Dit heet modus Handmatig.



Via input_number.zendure_2400_ac_handmatig_vermogen kun je zelf aangeven wat de batterij doet.

[ Voor 7% gewijzigd door gielz op 13-11-2025 07:59 ]

[mtimmerm]

Hallo,
Heeft iemand het werkend dat de prijzen van Nordpool aangepast worden zodat ze gelijk zijn aan Zonneplan. Ik heb deze template in de GUI ingevoerd:

{{ (current_price + (states('input_number.nordpool_additionele_kosten') | float)) * 1.21}}

Waar bij de input_number de waarde : 0.11807 heeft. Echter nordpool komt met 15 minuten prijzen en Zonneplan heeft uur prijzen. En dat komt niet mooi uit

Iemand een goed werkende oplossing? Alvast bedankt!

[mcurlym]

gielz schreef op donderdag 13 november 2025 @ 07:32:
[...]


Bovenstaande is niet nodig. Dit heet modus Handmatig.

[Afbeelding]

Via input_number.zendure_2400_ac_handmatig_vermogen kun je zelf aangeven wat de batterij doet.

Klopt, maar het Handmatig vermogen wordt niet gerespecteerd als je Dynamisch NOM runt. Bij Dynamisch NOM neemt je app 'snelladen' op het moment dat hij mag laden, en daar heb je het vermogen ingesteld op 2400 in de rest_commands. Met mijn aanpassing kan je dat vermogen ook handmatig begrenzen voor Dynamisch NOM.

[fabudop]

@mcurlym, volgens mij zijn die inputLimit en outputLimit gewoon de actueel gevraagde vermogens van de batterij. Het zijn geen limits, die naam is erg verwarrend. Gielz gebruikt ze ook in de configuration.yaml om de batterij aan te sturen.

Als ik http://<IP>/properties/report in mijn browser tik, zie ik staan (naast een hoop andere parameters):
"inputLimit":0,"outputLimit":391
en inderdaad was mijn batterij op dat moment 391W aan het leveren.

De echt limieten heten
"inverseMaxPower":800, "chargeMaxLimit":2400
Die kan je vast ook met een rest command wijzigen. Heb ik nog niet geprobeerd.

Enige wat ik me nu dan nog afvraag wat deze dan betekenen:
"packInputPower":390,
"outputPackPower":0,
"outputHomePower":390,
"gridInputPower":0,
Degene die die namen heeft bedacht had iets teveel biertjes op geloof ik....

[Taro]

mtimmerm schreef op donderdag 13 november 2025 @ 16:25:
Hallo,
Heeft iemand het werkend dat de prijzen van Nordpool aangepast worden zodat ze gelijk zijn aan Zonneplan. Ik heb deze template in de GUI ingevoerd:

{{ (current_price + (states('input_number.nordpool_additionele_kosten') | float)) * 1.21}}

Waar bij de input_number de waarde : 0.11807 heeft. Echter nordpool komt met 15 minuten prijzen en Zonneplan heeft uur prijzen. En dat komt niet mooi uit

Iemand een goed werkende oplossing? Alvast bedankt!

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.

[mcurlym]

@fabudop yes, en als je wil laden zet je idd de inputLimit op X en dan laadt hij ook met X vermogen