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.

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