Zendure producten in Home Assistant integreren deel 2

[Mscroos]

Henkoes schreef op vrijdag 29 mei 2026 @ 10:16:
Is het ook mogelijk om 4 of 5 torens te gebruik met de gast777 proxy? Extra vermogen zou super welkom zijn.

Nee, max 3.

[Henkoes]

Mscroos schreef op vrijdag 29 mei 2026 @ 11:17:
[...]

Nee, max 3.

maar waarom 3 als HEM 6 aan kan?

[Lange_Slurf]

Hippe Lip schreef op vrijdag 29 mei 2026 @ 11:14:
[...]

Ah, ik dacht dat ik de enige was. Dank je voor deze post.
Ik los het op door even naar een ander tabblad van de Gielz te gaan en weer teug. Dan staat de hele dag erop.

Maar het ligt dus niet aan mij of mijn telefoon of HA.

Ik heb het op mijn iPhone. En jij, @Lange_Slurf ?

Hier is het in Edge, maar ook op mn iPad (ook Edge) heb ik dit.

[ZuinigeRijder]

Mscroos schreef op donderdag 28 mei 2026 @ 23:27:
[...]

Ik heb net met de debug tool van @gast777 kunnen registreren wat er gebeurd als de accu niet meer reageert. Er werden gewoon POST opdrachten gestuurd en GET ontvangen van alle drie mijn systemen. De output bleef op 0 staan. Doordat de accu met de hoogste capaciteit aan de beurt was om te ontladen bleef de node-red daar de opdrachten naartoe sturen. Als jullie er iets aan hebben kan ik deze wel via DM sturen. Wellicht is er iets van een auto reset mogelijk in de toekomst?

Ik heb ook zo een probleem met één van de twee Solarflow 800 Plus batterijen. Het is al tweemaal voorgekomen dat die ene niet uit de Standby uit Flash (nog niet gezien bij Standby uit RAM) kwam, de andere wel. Het is ook eenmaal voorgekomen dat beide niet uit standby kwamen.

De stroom eraf en er weer op hielp niet. Moest echt de stroom eraf, batterij helemaal uitzetten (6 seconden power knop indrukken) en weer stroom erop. Daarna ging deze vanzelf laden. Vóór het uitzetten gaf het display van de omvormer gewoon aan dat er uitstekende Wifi was. Dit is ook de batterij die bij minder dan 70 Watt (35 Watt per SF800+) niet deed terugleveren.

Ik kan deze ook laten omruilen...

Liebe Kundin, lieber Kunde,
wir haben Ihre neueste Nachricht erhalten.
Sie können versuchen, das betroffene Gerät neu zu starten und anschließend den Betrieb für eine gewisse Zeit weiter zu beobachten. Sollte das Gerät weiterhin nicht die erwartete Leistung erreichen, können Sie uns gerne erneut kontaktieren, damit wir einen Austausch im Rahmen des Kundendienstes für Sie veranlassen können. Wir entschuldigen uns für die entstandenen Unannehmlichkeiten und danken Ihnen für Ihr Verständnis.
Mit freundlichen Grüßen
Zendure Team

Kijk het nog even aan, maar als het vaker gebeurt........

[TBird484]

Henkoes schreef op vrijdag 29 mei 2026 @ 10:16:
Is het ook mogelijk om 4 of 5 torens te gebruik met de gast777 proxy? Extra vermogen zou super welkom zijn.

Als je meer dan 3 van een bepaalde serie nodig hebt, dan heb je zeer waarschijnlijk niet het juiste product gekocht. Als extra vermogen je usecase is, dan kan je veel beter kijken naar de Solarflow 4000 Mix in combinatie met de Zendure Powerhub.

[RemmyB83]

ZuinigeRijder schreef op vrijdag 29 mei 2026 @ 12:42:
[...]


Ik heb ook zo een probleem met één van de twee Solarflow 800 Plus batterijen. Het is al tweemaal voorgekomen dat die ene niet uit de Standby uit Flash (nog niet gezien bij Standby uit RAM) kwam, de andere wel. Het is ook eenmaal voorgekomen dat beide niet uit standby kwamen.

De stroom eraf en er weer op hielp niet. Moest echt de stroom eraf, batterij helemaal uitzetten (6 seconden power knop indrukken) en weer stroom erop. Daarna ging deze vanzelf laden. Vóór het uitzetten gaf het display van de omvormer gewoon aan dat er uitstekende Wifi was. Dit is ook de batterij die bij minder dan 70 Watt (35 Watt per SF800+) niet deed terugleveren.

Ik kan deze ook laten omruilen...

[...]


Kijk het nog even aan, maar als het vaker gebeurt........

Ik had vanochtend ook een freeze met 1 van de 3 sf800 plus. Opdracht werdt wel verzonden maar niet uitgevoert. Ik heb via fireson even de batterij opgezocht en handmatig het schuifje voor opladen op 250W gezet. Daar reageerde hij direct op maar het duurde even voor hij weer reageerde op de proxy.

Ik heb nu wel als test het internet voor de cloud geblokkeerd van de accu's.

[Henkoes]

TBird484 schreef op vrijdag 29 mei 2026 @ 14:18:
[...]

Als je meer dan 3 van een bepaalde serie nodig hebt, dan heb je zeer waarschijnlijk niet het juiste product gekocht. Als extra vermogen je usecase is, dan kan je veel beter kijken naar de Solarflow 4000 Mix in combinatie met de Zendure Powerhub.

Die bestond op moment van aanschaf dus niet.. dus ik werk met de huidige situatie

[Henkoes]

@gast777 zou eventueel een 4e en 5e toren supported kunnen worden?

[RobTesla]

Ik heb hier al dingen zien passeren over zendures die niet bereikbaar zijn of niet reageren op commando's (ZenSDK). Ik heb vandaag eens mijn beide Zendure torens (2400AC) afgesneden van het internet. Ik bedoel: m'n firewall ingesteld dat deze niet naar het internet toe kunnen gaan. Ik heb nu voor de eerste keer gezien dat 1 van de twee eventjes niet reageerde op commando's. En ik heb ze al enkele maanden staan zonder voorgaande problemen. Zou het kunnen dat de Zendures effe echt het noorden kwijt zijn als ze geen "phone home" kunnen doen? Ze proberen misschien de Zendure-cloud te bereiken maar wachten op response en in die periode zijn ze dan even niet te besturen vanop het LAN...?

Oh: en bevestigd dat ze 'offline' zijn in de Zendure app na de firewall-aanpassing en ze even van de WiFi te kicken zodat ze opnieuw moesten verbinden.

[ Voor 10% gewijzigd door RobTesla op 29-05-2026 15:41 ]

[Mscroos]

RobTesla schreef op vrijdag 29 mei 2026 @ 15:36:
Ik heb hier al dingen zien passeren over zendures die niet bereikbaar zijn of niet reageren op commando's (ZenSDK). Ik heb vandaag eens mijn beide Zendure torens (2400AC) afgesneden van het internet. Ik bedoel: m'n firewall ingesteld dat deze niet naar het internet toe kunnen gaan.

Heb ze vooralsnog gewoon helemaal open staan, met good/excellent verbindingen. dus lijkt mij bij mij niet het geval.

[RobTesla]

Mscroos schreef op vrijdag 29 mei 2026 @ 15:47:
[...]

Heb ze vooralsnog gewoon helemaal open staan, met good/excellent verbindingen. dus lijkt mij bij mij niet het geval.

Het gaat inderdaad over al dan niet de toegang naar het internet afzetten. Ik merk het nu inderdaad af en toe bij beide Zendures dat ze geen response geven op http-calls voor een 30-tal seconden. Ik ga de firewall block nog eens weghalen om te zien of het inderdaad dat is. (Ik vermoed van wel, want ik heb dit gedrag in de maanden ervoor nog nooit gezien)

[noo]

RobTesla schreef op vrijdag 29 mei 2026 @ 16:05:
[...]

Het gaat inderdaad over al dan niet de toegang naar het internet afzetten. Ik merk het nu inderdaad af en toe bij beide Zendures dat ze geen response geven op http-calls voor een 30-tal seconden. Ik ga de firewall block nog eens weghalen om te zien of het inderdaad dat is. (Ik vermoed van wel, want ik heb dit gedrag in de maanden ervoor nog nooit gezien)

Een tijdje geleden werd hier gepost dat alleen DNS requests toestaan en de rest verbieden dit zou verhelpen.

[RobTesla]

noo schreef op vrijdag 29 mei 2026 @ 16:07:
[...]

Een tijdje geleden werd hier gepost dat alleen DNS requests toestaan en de rest verbieden dit zou verhelpen.

Och, daar moet ik over gelezen hebben, volg het hier nochtans ook wel regelmatig op. Dan zal ik enkel de DNS requests eens toelaten, de rest blocken.

[Theetjuh]

Ik heb daar ook last van, iedere 12 minuten verbreekt de verbinding even.
Zal er ook eens naar kijken, het viel me ook al op de afgelopen dagen dat ik de 2400+ in bezit heb.

[ Voor 17% gewijzigd door Theetjuh op 29-05-2026 17:09 ]

[RobTesla]

noo schreef op vrijdag 29 mei 2026 @ 16:07:
[...]

Een tijdje geleden werd hier gepost dat alleen DNS requests toestaan en de rest verbieden dit zou verhelpen.

Getest en negatief... Ook bij enkel DNS toelaten en de rest blocken kreeg ik bij beide Zendures af en toe timeouts.

[Hippe Lip]

Voor degenen met een Zappi laadpaal voor hun EV schreef ik een stukje in het Ervaringen met MyEnergi topic over zo goedkoop mogelijk laden. Daarbij maakt ik gebruik van een andere integratie van @gielz, de Dynamisch-HA.
Fijn dat je die ook in stand houdt en onderhoudt, Gielz!

[zagreus]

RobTesla schreef op vrijdag 29 mei 2026 @ 18:05:
[...]

Getest en negatief... Ook bij enkel DNS toelaten en de rest blocken kreeg ik bij beide Zendures af en toe timeouts.

Hier hetzelfde: verschillende protocollen en poorten apart geblokt, het lijkt mis te gaan bij blocken van mqtt (8883). De rest leek geen problemen op te leveren.

[ctrl-tab]

zagreus schreef op vrijdag 29 mei 2026 @ 20:33:
[...]

Hier hetzelfde: verschillende protocollen en poorten apart geblokt, het lijkt mis te gaan bij blocken van mqtt (8883). De rest leek geen problemen op te leveren.

Misschien eens testen of je er geen mqtt tussen kan zetten door de dns naar je eigen broker te wijzen

Of misschien is simpelweg een tcp verbinding genoeg om hem niet te laten blokkeren.

[ Voor 10% gewijzigd door ctrl-tab op 29-05-2026 21:32 ]

[gielz]

Hier staat ook nog een stukje over het blokkeren van de connectie; https://github.com/Zendure/zenSDK/issue/46

[Hippe Lip]

Heeft iemand al eens aan Zendure gevraagd waarom je die foutmeldingen krijgt als de Zendure geen toegang heeft tot het openbare internet?
@Taro misschien?

[ Voor 6% gewijzigd door Hippe Lip op 29-05-2026 21:45 ]

[Taro]

Hippe Lip schreef op vrijdag 29 mei 2026 @ 21:45:
Heeft iemand al eens aan Zendure gevraagd waarom je die foutmeldingen krijgt als de Zendure geen toegang heeft tot het openbare internet?
@Taro misschien?

Nee, nog nooit het internet geblokkeerd voor Zendure.

[Hippe Lip]

Taro schreef op vrijdag 29 mei 2026 @ 21:46:
[...]

Nee, nog nooit het internet geblokkeerd voor Zendure.

Dat was de vraag dan ook niet, @Taro …

[Taro]

Hippe Lip schreef op vrijdag 29 mei 2026 @ 21:47:
[...]

Dat was de vraag dan ook niet, @Taro …

En dus heb ik nog nooit foutmeldingen gekregen die ik vervolgens aan Zendure heb voorgelegd....

Beantwoord dat hem? Ik kan echt niet meer alles bijhouden of volgen, dus graag duidelijke vragen stellen.

[Hippe Lip]

Sorry @Taro, ik was even vergeten dat je al tot over je max vol zit. Dus lama.

Misschien is er iemand anders die het punt van slecht functioneren bij blokkeren van internettoegang aan Zendure heeft voorgelegd?

[Theetjuh]

zagreus schreef op vrijdag 29 mei 2026 @ 20:33:
[...]

Hier hetzelfde: verschillende protocollen en poorten apart geblokt, het lijkt mis te gaan bij blocken van mqtt (8883). De rest leek geen problemen op te leveren.

Met alleen 8883 open werkt het wel en stabiel

[ctrl-tab]

Hippe Lip schreef op vrijdag 29 mei 2026 @ 21:54:
Sorry @Taro, ik was even vergeten dat je al tot over je max vol zit. Dus lama.

Misschien is er iemand anders die het punt van slecht functioneren bij blokkeren van internettoegang aan Zendure heeft voorgelegd?

Ik had me ook voorgenomen dit te gaan doen dus ben even aan het testen gegaan.
- 2400AC 2x
- Heb op dit moment DNS toegestaan, en de rest geblokkeerd, voor 1 van mijn 2 zendures.
- Ondertussen een scriptje draaien dat elke seconde het HTTP endpoint van beide zendures ophaalt.

Allereerst reageert de Zendure client anders op een BLOCK dan op een REJECT.
Bij een block blijft client-side de connectie poging open staan tot deze time-out.
Bij een reject krijgt de client ' connection actively refused '

Bij een Block zie ik nog steeds veel uitgaande calls, meerdere per secode. Bij een REJECT blijft hij het rustigaan proberen, om de 5-10 seconden. Dit laatste lijkt me prima (liever een vinkje in de app, maar goed)

Dus REJECT lijkt in elk geval the way to go.

Helaas zie ik ook bij de REJECT om de 8-ish minuten een 10-15-tal http calls fout gaan. dus 10-15 seconden http endpoint down.

De niet-geblockte zendure gaat vrolijk door.
Nog eens getest met DNS block, maakt geen verschil.

Enige optie om te testen lijkt me dan nog om het adres te spoofen waar hij voor MQTT op verbindt .
mqtteu.zen-iot.com:8883 , met een dns override is dat vrij eenvoudig te doen.
De vraag is of dat goed gaat met authenticatie en evt een cert check die hij lokaal zou doen. Een en ander hangt dus af van wat voor client settings ze gebruiken voor de MQTT verbinding en waar het precies op stuk loopt.

(hij verbindt verbind trouwens ook met https://app.zendure.tech, ws voor regisratie en metadata).

Goed.. met de REJECT wordt de client ijn elk geval ontlast., en eens per 8 minuten 10-15 sec down is niet een mega probleem, alleen is dat wel lastig als je dan net een state change doet (bv start chargen), die mis je dan wel!

Het blijft een drama, chinese firmware... mijn goodwe invertor heeft ook van die brakke IOT formware... moet smorgens even online zijn, anders werkt de lokale modbus koppeling niet (je verzint het niet...)

[ctrl-tab]

ctrl-tab schreef op vrijdag 29 mei 2026 @ 23:27:
[...]

Ik had me ook voorgenomen dit te gaan doen dus ben even aan het testen gegaan.
- 2400AC 2x
- Heb op dit moment DNS toegestaan, en de rest geblokkeerd, voor 1 van mijn 2 zendures.
- Ondertussen een scriptje draaien dat elke seconde het HTTP endpoint van beide zendures ophaalt.

Allereerst reageert de Zendure client anders op een BLOCK dan op een REJECT.
Bij een block blijft client-side de connectie poging open staan tot deze time-out.
Bij een reject krijgt de client ' connection actively refused '

Bij een Block zie ik nog steeds veel uitgaande calls, meerdere per secode. Bij een REJECT blijft hij het rustigaan proberen, om de 5-10 seconden. Dit laatste lijkt me prima (liever een vinkje in de app, maar goed)

Dus REJECT lijkt in elk geval the way to go.

Helaas zie ik ook bij de REJECT om de 8-ish minuten een 10-15-tal http calls fout gaan. dus 10-15 seconden http endpoint down.

De niet-geblockte zendure gaat vrolijk door.
Nog eens getest met DNS block, maakt geen verschil.

Enige optie om te testen lijkt me dan nog om het adres te spoofen waar hij voor MQTT op verbindt .
mqtteu.zen-iot.com:8883 , met een dns override is dat vrij eenvoudig te doen.
De vraag is of dat goed gaat met authenticatie en evt een cert check die hij lokaal zou doen. Een en ander hangt dus af van wat voor client settings ze gebruiken voor de MQTT verbinding en waar het precies op stuk loopt.

(hij verbindt verbind trouwens ook met https://app.zendure.tech, ws voor regisratie en metadata).

Goed.. met de REJECT wordt de client ijn elk geval ontlast., en eens per 8 minuten 10-15 sec down is niet een mega probleem, alleen is dat wel lastig als je dan net een state change doet (bv start chargen), die mis je dan wel!

Het blijft een drama, chinese firmware... mijn goodwe invertor heeft ook van die brakke IOT formware... moet smorgens even online zijn, anders werkt de lokale modbus koppeling niet (je verzint het niet...)

Nog even door getest en een lokaal tcp endpoint op 8883 gestart , en daar mqtteu.zen-iot.com naar toe gewezen.
Ik zie de zendure netjes verbinden, die mqtt client verslikt zich natuurlijk.

Ook nu na een minuut of 8 wat timeouts. Ze komen nu wat meer verspreid binnen nu , maar toch een 10 seconden down ...
Misschien scheelt het nog als er een echte mqtt client luistert die ook daadwerkelijk verkeer ontvangt. Maar of dat lukt hangt af van de configuratie (authenticatie, client certificates etc)

edit:
Nog even doorgepakt. Lokale MQTT broker gedraaid met TLS. Zie de Zendure wel binnen komen maar strand op CA certificate mismatch. Begrijpelijk.
Ook nu, elke 8 minuten een seconde of 10-15 offline.
Ik zie ook elke keer rond dat tijdstip een MDNS query. Ik denk dat die hele stack gewoon reset of crasht en dat dat de timeouts veroorzaakt.

Kwam nog in een vage status terecht waar de ene zendure de andere aan het opladen was. Het lijkt er op dat er wat meer gebeurt dan alleen onbereikbaarheid van de ene Zendure. Goed....

Helaas , geen oplossing voor nu dus.. feature request dan maar! :)

[ Voor 10% gewijzigd door ctrl-tab op 30-05-2026 01:20 ]

[ZuinigeRijder]

ZuinigeRijder schreef op vrijdag 29 mei 2026 @ 12:42:
[...]


Ik heb ook zo een probleem met één van de twee Solarflow 800 Plus batterijen. Het is al tweemaal voorgekomen dat die ene niet uit de Standby uit Flash (nog niet gezien bij Standby uit RAM) kwam, de andere wel. Het is ook eenmaal voorgekomen dat beide niet uit standby kwamen.

De stroom eraf en er weer op hielp niet. Moest echt de stroom eraf, batterij helemaal uitzetten (6 seconden power knop indrukken) en weer stroom erop. Daarna ging deze vanzelf laden. Vóór het uitzetten gaf het display van de omvormer gewoon aan dat er uitstekende Wifi was. Dit is ook de batterij die bij minder dan 70 Watt (35 Watt per SF800+) niet deed terugleveren.

Ik kan deze ook laten omruilen...

[...]


Kijk het nog even aan, maar als het vaker gebeurt........

Hmm, gisteravond was het batterij 2 die niet uit Standby kwam.
Ik heb de "Standby Vertraging" op 30 minuten staan.

@gielz Het verschil in opslagmode Flash of RAM zou 19 Watt uitmaken. Hoe is dit gedetecteerd? De Solarflow 800 Plus heeft geen Offgrid poort. Mijn HW Energy Socket geeft 0 Watt aan, bij beide modes. Of wordt dit vanuit de batterij gevoed? En hoe weet je dan dat dit 19 Watt verbruikt?

Kan ik de Standby vertraging zetten naar meer dan 30 minuten? En wat is het effect dan?

code:

 name: Zendure 2400 AC Standby Vertraging
    icon: mdi:pause
    min: 5
    max: 30
    step: 1zendure_2400_ac_standby_vertraging
    mode: box
    unit_of_measurement: "Min"

Wil wel eens testen wat er gebeurd wanneer de Standby vertraging gezet wordt op meer dan 1 dag. Of is dit geen goed idee?


Maar er wordt volgens mij alleen naar de minuten gekeken in de conditites:

code:

- conditions:
          - condition: trigger
            id:
              - aansturing_trigger
          - condition: state
            entity_id: sensor.zendure_2400_ac_opslagmodus
            state:
              - Opslaan in RAM
          - condition: state
            entity_id: sensor.zendure_2400_ac_modus
            state:
              - Standby
            for:
              minutes: >-
                {{ states('input_number.zendure_2400_ac_standby_vertraging') |
                int(5) }}
          - condition: state
            entity_id: sensor.zendure_2400_ac_kalibreren
            state:
              - Nee
        sequence:
          - action: rest_command.zendure_standby
            data:
              sn: "{{ states('sensor.zendure_2400_ac_serienummer') }}"
          - action: logbook.log
            data:
              message: >-
                💤Na {{states('input_number.zendure_2400_ac_standby_vertraging')
                | int(5) }}                 minuten inactiviteit in standby
                zetten                 (Opslagmodus omzetten naar Flash) —
              entity_id: input_select.zendure_2400_ac_modus_selecteren
              name: " "
        alias: Na xx minuten inactiviteit in standby zetten

Dus meer dan 59 minuten zal deze nooit meer in Standby gaan?

[ Voor 29% gewijzigd door ZuinigeRijder op 30-05-2026 10:31 ]

[gielz]

ZuinigeRijder schreef op zaterdag 30 mei 2026 @ 10:22:
[...]


Hmm, gisteravond was het batterij 2 die niet uit Standby kwam.
Ik heb de "Standby Vertraging" op 30 minuten staan.

@gielz Het verschil in opslagmode Flash of RAM zou 19 Watt uitmaken. Hoe is dit gedetecteerd? De Solarflow 800 Plus heeft geen Offgrid poort. Mijn HW Energy Socket geeft 0 Watt aan, bij beide modes. Of wordt dit vanuit de batterij gevoed? En hoe weet je dan dat dit 19 Watt verbruikt?

Kan ik de Standby vertraging zetten naar meer dan 30 minuten? En wat is het effect dan?

code:

 name: Zendure 2400 AC Standby Vertraging
    icon: mdi:pause
    min: 5
    max: 30
    step: 1zendure_2400_ac_standby_vertraging
    mode: box
    unit_of_measurement: "Min"

Wil wel eens testen wat er gebeurd wanneer de Standby vertraging gezet wordt op meer dan 1 dag. Of is dit geen goed idee?


Maar er wordt volgens mij alleen naar de minuten gekeken in de conditites:

code:

- conditions:
          - condition: trigger
            id:
              - aansturing_trigger
          - condition: state
            entity_id: sensor.zendure_2400_ac_opslagmodus
            state:
              - Opslaan in RAM
          - condition: state
            entity_id: sensor.zendure_2400_ac_modus
            state:
              - Standby
            for:
              minutes: >-
                {{ states('input_number.zendure_2400_ac_standby_vertraging') |
                int(5) }}
          - condition: state
            entity_id: sensor.zendure_2400_ac_kalibreren
            state:
              - Nee
        sequence:
          - action: rest_command.zendure_standby
            data:
              sn: "{{ states('sensor.zendure_2400_ac_serienummer') }}"
          - action: logbook.log
            data:
              message: >-
                💤Na {{states('input_number.zendure_2400_ac_standby_vertraging')
                | int(5) }}                 minuten inactiviteit in standby
                zetten                 (Opslagmodus omzetten naar Flash) —
              entity_id: input_select.zendure_2400_ac_modus_selecteren
              name: " "
        alias: Na xx minuten inactiviteit in standby zetten

Dus meer dan 59 minuten zal deze nooit meer in Standby gaan?

Graag testen inderdaad dit kun je doen door max: 30 aan te passen naar 1440 minuten (1 dag). Hij heeft alleen extra standby gebruik als hij niet op de minimale soc zit en niet op de maximale soc en niets te doen heeft. Via een MID KWH meter zie je dan +/- 20-30 watt verbruik.

[Mistraller]

ctrl-tab schreef op vrijdag 29 mei 2026 @ 23:27:
[...]


Bij een Block zie ik nog steeds veel uitgaande calls, meerdere per secode. Bij een REJECT blijft hij het rustigaan proberen, om de 5-10 seconden. Dit laatste lijkt me prima (liever een vinkje in de app, maar goed)

Zelfs met vinkje gaan de Chinezen nog het net op hoor. Ik had op mijn 3D printer Lan-Only aangevinkt, vervolgens blokkade in de router en mijn printer wilde niet meer starten. Pas nadat ik de toegang had opgeheven starte hij weer. Gek genoeg geen probleem als er gewoon helemaal geen netwerk aanwezig was. Na een firmware patch was het opgelost.
Kortom lan-only vinkje moet je de Chinezen niet op vertrouwen.

[Mistraller]

Even een vraagje; ik ga binnenkort het één en ander aanpassen in mijn meterkast dus mijn P1 kabel naar de raspberry is even buiten gebruik. Als ik de Zendure P1 tijdelijk aansluit, en dan de boel in HEMS gooi, kan ik dan volstaan met Gielz in standby zetten? Of gaat Gielz de hele tijd proberen om de zendures in standby te krijgen.

[TBird484]

Mistraller schreef op zaterdag 30 mei 2026 @ 13:17:
Even een vraagje; ik ga binnenkort het één en ander aanpassen in mijn meterkast dus mijn P1 kabel naar de raspberry is even buiten gebruik. Als ik de Zendure P1 tijdelijk aansluit, en dan de boel in HEMS gooi, kan ik dan volstaan met Gielz in standby zetten? Of gaat Gielz de hele tijd proberen om de zendures in standby te krijgen.

Nee, je moet de automation component disablen. Dan draait Gielz in read only mode.

[RemmyB83]

TBird484 schreef op zaterdag 30 mei 2026 @ 13:28:
[...]

Nee, je moet de automation component disablen. Dan draait Gielz in read only mode.

Als het klopt wat je zegt, zou een 'monitor only' functie, misschien ook handig zijn?
(@gielz )

[jannus66]

RemmyB83 schreef op zaterdag 30 mei 2026 @ 14:04:
[...]

Als het klopt wat je zegt, zou een 'monitor only' functie, misschien ook handig zijn?
(@gielz )

Gewoon even een schuifje verzetten bij ‘automations’ komt toch op hetzelfde neer?

[RemmyB83]

jannus66 schreef op zaterdag 30 mei 2026 @ 14:47:
[...]

Gewoon even een schuifje verzetten bij ‘automations’ komt toch op hetzelfde neer?

Ja, daar heb je helemaal gelijk in.
Alleen niet iedereen heeft zich er helemaal in verdiept, of staat erbij stil als hij standby selecteert. Vandaar de suggestie🤗

Edit: Ik stond er zelf persoonlijk niet bij stil, dat als ik standbymodus zou selecteren, hij continue probeert de accu's in standby modus te zetten. Maar dacht juist dat hij dan alleen zou monitoren(geen aansturing).

[ Voor 22% gewijzigd door RemmyB83 op 30-05-2026 15:02 ]

[ppaulv]

ik zie net iets vreemds. Zie plaatje. Er zijn geen negatieve prijzen maar wel een lange periode exact 'nul'.

Dat is toch raar?

[Pakhaas]

ppaulv schreef op zaterdag 30 mei 2026 @ 15:14:
ik zie net iets vreemds. Zie plaatje. Er zijn geen negatieve prijzen maar wel een lange periode exact 'nul'.

Dat is toch raar?[Afbeelding]

Je hebt de btw en eb niet in de prijs zitten.

[ Voor 28% gewijzigd door Pakhaas op 30-05-2026 15:19 ]

[ppaulv]

dan nog, 6 uur lang exact dezelfde prijs (nul cent plus kosten). Dat is raar imho. Vind je niet?
(dat met die kosten wil me nog niet lukken, heb dat wel ergens vastgelegd maar zie het niet terug)

[ Voor 34% gewijzigd door ppaulv op 30-05-2026 15:23 ]

[R1chardTM]

- deleted -

[ Voor 120% gewijzigd door R1chardTM op 30-05-2026 16:26 ]

[Pakhaas]

ppaulv schreef op zaterdag 30 mei 2026 @ 15:22:
dan nog, 6 uur lang exact dezelfde prijs (nul cent plus kosten). Dat is raar imho. Vind je niet?
(dat met die kosten wil me nog niet lukken, heb dat wel ergens vastgelegd maar zie het niet terug)

Dat zie je nu bijna dagelijks. Ze kunnen de prijs gewoon sturen door wind- en zonneparken af te schakelen. Negatieve prijzen kost hun geld.

[ppaulv]

R1chardTM schreef op zaterdag 30 mei 2026 @ 16:20:
[...]

Nope markt stroomprijzen (dus zinder alle extra koste) zijn vandaag van 11 tot 16 nul euro.

https://www.zonneplan.nl/energie/dynamische-energieprijzen

Handig linkje, heb 'm opgeslagen. Heb het ook op m'n telefoon maar dit gaat sneller.
Maar zo te zien gaat er bij mij iets mis. Ik heb net (alweer) gevonden waar ik de getallen voor BTW, EB en opslag moet invullen (bij de helpers in HA settings), daar staat het allemaal netjes zoals al enkele keren hier voorbij gekomen is (BTW 0.21, EB 0.11 en opslag 0.01653) maar zo te zien wordt dat niet meegenomen in de grafiek (zie m'n vorige post daarover). Nergens foutmeldingen of zo maar toch is wat ik zie niet goed.

[ZuinigeRijder]

gielz schreef op zaterdag 30 mei 2026 @ 10:51:
[...]

Graag testen inderdaad dit kun je doen door max: 30 aan te passen naar 1440 minuten (1 dag). Hij heeft alleen extra standby gebruik als hij niet op de minimale soc zit en niet op de maximale soc en niets te doen heeft. Via een MID KWH meter zie je dan +/- 20-30 watt verbruik.

Dat heb ik gedaan. Beide SF800+ zijn nu al een tijdje 100% (vanaf 14:00 tot nu) bij modus NOM. Bij batterij 1 zie ik "Opslagmodus: opslaan in RAM". Maar bij de Zendure Proxy sensoren zie ik:
Zendure 1 Opslagmodus: Opslaan in RAM
Zendure 2 Opslagmodus: Opslaan in Flash

@gast777 Zou bij beide de opslagmodus hetzelfde moeten zijn (Opslaan in RAM)?

EDIT:
heb even gewisseld van NOM -> Snel ontladen -> NOM. Nu zijn ze beide "Opslaan in RAM". En voor de zekerheid ook een HA reboot gedaan. Even kijken of het nu wel goed blijft......

EDIT2:
Nu is batterij 2 weer Opslaan in Flash

[ Voor 12% gewijzigd door ZuinigeRijder op 30-05-2026 19:45 ]

[thijsh02]

Heeft iemand de Zendure Smart plug pro al werkend in HA? Ik krijg ze niet gevonden en kan ook niet achterhalen op welk protocol ze zitten... heb ze via wifi wel in de Zendure app

[Mistraller]

RemmyB83 schreef op zaterdag 30 mei 2026 @ 14:57:
[...]

Ja, daar heb je helemaal gelijk in.
Alleen niet iedereen heeft zich er helemaal in verdiept, of staat erbij stil als hij standby selecteert. Vandaar de suggestie🤗

Edit: Ik stond er zelf persoonlijk niet bij stil, dat als ik standbymodus zou selecteren, hij continue probeert de accu's in standby modus te zetten. Maar dacht juist dat hij dan alleen zou monitoren(geen aansturing).

Daarom stelde ik de vraag hier ook, ik twijfelde er ook aan maar je kunt een automation-schuifje ook op een dashboard zetten, dat heb ik voor iets anders ook. Dus als het voor jou handig is, dan zou je dit zelf zo kunnen toevoegen.

[Mistraller]

thijsh02 schreef op zaterdag 30 mei 2026 @ 17:20:
Heeft iemand de Zendure Smart plug pro al werkend in HA? Ik krijg ze niet gevonden en kan ook niet achterhalen op welk protocol ze zitten... heb ze via wifi wel in de Zendure app

[Afbeelding]

Wat voegt dit toe dan boven de eerste de beste (goedkope) smartplug? Ik heb een stuk of 15 Zigbee smartplugs en die kunnen ook allemaal vermogens meten.

[RemmyB83]

Mistraller schreef op zaterdag 30 mei 2026 @ 21:16:
[...]

Daarom stelde ik de vraag hier ook, ik twijfelde er ook aan maar je kunt een automation-schuifje ook op een dashboard zetten, dat heb ik voor iets anders ook. Dus als het voor jou handig is, dan zou je dit zelf zo kunnen toevoegen.

Ja, ik heb het volgens mijn wel eens gelezen maar omdat ik eigenlijk altijd NOM draai, sta ik er niet echt bij stil.
Nadeel van zelf het gielzdashboard aanpassen, is dat als hij een update uitbrengt je die dingen ook weer moet aanpassen.
Al heb ik hem nu bij mijn eigen aanvuldende batterij dashboard gezet.

[Mistraller]

RemmyB83 schreef op zaterdag 30 mei 2026 @ 21:35:
[...]

Ja, ik heb het volgens mijn wel eens gelezen maar omdat ik eigenlijk altijd NOM draai, sta ik er niet echt bij stil.
Nadeel van zelf het gielzdashboard aanpassen, is dat als hij een update uitbrengt je die dingen ook weer moet aanpassen.
Al heb ik hem nu bij mijn eigen aanvuldende batterij dashboard gezet.

Gewoon je eigen extra settings even in een kladje bewaren

[thijsh02]

Mistraller schreef op zaterdag 30 mei 2026 @ 21:18:
[...]

Wat voegt dit toe dan boven de eerste de beste (goedkope) smartplug? Ik heb een stuk of 15 Zigbee smartplugs en die kunnen ook allemaal vermogens meten.

Omdat ik er twee heb gekregen en deze werkend wil krijgen. Maar het lijkt erop dat ze geen api hebben en alleen via de zendure app aan te sturen zijn. Heb net een ticket bij zendure aangemaakt

[xtrme]

Zijn er meer mensen met een Zendure SolarFlow 800 Pro die af en toe "onbereikbaar" of unavailable wordt in Home Assistant? (Niet standby probleem)
Ik heb hier een opstelling met 2x 800 Pro. In eerste instantie gebruikte ik de cloud-integratie, maar daar trad het probleem nog vaker op. Inmiddels stuur ik alles lokaal aan via ZenSDK, wat duidelijk stabieler is, maar het probleem is niet volledig verdwenen.
Wat ik zie:
Entiteiten worden soms ineens unavailable.
De batterij blijft dan vaak wel gewoon werken, maar Home Assistant heeft geen actuele status meer.
Het probleem is meestal direct te herstellen door de laad- of ontlaadslider iets te wijzigen.
Een meer rigoureuze oplossing is het herladen van de integratie.
Gisteren heeft dit mij zelfs een volledige laad/ontlaadcyclus gekost omdat de aansturing niet meer reageerde.
Ik zit daarom te denken aan een automation die:
Controleert of de belangrijkste entiteiten langer dan 1 uur unavailable zijn.
Vervolgens automatisch een integration reload uitvoert.
Alleen wil ik voorkomen dat zo'n automation afgaat wanneer de batterij simpelweg:
100% vol is en niet verder kan laden.
0% leeg is en niet verder kan ontladen.
Hebben meer gebruikers van de 800 Pro hier last van? En zo ja:
Is dit een bekend ZenSDK- of firmwareprobleem?
Hoe detecteren jullie een "echte" vastloper versus een normale situatie waarbij laden of ontladen niet mogelijk is?
Heeft iemand hier al een nette Home Assistant automation voor gebouwd?

[xtrme]

thijsh02 schreef op zaterdag 30 mei 2026 @ 22:06:
[...]

Omdat ik er twee heb gekregen en deze werkend wil krijgen. Maar het lijkt erop dat ze geen api hebben en alleen via de zendure app aan te sturen zijn. Heb net een ticket bij zendure aangemaakt

Zijn het niet rebrand tuya's? Als je al smartlife app hebt /tuya

(In de zoek resultaten van de ZDSPPRO-EU, wordt door Gemini al een koppeling gemaakt met smartlife. Weet niet of dat door mijn historie wordt verzonnen, want er staat geen bron bij)

Probeer ze is toe te voegen als plug met metering

Zo ja dan kunnen via (local)tuya worden toegevoegd, vaak met metering

[ Voor 15% gewijzigd door xtrme op 31-05-2026 07:33 ]

[thijsh02]

Ik had het ook via Tuya geprobeerd, maar lukte ook niet. Krijg net deze reactie van Zendure:

Official Support

Currently, Zendure Plug Pro is not directly supported in the official Home Assistant integration list, so it cannot be automatically recognized in Home Assistant through standard methods.

Local API

At present, Zendure Plug Pro mainly relies on the official Zendure App for control, and the company has not yet opened a complete local API for third-party direct access.

[raven22]

xtrme schreef op zondag 31 mei 2026 @ 07:26:
Zijn er meer mensen met een Zendure SolarFlow 800 Pro die af en toe "onbereikbaar" of unavailable wordt in Home Assistant? (Niet standby probleem)
Ik heb hier een opstelling met 2x 800 Pro. In eerste instantie gebruikte ik de cloud-integratie, maar daar trad het probleem nog vaker op. Inmiddels stuur ik alles lokaal aan via ZenSDK, wat duidelijk stabieler is, maar het probleem is niet volledig verdwenen.
Wat ik zie:
Entiteiten worden soms ineens unavailable.
De batterij blijft dan vaak wel gewoon werken, maar Home Assistant heeft geen actuele status meer.
Het probleem is meestal direct te herstellen door de laad- of ontlaadslider iets te wijzigen.
Een meer rigoureuze oplossing is het herladen van de integratie.
Gisteren heeft dit mij zelfs een volledige laad/ontlaadcyclus gekost omdat de aansturing niet meer reageerde.
Ik zit daarom te denken aan een automation die:
Controleert of de belangrijkste entiteiten langer dan 1 uur unavailable zijn.
Vervolgens automatisch een integration reload uitvoert.
Alleen wil ik voorkomen dat zo'n automation afgaat wanneer de batterij simpelweg:
100% vol is en niet verder kan laden.
0% leeg is en niet verder kan ontladen.
Hebben meer gebruikers van de 800 Pro hier last van? En zo ja:
Is dit een bekend ZenSDK- of firmwareprobleem?
Hoe detecteren jullie een "echte" vastloper versus een normale situatie waarbij laden of ontladen niet mogelijk is?
Heeft iemand hier al een nette Home Assistant automation voor gebouwd?

Ik zie het vandaag voor het eerst met mijn 800 Plus. Maar deze staat in de tuin en de wifi is vrij zwak.
In de Zendure app zie ik het apparaat wel via BT, dus ik ga eerst even checken of ik de wifi daar wat kan verbeteren.

[Devke]

xtrme schreef op zondag 31 mei 2026 @ 07:26:
Zijn er meer mensen met een Zendure SolarFlow 800 Pro die af en toe "onbereikbaar" of unavailable wordt in Home Assistant? (Niet standby probleem)
Ik heb hier een opstelling met 2x 800 Pro. In eerste instantie gebruikte ik de cloud-integratie, maar daar trad het probleem nog vaker op. Inmiddels stuur ik alles lokaal aan via ZenSDK, wat duidelijk stabieler is, maar het probleem is niet volledig verdwenen.
Wat ik zie:
Entiteiten worden soms ineens unavailable.
De batterij blijft dan vaak wel gewoon werken, maar Home Assistant heeft geen actuele status meer.
Het probleem is meestal direct te herstellen door de laad- of ontlaadslider iets te wijzigen.
Een meer rigoureuze oplossing is het herladen van de integratie.
Gisteren heeft dit mij zelfs een volledige laad/ontlaadcyclus gekost omdat de aansturing niet meer reageerde.
Ik zit daarom te denken aan een automation die:
Controleert of de belangrijkste entiteiten langer dan 1 uur unavailable zijn.
Vervolgens automatisch een integration reload uitvoert.
Alleen wil ik voorkomen dat zo'n automation afgaat wanneer de batterij simpelweg:
100% vol is en niet verder kan laden.
0% leeg is en niet verder kan ontladen.
Hebben meer gebruikers van de 800 Pro hier last van? En zo ja:
Is dit een bekend ZenSDK- of firmwareprobleem?
Hoe detecteren jullie een "echte" vastloper versus een normale situatie waarbij laden of ontladen niet mogelijk is?
Heeft iemand hier al een nette Home Assistant automation voor gebouwd?

Ik heb geen 800. Is een reload altijd voldoende als hij vast zit? Of kom je dan toe aan een reset van de batterij / wifi?

[xtrme]

@raven22 zou geen wifi ding moeten zijn. Is mesh opgezet met een accesspoint 15m verderop in zo goed als vrij zicht, maar wellicht dat hij van punt wisselt

@Devke ja reload van de integratie of de schuif verplaatsen is voldoende dus lijkt meer een timeout, die op een soort van wake up reageert

[Devke]

xtrme schreef op zondag 31 mei 2026 @ 10:32:
@raven22 zou geen wifi ding moeten zijn. Is mesh opgezet met een accesspoint 15m verderop in zo goed als vrij zicht, maar wellicht dat hij van punt wisselt

@Devke ja reload van de integratie of de schuif verplaatsen is voldoende dus lijkt meer een timeout, die op een soort van wake up reageert

Oke, dan weet ik eerlijk gezegd de oplossing even niet. Ik herkende het wegvallen. Dat bij een 2400. Dat ligt denk ik echt aan de Wifi. Het gaat hier nu een dag of 5 goed. Dan liep het zo vast dat alleen een reset van een AP of batterij hielp.

[xtrme]

Devke schreef op zondag 31 mei 2026 @ 10:39:
[...]

Oke, dan weet ik eerlijk gezegd de oplossing even niet. Ik herkende het wegvallen. Dat bij een 2400. Dat ligt denk ik echt aan de Wifi. Het gaat hier nu een dag of 5 goed. Dan liep het zo vast dat alleen een reset van een AP of batterij hielp.

Heb daar ook het vermoeden liggen. Ga ook een statisch ip adres proberen. Helaas kan dat niet vanuit zendure maar alleen vanuit de router zover ik het lees

[Devke]

xtrme schreef op zondag 31 mei 2026 @ 10:51:
[...]

Heb daar ook het vermoeden liggen. Ga ook een statisch ip adres proberen. Helaas kan dat niet vanuit zendure maar alleen vanuit de router zover ik het lees

Is niet zo moeilijk. Inloggen en IP adres vast zetten. Echter het kan maar zo zijn dat je Wifi dekking soms even niet lekker werkt of je AP te oud is. Ik heb hier eerst met boosters gewerkt, ging altijd goed en zo ineens helaas pindakaas. Daarna naar een TP link AP/Router in AP mode. Leek beter te gaan maar uiteindelijk ook niet stabiel. Heb de boel omgegooid naar een AP van deze tijd. Daarom klop ik het nog even af, maar tot nu toe gaat het goed. Nog een paar dagen langer om het met zekerheid te zeggen. Vorige AP hield het ook dagen vol en dan was het toch ineens klaar.

[Ben(V)]

Het lijkt echt heel sterk op wifi problemen, naast slecht bereik zijn er nog een paar potentiële issues.

Zendure gebruikt o.a. mDNS en mesh systemen handelen dat nog wel eens niet goed af waardoor dit soort problemen kunnen ontstaan.
Ook switches die geen Igmp snooping ondersteunen leveren problemen op.
Vlan's en verschillende subnetten gebruiken werkt ook heel slecht.

Best advies is geen mesh systemen gebruiken, maar bedraad aangesloten AP's en als je ergens een switch gebruik kijken of die icmp snooping ondersteund.
Ook powerline is funest.

[ Voor 19% gewijzigd door Ben(V) op 31-05-2026 11:38 ]

[gielz]

Gielz update v20260529

http://zendure-ha.com/

English (Global)

⚠️ Please make sure to use the correct language update. ⚠️

This update mainly focuses on bug fixes. However, a few additional features have been introduced, such as the ability to disable exporting energy when connected solar panels are still generating power while the battery is full. We have also made the first preparations for the new Mix series.

New features

PV Export Disabled
You can now use a boolean to specify whether to export the PV generation from the connected panels when the battery is full, or to prevent it instead

Mix series

sensor.zendure_total_capacity
Added correct capacity for SolarFlow 3000 Mix AC+, SolarFlow 4000 Mix AC+ and SolarFlow 4000 Mix Pro

Dashboard

Zero Import
This will now start at the lowest recorded value instead of zero, to better show the difference from zero import per day.

Bug fixes

SOC Protection
When SOC protection is disabled and the battery is discharged below the minimum state of charge, Smart Matching will not start. This issue has now been fixed.

Dynamic Charging/Discharing Cycle
When the battery lost connection to the network during dynamic charging or discharging, the cycle would restart immediately. From now on, if the battery reconnects to the network within 15 seconds, the cycle will continue normally.

Dynamic Charging/Discharging Running
Sometimes after a dynamic cycle, the battery won’t switch to Smart Matching when expected. After a dynamic cycle, an extra check will be performed to verify that the cycle is completely finished.

Dynamic Lowest Price Period
When no lowest price periods were selected, this sensor generated an error message in the logbook. This issue has now been resolved.

Dutch (NL)

⚠️ Zorg ervoor dat je de juiste taalupdate gebruikt. ⚠️

Deze update staat in het teken van bugfixes. Wel zijn er wat extra dingen toegevoegd zoals het kunnen uitschakelen van terugleveren wanneer er aangesloten zonnepanelen aan de Zendure zitten en de batterij is vol. Ook de eerste voorbereidingen voor de nieuwe Mix serie.

Nieuwe functies

PV Export Uitgeschakeld
Je kunt nu met een boolean aangeven of je de PV-opwek van de aangesloten panelen wilt exporteren wanneer de batterij vol is, of deze juist wilt tegenhouden.

Mix series

sensor.zendure_2400_ac_totale_capaciteit
Juiste capaciteit toegevoegd voor SolarFlow 3000 Mix AC+, SolarFlow 4000 Mix AC+ and SolarFlow 4000 Mix Pro

Dashboard

Nul Import
Dit begint nu bij de laagst gemeten waarde in plaats van bij nul, zodat het verschil met nul import beter zichtbaar is per dag.

Bug fixes

SOC Bescherming
Wanneer SOC Bescherming is uitgeschakeld en de batterij onder het minimale laadpercentage wordt ontladen, start Nul op de meter niet. Dit probleem is nu opgelost.

Dynamisch Laden/Ontladen Cyclus
Wanneer tijdens het dynamisch laden of ontladen de batterij de verbinding met het netwerk verloor werd de cyclus direct herstart. Wanneer de batterij binnen 15 seconden weer verbinding heeft met het netwerk zal de cyclus vanaf nu gewoon doorlopen.

Dynamisch Laden/Ontladen Loopt
Soms schakelt de batterij na een dynamische cyclus niet naar Nul op de meter wanneer dat verwacht wordt. Na een dynamische cyclus wordt daarom een extra controle uitgevoerd om te verifiëren dat de cyclus volledig is afgerond.

Dynamisch Goedkoopste Periode
Wanneer er geen goedkope periodes waren geselecteerd gaf deze sensor een foutmelding in het logboek. Dit probleem is nu opgelost

[MrOwnalicious]

Hi allen,

Ik zit mogelijks met een bug of begrijp de integratie niet volledig. Ik heb gisteren de overstap gemaakt naar de sturing van de AC2400 via Gielz-integratie (dank voor creatie en onderhoud).

Echter zag ik al vrij snel dat de batterij eigenlijk nooit wou bijladen, maar wel laden. Ik kon dit wel forceren door eerst over te schakelen op quick charge, gevolgd door de terugschakeling naar smart mode.

Na verloop van tijd stopte de batterij telkens met laden, ook al was de max SOC nog niet bereikt en was er nog ruim overschot (- 2000 w) injectie.

Eigenlijk staan alle instellingen wel goed. Nu was ik zonet door de automatiseringen aan het scrollen en zag ik dat er bij het laden een voorwaarde is waaraan voldaan moet worden:

"Als Zendure power hoger is dan -30 en lager dan 30"

Nu zie ik dat Zendure power de gehele tijd rond de -45 a -50 W zit bij mij. Waarschijnlijk om mijn off-grid circuit te voeden, want deze waarde komt hier mee overeen. Het off-grid stopcontact staat in normal modus.

Ik heb deze voorwaarde uitgeschakeld en nu verloopt alles zoals verwacht: bij overschot wordt er geladen.


Nu blijft de vraag: waarom bestaat deze regel? Iedereen die een off-grid consumptie heeft van meer dan 30 watt, zal dan tegen dit probleem aanlopen? Bij mij zitten hier namelijk: modem, switches, hubs, ... op.

[gielz]

MrOwnalicious schreef op zondag 31 mei 2026 @ 12:11:
Hi allen,

Ik zit mogelijks met een bug of begrijp de integratie niet volledig. Ik heb gisteren de overstap gemaakt naar de sturing van de AC2400 via Gielz-integratie (dank voor creatie en onderhoud).

Echter zag ik al vrij snel dat de batterij eigenlijk nooit wou bijladen, maar wel laden. Ik kon dit wel forceren door eerst over te schakelen op quick charge, gevolgd door de terugschakeling naar smart mode.

Na verloop van tijd stopte de batterij telkens met laden, ook al was de max SOC nog niet bereikt en was er nog ruim overschot (- 2000 w) injectie.

Eigenlijk staan alle instellingen wel goed. Nu was ik zonet door de automatiseringen aan het scrollen en zag ik dat er bij het laden een voorwaarde is waaraan voldaan moet worden:

"Als Zendure power hoger is dan -30 en lager dan 30"

Nu zie ik dat Zendure power de gehele tijd rond de -45 a -50 W zit bij mij. Waarschijnlijk om mijn off-grid circuit te voeden, want deze waarde komt hier mee overeen. Het off-grid stopcontact staat in normal modus.

Ik heb deze voorwaarde uitgeschakeld en nu verloopt alles zoals verwacht: bij overschot wordt er geladen.


Nu blijft de vraag: waarom bestaat deze regel? Iedereen die een off-grid consumptie heeft van meer dan 30 watt, zal dan tegen dit probleem aanlopen? Bij mij zitten hier namelijk: modem, switches, hubs, ... op.

Die regel zit er in om te voorkomen dat hij abrupt van laden naar ontladen en terug gaat. Hij balanceert dan in de huidige modus tot het niet meer kan. Ik ken een aantal gebruikers die de offgrid gebruiken met drogers, vriezers etc zonder problemen.

Zou je even terug naar de basis kunnen gaan en dan de batterij van standby naar NOM kunnen zetten als modus. Post daarna even na 5-10 minuten een screenshot hoe tabblad 1 en 2 van het standaard dashboard er uit ziet.

[MrOwnalicious]

Bij deze screenshots van beide tabs. Eerst enkele minuten op standby, gevolgd door enkele minuten NOM (default automatiseringen).Mogelijks is het interessant om de power van het off-grid stopcontact ervanaf te trekken tijdens het uitvoeren van die ene voorwaarde? Die 40 watt verbruik is echt extreem stabiel bij mij.

[ Voor 10% gewijzigd door MrOwnalicious op 31-05-2026 12:34 ]

[gielz]

MrOwnalicious schreef op zondag 31 mei 2026 @ 12:30:
Bij deze screenshots van beide tabs. Eerst enkele minuten op standby, gevolgd door enkele minuten NOM (default automatiseringen).

[Afbeelding]

[Afbeelding]

Mogelijks is het interessant om de power van het off-grid stopcontact ervanaf te trekken tijdens het uitvoeren van die ene voorwaarde? Die 40 watt verbruik is echt extreem stabiel bij mij.

Zou ook standaard moeten gebeuren maar wellicht heb je een bug gevonden. Welke firmware zit op je zendure en welk device heb je? Deel hier ook even je properties http://<zendureip>/properties/report

Offgrid zou volledig uitgesloten moeten worden in de aansturing tenzij er PV op zit.

[ Voor 3% gewijzigd door gielz op 31-05-2026 13:00 ]

[MrOwnalicious]

Omvormer en firmware: SolarFlow 2400 AC V1.0.19

JSON:

{
   "timestamp":1780225985,
   "messageId":190,
   "sn":"HOA1NAN9N446402",
   "version":2,
   "product":"solarFlow2400AC",
   "properties":{
      "heatState":0,
      "packInputPower":38,
      "outputPackPower":0,
      "outputHomePower":0,
      "remainOutTime":59940,
      "packState":0,
      "electricLevel":79,
      "gridInputPower":0,
      "solarInputPower":0,
      "solarPower1":0,
      "solarPower2":0,
      "solarPower3":0,
      "solarPower4":0,
      "solarPower5":0,
      "solarPower6":0,
      "pass":0,
      "reverseState":0,
      "socStatus":0,
      "hyperTmp":3081,
      "gridOffPower":38,
      "dcStatus":1,
      "pvStatus":0,
      "acStatus":2,
      "dataReady":1,
      "gridState":1,
      "BatVolt":5012,
      "socLimit":0,
      "faultLevel":0,
      "writeRsp":0,
      "acMode":1,
      "inputLimit":0,
      "outputLimit":0,
      "socSet":1000,
      "minSoc":100,
      "gridStandard":6,
      "gridReverse":1,
      "inverseMaxPower":800,
      "lampSwitch":0,
      "gridOffMode":0,
      "IOTState":2,
      "fanSwitch":1,
      "fanSpeed":0,
      "bindstate":0,
      "VoltWakeup":0,
      "OldMode":0,
      "OTAState":0,
      "LCNState":0,
      "factoryModeState":0,
      "ts":1780225984,
      "tsZone":14,
      "smartMode":1,
      "chargeMaxLimit":1600,
      "phaseSwitch":2,
      "batCalTime":60,
      "packNum":2,
      "rssi":-66,
      "is_error":0
   },
   "packData":[
      {
         "sn":"FO4NLN8N3607552",
         "packType":5,
         "socLevel":81,
         "state":0,
         "power":0,
         "maxTemp":3021,
         "totalVol":5010,
         "batcur":0,
         "maxVol":334,
         "minVol":334,
         "softVersion":4106,
         "heatState":0
      },
      {
         "sn":"FO4NLN8N3607550",
         "packType":5,
         "socLevel":78,
         "state":0,
         "power":0,
         "maxTemp":2991,
         "totalVol":5000,
         "batcur":0,
         "maxVol":333,
         "minVol":333,
         "softVersion":4106,
         "heatState":0
      }
   ]
}

[ppaulv]

Mistraller schreef op zaterdag 30 mei 2026 @ 21:49:
[...]

Gewoon je eigen extra settings even in een kladje bewaren

of misschien handiger (heb ik gedaan) : als een aparte losse file in de packages folder en packages includen in je configuratie.
Ik heb 6 yaml files in de packages folder staan en één daarvan is de Gielz config, een ander de Nordpool en de rest is van eigen hand.
Alleen een wijziging in een bestaand Gielz dashboard is andere koek, je zou het in een eigen, apart dashboard kunnen zetten (die heb ik ook een aantal).
Het is maar een idee.

[gielz]

MrOwnalicious schreef op zondag 31 mei 2026 @ 13:16:
Omvormer en firmware: SolarFlow 2400 AC V1.0.19

JSON:

{
   "timestamp":1780225985,
   "messageId":190,
   "sn":"HOA1NAN9N446402",
   "version":2,
   "product":"solarFlow2400AC",
   "properties":{
      "heatState":0,
      "packInputPower":38,
      "outputPackPower":0,
      "outputHomePower":0,
      "remainOutTime":59940,
      "packState":0,
      "electricLevel":79,
      "gridInputPower":0,
      "solarInputPower":0,
      "solarPower1":0,
      "solarPower2":0,
      "solarPower3":0,
      "solarPower4":0,
      "solarPower5":0,
      "solarPower6":0,
      "pass":0,
      "reverseState":0,
      "socStatus":0,
      "hyperTmp":3081,
      "gridOffPower":38,
      "dcStatus":1,
      "pvStatus":0,
      "acStatus":2,
      "dataReady":1,
      "gridState":1,
      "BatVolt":5012,
      "socLimit":0,
      "faultLevel":0,
      "writeRsp":0,
      "acMode":1,
      "inputLimit":0,
      "outputLimit":0,
      "socSet":1000,
      "minSoc":100,
      "gridStandard":6,
      "gridReverse":1,
      "inverseMaxPower":800,
      "lampSwitch":0,
      "gridOffMode":0,
      "IOTState":2,
      "fanSwitch":1,
      "fanSpeed":0,
      "bindstate":0,
      "VoltWakeup":0,
      "OldMode":0,
      "OTAState":0,
      "LCNState":0,
      "factoryModeState":0,
      "ts":1780225984,
      "tsZone":14,
      "smartMode":1,
      "chargeMaxLimit":1600,
      "phaseSwitch":2,
      "batCalTime":60,
      "packNum":2,
      "rssi":-66,
      "is_error":0
   },
   "packData":[
      {
         "sn":"FO4NLN8N3607552",
         "packType":5,
         "socLevel":81,
         "state":0,
         "power":0,
         "maxTemp":3021,
         "totalVol":5010,
         "batcur":0,
         "maxVol":334,
         "minVol":334,
         "softVersion":4106,
         "heatState":0
      },
      {
         "sn":"FO4NLN8N3607550",
         "packType":5,
         "socLevel":78,
         "state":0,
         "power":0,
         "maxTemp":2991,
         "totalVol":5000,
         "batcur":0,
         "maxVol":333,
         "minVol":333,
         "softVersion":4106,
         "heatState":0
      }
   ]
}

Ik zal morgen even hier met de offgrid spelen tussendoor om te kijken waarom dit bij jou anders word berekend in de API. Ik zie hier namelijk netjes dit;



De batterij is aangesloten aan het net en aangezien er geen stroomstoring is komt dit netjes uit het net en niet direct uit de batterij. Zijn in Belgie de regels anders? Want ik zie in de API dat hij ziet dat je op grid "Belgium" zit.

Wellicht dat hier nog andere zijn die even iets op de offgrid (afnemer) kunnen aansluiten om te zien wat er exact daar gedaan word met de data.

[DeadMetal]

gielz schreef op zondag 31 mei 2026 @ 12:05:

Gielz update v20260529

http://zendure-ha.com/

Bedankt, updaten is gelukt. Een vreemd ding wat ik zag gebeuren, is dat na de herstart van HA, de prijsgrafieken verkeerde data toonden, namelijk data zónder energiebelasting en BTW. Alsof ze even naar de kale Nordpool sensor keken, in plaats van naar de geconfigureerde sensor.nordpool_kwh_nl_eur_5_09_0 (uit nordpool.yaml, of dat diens data nog verkeerd was)
Terwijl ik dat aan het troubleshooten was, stond het 10 minuten later ineens weer goed.

Ik heb je package nu 2 weken in gebruik @gielz en het draait allemaal soepel
Een ding wat mij echter nog blijft verwarren, is dat in je dashboard op het 1e tabblad, negatieve getallen (in de 2 grote grafieken) 'opladen van de batterij' betekent. Echter, helemaal bovenaan, bij die 3 kleine icoontjes en cijfertjes (watt, batterijpercentage en aantal schakelingen) betekent een positief getal juist dat de batterij aan het opladen is.

[ Voor 27% gewijzigd door DeadMetal op 31-05-2026 18:46 ]

[MrOwnalicious]

Er lijkt toch iets mis te gaan bij mijn AC2400: ik heb al 2 kortstondige stroomonderbrekingen gehad op het off-grid stopcontact deze namiddag. Dit was merkbaar, aangezien mijn modem e.d. erop zit.

Ik gebruik deze als een soort UPS.

Na stroomonderbreking 1, werd de off-grid consumptie niet meer meegerekend in de Zendure power sensor. Sinds de tweede onderbreking weer wel.

Screenshot van een tijdelijk correcte situatie:



Toevoeging: op dit moment zie ik hetvolgende:
[EDIT]: eigenlijk logisch, diezelfde voorwaarde, zijnde -30 en 30 is ook van toepassing bij ontladen. De discharge power is de gewenste hoeveelheid ontlading, de Zendure power is de actual power flow. Na het uitschakelen van die voorwaarde bij ontladen, ontlaadt de batterij wel.

[ Voor 28% gewijzigd door MrOwnalicious op 31-05-2026 21:34 ]

[Tiesert]

Laat maar...

[ Voor 105% gewijzigd door Tiesert op 01-06-2026 22:49 ]

[gast777]

ZuinigeRijder schreef op zaterdag 30 mei 2026 @ 16:52:
[...]


Zendure 1 Opslagmodus: Opslaan in RAM
Zendure 2 Opslagmodus: Opslaan in Flash

@gast777 Zou bij beide de opslagmodus hetzelfde moeten zijn (Opslaan in RAM)?

EDIT:
heb even gewisseld van NOM -> Snel ontladen -> NOM. Nu zijn ze beide "Opslaan in RAM". En voor de zekerheid ook een HA reboot gedaan. Even kijken of het nu wel goed blijft......

EDIT2:
Nu is batterij 2 weer Opslaan in Flash

Na 5 minuten nul vermogen zet de proxy het niet actieve device in 'slaap', oftewel smartmode=0 (oftwewel Opslaan in Flash). Dus je observatie is correct, hoe de proxy behoort te werken.

[ Voor 16% gewijzigd door gast777 op 01-06-2026 00:31 ]

[ZuinigeRijder]

@gast777 Bij @gielz settings kun je de "Standby Vertraging" instellen, dus de proxy overruled dat met een vaste waarde van 5 minuten? En wanneer ik dit op een andere waarde dan 5 minuten wil, waar moet ik dat dan aanpassen?

[Wai_AM]

DeadMetal schreef op zondag 31 mei 2026 @ 17:50:
[...]

Bedankt, updaten is gelukt. Een vreemd ding wat ik zag gebeuren, is dat na de herstart van HA, de prijsgrafieken verkeerde data toonden, namelijk data zónder energiebelasting en BTW. Alsof ze even naar de kale Nordpool sensor keken, in plaats van naar de geconfigureerde sensor.nordpool_kwh_nl_eur_5_09_0 (uit nordpool.yaml, of dat diens data nog verkeerd was)
Terwijl ik dat aan het troubleshooten was, stond het 10 minuten later ineens weer goed.

Iedere wijziging in BTW%, Energiebelasting, energievergoeding of herstart van HA zorgt ervoor dat je eerst de kale prijs te zien krijgt. iedere volgende kwartier na je tijdstip van wijziging worden de variabelen weer berekend zodat je de correcte cijfers hebt. Dit heeft denk ik met de verversing van HACS Noordpool te maken. Mocht je weten hoe je het proces kan vervroegen dan kan je het hier delen en dank voor je bijdrage.

[Henkoes]

Vraagje over de spread. Als de Spread lager is dan ingesteld. Doet de batterij dan helemaal niks of alleen de uren waar de spread niet gehaald wordt niks?

[Henkoes]

Is het mogelijk de NL en EN op dezelfde PI te draaien met en 1 of 2 torens apart op de NL aan te sturen? Of gaat dit mis?

[Pakhaas]

Henkoes schreef op maandag 1 juni 2026 @ 17:23:
Vraagje over de spread. Als de Spread lager is dan ingesteld. Doet de batterij dan helemaal niks of alleen de uren waar de spread niet gehaald wordt niks?

Dan doet de batterij niets

[Gramser]

Het blijft bijzonder en ik moet er nog eens goed induiken, maar er is iets dat mijn setup van 2x 2400AC+ van slag maakt. De ene toren gaat op standby en de andere gaat ontladen met een vast -laag- wattage. Op standby zetten en weer naar NoM helpt niet. Disablen van de automation helpt niet. In HEMS zetten helpt niet. Alleen een harde restart (knop tot lange piep indrukken, rood bliksempje, stekker eruit, en weer terug erin) werkt. Tien seconden werk, maar je zal je accu maar op een vaste aansluiting hebben zitten. Ik hoop dat Zendure snel die harde reset softwarematig gaat inbouwen want als ik met vakantie ben heb ik hier niks aan
Het gebeurt niet vaak, dit is de tweede keer, en ik weet ook niet of er een trigger is die ze weer NOM laat draaien, maar handig is anders

[ Voor 9% gewijzigd door Gramser op 01-06-2026 18:38 ]

[gast777]

ZuinigeRijder schreef op maandag 1 juni 2026 @ 08:08:
@gast777 Bij @gielz settings kun je de "Standby Vertraging" instellen, dus de proxy overruled dat met een vaste waarde van 5 minuten? En wanneer ik dit op een andere waarde dan 5 minuten wil, waar moet ik dat dan aanpassen?

Nee hij overruled de 15 minuten van Gielz niet. Dat is namelijk iets anders (subtiel verschil).

Als Gielz de boel in Standby zet (na de "Standby Vertraging"), dan is dat voor de gehele "Virtuele Zendure".

De Proxy doet iets anders. Die zet de individuele Zendures achter de proxy in Standby (nooit allemaal tegelijk) bij laag vermogen, na 5 minuten van "niet actief" zijn.

Mocht je die tijd willen veranderen, dan kan dat. In het blokje "Vul hier de Zendure IP adressen in" heb je deze tweakbare variabelen:

[Hippe Lip]

Gramser schreef op maandag 1 juni 2026 @ 18:37:
Het blijft bijzonder en ik moet er nog eens goed induiken, maar er is iets dat mijn setup van 2x 2400AC+ van slag maakt. De ene toren gaat op standby en de andere gaat ontladen met een vast -laag- wattage. Op standby zetten en weer naar NoM helpt niet. Disablen van de automation helpt niet. In HEMS zetten helpt niet. Alleen een harde restart (knop tot lange piep indrukken, rood bliksempje, stekker eruit, en weer terug erin) werkt. Tien seconden werk, maar je zal je accu maar op een vaste aansluiting hebben zitten. Ik hoop dat Zendure snel die harde reset softwarematig gaat inbouwen want als ik met vakantie ben heb ik hier niks aan
Het gebeurt niet vaak, dit is de tweede keer, en ik weet ook niet of er een trigger is die ze weer NOM laat draaien, maar handig is anders

Dat klinkt inderdaad niet fijn, @Gramser! Heb je dit al aan Zendure gemeld? Ben benieuwd wat hun antwoord dan is.
En het gaat steeds om dezelfde van de twee stapels die je hebt staan?

En dit doet me denken aan de zekeringautomaten van Shelly. Die heeft een tijdje geleden zekeringautomaten (MCB’s) aangekondigd die op afstand aan en uit te zetten zijn (en kunnen meten). Helaas zijn ze nog niet leverbaar.

Om misverstanden te voorkomen: als zo’n ding wegens overbelasting zelfstandig is uitgeschakeld kun je die niet op afstand inschakelen. Dat gaat alleen als die ook op afstand uitgeschakeld is. Maar dat zou zo’n probleem als van @Gramser mogelijk wel kunnen verhelpen.

[Henkoes]

<knip> Geduld! Zo snel kicken is niet de bedoeling.

[ Voor 82% gewijzigd door Septillion op 01-06-2026 23:47 ]

[RemmyB83]

Henkoes schreef op maandag 1 juni 2026 @ 22:32:
[...]

Weet iemand of dit kan?

Ik weet dat je beide naast elkaar kan draaien.
Maar je kan die sensor niet zomaar voor beide gebruiken om NOM te draaien.

Ik denk dat je 1 extra entiteit moet maken, die de helft van je P1 registeerd. En die in beide integraties, als p1 in geven.
(Ik heb hier geen ervaring mee, dus geen garantie)

[Hippe Lip]

Henkoes schreef op maandag 1 juni 2026 @ 22:32:
[mbr]<knip> Geduld! Zo snel kicken is niet de bedoeling.[/]

Ik denk wel dat dit kan. Ik vebruik behalve de zenSDK ook de Dynamisch-HA van @gielz in het Nederlands naast de Gielz (+ proxy) in het Engels. Die twee bijten elkaar niet en draaien volledig onafhankelijk.

@gielz zal volledige uitsluiting kunnen geven.

Maar vergeet dan niet wat @RemmyB83 zei: je kunt geen twee kapiteins op één schip hebben. Er kan er dus maar eentje NOM draaien. Maar je kunt die twee wel met een extra automatisering uit elkaar houden of zo.

[ Voor 20% gewijzigd door Hippe Lip op 01-06-2026 23:52 ]

[Gramser]

Hippe Lip schreef op maandag 1 juni 2026 @ 22:22:
[...]

Dat klinkt inderdaad niet fijn, @Gramser! Heb je dit al aan Zendure gemeld? Ben benieuwd wat hun antwoord dan is.
En het gaat steeds om dezelfde van de twee stapels die je hebt staan?

En dit doet me denken aan de zekeringautomaten van Shelly. Die heeft een tijdje geleden zekeringautomaten (MCB’s) aangekondigd die op afstand aan en uit te zetten zijn (en kunnen meten). Helaas zijn ze nog niet leverbaar.

Om misverstanden te voorkomen: als zo’n ding wegens overbelasting zelfstandig is uitgeschakeld kun je die niet op afstand inschakelen. Dat gaat alleen als die ook op afstand uitgeschakeld is. Maar dat zou zo’n probleem als van @Gramser mogelijk wel kunnen verhelpen.

Ik moet eerlijk zeggen dat ik er nog niet aan dacht om dit bij Zendure te melden. Om de eoa reden heb ik in mijn hoofd dat als ik geen HEMS gebruik, ik niet bij Zendure terecht zou kunnen. Misvatting die nergens op gebaseerd is. Maar, ik ga er eerst nog wat verder in duiken. Ik meen dat het bij dezelfde stapel gebeurt inderdaad. En wat je zegt over de Shelly zekeringautomaten kan ik me wat bij voorstellen: na overbelasting zou ik eerst ook even willen zíen wat ik weer aanzet... maar dit was geen overbelasting. Eerder de weg kwijt zijn... ik hou het nog even in de gaten, het draait weer mooi nu. Heb er wel eens aan gedacht dat het kan liggen aan het feit dat de twee stapels ongelijk zijn, en dat is geen ideaal uitgangspunt voor de @gast777 proxy.

[Devke]

Gramser schreef op dinsdag 2 juni 2026 @ 08:42:
[...]

Ik moet eerlijk zeggen dat ik er nog niet aan dacht om dit bij Zendure te melden. Om de eoa reden heb ik in mijn hoofd dat als ik geen HEMS gebruik, ik niet bij Zendure terecht zou kunnen. Misvatting die nergens op gebaseerd is. Maar, ik ga er eerst nog wat verder in duiken. Ik meen dat het bij dezelfde stapel gebeurt inderdaad. En wat je zegt over de Shelly zekeringautomaten kan ik me wat bij voorstellen: na overbelasting zou ik eerst ook even willen zíen wat ik weer aanzet... maar dit was geen overbelasting. Eerder de weg kwijt zijn... ik hou het nog even in de gaten, het draait weer mooi nu. Heb er wel eens aan gedacht dat het kan liggen aan het feit dat de twee stapels ongelijk zijn, en dat is geen ideaal uitgangspunt voor de @gast777 proxy.

Wel een leuke test. Als het zich weer voordoet de stapels gelijk maken even en kijken wat er dan gebeurd.

[Mscroos]

Gramser schreef op maandag 1 juni 2026 @ 18:37:
Het blijft bijzonder en ik moet er nog eens goed induiken, maar er is iets dat mijn setup van 2x 2400AC+ van slag maakt. De ene toren gaat op standby en de andere gaat ontladen met een vast -laag- wattage. Op standby zetten en weer naar NoM helpt niet. Disablen van de automation helpt niet. In HEMS zetten helpt niet. Alleen een harde restart (knop tot lange piep indrukken, rood bliksempje, stekker eruit, en weer terug erin) werkt. Tien seconden werk, maar je zal je accu maar op een vaste aansluiting hebben zitten. Ik hoop dat Zendure snel die harde reset softwarematig gaat inbouwen want als ik met vakantie ben heb ik hier niks aan
Het gebeurt niet vaak, dit is de tweede keer, en ik weet ook niet of er een trigger is die ze weer NOM laat draaien, maar handig is anders

@Gramser Ik heb hetzelfde, heb drie gelijke setjes. Heb dit nu op 2 van de drie gehad. de laatste keer dat mij het is overkomen ben ik de zendure app ingegaan, dan naar tweede tabje "devices" heb de accu geselecteerd, tandwieltje voor settings. Daarna in optie on grid setting gegaan. Heb daar handmatig een duwtje gegeven omdat je daar normaal continue de aanpassingen van @gielz / @gast777 in ziet. heb gewoon die instellingen aangepast. En zag daarna dat de updates van Giels/gast777 weer binnenkwamen via zensdk.

Ben nu aan het afwachten of dat dit nog een keer gebeurd om nog een keer te testen, maar lijkt mij dat de API blokkeert of zo en dat via de app de blokkade opgeheven kan worden. Als het me nog een keer gebeurd ga ik weer testen en een ticket bij Zendure raisen.

[Gramser]

Dan zou dat betekenen dat het wèl softwarematig op afstand te resetten is? Ga ik proberen! Wat heb je daar precies aangepast dan, en moest je eerst de boel in HEMS zetten?

[ Voor 30% gewijzigd door Gramser op 02-06-2026 12:53 ]

[Mscroos]

Gramser schreef op dinsdag 2 juni 2026 @ 12:44:
Dan zou dat betekenen dat het wèl softwarematig op afstand te resetten is? Ga ik proberen! Wat heb je daar precies aangepast dan, en moest je eerst de boel in HEMS zetten?

Is me nog maar 1 keer gelukt. Hems hoeft niet aan te staan omdat in dat scherm de accu rechtstreeks wordt aangesproken. Ik heb volgens mij de Gielz setting op stand-by gezet, daarna in de zendure app de instelling naar 100 en weer naar 0 gezet en daarna weer smart matching gedaan. Ik meld me weer als het nog een keer gebeurd....

Het is overigens geen reset of zo, maar volgens mij clear je "iets" als je zelf die settings zet. Zou mooi zijn als andere forumleden ook proberen om iets via deze weg voor elkaar te krijgen. Helpt zendure misschien in het debuggen waar de non-responsiveheid vandaan komt.

[Gramser]

Thanks, absoluut een poging waard!

[Mscroos]

Gramser schreef op dinsdag 2 juni 2026 @ 13:56:
Thanks, absoluut een poging waard!

Alsof de duivel er mee speelt... unit 3 was net aan de beurt.... deze bleef hangen op ontladen. Ik heb dus nu 3 dagen achter elkaar een storing... eerst set 1, daarna 2 en daarna 3. Ik heb hem echter wel remote vlot kunnen trekken!!

Stappen:

1. Unit blijft laden (494W) terwijl hij op smart matching staat en eigenlijk op ontladen zou moeten staan, dat zie ik in de grafiek op de eerste tab van Gielz.
2. Ik zet de Gielz naar standby, unit blijft laden (494W). Wifi status is overigens Excellent.
3. Nadat ik hem op standby heb gezet ga ik naar zendure app en zet batterij 3 op 101W laden. Ga even naar Gielz om te checken of dit doorkomt... Ja hoor ik zie hem daar schakelen naar 101W!
4. Ga weer terug naar Zendure en zet hem op 0W en druk op save.
5. Terug naar Smart matching en TADAAAA, hij reageert weer.....

Ik heb een screen capture filmpje gemaakt waarin het duidelijk zichtbaar is wat er gebeurd. Kan deze hier niet invoegen, maar kan wel via dm delen denk ik.

@gielz @gast777 hebben jullie advies wat ik het beste kan doen?

[Henkoes]

RemmyB83 schreef op maandag 1 juni 2026 @ 23:27:
[...]

Ik weet dat je beide naast elkaar kan draaien.
Maar je kan die sensor niet zomaar voor beide gebruiken om NOM te draaien.

Ik denk dat je 1 extra entiteit moet maken, die de helft van je P1 registeerd. En die in beide integraties, als p1 in geven.
(Ik heb hier geen ervaring mee, dus geen garantie)

Super!!

[Henkoes]

Hippe Lip schreef op maandag 1 juni 2026 @ 23:50:
[...]

Ik denk wel dat dit kan. Ik vebruik behalve de zenSDK ook de Dynamisch-HA van @gielz in het Nederlands naast de Gielz (+ proxy) in het Engels. Die twee bijten elkaar niet en draaien volledig onafhankelijk.

@gielz zal volledige uitsluiting kunnen geven.

Maar vergeet dan niet wat @RemmyB83 zei: je kunt geen twee kapiteins op één schip hebben. Er kan er dus maar eentje NOM draaien. Maar je kunt die twee wel met een extra automatisering uit elkaar houden of zo.

Super dank!!

[DaGoose]

Misschien is het al eens voorbij gekomen, maar ik kan er niks over vinden. ik heb 2 hypers en ik draai nu de zendure sdk wat op zich goed werkt. Maar ik wil eigenlijk wel de gielz gaan draaien. Waarom staan de hypers er niet bij?

[Devke]

Ik ga hem hier toch maar even droppen. Gister schreef ik een post over het wifi spook in het zendure algemene topic. Helaas. Vandaag is het gezeur weer begonnen. Zendure stopt met laden/ontladen.

Mijn setup:
2 x 2400 AC met 3 batterijen per set.
Gielz integratie
Gast777 proxy

Vandaag update gedaan naar de laatste versie van de proxy. Zojuist stopte de batterij met ontladen (NOM), Ik zag dat een aantal sensoren niet beschikbaar waren. Set 1 was de boosdoener. Deze even een paar seconde uitgezet en de boel loopt weer. Als ik nu een reset van het AP had gedaan was het ook goed gegaan. Die heb ik al een x gedaan. AP al vervangen, eigen SSID voor de batterijen. AP via vaste kabel verbonden aan de router van de ISP. Beetje zoeken is leuk maar dit begint echt vervelend te worden. Gaat de Zendure nu de freeze in? Toch het AP? Iets anders in het netwerk? Beide Zendure's hebben een vast IP adres. Any clues?

[MrOwnalicious]

Mogelijks lichtjes off-topic, maar is het algemen sentiment van de Zendure batterij-oplossingen nog positief of beginnen er meer en meer pijnpunten naar boven te komen?

[Pakhaas]

MrOwnalicious schreef op dinsdag 2 juni 2026 @ 21:51:
Mogelijks lichtjes off-topic, maar is het algemen sentiment van de Zendure batterij-oplossingen nog positief of beginnen er meer en meer pijnpunten naar boven te komen?

Dit is het Zendure icm HA topic.

[PeaceNlove]

MrOwnalicious schreef op dinsdag 2 juni 2026 @ 21:51:
Mogelijks lichtjes off-topic, maar is het algemen sentiment van de Zendure batterij-oplossingen nog positief of beginnen er meer en meer pijnpunten naar boven te komen?

Ik ben nu 4 maanden onderweg met mijn 800+ en HomeAssistant. Geen enkel probleem tot nu toe, zelfs nog een uitbreiding gedaan en dus 2 ab2000x er onder. Prima aanschaf tot zover

[Hippe Lip]

MrOwnalicious schreef op dinsdag 2 juni 2026 @ 21:51:
Mogelijks lichtjes off-topic, maar is het algemen sentiment van de Zendure batterij-oplossingen nog positief of beginnen er meer en meer pijnpunten naar boven te komen?

Je kunt je vraag beter in Het grote Zendure plug-and-play thuisaccu systemen topic stellen, maar ik ben uitsluitend en 100% positief over

1. mijn 2 stapels Zendure 2400AC+ met elk 3 extra batterijen eronder,
2. de integratie van @gielz en
3. de proxy van @gast777.

Geen haar op mijn hoofd die ook maar één klein onderdeel daarvan anders zou doen als ik opnieuw zou beginnen.

[Tiesert]

MrOwnalicious schreef op dinsdag 2 juni 2026 @ 21:51:
Mogelijks lichtjes off-topic, maar is het algemen sentiment van de Zendure batterij-oplossingen nog positief of beginnen er meer en meer pijnpunten naar boven te komen?

Nog maar kort onderweg, maar 2400AC+ met HA/zenSDK/Fireson en ondanks wat kleine strubbelingen erg positief!

[RemmyB83]

Devke schreef op dinsdag 2 juni 2026 @ 21:07:
Ik ga hem hier toch maar even droppen. Gister schreef ik een post over het wifi spook in het zendure algemene topic. Helaas. Vandaag is het gezeur weer begonnen. Zendure stopt met laden/ontladen.

Mijn setup:
2 x 2400 AC met 3 batterijen per set.
Gielz integratie
Gast777 proxy

Vandaag update gedaan naar de laatste versie van de proxy. Zojuist stopte de batterij met ontladen (NOM), Ik zag dat een aantal sensoren niet beschikbaar waren. Set 1 was de boosdoener. Deze even een paar seconde uitgezet en de boel loopt weer. Als ik nu een reset van het AP had gedaan was het ook goed gegaan. Die heb ik al een x gedaan. AP al vervangen, eigen SSID voor de batterijen. AP via vaste kabel verbonden aan de router van de ISP. Beetje zoeken is leuk maar dit begint echt vervelend te worden. Gaat de Zendure nu de freeze in? Toch het AP? Iets anders in het netwerk? Beide Zendure's hebben een vast IP adres. Any clues?

Je bent niet de enige.
Al ben ik niet 100% overtuigd dat het bij mijn aan het netwerk ligt. Ik zie bijvoorbeeld dat een batterij een opdracht krijgt maar dat deze niet wordt uitgevoerd. Als ik vervolgens naar de zendure integratie ga, en de omvormer op zoek kan ik deze gewoon aansturen. Ergens gaat het dus niet goed. Grote vraag is wat, waar, en waarom.
Ik heb hier ook via DM contact over met @gast777.

Misschien kun je volgende keer bij problemen ook eens kijken of je hem via de officiele zendure integratie(fireson) nog wel kunt aansturen? Dan verteld dat misschien ook weer iets over je netwerk.

[Mscroos]

RemmyB83 schreef op dinsdag 2 juni 2026 @ 23:35:
[...]

Je bent niet de enige.
Al ben ik niet 100% overtuigd dat het bij mijn aan het netwerk ligt. Ik zie bijvoorbeeld dat een batterij een opdracht krijgt maar dat deze niet wordt uitgevoerd. Als ik vervolgens naar de zendure integratie ga, en de omvormer op zoek kan ik deze gewoon aansturen. Ergens gaat het dus niet goed. Grote vraag is wat, waar, en waarom.
Ik heb hier ook via DM contact over met @gast777.

Heb hetzelfde en kan dan inderdaad via Zendure app gewoon aansturen, waarna ook de api het weer oppakt. Heb het op drie setjes. Netwerk staat op goed of excellent. (Zie ook mijn post eerder vandaag)

[Devke]

RemmyB83 schreef op dinsdag 2 juni 2026 @ 23:35:
[...]

Je bent niet de enige.
Al ben ik niet 100% overtuigd dat het bij mijn aan het netwerk ligt. Ik zie bijvoorbeeld dat een batterij een opdracht krijgt maar dat deze niet wordt uitgevoerd. Als ik vervolgens naar de zendure integratie ga, en de omvormer op zoek kan ik deze gewoon aansturen. Ergens gaat het dus niet goed. Grote vraag is wat, waar, en waarom.
Ik heb hier ook via DM contact over met @gast777.

Misschien kun je volgende keer bij problemen ook eens kijken of je hem via de officiele zendure integratie(fireson) nog wel kunt aansturen? Dan verteld dat misschien ook weer iets over je netwerk.

Ik zie nu bijvoorbeeld dat Zendure 1 Signaal Sterkte sensor niet beschikbaar is. Propertyreport is van beide batterijen niet op te vragen. Kans bestaat dan Set 2 ook zo komt met niet beschikbaar, maar dat is nog niet. Via Gielz is gewoon te sturen nog. Alle sensoren verder zijn gewoon beschikbaar rondom de integratie. Eerder vanavond was van 1 Zendure de properties niet te bekijken, Wifi signaal niet beschikbaar (sensor) en toen was het klaar met ontladen. Ik heb er met @gast777 ook contact over. Ik heb dit al een tijdje. Het lijkt op een partoon van de issues beginnen, worden heftiger (volgen elkaar sneller op) en daarna is het weer dagen windstil. Om misschien wat vergelijkingsmateriaal te geven, NR spuugt hij mij dit dan uit:

YAML:

2 Jun 22:46:00 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:46:05 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:46:10 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:46:25 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:46:30 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:46:40 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:46:45 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:46:50 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:46:53 - [error] [http request:Call 2 Zendure API] no response from server
2 Jun 22:46:53 - [error] [http request:Call 2 Zendure API] no response from server
2 Jun 22:47:00 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:47:15 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:47:20 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:47:25 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:47:30 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:47:35 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:47:40 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:47:50 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:47:55 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:48:00 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:48:05 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:48:10 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:48:15 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:48:25 - [error] [http request:Call 2 Zendure API (POST)] RequestError: socket hang up
2 Jun 22:48:40 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:48:45 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:48:50 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:48:55 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:49:00 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:49:05 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:49:10 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:49:15 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:49:25 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:49:30 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:49:35 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:49:40 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:49:45 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:49:50 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:49:55 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:50:00 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET
2 Jun 22:50:05 - [error] [http request:Call 2 Zendure API (POST)] RequestError: read ECONNRESET

Ik laat hem even lopen, kan zijn dat het zich vanzelf hersteld, ook wel eens gezien.

Edit: Inmiddels properties Set 2 weer beschikbaar, 1 nog niet. Vanuit gielz de offgrid poort aansturing bv dan niet mogelijk (via proxy): Client error occurred when calling resource "http://192.168.2.50/properties/write, terwijl die zelfde Set 1 wel nu gewoon aangestuurd wordt door gielz m.b.t. ontladen.