Zendure producten in Home Assistant integreren deel 2

[dennisdew16]

martinvdm schreef op zaterdag 25 oktober 2025 @ 17:55:
[...]

Mooie apex is dit voor inzicht, zeker met de goedkoopste en dure uren op de achtergrond, wil je wellicht de code hiervan delen?

Is al even beschikbaar, denk dat de topic start inmiddels wel is aangepast met deze code inbegrepen.

[gielz]

martinvdm schreef op zaterdag 25 oktober 2025 @ 17:55:
[...]

Mooie apex is dit voor inzicht, zeker met de goedkoopste en dure uren op de achtergrond, wil je wellicht de code hiervan delen?

Zit standaard in zenSDK (Gielz) verwerkt; https://github.com/Gielz1986/Zendure-HA-zenSDK
Of de losse versie is hier beschikbaar voor alleen het dynamische gedeelte; https://github.com/Gielz1986/Dynamisch-HA

[Taro]

Bikkelreal schreef op zaterdag 25 oktober 2025 @ 17:15:
Is het iemand opgevallen van de intregatie cheapest-energy-hours niet meer werkt met nordpool.

Nordpool heeft bij me de nieuwe prijzen geladen van morgen en alle templates met Cheapest_energy staan op Unavailble.

Terwijl alles binnen komt in Nordpool, is er hier iets veranderd?
Al meer mensen hbeben dit probleem zo te zien:)

v7.0.2 Latest
🐛 BUG FIXES

In v6.0.4 a check was introduced to make sure the prices for today use the same time period as the data for tomorrow. However, this check is now causing issues with the move from daylight savings time to normal time. Therefore I temporarily removed this check as a hotfix, I will make a proper fix after the weekend.

Viel mij al op dat ie vanavond niet automatisch duur ging ontladen en vond de Tracering al vreemd gedrag vertonen. Nu naar 7.0.2 gegaan, benieuwd.

[jordyc]

Bij mij heeft 7.0.2 niks gedaan. Ik krijg nog steeds error meldingen op al mijn cheapest hours berekeningen. Had gehoopt dat die vanacht wel op zouden lossen, maar helaas. Ik las wel dat de maker hier structureel iets voor ging maken.

[Devke]

jordyc schreef op zondag 26 oktober 2025 @ 08:02:
Bij mij heeft 7.0.2 niks gedaan. Ik krijg nog steeds error meldingen op al mijn cheapest hours berekeningen. Had gehoopt dat die vanacht wel op zouden lossen, maar helaas. Ik las wel dat de maker hier structureel iets voor ging maken.

Gebruik de oplossing van @gielz hier. Werkt perfect.

[Taro]

Devke schreef op zondag 26 oktober 2025 @ 09:32:
[...]

Gebruik de oplossing van @gielz hier. Werkt perfect.

Maar met die oplossing kan je niet je laadpaal bedienen of andere apparaten schakelen, dus Cheapest Hours moet gewoon goed met Nord Pool werken.

[gielz]

Taro schreef op zondag 26 oktober 2025 @ 10:52:
[...]

Maar met die oplossing kan je niet je laadpaal bedienen of andere apparaten schakelen, dus Cheapest Hours moet gewoon goed met Nord Pool werken.

Je kunt toch met mijn oplossing makkelijk een laadpaal bedienen? Goedkoop = JA = Laden

Zie dat er inmiddels ook een update is voor Cheapest Hours

[Taro]

gielz schreef op zondag 26 oktober 2025 @ 11:13:
[...]


Je kunt toch met mijn oplossing makkelijk een laadpaal bedienen? Goedkoop = JA = Laden

Zie dat er inmiddels ook een update is voor Cheapest Hours

Het gaat er hier in huis iets complexer aan toe.

Idd 7.0.3 uit, benieuwd.

[martinvdm]

@gielz ik ben een beetje aan het overstappen op jou ZendSDK (weekend bezigheid )
Ik begrijp echter niet heel goed de werking van Dynamisch NOM en dan met name de spread.
Je kunt een dynamisch_minimale_spread ingeven en ook een switch zetten dynamisch_recent_geladen. Kun je wellicht iets meer duiding geven wat het doet ?

[gielz]

martinvdm schreef op zondag 26 oktober 2025 @ 11:21:
@gielz ik ben een beetje aan het overstappen op jou ZendSDK (weekend bezigheid )
Ik begrijp echter niet heel goed de werking van Dynamisch NOM en dan met name de spread.
Je kunt een dynamisch_minimale_spread ingeven en ook een switch zetten dynamisch_recent_geladen. Kun je wellicht iets meer duiding geven wat het doet ?

Ik zal de readme wel iets verbeteren voor deze modus. Maar hij werkt als volgt in de praktijk;

Je geeft aan hoeveel uren je extra goedkoop wilt opladen. In de praktijk als je niet handelt pak je bijvoorbeeld 4 uur goedkoop laden en 20 uur duur mee berekenen. Hier komt vervolgens een Dynamisch Spread Indicatie NOM uit in %en. Je geeft aan in de minimale spread wat jij wenselijk vind voor goedkoop laden. Vervolgens gaat alles automatisch en hoef je hier niet meer naar te kijken. Elke dag voert hij dit programma uit.

Het Dynamisch Recent Geladen vinkje is specifiek om te voorkomen dat er mensen zijn die zeggen 10uur goedkoop opladen met een batterij van 2,88kwh. Dat zal dus niet lekker gaan lopen waardoor je constant krijgt dat hij bij 99% SOC weer gaat bijladen. In de automatisering gaat hij zelf aan de slag met dit vinkje om ervoor te zorgen dat hij eerst 10% gaat ontladen alvorens hij weer goedkoop gaat laden.
--------
De basis instelling is wat mij betreft x uren laden tot je batterij weer in de winter op 80% zit (rest is voor de zon) met een minimale spread van 20-25% (ligt aan je RTE). Of je kunt de spread helemaal los laten en gewoon standaard deze op 0% zetten.

[gielz]

zenSDK (Gielz) - bugfix

Dynamisch NOM modus bugfix
Wanneer de batterij goedkoop aan het opladen was en er van modus werd gewijzigd naar bijvoorbeeld Standby of een andere modus dan werd het opladen niet gestopt. Hij zal nu wel stoppen met opladen en indien modus Dynamisch NOM weer geactiveerd word zal hij weer goedkoop gaan opladen indien van toepassing.

Automatisering zal vervangen moeten worden door de meest recente (copy + paste).

Bug gemeld door @Gyrolion

Wijzigingen: https://github.com/Gielz1...e2d8db9018fd21baa7b45a761

[martinvdm]

gielz schreef op zondag 26 oktober 2025 @ 11:38:
[...]


Ik zal de readme wel iets verbeteren voor deze modus. Maar hij werkt als volgt in de praktijk;

Je geeft aan hoeveel uren je extra goedkoop wilt opladen. In de praktijk als je niet handelt pak je bijvoorbeeld 4 uur goedkoop laden en 20 uur duur mee berekenen. Hier komt vervolgens een Dynamisch Spread Indicatie NOM uit in %en. Je geeft aan in de minimale spread wat jij wenselijk vind voor goedkoop laden. Vervolgens gaat alles automatisch en hoef je hier niet meer naar te kijken. Elke dag voert hij dit programma uit.

Het Dynamisch Recent Geladen vinkje is specifiek om te voorkomen dat er mensen zijn die zeggen 10uur goedkoop opladen met een batterij van 2,88kwh. Dat zal dus niet lekker gaan lopen waardoor je constant krijgt dat hij bij 99% SOC weer gaat bijladen. In de automatisering gaat hij zelf aan de slag met dit vinkje om ervoor te zorgen dat hij eerst 10% gaat ontladen alvorens hij weer goedkoop gaat laden.
--------
De basis instelling is wat mij betreft x uren laden tot je batterij weer in de winter op 80% zit (rest is voor de zon) met een minimale spread van 20-25% (ligt aan je RTE). Of je kunt de spread helemaal los laten en gewoon standaard deze op 0% zetten.

top helder!

[martinvdm]

Waar ik in de ZenSDK (Fireson) de mogelijkheid had tot het zetten van een maximaal ontlaad/oplaad vermogen, o.a. middels de FuseGroup is dit in @gielz niet meer mogelijk. Wellicht een tip om een input_number te maken waarin rekening gehouden wordt met een maximaal ingesteld ontlaad en oplaad vermogen. Nu gaat ie namelijk naar 2400w.

[gielz]

martinvdm schreef op zondag 26 oktober 2025 @ 12:24:
Waar ik in de ZenSDK (Fireson) de mogelijkheid had tot het zetten van een maximaal ontlaad/oplaad vermogen, o.a. middels de FuseGroup is dit in @gielz niet meer mogelijk. Wellicht een tip om een input_number te maken waarin rekening gehouden wordt met een maximaal ingesteld ontlaad en oplaad vermogen. Nu gaat ie namelijk naar 2400w.

Je kunt het beste dit direct op de omvormer zelf instellen en niet in een integratie. Dan weet je ook zeker dat hij nooit deze waarde kan overrulen. Dit kan in de app of direct via CMD op de PC;

http://<IP batterij>/properties/report

Deze waarde bepalen je maximum;
"inverseMaxPower":2400
"chargeMaxLimit":2400

Command voor in CDM om de inverseMaxPower op bijvoorbeeld 1200 te zetten;

code:

curl -X POST "http://<IP>/properties/write" -H "Content-Type: application/json" -d "{\"sn\": \"<SERIALNR>\",\"properties\":{\"inverseMaxPower\":1200}}"

[ Voor 24% gewijzigd door gielz op 26-10-2025 12:35 ]

[jordyc]

Taro schreef op zondag 26 oktober 2025 @ 11:17:
[...]

Het gaat er hier in huis iets complexer aan toe.

Idd 7.0.3 uit, benieuwd.

Werkt 7.0.3 bij jou? Ik krijg nog steeds de melding dat de sensor "unavailable" die ik niet helemaal snap. Want in de Nordpool sensor zit wel alle data en de activity kan ik ook niet aan elkaar breien.

[Taro]

jordyc schreef op zondag 26 oktober 2025 @ 13:04:
[...]


Werkt 7.0.3 bij jou? Ik krijg nog steeds de melding dat de sensor "unavailable" die ik niet helemaal snap. Want in de Nordpool sensor zit wel alle data en de activity kan ik ook niet aan elkaar breien.
[Afbeelding]

Nee idd, nog steeds kapot.

[c0mplex1]

7.0.3 werkt hier perfect zonder Nordpool integratie.
Ik gebruik een eigen geschreven integratie die de EnergyZero tarieven opvraagt.

[iwanovich]

gielz schreef op zondag 26 oktober 2025 @ 12:32:
[...]


Je kunt het beste dit direct op de omvormer zelf instellen en niet in een integratie. Dan weet je ook zeker dat hij nooit deze waarde kan overrulen. Dit kan in de app of direct via CMD op de PC;

http://<IP batterij>/properties/report

Deze waarde bepalen je maximum;
"inverseMaxPower":2400
"chargeMaxLimit":2400

Command voor in CDM om de inverseMaxPower op bijvoorbeeld 1200 te zetten;

code:

curl -X POST "http://<IP>/properties/write" -H "Content-Type: application/json" -d "{\"sn\": \"<SERIALNR>\",\"properties\":{\"inverseMaxPower\":1200}}"

Ik had precies hetzelfde als @martinvdm, ik ga de rest-(curl)oplossing van @gielz uitproberen aangezien ik de zendure-app al verwijderd heb. Ik wilde, zonder het apparaat aan internet te koppelen, direct de zensdk(Gielz) gebruiken, maar dat kon helaas niet met de firmware 1.0.1.
Voor het downloaden van de zendure app (140mb) is ook een Google account (android) nodig. Maar het kan nog geen scherm laden zonder verbinding naar de zendure cloud. Ondanks de vele (niet essentieel nodige) rechten die de app het liefst wil hebben en ook al is er een bluetoothverbinding met de omvormer aanwezig. In het kort: tnx @gielz!

[martinvdm]

@gielz ik ben inmiddels over op jou versie en tot nu toe lijkt het goed te gaan. Wat ik echter wel merk is dat de sensor.zendure_2400_ac_modus geen andere modus als Ontladen/Opladen kent. Dit heeft natuurlijk met de onderliggende acMode te maken, echter had de ZenSDK(Fireson) wel een Stand-By modus. Dit bracht een stuk handiger overzicht dat je ook wist dat de batterij in Stand-By was gezet bijv bij minimale of maximale SOC. Heb je hier enig idee van?

[jordyc]

@Taro net bericht van de maker gekregen. Er zit een bug in het gebruik van de "use_hourly" setting. Morgen wordt dit gefixt.

[gielz]

martinvdm schreef op zondag 26 oktober 2025 @ 19:28:
@gielz ik ben inmiddels over op jou versie en tot nu toe lijkt het goed te gaan. Wat ik echter wel merk is dat de sensor.zendure_2400_ac_modus geen andere modus als Ontladen/Opladen kent. Dit heeft natuurlijk met de onderliggende acMode te maken, echter had de ZenSDK(Fireson) wel een Stand-By modus. Dit bracht een stuk handiger overzicht dat je ook wist dat de batterij in Stand-By was gezet bijv bij minimale of maximale SOC. Heb je hier enig idee van?

Zou inderdaad een mooie aanvulling zijn. Ik zet deze op de lijst voor de volgende release dat je dat ook ziet bij deze sensor.

[martinvdm]

gielz schreef op zondag 26 oktober 2025 @ 19:45:
[...]


Zou inderdaad een mooie aanvulling zijn. Ik zet deze op de lijst voor de volgende release dat je dat ook ziet bij deze sensor.

Zou super zijn! Ik weet niet echt hoe men dit in de fireson versie deed, ik dacht dat acMode alleen 1 en 2 kende maar volgens mij is er ook een 0 voor Stand-By. iig werd in de fireson versie ook de sensor aangepast zodat je ook inzicht hebt in de daadwerkelijk huidige stand en kun je dus ook bijv bij minimale soc zien dan die terug op Stand-By gezet is. Dank voor al je effort.

[gielz]

martinvdm schreef op zondag 26 oktober 2025 @ 19:57:
[...]

Zou super zijn! Ik weet niet echt hoe men dit in de fireson versie deed, ik dacht dat acMode alleen 1 en 2 kende maar volgens mij is er ook een 0 voor Stand-By. iig werd in de fireson versie ook de sensor aangepast zodat je ook inzicht hebt in de daadwerkelijk huidige stand en kun je dus ook bijv bij minimale soc zien dan die terug op Stand-By gezet is. Dank voor al je effort.

Komt goed;

[mcurlym]

Ik heb net mijn 2400AC en AB3000X (heb er twee besteld, maar tweede wordt pas later geleverd) in gebruik genomen. De @gielz 'app' in gebruik genomen (de laatste nieuwe versie van github) en ik kan alle sensors zien en veranderen. De 2400AC/batterij lijkt echter niet te reageren op commando's. Wat zie ik over het hoofd?

aanvulling: in de zendure app (HEMS uitgeschakeld), zie ik onder de 2400AC de wattages bij de 'On-grid setting' wel veranderen. Maar de batterij zelf lijkt niets te doen...

[ Voor 21% gewijzigd door mcurlym op 27-10-2025 23:09 ]

[gielz]

mcurlym schreef op maandag 27 oktober 2025 @ 22:58:
Ik heb net mijn 2400AC en AB3000X (heb er twee besteld, maar tweede wordt pas later geleverd) in gebruik genomen. De @gielz 'app' in gebruik genomen (de laatste nieuwe versie van github) en ik kan alle sensors zien en veranderen. De 2400AC/batterij lijkt echter niet te reageren op commando's. Wat zie ik over het hoofd?

Kun je via Ontwikkelhulpmiddelen > Acties > zoeken op Zendure wel alle commandos zien en bijvoorbeeld zendure_snel_laden uitvoeren. Dan zou je deze melding moeten krijgen;

code:

content: >-
  {"timestamp":1761602868,"messageId":161,"error":"SN does not
  match","code":401}
status: 401
headers:
  Content-Type: text/html
  Transfer-Encoding: chunked

[mcurlym]

gielz schreef op maandag 27 oktober 2025 @ 23:08:
[...]


Kun je via Ontwikkelhulpmiddelen > Acties > zoeken op Zendure wel alle commandos zien en bijvoorbeeld zendure_snel_laden uitvoeren. Dan zou je deze melding moeten krijgen;

code:

content: >-
  {"timestamp":1761602868,"messageId":161,"error":"SN does not
  match","code":401}
status: 401
headers:
  Content-Type: text/html
  Transfer-Encoding: chunked

bedankt voor de snelle reactie!
Als ik die actie uitvoer krijg ik: "Client error occurred when calling resource "http://10.0.0.27/properties/write""

[gielz]

mcurlym schreef op maandag 27 oktober 2025 @ 23:10:
[...]


bedankt voor de snelle reactie!
Als ik die actie uitvoer krijg ik: "Client error occurred when calling resource "http://10.0.0.27/properties/write""

Hij geeft aan dat hij de batterij niet kan bereiken op dat ip-adres. Hebben alle sensoren wel een waarde zoals bijvoorbeeld Zendure 2400 AC Signaalsterkte of Zendure 2400 AC Laadpercentage

Je kunt ook dit testen in je browser; http://10.0.0.27/properties/report

[ Voor 7% gewijzigd door gielz op 27-10-2025 23:17 ]

[mcurlym]

ja, gek genoeg wel...


aanvulling:

en op 10.0.0.27/properties/report krijg ik volgend antwoord (sn aangepast):
{"timestamp":1761603758,"messageId":33,"sn":"XXXXXX","version":2,"product":"solarFlow2400AC","properties":{"heatState":0,"packInputPower":0,"outputPackPower":0,"outputHomePower":0,"remainOutTime":59940,"packState":0,"electricLevel":56,"gridInputPower":0,"solarInputPower":0,"solarPower1":0,"solarPower2":0,"solarPower3":0,"solarPower4":0,"solarPower5":0,"solarPower6":0,"pass":0,"reverseState":0,"socStatus":0,"hyperTmp":2941,"gridOffPower":0,"dcStatus":0,"pvStatus":0,"acStatus":0,"dataReady":1,"gridState":1,"BatVolt":4924,"socLimit":0,"writeRsp":0,"acMode":2,"inputLimit":0,"outputLimit":0,"socSet":1000,"minSoc":100,"gridStandard":4,"gridReverse":2,"inverseMaxPower":800,"lampSwitch":1,"gridOffMode":2,"IOTState":2,"fanSwitch":1,"fanSpeed":0,"bindstate":0,"VoltWakeup":0,"OldMode":0,"OTAState":0,"LCNState":0,"factoryModeState":0,"ts":1761603753,"tsZone":13,"smartMode":0,"chargeMaxLimit":2400,"phaseSwitch":1,"packNum":1,"rssi":-55,"is_error":0},"packData":[{"sn":"XXXXX","packType":5,"socLevel":56,"state":0,"power":0,"maxTemp":2931,"totalVol":4910,"batcur":0,"maxVol":327,"minVol":327,"softVersion":4106,"heatState":0}]}

[ Voor 63% gewijzigd door mcurlym op 27-10-2025 23:24 ]

[gielz]

mcurlym schreef op maandag 27 oktober 2025 @ 23:20:
ja, gek genoeg wel...
[Afbeelding]

Je moet toch een keer de eerste zijn in iets heb dit nog nooit eerder gezien dat je wel informatie kan ophalen maar niet kan posten. Wellicht toch iets vreemds in het netwerk. Zou iig de batterij gewoon even herstarten.

[mcurlym]

yes! Ik dacht dat ik dat al een keer gedaan had, maar blijkbaar niet dus. Nu doet ie het wel en gaat hij richting de NOM. Bedankt voor de snelle interventie

[Polvo176]

Ik heb HA nu draaien op een Pi 4 met de Zendure integratie.
Het is de bedoeling dat ik alleen de gegevens uitlees op een dashboard zonder dat HA de zendures gaat besturen.
Dat blijkt wel te gebeuren, maar kennelijk alleen met de Hypers, niet met de SF800Pro.
Is dat ergens een instelling?

[martinvdm]

Polvo176 schreef op dinsdag 28 oktober 2025 @ 13:18:
Ik heb HA nu draaien op een Pi 4 met de Zendure integratie.
Het is de bedoeling dat ik alleen de gegevens uitlees op een dashboard zonder dat HA de zendures gaat besturen.
Dat blijkt wel te gebeuren, maar kennelijk alleen met de Hypers, niet met de SF800Pro.
Is dat ergens een instelling?

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

[remcoXP]

@gielz Zou je aub ook je mooie dashboard code willen delen of op je github willen zetten?

[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.