Zendure producten in Home Assistant integreren deel 2

[Aardedraadje]

Devke schreef op woensdag 3 juni 2026 @ 00:51:
[...]

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.

Of het een oplossing voor jouw probleem is weet ik niet, maar ik had ook last van regelmatig wegvallen van de sensoren i.c.m. Gielz. Geen vastlopers, dat niet.

Dedicated AP voor de zendures net een meter van ze af, dus daar kon het niet aan liggen.

Toen heb ik de Rest interval op 2s gezet ipv 1s en sindsdien nauwelijks meer gezien.

[Devke]

Aardedraadje schreef op woensdag 3 juni 2026 @ 05:30:
[...]

Of het een oplossing voor jouw probleem is weet ik niet, maar ik had ook last van regelmatig wegvallen van de sensoren i.c.m. Gielz. Geen vastlopers, dat niet.

Dedicated AP voor de zendures net een meter van ze af, dus daar kon het niet aan liggen.

Toen heb ik de Rest interval op 2s gezet ipv 1s en sindsdien nauwelijks meer gezien.

Alle denkbare opties zijn welkom. AP ligt inderdaad dichtbij. Meter of 4 afstand denk ik.

[Devke]

Ik heb eens wat verder gegraven met ChatGPT. Testjes laten bedenken. Heb hem daar een samenvatting van laten maken.

Ik ben al een tijd aan het zoeken naar de oorzaak van problemen met mijn twee Zendure batterijen (IP's 192.168.2.50 en 192.168.2.58) die via Home Assistant en Node-RED worden uitgelezen.

## Situatie

* Home Assistant draait op een QNAP NAS.
* Node-RED draait ook op dezelfde NAS.
* Twee Zendure batterijen worden via de lokale API uitgelezen.
* Oorspronkelijk draaide alles via een oude TP-Link TL-WR941ND.
* Deze vervangen door een TP-Link Omada EAP650 access point.
* Zendures hebben een sterk WiFi-signaal:

* Zendure 1: -43 dBm
* Zendure 2: -34 dBm

## Symptomen

Node-RED geeft regelmatig fouten zoals:

* `RequestError: read ECONNRESET`
* `no response from server`
* `TypeError: values.original[x].packData is not iterable`

Hierdoor vallen de lokale API-gegevens weg.

## Wat getest is

### Netwerkbereik

Zendures hebben goed bereik (-43 en -34 dBm).

### Vast kanaal ingesteld

Op de Omada:

* 2.4 GHz vast op kanaal 6
* kanaalbreedte 20 MHz
* zendvermogen hoog

### Mesh en roaming uitgeschakeld

Op advies zijn Mesh/Fast Roaming functies uitgeschakeld omdat dit soms problemen kan geven bij IoT-apparaten.

Dit staat pas recent uit, echter daarna ook issues.

### Connectiviteit getest

Ping blijft werken.

TCP-poort 80 blijft bereikbaar:

```powershell
tnc 192.168.2.50 -Port 80
tnc 192.168.2.58 -Port 80
```

Resultaat:

```text
TcpTestSucceeded : True
```

voor beide batterijen.

### Lokale API getest

Endpoint:

```text
http://<ip>/properties/report
```

Resultaten:

#### Batterij 192.168.2.58

```text
curl: (52) Empty reply from server
```

#### Batterij 192.168.2.50

```text
curl: (56) Recv failure: Connection was aborted
```

Belangrijk:

* TCP-verbinding wordt opgezet.
* HTTP-request komt aan.
* Er komt geen bruikbare HTTP-response terug.

### Herstelacties

Wanneer problemen optreden:

* Reboot van het AP lijkt vaak te helpen.
* Batterijen uit- en aanzetten helpt ook.

Na een reset werkt de lokale API weer.

## Wat hiermee lijkt uitgesloten

* Slecht WiFi-bereik.
* Apparaten volledig offline.
* Poort 80 niet bereikbaar.
* IP-conflicten (voor zover zichtbaar).

## Openstaande vraag

Omdat:

* ping blijft werken,
* TCP-poort 80 bereikbaar blijft,
* maar de HTTP-response ontbreekt,

vraag ik mij af of:

1. de lokale Zendure HTTP/API-service vastloopt;
2. de Zendure WiFi-stack in een rare toestand terechtkomt;
3. Node-RED polling of API-verkeer de lokale webserver overbelast;
4. er een bekende firmwarebug in Zendure zit;
5. of dat iemand vergelijkbare ervaringen heeft met lokale API timeouts/ECONNRESET meldingen.

Ik heb vanmorgen 10 minuten NR eens uitgezet, 1 Zendure herstelde en gaf weer properties. Nr 2 niet. Reset gedaan van AP, had ook de Zendure kunnen zijn en het loopt weer.
(Samenvatting is door AI gegenereerd) / maakt het voor mij iets makkelijker het overzicht op dit lastige issue te krijgen.

[ZuinigeRijder]

Aardedraadje schreef op woensdag 3 juni 2026 @ 05:30:
[...]

Of het een oplossing voor jouw probleem is weet ik niet, maar ik had ook last van regelmatig wegvallen van de sensoren i.c.m. Gielz. Geen vastlopers, dat niet.

Dedicated AP voor de zendures net een meter van ze af, dus daar kon het niet aan liggen.

Toen heb ik de Rest interval op 2s gezet ipv 1s en sindsdien nauwelijks meer gezien.

Waar heb je het rest interval van 1s naar 2s aangepast? Op twee plaatsten?

code:

rest:
  - resource_template: "http://{{ states('input_text.zendure_2400_ac_ip_adres') }}/properties/report"
    scan_interval: 1
    sensor:
      - name: "Zendure 2400 AC Batterij 1 Celbalans Status"

en

code:

- resource_template: "http://{{ states('input_text.homewizard_p1_ip_adres') }}/api/v1/data"
    scan_interval: 1
    sensor:
      - name: "Homewizard P1 Vermogen"

Of (nog) ergens anders?

[RemmyB83]

Devke schreef op woensdag 3 juni 2026 @ 00:51:
[...]

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.

Waar haal je die gegevens precies uit NR?
Al denk ik dat onze problemen niet het zelfde zijn.
Ik had bijvoorbeeld dit gisteren
Om +/- 13:30 wordt NOM niet meer gevolgd.
Gielz gaat even later in standby, en de batterij krijgt nog wel opdrachten. Maar voert ze niet uit.

Pas na ingrijpen van mijn kant, wordt NOM hervat.

@Mscroos heb je vergelijkbare problemen? Of toch weer net iets anders?

[ZuinigeRijder]

Aardedraadje schreef op woensdag 3 juni 2026 @ 05:30:
[...]

Of het een oplossing voor jouw probleem is weet ik niet, maar ik had ook last van regelmatig wegvallen van de sensoren i.c.m. Gielz. Geen vastlopers, dat niet.

Dedicated AP voor de zendures net een meter van ze af, dus daar kon het niet aan liggen.

Toen heb ik de Rest interval op 2s gezet ipv 1s en sindsdien nauwelijks meer gezien.

Ik heb "Standby Vertaging" van 30 minuten naar 1440 minuten gezet in de settings van @gielz

gielz in "Zendure producten in Home Assistant integreren deel 2"

En singleMode_delayed_standby_timer op 86400 seconden gezet in Node red van @gast777 :
gast777 in "Zendure producten in Home Assistant integreren deel 2"

Hierdoor blijven mijn 2x Solarflow 800 Plus nu in Opslagmode RAM. Tot nu toe (nog maar een paar dagen lopen) is het probleem (nog) niet teruggekomen. Maar het is te kort om te zeggen dat dit het probleem (mogelijk) oplost.

[Devke]

RemmyB83 schreef op woensdag 3 juni 2026 @ 08:22:
[...]

Waar haal je die gegevens precies uit NR?
Al denk ik dat onze problemen niet het zelfde zijn.
Ik had bijvoorbeeld dit gisteren[Afbeelding]
Om +/- 13:30 wordt NOM niet meer gevolgd.
Gielz gaat even later in standby, en de batterij krijgt nog wel opdrachten. Maar voert ze niet uit.
[Afbeelding]
Pas na ingrijpen van mijn kant, wordt NOM hervat.

@Mscroos heb je vergelijkbare problemen? Of toch weer net iets anders?

NR draait hier op een NAS in docker. Daar kan ik NR aanklikken en in de logfile kijken. Ik denk dat NR hier de opdrachten wel stuurt maar de batterij al te ver is. Soms nog wel gewoon reactie, soms ook totaal niet meer. Het zou dus zomaar hetzelfde kunnen zijn? Pas na Reboot AP of Zendure is het direct goed weer. Soms hersteld het zich vanzelf maar dat is mondjes maat. Je zou je AP eens kunnen rebooten ter vergelijk. Werkt het dan ook weer?

[ Voor 6% gewijzigd door Devke op 03-06-2026 08:31 ]

[gielz]

ZuinigeRijder schreef op woensdag 3 juni 2026 @ 08:26:
[...]


Ik heb "Standby Vertaging" van 30 minuten naar 1440 minuten gezet in de settings van @gielz

gielz in "Zendure producten in Home Assistant integreren deel 2"

En singleMode_delayed_standby_timer op 86400 seconden gezet in Node red van @gast777 :
gast777 in "Zendure producten in Home Assistant integreren deel 2"

Hierdoor blijven mijn 2x Solarflow 800 Plus nu in Opslagmode RAM. Tot nu toe (nog maar een paar dagen lopen) is het probleem (nog) niet teruggekomen. Maar het is te kort om te zeggen dat dit het probleem (mogelijk) oplost.

Zou zo maar kunnen dat die smartmode hem actief houd. Ik draai hier nu 12 maanden zonder downtime. Het grote verschil tov de meeste is dat smartmode hier nooit uit gaat. Er is altijd activiteit tijdens NOM.

[RemmyB83]

Devke schreef op woensdag 3 juni 2026 @ 08:29:
[...]

NR draait hier op een NAS in docker. Daar kan ik NR aanklikken en in de logfile kijken. Ik denk dat NR hier de opdrachten wel stuurt maar de batterij al te ver is. Soms nog wel gewoon reactie, soms ook totaal niet meer. Het zou dus zomaar hetzelfde kunnen zijn? Pas na Reboot AP of Zendure is het direct goed weer. Soms hersteld het zich vanzelf maar dat is mondjes maat. Je zou je AP eens kunnen rebooten ter vergelijk. Werkt het dan ook weer?

Ik draai NR in HA op een HP T630.
Ik kan NR dan ook niet aanklikken en logfile bekijken. En in NR zelf heb ik ook geen idee, waar ik vergelijkbare gegevens als die van jouw kan vinden.
Ik kreeg ze tot nu toe aan de praat zonder ap te herstarten, maar zal het volgende keer eens proberen. Ap op nog geen 5meter afstand, maar helaas verbinden ze nog wel eens met eentje die verder weg is. Verbinding is dan ook niet altijd optimaal, maar dat is het bij jouw wel en dan kun je dus ook nog problemen hebben.
Ik heb overigens net de suggestie van @Aardedraadje (bedankt daarvoor)toegepast, misschien dat het helpt.

[ZuinigeRijder]

gielz schreef op woensdag 3 juni 2026 @ 08:49:
[...]


Zou zo maar kunnen dat die smartmode hem actief houd. Ik draai hier nu 12 maanden zonder downtime. Het grote verschil tov de meeste is dat smartmode hier nooit uit gaat. Er is altijd activiteit tijdens NOM.

Gebruik je ook de proxy? Of maar 1 systeem? Omdat de proxy van @gast777 de omvormer naar Flash zet ná 5 minuten geen opdrachten, ongeacht de setting "Standby Vertraging".

[gielz]

ZuinigeRijder schreef op woensdag 3 juni 2026 @ 08:53:
[...]


Gebruik je ook de proxy? Of maar 1 systeem? Omdat de proxy van @gast777 de omvormer naar Flash zet ná 5 minuten geen opdrachten, ongeacht de setting "Standby Vertraging".

Ik gebruik geen proxy. En dus de gielz zoals die is met 15 min standby vertraging de afgelopen 12 maanden.

[Devke]

ZuinigeRijder schreef op woensdag 3 juni 2026 @ 08:53:
[...]


Gebruik je ook de proxy? Of maar 1 systeem? Omdat de proxy van @gast777 de omvormer naar Flash zet ná 5 minuten geen opdrachten, ongeacht de setting "Standby Vertraging".

Ik heb net de standby vertraging ook eens naar 1440 minuten gezet. De Zendures even laten laden. Standby verbruik kan ik zien via de HW kWh MID meter. Set 1 staat dus werkelijk iets te verbruiken, Set 2 niet maar staan toch beiden in RAM volgens de sensoren.

[ZuinigeRijder]

@Devke De proxy zet de Opslagmode naar Flash bij 5 minuten inactiviteit.
Dus je moet óók het volgende aanpassen:

singleMode_delayed_standby_timer op 86400 seconden (of een lager getal) in Node red van @gast777 :
gast777 in "Zendure producten in Home Assistant integreren deel 2"

P.S. is de noodstroom-uitgang actief bij één van de beide batterijen?

[ Voor 10% gewijzigd door ZuinigeRijder op 03-06-2026 09:24 ]

[Devke]

ZuinigeRijder schreef op woensdag 3 juni 2026 @ 09:23:
@Devke De proxy zet de Opslagmode naar Flash bij 5 minuten inactiviteit.
Dus je moet óók het volgende aanpassen:

singleMode_delayed_standby_timer op 86400 seconden (of een lager getal) in Node red van @gast777 :
gast777 in "Zendure producten in Home Assistant integreren deel 2"

P.S. is de noodstroom-uitgang actief bij één van de beide batterijen?

aangepast, opgeslagen middels deploy. Situatie blijft hetzelfde.

[ZuinigeRijder]

@Devke Jij hebt 2x 2400 AC, ik 2x 800 Plus. Die van mij heeft geen noodstroom uitgang. Bij mij zijn ze allebei 0 Watt (beide gemeten door HomeWizard Energy Socket).
Jij hebt de noodstroom uitgang (Offgrid modus) uitgezet bij beide?

[ Voor 3% gewijzigd door ZuinigeRijder op 03-06-2026 09:33 ]

[Devke]

ZuinigeRijder schreef op woensdag 3 juni 2026 @ 09:32:
@Devke Jij hebt 2x 2400 AC, ik 2x 800 Plus. Die van mij heeft geen noodstroom uitgang. Bij mij zijn ze allebei 0 Watt (beide gemeten door HomeWizard Energy Socket).
Jij hebt de noodstroom uitgang (Offgrid modus) uitgezet bij beide?

Yep beide zijn uit. Maar ik denk dat we het over iets verschillends hebben? Ik heb het over de Standby vertraging in gielz en gast777 proxy integratie.

[Devke]

ZuinigeRijder schreef op woensdag 3 juni 2026 @ 09:32:
@Devke Jij hebt 2x 2400 AC, ik 2x 800 Plus. Die van mij heeft geen noodstroom uitgang. Bij mij zijn ze allebei 0 Watt (beide gemeten door HomeWizard Energy Socket).
Jij hebt de noodstroom uitgang (Offgrid modus) uitgezet bij beide?

Kijk hier zie je ook dat bij handmatig ze aanzwengelen nr 2 ook uit slaap moet komen lijkt.



Nr 1 pakt de standby vertraging op nr 2 niet. Smartmode staat op 1 als ik de properties bekijk. Bij beide.

[ Voor 6% gewijzigd door Devke op 03-06-2026 09:39 ]

[Mistraller]

Die connectieproblemen heb ik hier ook veelvuldig gezien, met name als de zendures direct aan mijn deco gekoppeld zijn, en niet als er een domme slechte repeater tussen zit. En dan doet Gielz het niet meer, maar de app nog wel.
Ik denk ook dat de zendure webserver cq implementatie ermee samenhangt. Maar dan meer op laag 4 of zo; TCP connectie die open blijft staan oid.

[wautah91]

DaGoose schreef op dinsdag 2 juni 2026 @ 16:25:
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?

Omdat de Hyper2000 alleen werkt met communicatie via MQTT. De nieuwe zendures kunnen ook via REST communiceren waar gielz gebruik van maakt. Om de gielz automatisering te gebruiken met een Hyper2000 kun je gebruik maken van mijn Hyper2000 proxy. Werkt bij mijzelf al maanden goed, heb nog geen berichten van andere testers. Ik gebruik zelf de NL variant van de gielz package met één Hyper. @gielz misschien goed om in jouw readme ook een verwijzing te zetten naar de Hyper-proxy zodat ook Hyper2000 gebruikers met jouw package aan de gang kunnen?

[oeps]

Hi all,
Ik heb een klein zetje nodig:
Ben me aan het voorbereiden om volgende maand over te gaan naar een dynamisch contract.
Uitgangspunt:

• De Gielz1986zendure integratie werkt als een tierelier met de 2400 Pro.

Net geïnstalleerd:

• De HACS Nordpool integratie en de huidige prijs zie ik in de sensor.nordpool.
• Bij het toevoegen van Nord pool had ik als testje even een template toegevoegd om later de opslag van mijn energieleverancier in te zetten. Waar kan ik deze template achteraf aanpassen?
  Ik zie geen config optie bij de integratie of is het weggooien en opnieuw aanmaken?
• Ben ik klaar zodra ik de sensor.nordpool correct heb of moet ik nog helpers/templates/automations aanmaken? Ik zie in dit topic yaml voorbeelden maar vraag me af of dat custom dingen zijn of noodzakelijke?
• Het lijkt er ook op dat nordpool nu via de gui gaat en dat er yaml code nu niet meer van toepassing is, klopt dat?
• Ik wil handig gebruik maken van lage/hoge prijzen en dan vooral er zo min mogelijk mee bezig zijn.Voegt dan aio_energy_management iets toe voor wat ik wil?

Dank!

[Tiesert]

oeps schreef op woensdag 3 juni 2026 @ 12:34:
Hi all,
Ik heb een klein zetje nodig:
Ben me aan het voorbereiden om volgende maand over te gaan naar een dynamisch contract.
Uitgangspunt:

• De Gielz1986zendure integratie werkt als een tierelier met de 2400 Pro.

Net geïnstalleerd:

• De HACS Nordpool integratie en de huidige prijs zie ik in de sensor.nordpool.
• Bij het toevoegen van Nord pool had ik als testje even een template toegevoegd om later de opslag van mijn energieleverancier in te zetten. Waar kan ik deze template achteraf aanpassen?
  Ik zie geen config optie bij de integratie of is het weggooien en opnieuw aanmaken?
• Ben ik klaar zodra ik de sensor.nordpool correct heb of moet ik nog helpers/templates/automations aanmaken? Ik zie in dit topic yaml voorbeelden maar vraag me af of dat custom dingen zijn of noodzakelijke?
• Het lijkt er ook op dat nordpool nu via de gui gaat en dat er yaml code nu niet meer van toepassing is, klopt dat?
• Ik wil handig gebruik maken van lage/hoge prijzen en dan vooral er zo min mogelijk mee bezig zijn.Voegt dan aio_energy_management iets toe voor wat ik wil?

Dank!

Hi, ben juist overgestapt van HACS Nordpool naar de Nordpool-integratie die tegenwoordig standaard in HA zit. Verder inderdaad AIO gebruikt om makkelijk allerlei tijdblokken te maken met goedkope of juist dure uren afhankelijk van het doel. En dan de agenda op het dashboard voor het overzicht wanneer die uren zijn.

Met deze aanpassing om de BTW voor NL mee te nemen. Een aparte input voor bijkomende kosten kan ook.

code:

price_modifications: >
          {%- set as_snt = price / 10.0 %} # naar centen
          {%- set with_taxes = (as_snt * 1.21) | float %} # plus BTW
          {{ with_taxes }}

Ik vond handig:
# https://www.creatingsmarthome.com/index.php/2025/09/12/home-assistant-migrating-to-the-official-nord-pool-integration/

# https://www.creatingsmarthome.com/index.php/2024/07/27/home-assistant-nord-pool-cheapest-hours-with-aio-energy-management/

[ Voor 8% gewijzigd door Tiesert op 03-06-2026 14:28 ]

[Gramser]

Mijn @gielz / @gast777 combi draait niet echt lekker de laatste dagen. Alsof één toren steeds een connectie verliest en blijft hangen op het laatste bekende commando (laden, of ontladen, of standby etc). Ik draai NoM. Als ik hem in HEMS zet lijkt het wel goed te gaan en doet de toren weer actief mee. Ik heb vanochtend de torens alweer gereset (tweede keer in drie dagen) maar ditmaal kwam het probleem bijna meteen weer terug. Ik herstart HA maar eens een keer en kijk of dat werkt. Ik moet het wat langer monitoren op een groot scherm om de grafieken ook beter te kunnen zien, zodat ik het issue hier ook wat beter kan voorleggen. Maar HEMS houdt hem minder mooi op de nul dan Gielz (wanneer die lekker werkt).

In HEMS luisteren de torentjes overigens naar de Zendure P1-meter. In HA naar een HomWizard. Schakelen jullie de Zendure P1 meter uit als je met HA werkt? Bijt dat elkaar niet stiekem, als je die aangesloten houdt?

[ctrl-tab]

Tiesert schreef op woensdag 3 juni 2026 @ 14:21:
[...]

Hi, ben juist overgestapt van HACS Nordpool naar de Nordpool-integratie die tegenwoordig standaard in HA zit. Verder inderdaad AIO gebruikt om makkelijk allerlei tijdblokken te maken met goedkope of juist dure uren afhankelijk van het doel. En dan de agenda op het dashboard voor het overzicht wanneer die uren zijn.

Ik vond handig:
# https://www.creatingsmarthome.com/index.php/2025/09/12/home-assistant-migrating-to-the-official-nord-pool-integration/

# https://www.creatingsmarthome.com/index.php/2024/07/27/home-assistant-nord-pool-cheapest-hours-with-aio-energy-management/

Gebruik zelf ook de builtin nordpool integration en de AIO energy management plugin.
Nadeel van builtin nordpool integratie is dat die maar 1 configuratie accepteert. En ik wil minimaal losse prijzen zien van:
- inkoop prijs
- verkoop prijs voor zonsondergang (met zonnebonus)
- verkoop prijs na zonsondergang (zonder zonnebonus)
- verkoop prijs (2027)
- ...

Daarin vult AIO Energy management aan gezien die zelf price modifications doet. Bovendien inzetbaar voor meerdere doeleinden dan alleen battery charging.
Ik vind het chargen op een spread percentage (gielz) niet handig, ik wil chargen op basis van een bepaalde threshold in centen per kwh. Dat los ik op met automations.

Van de andere kant is de Gielz integratie visueel wel top.
Om die reden heb ik een HA Nordpool --> HACS Nordpool conversie template in HA staan zodat ik wel de mooie plaatjes in Gielz heb want de interface is top!

[oeps]

@Tiesert , @ctrl-tab , Dank je voor de zet!
@ctrl-tab , Zou je die conversie template kunnen delen? De ingebouwde Nord pool scheelt weer een hacs integratie en als ik de nadelen met conversie kan verzachten zou dat top zijn!
Uiteindelijk wil ik ook het liefst op spread in centen per kWh (zit dat ook in die conversie template?). Beetje dubbel is het wel, verlies in de batterij is een % en de kostencomponenten zijn in centen/kWh. in hoeverre dat wel/niet lood om oud ijzer is binnen prijsmarges gaan we meemaken.
Dank!

[ctrl-tab]

oeps schreef op woensdag 3 juni 2026 @ 15:27:
@Tiesert , @ctrl-tab , Dank je voor de zet!
@ctrl-tab , Zou je die conversie template kunnen delen? De ingebouwde Nord pool scheelt weer een hacs integratie en als ik de nadelen met conversie kan verzachten zou dat top zijn!
Uiteindelijk wil ik ook het liefst op spread in centen per kWh (zit dat ook in die conversie template?). Beetje dubbel is het wel, verlies in de batterij is een % en de kostencomponenten zijn in centen/kWh. in hoeverre dat wel/niet lood om oud ijzer is binnen prijsmarges gaan we meemaken.
Dank!

Zeker, bij deze. Sterker nog je kunt de builtin niet naast de HACS draaien, dan komen de sensoren in de knoop.

Let op ik doe een conversie van kwartier-prijzen naar uur-prijzen gezien ik bij zonneplan zit en die een gemiddelde pakken van de 4 kwartieren.
Ook gebruik ik input numbers voor de variablen zoals btw, zonnebonus etc.

De spread in centen bereken ik als volgt.
Input number, daarin staat nu 0,12 (vanaf 12 cent verschil wil ik handelen, anders gewoon NOM)
Ik heb een automation waar ik de gemiddelde duurste prijs in de avond vergelijk met de gemiddelde prijs waarmee ik geladen heb (automation gooit die prijs in een last_charged_price input number zodat ik weet wat de prijs van de opgeslagen stroom was, ook voor andere afwegingen

Als dat verschil meer dan 12 cent is ga ik dischargen in de avond. Op dit moment gooi ik hem dan helemaal leeg. In 2027 wordt het wat dynamischer (ook winst morgen meenemen, en als het niet zonnig wordt laat ik hem ook met rust en nog wat zaken).

Tip: Claude is echt enorm sterk in het bouwen van templates en automations.

Edit: @oeps je moet ook nog wat zaken wijzigen in de template file van gielz trouwens;

code:

sed -i 's/{{ item\.start\.isoformat() }}/{{ item.start if item.start is string else item.start.isoformat() }}/g' zendure_gielz1986_global.yaml
sed -i 's/{{ item\.end\.isoformat() }}/{{ item.end if item.end is string else item.end.isoformat() }}/g' zendure_gielz1986_global.yaml

code:

      # --- CURRENT PRICE (mimics old HACS sensor) ---
      - name: nordpool_kwh_nl_eur_3_095_0
        unique_id: nordpool_kwh_nl_eur_3_095_0
        unit_of_measurement: "EUR/kWh"
        icon: mdi:currency-eur
        state_class: measurement
        state: >
          {% set opslag = states('input_number.energy_opslag') | float(0) %}
          {% set vat    = states('input_number.energy_vat')    | float(0) %}
          {% set tax    = states('input_number.energy_tax')    | float(0) %}
          {% if today_price is mapping and today_price['NL'] | list | count > 0 %}
            {% set now_slot = now().replace(second=0, microsecond=0) %}
            {% set now_slot = now_slot.replace(minute=(now_slot.minute // 15) * 15) %}
            {% set current = namespace(price=none) %}
            {% for state in today_price['NL'] %}
              {% set slot_start = state.start | as_datetime | as_local %}
              {% if slot_start == now_slot %}
                {% set current.price = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
              {% endif %}
            {% endfor %}
            {{ current.price | default('unavailable') }}
          {% else %}
            unavailable
          {% endif %}
        attributes:
          current_price: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% if today_price is mapping and today_price['NL'] | list | count > 0 %}
              {% set now_slot = now().replace(second=0, microsecond=0) %}
              {% set now_slot = now_slot.replace(minute=(now_slot.minute // 15) * 15) %}
              {% set current = namespace(price=none) %}
              {% for state in today_price['NL'] %}
                {% set slot_start = state.start | as_datetime | as_local %}
                {% if slot_start == now_slot %}
                  {% set current.price = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% endif %}
              {% endfor %}
              {{ current.price | default(none) }}
            {% else %}
              {{ none }}
            {% endif %}
          today: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [(data.group | sum / 4) | round(5)] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}
          tomorrow: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[]) %}
            {% if tomorrow_price is mapping %}
              {% for state in tomorrow_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [(data.group | sum / 4) | round(5)] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}
          tomorrow_valid: >
            {{ tomorrow_price is mapping and tomorrow_price['NL'] | list | count > 0 }}
          average: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [(data.group | sum / 4)] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
              {{ (data.prices | sum / data.prices | count) | round(5) }}
            {% else %}
              {{ 0 }}
            {% endif %}
          low_price: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set cutoff = 0.95 %}
            {% set data = namespace(prices=[], group=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [(data.group | sum / 4)] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
              {% set avg = data.prices | sum / data.prices | count %}
              {% set now_slot = now().replace(second=0, microsecond=0) %}
              {% set now_slot = now_slot.replace(minute=(now_slot.minute // 15) * 15) %}
              {% set current = namespace(price=avg) %}
              {% for state in today_price['NL'] %}
                {% set slot_start = state.start | as_datetime | as_local %}
                {% if slot_start == now_slot %}
                  {% set current.price = ((state.price / 1000 + tax + opslag) * (1 + vat)) %}
                {% endif %}
              {% endfor %}
              {{ current.price < avg * cutoff }}
            {% else %}
              {{ false }}
            {% endif %}
          raw_today: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[], starts=[], ends=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 1 %}
                  {% set data.starts = data.starts + [state.start] %}
                {% endif %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [{'start': data.starts[-1], 'end': state.end, 'value': (data.group | sum / 4) | round(5)}] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}
          raw_tomorrow: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[], starts=[], ends=[]) %}
            {% if tomorrow_price is mapping %}
              {% for state in tomorrow_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 1 %}
                  {% set data.starts = data.starts + [state.start] %}
                {% endif %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [{'start': data.starts[-1], 'end': state.end, 'value': (data.group | sum / 4) | round(5)}] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}

[ Voor 4% gewijzigd door ctrl-tab op 03-06-2026 20:40 ]

[Hippe Lip]

Tiesert schreef op woensdag 3 juni 2026 @ 14:21:
Hi, ben juist overgestapt van HACS Nordpool naar de Nordpool-integratie die tegenwoordig standaard in HA zit.

Zit die tegenwoordig standaard in HA of bedoel je dat het een integratie is die op de standaard lijst staat en zo via Settings > Devices & Services > Add Integration toegevoegd kan worden, @Tiesert?

[Devke]

Gramser schreef op woensdag 3 juni 2026 @ 14:36:
Mijn @gielz / @gast777 combi draait niet echt lekker de laatste dagen. Alsof één toren steeds een connectie verliest en blijft hangen op het laatste bekende commando (laden, of ontladen, of standby etc). Ik draai NoM. Als ik hem in HEMS zet lijkt het wel goed te gaan en doet de toren weer actief mee. Ik heb vanochtend de torens alweer gereset (tweede keer in drie dagen) maar ditmaal kwam het probleem bijna meteen weer terug. Ik herstart HA maar eens een keer en kijk of dat werkt. Ik moet het wat langer monitoren op een groot scherm om de grafieken ook beter te kunnen zien, zodat ik het issue hier ook wat beter kan voorleggen. Maar HEMS houdt hem minder mooi op de nul dan Gielz (wanneer die lekker werkt).

In HEMS luisteren de torentjes overigens naar de Zendure P1-meter. In HA naar een HomWizard. Schakelen jullie de Zendure P1 meter uit als je met HA werkt? Bijt dat elkaar niet stiekem, als je die aangesloten houdt?

Wat gebeurd er als je niet je Zendure reset maar je AP bij dit issue?

[Gramser]

Mijn Zendures waren echt van het padje vandaag. Enorm veel relaisschakelingen, en ongefundeerd gestuiter. HEMS of Gielz maakte eigenlijk niet uit. Ik kreeg op enig moment het idee dat het -in HEMS- wel eens aan de Zendure P1-meter kon liggen. Alsof die verkeerde waardes aangaf. En concurreerde met de HW P1 die Gielz gebruikt. Ik heb de Zendure P1 eens uitgeschakeld en vanaf toen leek het beter te gaan. Daarna terug naar Gielz, en na een tijdje stabiliseerde het beeld zich. Nu werkt alles weer naar behoren (behalve HEMS natuurlijk). Raar gedoe. Benieuwd wat er gebeurt als ik die Zendure P1-meter weer verbindt. Plaatjes bij het praatje:


Stuiterende HW-weergave


Stuiterstuiter met erna flatliner


Na flatliner volgt Gielz de hartslag weer…

[Gramser]

Devke schreef op woensdag 3 juni 2026 @ 18:11:
[...]

Wat gebeurd er als je niet je Zendure reset maar je AP bij dit issue?

Ik gebruik geen dedicated accesspoint meer… of bedoel je dat niet?

[ Voor 6% gewijzigd door Gramser op 03-06-2026 18:17 ]

[Pakhaas]

@Gramser heb je dan de Zendure P1 en HW P1 tegelijk aan?

[ctrl-tab]

Hippe Lip schreef op woensdag 3 juni 2026 @ 17:59:
[...]

Zit die tegenwoordig standaard in HA of bedoel je dat het een integratie is die op de standaard lijst staat en zo via Settings > Devices & Services > Add Integration toegevoegd kan worden, @Tiesert?

Je hebt hacs niet nodig voor de nordpool integratie, zit er standaard in tegenwoordig.

Eerlijk is eerlijk,.hij is minder goed dan de hacs versie. O.a. niet mogelijk meerdere configs te maken, service gebaseerd dus je moet met templates aan de gang. Niet compatible met hacs versie dus qua sensoren.
Maarja beter dan een custom integratie imo.

Maar je kan die backwards compatibility zelf bouwen met templates (zie code hierboven ergens)

[Gramser]

Pakhaas schreef op woensdag 3 juni 2026 @ 18:20:
@Gramser heb je dan de Zendure P1 en HW P1 tegelijk aan?

Ja. Anders kan ik niks met HEMS als ik Gielz disable. En op afstand al helemaal niet 🙂. Maar dat zou elkaar niet moeten bijten toch? HEMS is Zendure P1, Gielz is HW P1

[Pakhaas]

Geen idee. Ik heb alleen een HW P1 meter en godzijdank werkt die ook in HEMS. Maar gelukkig nog niet HEMS nodig gehad.

[Devke]

Gramser schreef op woensdag 3 juni 2026 @ 18:17:
[...]


Ik gebruik geen dedicated accesspoint meer… of bedoel je dat niet?

Yep. Ik ben namelijk benieuwd of je met een netwerk reset het ook weer werkend krijgt.

[Gramser]

Dat zal ik dan een volgende keer eens proberen - vereist in mijn geval dan een modemreset.

[Devke]

Gramser schreef op woensdag 3 juni 2026 @ 20:05:
Dat zal ik dan een volgende keer eens proberen - vereist in mijn geval dan een modemreset.

Dankje. Ben benieuwd. Hier zorgt dat ervoor dat de besturing ook weer goed gaat. Ik probeer de vinger te leggen op het wegvallen van de verbindingen steeds.

[Gramser]

Het houdt je bezig, die batterijtjes

[_AcS_]

Devke schreef op woensdag 3 juni 2026 @ 20:10:
[...]

Dankje. Ben benieuwd. Hier zorgt dat ervoor dat de besturing ook weer goed gaat. Ik probeer de vinger te leggen op het wegvallen van de verbindingen steeds.

Heb je dat wegvallen van de verbinding ook als je alleen HEMS gebruikt, dus geen HA?

[RemmyB83]

Devke schreef op woensdag 3 juni 2026 @ 19:57:
[...]

Yep. Ik ben namelijk benieuwd of je met een netwerk reset het ook weer werkend krijgt.

Yup, hier reageerde batterij nr 3 niet meer in gielz, en bleef hangen op ontladen met 800W.
Met HEMS op 0 gezet, en vervolgens HEMS uit. Daarna reageerde hij ook niet op opdrachten van Gielz/proxy.

Dit terwijl ik vandaag:
- de interval van 1 naar 2sec heb gezet (tip van @Aardedraadje)
Ram naar flash interval van 5min naar 60min heb gezet, staat nu op 7200(2uur). (Tip van @ZuinigeRijder)

Na een reset van mijn modem(fritzbox), kwam hij weer tot leven. Maar was verbonden met mijn fritzbox repeater, die ik niet heb gereset. En is nu weer verbonden met mijn modem, en niet de repeater.

Edit: heb nu ook de Zendure P1 er maar uitgehaald. Misschien dat die toch zit te kwarren, net als dat je niet 100% lokaal kan gaan zonder problemen.

[ Voor 9% gewijzigd door RemmyB83 op 03-06-2026 21:25 ]

[Tiesert]

Hippe Lip schreef op woensdag 3 juni 2026 @ 17:59:
[...]

Zit die tegenwoordig standaard in HA of bedoel je dat het een integratie is die op de standaard lijst staat en zo via Settings > Devices & Services > Add Integration toegevoegd kan worden, @Tiesert?

Ja dat laatste zoals @ctrl-tab al aangaf, Bij de HACS versie zie je nu ook een ander kleurtje om aan te geven dat hij iets vervangt wat al standaard in HA beschikbaar is,

[Devke]

RemmyB83 schreef op woensdag 3 juni 2026 @ 21:02:
[...]

Yup, hier reageerde batterij nr 3 niet meer in gielz, en bleef hangen op ontladen met 800W.
Met HEMS op 0 gezet, en vervolgens HEMS uit. Daarna reageerde hij ook niet op opdrachten van Gielz/proxy.

Dit terwijl ik vandaag:
- de interval van 1 naar 2sec heb gezet (tip van @Aardedraadje)
Ram naar flash interval van 5min naar 60min heb gezet, staat nu op 7200(2uur). (Tip van @ZuinigeRijder)

Na een reset van mijn modem(fritzbox), kwam hij weer tot leven. Maar was verbonden met mijn fritzbox repeater, die ik niet heb gereset. En is nu weer verbonden met mijn modem, en niet de repeater.

Edit: heb nu ook de Zendure P1 er maar uitgehaald. Misschien dat die toch zit te kwarren, net als dat je niet 100% lokaal kan gaan zonder problemen.

Hier werd het er ook niet beter op, AP denk ik vandaag al 3x herstart en meteen weer leven. Ik ben even met wat leute aan het kijken. Ik ga even terug naar de basis. 1 Set, alleen gielz. Kijken of die basis stabiel is. Gaat even wat tijd kosten weer maar zie ff geen andere mogelijkheid. Voor mijn gevoel alles al wel een x geprobeerd. Dank voor je terugkoppeling.

[Devke]

_AcS_ schreef op woensdag 3 juni 2026 @ 20:22:
[...]

Heb je dat wegvallen van de verbinding ook als je alleen HEMS gebruikt, dus geen HA?

Niet geprobeerd (nog). Zie vorige post van me hiervoor.

[Hippe Lip]

Tiesert schreef op woensdag 3 juni 2026 @ 22:09:
[...]

Ja dat laatste zoals @ctrl-tab al aangaf, Bij de HACS versie zie je nu ook een ander kleurtje om aan te geven dat hij iets vervangt wat al standaard in HA beschikbaar is,

@Tiesert Ik blijf het toch opvallend en verwarrend vinden als @ctrl-tab en jij het hebben over dat het er al standaard in zit.

Begin dit jaar heb ik de HACS-versie er even uitgekieperd omdat ik met de standaard integratieversie aan de slag wilde, maar daarvoor moest ik toch echt een integratie installeren. Die is dus niet standaard in HA aanwezig, die zit niet standaard in HA als je die nieuw installeert. Daarvoor moet je toch echt iets extra’s doen, toch?

Of hebben we het nou toch over hetzelfde?

[raven22]

Gramser schreef op woensdag 3 juni 2026 @ 18:45:
[...]

Ja. Anders kan ik niks met HEMS als ik Gielz disable. En op afstand al helemaal niet 🙂. Maar dat zou elkaar niet moeten bijten toch? HEMS is Zendure P1, Gielz is HW P1

Gielz werkt ook prima met de Zendure P1, dus waarom de hw P1 niet verwijderen?

[Gramser]

raven22 schreef op donderdag 4 juni 2026 @ 05:31:
[...]

Gielz werkt ook prima met de Zendure P1, dus waarom de hw P1 niet verwijderen?

Omdat ik de HW P1 gebruik voor de HW-omgeving hier in huis…

[ctrl-tab]

Hippe Lip schreef op woensdag 3 juni 2026 @ 23:57:
[...]

@Tiesert Ik blijf het toch opvallend en verwarrend vinden als @ctrl-tab en jij het hebben over dat het er al standaard in zit.

Begin dit jaar heb ik de HACS-versie er even uitgekieperd omdat ik met de standaard integratieversie aan de slag wilde, maar daarvoor moest ik toch echt een integratie installeren. Die is dus niet standaard in HA aanwezig, die zit niet standaard in HA als je die nieuw installeert. Daarvoor moet je toch echt iets extra’s doen, toch?

Of hebben we het nou toch over hetzelfde?

[Afbeelding]

Ja die moet je toevoegen zoals iedere integratie.

[Wai_AM]

Hippe Lip schreef op woensdag 3 juni 2026 @ 23:57:
[...]

@Tiesert Ik blijf het toch opvallend en verwarrend vinden als @ctrl-tab en jij het hebben over dat het er al standaard in zit.

Begin dit jaar heb ik de HACS-versie er even uitgekieperd omdat ik met de standaard integratieversie aan de slag wilde, maar daarvoor moest ik toch echt een integratie installeren. Die is dus niet standaard in HA aanwezig, die zit niet standaard in HA als je die nieuw installeert. Daarvoor moet je toch echt iets extra’s doen, toch?

Of hebben we het nou toch over hetzelfde?

[Afbeelding]

@ctrl-tab @Tiesert
post in april : https://gathering.tweakers.net/forum/view_message/85023966
Je maakt een kopie na sensor genaamd

code:

      - name: nordpool_kwh_nl_eur_5_10_0
        unique_id: nordpool_kwh_nl_eur_5_10_0

en de formule aanpast zonder energiebelasting en btw, dan heb je zowel met als zonder met de officiele nordpool

[DaGoose]

Devke schreef op woensdag 3 juni 2026 @ 22:15:
[...]

Hier werd het er ook niet beter op, AP denk ik vandaag al 3x herstart en meteen weer leven. Ik ben even met wat leute aan het kijken. Ik ga even terug naar de basis. 1 Set, alleen gielz. Kijken of die basis stabiel is. Gaat even wat tijd kosten weer maar zie ff geen andere mogelijkheid. Voor mijn gevoel alles al wel een x geprobeerd. Dank voor je terugkoppeling.

Ik ben ook al even aan het stoeien met wegvallende verbindingen met 2 hypers. Ik was eerst ook bezig met wifi. Apart/decicated accespoint en SSID geprobeerd (op 2m afstand) waarvoor ik zelfs met HA met een ping die wegvalt de POE uit/aan zet en zo het accespoint automatisch reset. Dat werkte op zich, maar in sommige gevallen niet, want dan bleef de wifi verbinding wel open staan en de ping reply dus ook. Van alles geprobeerd, andere kanalen, settings, je kent het, niks hielp eigenlijk echt. Tot ik van de week ineens dacht, ik ga eens proberen om in de integratie (ik gebruik de zendure integratie) de connection mode van local (wat je wilt eigenlijk) naar cloud (je wilt het eigenlijk niet) te zetten. Inmiddels draait hij daar nu al 2 dagen mee zonder 1 hickup.

Ik heb destijds ook een tijdje met HEMS (eerste versie) gedraaid en ik kan mij niet herrineren dat ik toen wel eens een hangende hyper had op deze manier. Maar dat is ook een (deels in ieder geval toch?) cloud verbinding.
Zijn hier al meer mensen mee aan het experimenteren geweest?

[Gramser]

Ik probeer ervoor te waken dat ik niet continu updates geeft over het blijven hangen van een van de twee torens, maar sinds ik gisteren de Zendure P1-meter heb uitgeschakeld, heb ik geen problemen meer gehad. Gielz volgt de HomeWizard-P1 als een slaafse hond.

Kan natuurlijk ook toeval zijn. Ik denk dat ik 'm einde dag weer eens toevoeg om te kijken of er weer hickups gaan ontstaan.

Toch denk ik ook wel eens dat het serverside optreedt. Dat daar iets niet lekker loopt. Maar helaas ben ik daarvoor niet technisch onderlegd genoeg.

[ctrl-tab]

Wai_AM schreef op donderdag 4 juni 2026 @ 08:13:
[...]

@ctrl-tab @Tiesert
post in april : https://gathering.tweakers.net/forum/view_message/85023966
Je maakt een kopie na sensor genaamd

code:

      - name: nordpool_kwh_nl_eur_5_10_0
        unique_id: nordpool_kwh_nl_eur_5_10_0

en de formule aanpast zonder energiebelasting en btw, dan heb je zowel met als zonder met de officiele nordpool

Kan je beter uitleggen wat je bedoelt? Kan er geen chocolade van maken

[Ben(V)]

Gramser schreef op donderdag 4 juni 2026 @ 05:39:
[...]

Omdat ik de HW P1 gebruik voor de HW-omgeving hier in huis…

En waarom zou je de HW P1 niet voor beiden gebruiken?
Er wordt alleen dat mee gelezen en niets verstuurd dus je kunt die HW P1 prima voor meer dingen gelijktijdig gebruiken.

Twee P1 opnemers is enkel overbodige overhead.

[Gramser]

Omdat de HW P1 niet werkt met mijn Zendures...

[wautah91]

DaGoose schreef op donderdag 4 juni 2026 @ 09:02:
[...]

Ik ben ook al even aan het stoeien met wegvallende verbindingen met 2 hypers. Ik was eerst ook bezig met wifi. Apart/decicated accespoint en SSID geprobeerd (op 2m afstand) waarvoor ik zelfs met HA met een ping die wegvalt de POE uit/aan zet en zo het accespoint automatisch reset. Dat werkte op zich, maar in sommige gevallen niet, want dan bleef de wifi verbinding wel open staan en de ping reply dus ook. Van alles geprobeerd, andere kanalen, settings, je kent het, niks hielp eigenlijk echt. Tot ik van de week ineens dacht, ik ga eens proberen om in de integratie (ik gebruik de zendure integratie) de connection mode van local (wat je wilt eigenlijk) naar cloud (je wilt het eigenlijk niet) te zetten. Inmiddels draait hij daar nu al 2 dagen mee zonder 1 hickup.

Ik heb destijds ook een tijdje met HEMS (eerste versie) gedraaid en ik kan mij niet herrineren dat ik toen wel eens een hangende hyper had op deze manier. Maar dat is ook een (deels in ieder geval toch?) cloud verbinding.
Zijn hier al meer mensen mee aan het experimenteren geweest?

Mijn ervaring is dat het stabiel werkt met de Hyper wanneer je de update interval (write) verhoogt van 1 naar 5 en je local verbind met MQTT icm een bluetooth proxy via een losse esp32. In mijn huidige testversie van de hyper proxy filter ik ook de berichten eruit die tussen 0-5 seconden binnenkomen. Sindsdien geen downtime meer gehad met de hyper. Daarvoor schoot hij nog wel eens in een freeze.


@gielz is het misschien een idee om de automatisering te laten triggeren op een wijziging van de P1 meter in plaats van vast om de 5 seconden? Blijft hij dan niet mooier synchroon lopen voor NOM aangezien de P1 meters kunnen updaten tussen de 1-10 seconden?

[ Voor 7% gewijzigd door wautah91 op 04-06-2026 10:35 ]

[Wai_AM]

ctrl-tab schreef op donderdag 4 juni 2026 @ 09:45:
[...]

Kan je beter uitleggen wat je bedoelt? Kan er geen chocolade van maken

code:

    sensor:
      - name: nordpool_kwh_nl_eur_5_09_0
        unique_id: nordpool_kwh_nl_eur_5_09_0
        unit_of_measurement: "€/kWh"
        icon: mdi:cash
        device_class: energy
        state: > # returns the current price
...................................................

Achter sensor worden sensoren gedefineerd.
Daar staat nu nordpool_kwh_nl_eur_5_09_0
als je die helemaal kopieert, en daaronder zet.
verander de naam en de functie van berekenen van additionele kosten, dan heb je ook een sensor voor marktprijs.
Net zoiets als mijn voorbeeld van HACS norpool.

[Ben(V)]

Gramser schreef op donderdag 4 juni 2026 @ 09:54:
Omdat de HW P1 niet werkt met mijn Zendures...

Dan kun je de Zendure P1 toch gewoon voor alles gebruiken.
Je hebt toch niet voor niets HA om alles aan elkaar te knopen?

[Gramser]

Nee, ik kan de Zendure P1 niet gebruiken voor het HW-ecosysteem thuis. En die moet intact blijven. Ik zou nog wel een keer kunnen proberen om Zendure P1 met Gielz te gebruiken zodat er voor de Zendures maar één kapiteintje is. Maar dan heb ik nog de situatie dat ik er twee gebruik in huis.

[gielz]

Gramser schreef op donderdag 4 juni 2026 @ 10:38:
Nee, ik kan de Zendure P1 niet gebruiken voor het HW-ecosysteem thuis. En die moet intact blijven. Ik zou nog wel een keer kunnen proberen om Zendure P1 met Gielz te gebruiken zodat er voor de Zendures maar één kapiteintje is. Maar dan heb ik nog de situatie dat ik er twee gebruik in huis.

Ik heb hier ook een Zendure P1 liggen (in de doos) just in case. Maar deze sluit ik alleen aan wanneer alles kapot gaat en je echt zou moeten terugvallen op HEMS. Is dat geen optie?

[gielz]

wautah91 schreef op donderdag 4 juni 2026 @ 10:23:
[...]
@gielz is het misschien een idee om de automatisering te laten triggeren op een wijziging van de P1 meter in plaats van vast om de 5 seconden? Blijft hij dan niet mooier synchroon lopen voor NOM aangezien de P1 meters kunnen updaten tussen de 1-10 seconden?

Dat gaat dus niet. Want stel je hebt een 1 seconden slimme meter dan zal hij elke seconden gaan bijsturen. Vervolgens heeft de batterij 4-5 seconden nodig om zijn doel te bereiken.

Je krijgt dan hele mooie golven op de P1 alleen de surfplank ontbreekt nog.

[Devke]

DaGoose schreef op donderdag 4 juni 2026 @ 09:02:
[...]

Ik ben ook al even aan het stoeien met wegvallende verbindingen met 2 hypers. Ik was eerst ook bezig met wifi. Apart/decicated accespoint en SSID geprobeerd (op 2m afstand) waarvoor ik zelfs met HA met een ping die wegvalt de POE uit/aan zet en zo het accespoint automatisch reset. Dat werkte op zich, maar in sommige gevallen niet, want dan bleef de wifi verbinding wel open staan en de ping reply dus ook. Van alles geprobeerd, andere kanalen, settings, je kent het, niks hielp eigenlijk echt. Tot ik van de week ineens dacht, ik ga eens proberen om in de integratie (ik gebruik de zendure integratie) de connection mode van local (wat je wilt eigenlijk) naar cloud (je wilt het eigenlijk niet) te zetten. Inmiddels draait hij daar nu al 2 dagen mee zonder 1 hickup.

Ik heb destijds ook een tijdje met HEMS (eerste versie) gedraaid en ik kan mij niet herrineren dat ik toen wel eens een hangende hyper had op deze manier. Maar dat is ook een (deels in ieder geval toch?) cloud verbinding.
Zijn hier al meer mensen mee aan het experimenteren geweest?

Zendures hebben toegang hier tot internet. Die weg is dus niet afgesloten. Wel veel herkenning. Ik zat ook al te denken aan een scriptje die de boel reset ( te gek voor woorden ). Eerst maar eens opnieuw de boel opbouwen. Ik zie gielz op 1 set wel draaien maar veel sensoren updaten niet eens binnen HA.

[Gramser]

gielz schreef op donderdag 4 juni 2026 @ 10:43:
[...]


Ik heb hier ook een Zendure P1 liggen (in de doos) just in case. Maar deze sluit ik alleen aan wanneer alles kapot gaat en je echt zou moeten terugvallen op HEMS. Is dat geen optie?

Dat is het zeker wel! Alleen tot nu toe is het een paar keer voorgekomen dat ik wilde terugvallen op HEMS omdat ik HA nog niet echt begreep. En dus om wat te testen als de boel een beetje raar deed. Beetje kip en ei. En met beide P1's aangesloten kan ik ook op afstand HEMS weer activeren.

Maar, ik ga gewoon een tijd zonder Zendure P1-draaien, nu. Op tijd voor ik met vakantie ga... kan ik zien of het blijft werken.

[Tiesert]

Hippe Lip schreef op woensdag 3 juni 2026 @ 23:57:
[...]

@Tiesert Ik blijf het toch opvallend en verwarrend vinden als @ctrl-tab en jij het hebben over dat het er al standaard in zit.

Begin dit jaar heb ik de HACS-versie er even uitgekieperd omdat ik met de standaard integratieversie aan de slag wilde, maar daarvoor moest ik toch echt een integratie installeren. Die is dus niet standaard in HA aanwezig, die zit niet standaard in HA als je die nieuw installeert. Daarvoor moet je toch echt iets extra’s doen, toch?

Of hebben we het nou toch over hetzelfde?

[Afbeelding]

Als we als definities voor "er standaard inzitten" hanteren:

1. onderdeel van core functionaliteit van HA, niet de-installeerbaar.
2. standaard integratie, direct meegeinstalleerd met core (zoals Sun), mogelijk deinstalleerbaar
3. optionele integratie die direct vanuit HA te installeren en activeren is, zonder dat HACS nodig is.
4. optionele integratie die alleen via HACS te installeren en activeren is. Deze hebben bij het overzicht van integraties een oranje box (custom integration). Deze box wordt rood als er een alternatief van optie 2 beschikbaar is.

Dan had ik het over een overstap van Nordpool van 4 naar 3. Die heb ik gedaan. En volgens mij heeft @ctrl-tab ook 3.

[Pakhaas]

Gramser schreef op donderdag 4 juni 2026 @ 09:14:
Ik probeer ervoor te waken dat ik niet continu updates geeft over het blijven hangen van een van de twee torens, maar sinds ik gisteren de Zendure P1-meter heb uitgeschakeld, heb ik geen problemen meer gehad. Gielz volgt de HomeWizard-P1 als een slaafse hond.

Kan natuurlijk ook toeval zijn. Ik denk dat ik 'm einde dag weer eens toevoeg om te kijken of er weer hickups gaan ontstaan.

Toch denk ik ook wel eens dat het serverside optreedt. Dat daar iets niet lekker loopt. Maar helaas ben ik daarvoor niet technisch onderlegd genoeg.

Dat was ook mijn idee met mijn opmerking. 2 P1 meters tegelijk, kan wel eens de oorzaak zijn.

[Gramser]

Pakhaas schreef op donderdag 4 juni 2026 @ 12:07:
[...]

Dat was ook mijn idee met mijn opmerking. 2 P1 meters tegelijk, kan wel eens de oorzaak zijn.

Dat begon mij dus ook te dagen. Wie weet - de test loopt al

[DeadMetal]

Het valt me op dat de gielz-integratie mijn logbook compleet volspamt met berichten over de vermogensopdracht die hij geeft aan de batterij, of er nul-import is gedetecteert en de hartbeat. Dit maakt mijn logbook onbruikbaar omdat ik daar regelmatig in kijk om te zien welke echt belangrijke zaken er in huis gebeurd zijn (deuren en ramen open etc). Hoe kan ik dit fixen?

[Kurios]

Met een nieuwe Zendure 2400 Ac+ lukt het me niet om deze via HA aan te sturen. Hij blijft altijd op Inactive staan ongeacht wat voor commandos ik stuur via de verschillende integraties. De integraties configureren lijkt allemaal te werken, maar de batterij laten laden of ontladen lukt niet.

Het gekke is dat ook de beschikbare capaciteit (kWh) niet uitgelezen kan worden.

Heeft iemand dit ook eens meegemaakt?

[c0mplex1]

DeadMetal schreef op donderdag 4 juni 2026 @ 12:26:
Het valt me op dat de gielz-integratie mijn logbook compleet volspamt met berichten over de vermogensopdracht die hij geeft aan de batterij, of er nul-import is gedetecteert en de hartbeat. Dit maakt mijn logbook onbruikbaar omdat ik daar regelmatig in kijk om te zien welke echt belangrijke zaken er in huis gebeurd zijn (deuren en ramen open etc). Hoe kan ik dit fixen?

Je kunt de ingebouwde Activity integration in HA gebruiken om extensies te excluden.
https://www.home-assistant.io/integrations/logbook/

[Mscroos]

Kurios schreef op donderdag 4 juni 2026 @ 12:32:
Met een nieuwe Zendure 2400 Ac+ lukt het me niet om deze via HA aan te sturen. Hij blijft altijd op Inactive staan ongeacht wat voor commandos ik stuur via de verschillende integraties. De integraties configureren lijkt allemaal te werken, maar de batterij laten laden of ontladen lukt niet.

Het gekke is dat ook de beschikbare capaciteit (kWh) niet uitgelezen kan worden.

Heeft iemand dit ook eens meegemaakt?

Stuur eens wat screenshots van het dashboard van Gielz (vooral de instellingen tab) en staat de automation goed en wordt deze getriggerd?

[Luuk741]

Kurios schreef op donderdag 4 juni 2026 @ 12:32:
Met een nieuwe Zendure 2400 Ac+ lukt het me niet om deze via HA aan te sturen. Hij blijft altijd op Inactive staan ongeacht wat voor commandos ik stuur via de verschillende integraties. De integraties configureren lijkt allemaal te werken, maar de batterij laten laden of ontladen lukt niet.

Het gekke is dat ook de beschikbare capaciteit (kWh) niet uitgelezen kan worden.

Heeft iemand dit ook eens meegemaakt?

Heb je de Zendure wel uit HEMS gehaald?

[Kurios]

Luuk741 schreef op donderdag 4 juni 2026 @ 12:45:
[...]

Heb je de Zendure wel uit HEMS gehaald?

ja dat heb ik inderdaad gedaan. Via de app kon ik het losse device nog wel bedienen, maar het is me gek genoeg nooit gelukt via HA.

[Kurios]

HA kan de batterij wel bereiken, en info uitlezen, maar dat rode kruis blijft (ook na een aantal uur verbonden)

[ Voor 86% gewijzigd door Kurios op 04-06-2026 14:27 ]

[Gramser]

Het rode kruis zegt al dat er iets niet goed gaat bij jou... dat kan @gielz waarschijnlijk direct wel duiden. Je hebt neem ik aan de automation wel enabled?

[ Voor 17% gewijzigd door Gramser op 04-06-2026 12:57 ]

[Mscroos]

Kurios schreef op donderdag 4 juni 2026 @ 12:46:
[...]

ja dat heb ik inderdaad gedaan. Via de app kon ik het losse device nog wel bedienen, maar het is me gek genoeg nooit gelukt via HA.

Automation draait niet...

[DaGoose]

Devke schreef op donderdag 4 juni 2026 @ 11:02:
[...]

Zendures hebben toegang hier tot internet. Die weg is dus niet afgesloten. Wel veel herkenning. Ik zat ook al te denken aan een scriptje die de boel reset ( te gek voor woorden ). Eerst maar eens opnieuw de boel opbouwen. Ik zie gielz op 1 set wel draaien maar veel sensoren updaten niet eens binnen HA.

Nee, ik bedoel echt dat je in de integratie hem op cloud zet IPV local. Bij mij hebben ze ook altijd al een verbinding naar buiten. Ik vindt het bijzonder dat sinds ik dit dus naar cloud heb gezet het blijft werken. Inmiddels al bijna 2 dagen terwijl ik normaal minstens 1x per dag actie moest ondernemen om het weer te laten werken.

[DeadMetal]

c0mplex1 schreef op donderdag 4 juni 2026 @ 12:41:
[...]

Je kunt de ingebouwde Activity integration in HA gebruiken om extensies te excluden.
https://www.home-assistant.io/integrations/logbook/

Dank, dat heeft iets geholpen, ik heb de entity_glob 'binary_sensor.p1*' uitgesloten, en het domein 'automation' en 'input_datetime' uitgesloten. Dat helpt om de hartbeat en p1 'nul import gedetecteerd' meldingen te verbergen.

Maar dit blijft nog over. Enig idee hoe die te verbergen in het logbook?

[Devke]

DaGoose schreef op donderdag 4 juni 2026 @ 13:13:
[...]

Nee, ik bedoel echt dat je in de integratie hem op cloud zet IPV local. Bij mij hebben ze ook altijd al een verbinding naar buiten. Ik vindt het bijzonder dat sinds ik dit dus naar cloud heb gezet het blijft werken. Inmiddels al bijna 2 dagen terwijl ik normaal minstens 1x per dag actie moest ondernemen om het weer te laten werken.

[Afbeelding]

Ah jij draait de integratie van Zendure zelf zo te zien. Ik draai de integratie van @gielz en proxy van @gast777.

[gielz]

DeadMetal schreef op donderdag 4 juni 2026 @ 13:14:
[...]

Dank, dat heeft iets geholpen, ik heb de entity_glob 'binary_sensor.p1*' uitgesloten, en het domein 'automation' en 'input_datetime' uitgesloten. Dat helpt om de hartbeat en p1 'nul import gedetecteerd' meldingen te verbergen.

Maar dit blijft nog over. Enig idee hoe die te verbergen in het logbook?

[Afbeelding]

Je kunt wat je niet essentieel vind uitschakelen in de automatisering. Ze zitten bij iedere essentiële actie. Of deze excluden input_select.zendure_2400_ac_modus_selecteren / input_select.zendure_operation_mode

[ Voor 6% gewijzigd door gielz op 04-06-2026 13:36 ]

[Kurios]

Mscroos schreef op donderdag 4 juni 2026 @ 12:57:
[...]

Automation draait niet...

inderdaad, deze was niet gestart. Na het runnen lijkt het wel goed te werken. thanks!

[Hippe Lip]

ctrl-tab schreef op donderdag 4 juni 2026 @ 09:45:
[...]

Kan je beter uitleggen wat je bedoelt? Kan er geen chocolade van maken

Heb je de link gevolgd die @Wai_AM erbij gaf?
Daar staat het hele, uitgebreide chocoladerecept.

[abaart]

Ik heb helaas niet de tijd om elke dag dit topic helemaal bij te houden, maar als ik een paar pagina's terug lees zie ik toch vrij regelmatig nog allerlei vage problemen langskomen zoals wegvallen van de verbinding, zoals:

Devke schreef op woensdag 3 juni 2026 @ 00:51:
[...]

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.

oeps schreef op zondag 3 mei 2026 @ 17:10:
Hallo allemaal,
Heb/had een issue met de Gielz integratie (of eigenlijk HA zelf). Heb nu een workaround maar snap de oorzaak niet. Sorry, wat langere post.
Ik deel het hier zodat het later door anderen gevonden kan worden en hopelijk weet iemand wat hier echt aan de hand is.


Het uitte zich (door toeval van het moment?) dat de batterij opeens op vol vermogen ging ontladen gedurende ongeveer 2 uur. Daarna normaal, wij waren weg dus het ging vanzelf allemaal! Bij mij is op vol vermogen gelukkig op dit moment nog 800W omdat de Zendure 2400 Pro (zonder panelen nog) nu nog op een stopcontact zit.
[Afbeelding]
Ingezoomed:
[Afbeelding]

Na speuren kwam ik het volgende tegen in de HA logging met eindeloos veel repeats in de logging:

[...]

Ik heb de batterij pas 3 weken en tot 30 april had ik een eigen +/- P1 Power sensor die elke 5 seconden ververst.
Afgelopen donderdag de rest api versie naar de Zendure P1 meter toegevoegd aan HA en die sensor in Gielz gezet. Werkte prima maar toen niet in de HA log gekeken.
Bij time-out errors is de eerste suggestie natuurlijk: Je hebt bagger Wifi of je hebt een bagger HA server.
De Zendure P1 meter en dongle en bridge hangen beiden in de meterkast naast een paar andere ESPhome sensors waaronder de P1 meter sensor die ik al tijden gebruik zonder problemen.
HA draait in een VM op Proxmox op een i5. De VM heeft 6GB ram en 6 virtuele CPU’s. Een ping naar Zendure P1 geeft gemiddeld 4,6ms roundtrip.
Als workaround gebruik ik nu gewoon weer de +/- Power sensor die ik had.
Om te testen heb ik de Zendure P1 via rest even op 2 seconden gezet. Met 1 seconde was de log zo’n beetje vol met bovenstaande error. Met 2 seconden heb ik een enkele time-out gezien gedurende een uur of 8.

• Ik weet uiteraard niet 100% zeker dat de time-outs de oorzaak zijn het opeens hard ontladen.

Mijn theorie tot nu toe: Af en toe is er door de Quooker even een piek waardoor de batterij op 800W ontladen gaat en net op dat moment gaf iets er de brui aan om zich twee uur later weer te herstellen. Zie ook de screenshots uit de Gielz log.

[Afbeelding]

[Afbeelding]

[Afbeelding]

In de HA log zie ik ook de volgende error:

[...]

Ik snap de error message niet helemaal: http://192.168.178.156/properties/report failed zou kunnen als er even geen connectie is/
Maar http:///api/v1/data failed en http://unknown/api/v1/data failed snap ik niet. Lijkt dan een leeg IP adres veld of de tekst unknown in een IP address veld. In de screenshot met mijn instellingen.
[Afbeelding]
De 192.168.178.156 is de 2400 Pro zelf. De wifi is meestal “Good”, heel soms “weak” (nog onderzoeken) maar in de periode van ontlading was het “Good”, tussen 16:00-18:00. Fritz-box bedrade AP is 2 muren en een verdieping verder. Daar is nog iets te verbeteren. AP dichter bij raam zodat de garage beter in beeld is.
[Afbeelding]
Herkent iemand de problemen met Rest in HA (ik gebruik zelf één rest commando in HA om een ESPhome elke nacht even te herstarten.
Dank!

Devke schreef op woensdag 3 juni 2026 @ 00:51:
[...]

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.

Mistraller schreef op dinsdag 5 mei 2026 @ 10:24:
[...]

Goeie tip; ik had inderdaad wel naar de resources gekeken maar ik had inderdaad nog geen goede history. Uit de logs lijken simpelweg de acties te missen.

[...]

Uiteraard ook mijn eerste gedachte. Die laptop waar het geheel op draait is al een oudje inderdaad. Maar met 900 entiteiten, ZHA, influx, grafana, een heleboel kleine integraties, en relatief eenvoudige automations tot nu toe altijd als een zonnetje.
Draait op een SSD. duplicate IP gaat je HA niet van op z'n gat Maar nee, ik heb de zendures een reserved IP in de router gegeven en ik kan ze verder prima zien in de app. En ik heb nooit netwerk issues gehad, zou sterk zijn als dat nu ineens aan het licht komt.

Echter: Resources lijkt wel de basis te zijn van de problemen. Ik zag dat hij enorm heeft staan swappen, tot ongeveer 6u vannacht, toen was ha core volgens mij gecrashed. En toen had ik dus node-red al gestopt en gielz naar 1 zendure laten kijken.
Helaas is ram uitbreiding voor die laptop bizar duur. Ik had 2GB toegewezen aan de VM, omdat de host slechts 4gb heeft. Nu de vm naar 2,5gig gezet en dat lijkt wel te helpen.
Dus ik hou het even in de gaten. Het lijkt wel by far de meest resource intensieve toevoeging op mijn HA instance die ik tot nu toe gezien heb, en dat zag ik niet aankomen; ik meen dat er geen minimale system resources waren opgegeven. Als blijkt dat ik daaronder zit is het misschien slim om in de prerequisites op te nemen. Dan zal ik nog wel eens meer testen, ik heb nog een andere laptop waar nieuwer type geheugen in gaat (en ook al zit). Reden voor laptop? Backup power

Dus ik ga het nog eens met de system monitor integration bekijken.

Tot zover alvast bedankt voor het meedenken!


Edit: Node-RED weet aangezet, en sommige stappen in de flow duren naar mijn idee wel érg lang . Gekke is dat het lijkt dat ie met zendure 3 wil connecten, maar die staat gewoon op "". (Call 3 zendure API; econn reset)
Swap usage in HA loopt weer op. Lijkt wel een memory leak?

[core-ssh ~]$ free -h
total used free shared buff/cache available
Mem: 2.4G 1.5G 36.1M 4.1M 864.6M 989.7M
Swap: 815.1M 348.4M 466.7M

metalmarco schreef op vrijdag 8 mei 2026 @ 17:34:
[...]

Het ligt inderdaad aan de aansturing in de Deco/Zendure zelf. Het is bekend dat de Zendures erg doof zijn met WiFi.

Ook geprobeerd met een Repeater er tussen in, maar dat was net zo'n drama. Dus vermoed echt dat het iets is tussen de deco/zendure.

Heb zelf hier ook een Deco Mesh Netwerk (Xe75Pro), en heb ze inderdaad ook op een eigen IoT netwerk en alleen 2.4Ghz. Maar wat bij mij heeft geholpen (nog maar gemiddeld 5 uitval per dag van 5 seconden, omdat er vaak 1 omvormer "geen bereik" heeft) is 1 van de mesh routers iets dichterbij gezet (1 meter) en "snelle roaming" en "beamforming" uitzetten.

En dat bereik is twijfel achtig inderdaad, aangezien de deco app 1 streepje minder heeft soms. En bij mij staat 1 mesh router nog geen 5 meter hemelsbreed van de zendures (3 stuks).

Gramser schreef op zondag 10 mei 2026 @ 20:04:
Ik heb wat mafs, misschien herkennen jullie het? Nu ik terug van vakantie weer eens in HA kijk, zie ik dat een van de twee torentjes op standby staat terwijl hij wel een ontlaadcommando krijgt. Ik heb de automation al even uitgezet, de modus van beiden naar standby gezet en weer terug naar smart matching, en ook even HEMS geactiveerd maar ik krijg torentje 2 niet aan het ontladen.

Kan ik dat op enige manier alsnog op afstand triggeren zonder dat ik meteen de boel weer van de stroom moet halen voor een reset?

edit:
blijkbaar heb ik wel íets getriggerd… want ook device 2 is weer gaan ontladen. Nou mooi. Gekke dingen zijn het af en toe.

[Afbeelding]

hemertje schreef op zaterdag 16 mei 2026 @ 12:29:
Goede test, en heel relevant voor mij — ik heb gisteren met Claude Code mijn HA-logs uitgespit en kwam onafhankelijk bij dezelfde conclusie uit. Ik draaide vanmorgen een continue meting vanaf mijn MacBook:
elke 30 sec een ping naar mijn 3 Zendures EN een test-call naar de Node-RED proxy. Resultaat:

- Zendures zelf: keurig 5-16 ms response, geen packet loss
- Node-RED proxy: af en toe spontaan 5+ seconden timeout, terwijl de Zendures dus prima bereikbaar zijn

Dat sluit Wi-Fi-issues bij mij ook uit. Het probleem zit echt in iets dat de Node-RED proxy zelf periodiek ophoudt — niet in het netwerk en niet in de Zendures.

Wat me opvalt aan jouw bevinding:
laden gaf gehakkel, ontladen ging strak. Dat past bij de hypothese dat de proxy moeite heeft met de hoge frequentie POST-commando's tijdens Dynamic Trading laden. Bij ontladen draai je vaak op een vaster setpoint, dus minder POSTs richting de Zendures.

@gast777 , eventueel iets om te checken:
lukt het om de proxy te profilen tijdens een actieve dynamische laad-cyclus? Ik denk specifiek aan event-loop blocking of garbage collection pauzes in Node.js. Mijn timeouts duurden meestal ~1,3 sec (één gemiste poll) maar af en toe 5+ sec (de "luide" ones). Geen TCP RESET errors zoals bij @abaart's 800 Plus, dus ander failure-patroon.

Ik laat de monitor de hele dag draaien — als ik iets reproduceerbaars vind koppel ik het terug.

Al deze posts komen overeen met de problemen en symptomen waar ik voorheen ook last van had.

En er wordt ook al geknutseld in de goede richting:

wautah91 schreef op donderdag 4 juni 2026 @ 10:23:
[...]

Mijn ervaring is dat het stabiel werkt met de Hyper wanneer je de update interval (write) verhoogt van 1 naar 5 en je local verbind met MQTT icm een bluetooth proxy via een losse esp32. In mijn huidige testversie van de hyper proxy filter ik ook de berichten eruit die tussen 0-5 seconden binnenkomen. Sindsdien geen downtime meer gehad met de hyper. Daarvoor schoot hij nog wel eens in een freeze.


@gielz is het misschien een idee om de automatisering te laten triggeren op een wijziging van de P1 meter in plaats van vast om de 5 seconden? Blijft hij dan niet mooier synchroon lopen voor NOM aangezien de P1 meters kunnen updaten tussen de 1-10 seconden?

Het heersende geloof is op dit moment dat dit enkel veroorzaakt kan worden door het zogenaamde "wifi-spook"

In het main Zendure topic heb ik mijn ervaringen gedeeld van een paar weken test draaien met een alternatieve proxy, die overladen van de Zendures voorkomt. Mijn verwachting is dat voor veel van jullie dit de problemen zou kunnen oplossen.

Het tackelt het probleem van 3 kanten tegelijk:

• Voorkomen van overladen van Zendures met (opgehoopte) HTTP requests vanuit HA/gielz, waardoor deze niet in 'overload-mode' gaat (ECONNRESET, etc)
• Als een zendure tijdelijk even problemen heeft, wordt die eventjes met rust gelaten zodat die zich kan herstellen (dit werd in een van de posts hierboven bereikt door de AP/router te power-cyclen)
• Zorgt ervoor dat de sensoren in HA (GET request) altijd een tijdige reactie ontvangen, waardoor ze niet meer 'unknown' worden.

Hierdoor worden problemen voorkomen, ook bij een (mogelijk) niet-perfecte WiFi verbinding van de Zendure

abaart schreef op vrijdag 5 juni 2026 @ 13:12:
[...]

Voor degenen die hier ook last van denken te hebben, je kunt geld besparen voor een nieuw AP en kabels trekken, want dat is niet nodig.

Met wat vriendelijker aanstuur gedrag en slimme graceful-degradation zijn de problemen ook prima op te lossen.

Hiervoor had ik bijna altijd minimaal 3 'unknown' momenten per dag, met een CAT6A aangesloten TP-Link Omada AP <1m van de Zendures.

Met de slimme aansturing is dit gereduceerd tot maximaal een paar keer per week enkele seconden dat de GET informatie in HA uit de cache komt, omdat de Zendure (of het wifi-spook, als je daar in gelooft) eventjes druk is met een interne cronjob, of wat dan ook. Dit door te zorgen dat er nooit meer dan 2 gelijktijdige HTTP connecties kunnen ontstaan naar een Zendure; En dat HA/gielz nooit een GET timeout terugkrijgt.

In zo'n geval blijven de andere Zendures in de pool vrolijk doorwerken, en de 'drukke' Zendure trouwens ook, deze wordt na 30 seconden stabiele reacties automatisch weer meegenomen in de aansturing van HA.

[Afbeelding]
Hier in rood 2 momenten de afgelopen week waar er even een hiccup was met 1 van de Zendures.

[Afbeelding]
Hier details van de netjes opgevangen Zendure hiccups

Verdere discussie in dit GitHub issue, en hier de alternatieve proxy met slimme aansturing. Kan vrij gemakkelijk via HACS geïnstalleerd en geüpdatet worden.

Wellicht ten overvloede, ik heb mijn AP of andere onderdelen van mijn netwerk niet aangeraakt. De Zendures staan ook nog op exact dezelfde plek.

Het wifi-spook bestaat dus niet.

Bij mij draait het nu als een zonnetje! Sowieso moet je niet in spoken geloven, maar in wifi-spoken al helemaal niet

[Gramser]

Ik vind dit echt zo knap en als ik HA al goed genoeg zou snappen, zou ik het meteen installeren 😆. Vooralsnog lijken mijn problemen voorbij nu ik nog slechts 1 P1-meter gebruik.

[ctrl-tab]

gielz schreef op donderdag 4 juni 2026 @ 10:46:
[...]


Dat gaat dus niet. Want stel je hebt een 1 seconden slimme meter dan zal hij elke seconden gaan bijsturen. Vervolgens heeft de batterij 4-5 seconden nodig om zijn doel te bereiken.

Je krijgt dan hele mooie golven op de P1 alleen de surfplank ontbreekt nog.

Heb dit bij mijn dsmr4 meter gedaan, en ook dan gaat het helemaal mis, op gegeven moment. Meestal na een plotselinge spike.
De theorie is dat de dsmr4 meter exact het zelfde is als het moment van bericht-transmissie.
Als dat daadwerkelijk zo is , is er in de volgende 10 seconden genoeg tijd voor de batterij om te anticiperen..
Het is toch niet consistent het geval. Sinds de update frequentie 20s is, heb ik geen issues meer behalve wat lag.

[Henkoes]

@gast777 is het mogelijk dat je support voor 4 of 5 torens van omvormers support?

[DeadMetal]

abaart schreef op vrijdag 5 juni 2026 @ 13:12:
[...]

Verdere discussie in dit GitHub issue, en hier de alternatieve proxy met slimme aansturing. Kan vrij gemakkelijk via HACS geïnstalleerd en geüpdatet worden.

@abaart ik reageer liever in dit topic. Ik wilde eens experimenteren met wat je gemaakt heb, maar ik loop vast. Je 'AppDaemon via HACS' stappenplan op https://github.com/abaart/Zendure-zenSDK-proxy is iets te beknopt voor me, hopelijk kan je laten zien wat ik fout doe. Appdeamon is nieuw voor me. HACS heb ik al.

Stap 1 t/m 7 heb ik gedaan, ging makkelijk
Stap 8 & 9, zit dat dan hier? /addon_configs/a0d7b954_appdaemon/appdaemon.yaml

YAML:

---
appdaemon:
  production_mode: true
  latitude: 52.379189
  longitude: 4.899431
  elevation: 2
  time_zone: Europe/Amsterdam
  plugins:
    HASS:
      type: hass
      token: !env_var SUPERVISOR_TOKEN
http:
  url: http://0.0.0.0:5050
admin:
api:
hadashboard:

Stap 10, zit dat dan hier? /addon_configs/a0d7b954_appdaemon/apps/apps.yaml
Daar heb ik de code toegevoegd van examples/apps.yaml (toegevoegd aan apps.yaml die enkel iets over hello world bevatte), de 2 Zendure ip-adressen aangepast, verder niks, en opgeslagen.

Als ik dan stap 13 uitvoer, de appdeamon app (addon) herstart, dan zie ik in de addon logs

code:

ModuleNotFoundError: No module named 'zendure_proxy'

En uitgebreider:

code:

[15:13:36] INFO: Starting AppDaemon...
s6-rc: info: service legacy-services successfully started
2026-06-05 15:13:56.016630 INFO AppDaemon: ------------------------------------------------------------
2026-06-05 15:13:56.017709 INFO AppDaemon: AppDaemon Version 4.5.13 starting
2026-06-05 15:13:56.018727 INFO AppDaemon: ------------------------------------------------------------
2026-06-05 15:13:56.019641 INFO AppDaemon: Python version is 3.12.13
2026-06-05 15:13:56.020515 INFO AppDaemon: Configuration read from: /config/appdaemon.yaml
2026-06-05 15:13:56.023907 INFO AppDaemon: Using /config/apps as app_dir
2026-06-05 15:13:56.029723 INFO AppDaemon: Loading built-in plugin 'HASS' using 'HassPlugin' from 'appdaemon.plugins.hass.hassplugin'
2026-06-05 15:13:56.031560 INFO HASS: HASS Plugin initialization complete
2026-06-05 15:13:56.033203 INFO AppDaemon: Initializing HTTP
2026-06-05 15:13:56.035259 INFO AppDaemon: Using 'ws' for event stream
2026-06-05 15:13:56.047815 INFO AppDaemon: Starting API
2026-06-05 15:13:56.055865 INFO AppDaemon: Starting Admin Interface
2026-06-05 15:13:56.057227 INFO AppDaemon: Starting Dashboards
2026-06-05 15:13:56.133217 INFO AppDaemon: Starting apps with 2 worker threads. Apps will all be assigned threads and pinned to them.
2026-06-05 15:13:56.148062 INFO AppDaemon: Running on port 5050
2026-06-05 15:13:56.150663 INFO AppDaemon: Waiting for plugins to be ready
2026-06-05 15:13:56.171739 INFO HASS: Connected to Home Assistant 2026.6.0 with aiohttp websocket
2026-06-05 15:13:56.176007 INFO HASS: Authenticated to Home Assistant 2026.6.0
2026-06-05 15:13:56.191319 INFO HASS: Waiting for Home Assistant to start
2026-06-05 15:13:56.214043 INFO AppDaemon: All plugins ready
2026-06-05 15:13:56.277149 INFO AppDaemon: Scheduler running in realtime
2026-06-05 15:13:56.320442 ERROR Error: =====  Error importing 'zendure_proxy'  ===================================
2026-06-05 15:13:56.327158 ERROR Error: FailedImport: Failed to import 'zendure_proxy'
2026-06-05 15:13:56.328331 ERROR Error:   Import paths:
2026-06-05 15:13:56.329586 ERROR Error:     /config/apps
2026-06-05 15:13:56.337200 ERROR Error:   ModuleNotFoundError: No module named 'zendure_proxy'
2026-06-05 15:13:56.343161 ERROR Error: ===========================================================================
2026-06-05 15:13:56.346098 WARNING AppDaemon: Failed to start apps: {'zendure_proxy'}
2026-06-05 15:13:56.356672 INFO AppDaemon: Starting apps: ['hello_world']
2026-06-05 15:13:56.421955 INFO AppDaemon: Calling initialize() for hello_world
2026-06-05 15:13:56.428329 INFO HASS: Completed initialization in 363ms
2026-06-05 15:13:56.716936 INFO hello_world: Hello from AppDaemon
2026-06-05 15:13:56.720641 INFO hello_world: You are now ready to run Apps!
2026-06-05 15:13:56.724506 INFO AppDaemon: App initialization complete

[Gramser]

Ik doe, als HA-beginner, eens een poging het standaard energy-dashboard een beetje netjes werkend te krijgen. Ik weet alleen niet goed wat ik moet invullen bij de eigenschappen van de batterij.



Ik heb nu bovenstaand. Maar weet niet helemaal of dat correct is. En wat moet ik invullen bij power measurement? Misschien wel twee sensoren, Zendure power import en Zendure power export?

[Idr548]

Mooie toevoeging die balans, al kan het wel wat vertekend beeld geven.
boven de 90% kan er wel snel wat onbalans zijn tussen de cellen denk ik.
Zou het nuttig kunnen zijn op de polling van de balans wat lager te zetten. Dit kan wel snel ping-pongen zie ik.

En een andere vraag.
Is er een gekende manier op de NL gielz integratie over te zetten naar de EN sensors etc zonder de historiek kwijt te geraken?

[Mistraller]

abaart schreef op vrijdag 5 juni 2026 @ 14:32:
Ik heb helaas niet de tijd om elke dag dit topic helemaal bij te houden, maar als ik een paar pagina's terug lees zie ik toch vrij regelmatig nog allerlei vage problemen langskomen zoals wegvallen van de verbinding, zoals:

[...]


[...]


[...]


[...]


[...]


[...]


[...]


Al deze posts komen overeen met de problemen en symptomen waar ik voorheen ook last van had.

En er wordt ook al geknutseld in de goede richting:

[...]


Het heersende geloof is op dit moment dat dit enkel veroorzaakt kan worden door het zogenaamde "wifi-spook"

In het main Zendure topic heb ik mijn ervaringen gedeeld van een paar weken test draaien met een alternatieve proxy, die overladen van de Zendures voorkomt. Mijn verwachting is dat voor veel van jullie dit de problemen zou kunnen oplossen.

Het tackelt het probleem van 3 kanten tegelijk:

• Voorkomen van overladen van Zendures met (opgehoopte) HTTP requests vanuit HA/gielz, waardoor deze niet in 'overload-mode' gaat (ECONNRESET, etc)
• Als een zendure tijdelijk even problemen heeft, wordt die eventjes met rust gelaten zodat die zich kan herstellen (dit werd in een van de posts hierboven bereikt door de AP/router te power-cyclen)
• Zorgt ervoor dat de sensoren in HA (GET request) altijd een tijdige reactie ontvangen, waardoor ze niet meer 'unknown' worden.

Hierdoor worden problemen voorkomen, ook bij een (mogelijk) niet-perfecte WiFi verbinding van de Zendure

[Afbeelding]

[Afbeelding]


[...]


Bij mij draait het nu als een zonnetje! Sowieso moet je niet in spoken geloven, maar in wifi-spoken al helemaal niet

Ik ben het helemaal eens met jouw conclusie dat de Zendure overloaded raakt en de interne webserver teveel connecties open heeft staan en daardoor uit de lucht gaat.
Wat ik echter niet snap is dat er ondanks een goede wifi verbinding toch dingen mis lijken te gaan, die in mijn geval met een oude trage budget wifi repeater opgelost lijken te zijn.
Jouw proxy verhelpt veel, maar verstopt wel een beetje het échte probleem denk ik. Dat de huidige implementaties nog ietwat happyflow gebouwd zijn als het gaat om connecties, daar is jouw aanvulling in elk geval heel sterk.

Maar nu hebben we al 3 implementaties die in sync moeten blijven, wordt dit niet heel ingewikkeld zo?

[abaart]

Mistraller schreef op vrijdag 5 juni 2026 @ 16:39:
[...]

Ik ben het helemaal eens met jouw conclusie dat de Zendure overloaded raakt en de interne webserver teveel connecties open heeft staan en daardoor uit de lucht gaat.
Wat ik echter niet snap is dat er ondanks een goede wifi verbinding toch dingen mis lijken te gaan, die in mijn geval met een oude trage budget wifi repeater opgelost lijken te zijn.
Jouw proxy verhelpt veel, maar verstopt wel een beetje het échte probleem denk ik. Dat de huidige implementaties nog ietwat happyflow gebouwd zijn als het gaat om connecties, daar is jouw aanvulling in elk geval heel sterk.

Maar nu hebben we al 3 implementaties die in sync moeten blijven, wordt dit niet heel ingewikkeld zo?

Ik denk dat het effect van een niet-perfecte wifi verbinding wellicht hem zit in hele kleine timings verschillen. Stel dat door een suboptimale verbinding een HTTP request naar een Zendure er 200ms over doet ipv 100ms. Dan blijft die HTTP connectie toch 2x zo lang open en bezet. De default in gielz is elke seconde een GET request, en POST requests afhankelijk van de modus. Maar in NOM meestal elke run van de automation (standaard elke 5 seconden). In een versie van een paar maanden geleden leek het er ook op dat een automation-run meerdere POST requests kan afvuren.

Dan onderdeel 2 van de puzzel, de Zendure zelf. Er zijn bepaalde situaties waarin deze het even 'druk' lijkt te hebben. Ik heb het bijvoorbeeld gezien bij wisselen tussen standby/laden/ontladen. In mijn geval duurt het dan soms ineens eventjes 15 tot 30 seconden bijvoorbeeld voordat ie daar 'doorheen' is. In die tussentijd zijn er dus worst case 30 + (30/5*1,5) = 39 requests afgevuurd door HA/gielz.

De NodeRed proxy lijkt als een HTTP connectie 'bezet' is, voor nieuwe requests een nieuwe verbinding te openen. Het zou dus zomaar kunnen dat deze in ons scenario probeert om 38 nieuwe connecties te openen met de Zendure. Want we hebben de hangende connectie, en alle nieuwe requests, waar de Zendure ook lang over doet om de HTTP response terug te sturen, omdat die even 'druk' is.

Bij de 800 plus gaat ie over zijn nek bij > 6 gelijktijdige connecties. Daarna gaat ie connecties weigeren, afkappen, of ongeldige responses sturen. Resultaat, HA sensoren worden 'unknown', wat bij de volgende automation run weer voor nieuwe extra POST requests zorgt.

Die 200ms ipv 100ms, betekent dat elke HTTP request 2x zo lang een connectie bezet houdt, waardoor je wellicht al sneller (bij kortere hiccups in de Zendure) over de 6 open connecties gaat.

Maar echt zeker weet ik dit niet. Dit is mijn theorie.
Maar als dit het is, dan vind ik de oorzaak volledig bij wifi leggen een beetje kort door de bocht. De aansturing kan ook wat netter. Vandaar de alternatieve proxy. Ik denk dat wat ik nu in Python code heb geïmplementeerd, lastig of misschien zelfs wel helemaal niet verwerkt zou kunnen worden in een HA automation of in NodeRed. Door beperkingen van die platforms/omgevingen.

In principe houden beide proxies zich vrij dicht bij de structuur van de Zendure zelf, dus wat dat betreft is compatible blijven niet echt een groot issue, verwacht ik.
Als gielz wijzigt, is de python proxy waarschijnlijk in een paar Codex/Claude prompts bijgewerkt.

[gast777]

NB, zojuist heb ik ook een nieuwe versie van de Node-RED Proxy gepost (20260605), die ook als doel heeft om genoemd probleem/symptoom te adresseren.

Als iemand die dergelijke problemen ervaart die wil installeren en terugkoppelen of er symptomen verdwenen zijn en wat er eventueel nog over is, dan hoor ik het graag.

Wat nieuw is toegevoegd: Detectie of er een communicatieprobleem is tussen de proxy en de Zendures. Zo ja, stuur 15 seconden geen HTTP packets naar de Zendures. In plaats daarvan, stuur de laatste GET Response (uit cache) nog een keer naar HA.

Wat dit oplost:

1) HA zal geen onderbrekingen in de grafieken meer tonen als de communicatie naar de Zendures tijdelijk om wat voor reden dan ook niet werkt.

2) Als een Zendure HTTP server in een problematische staat is, zou deze mogelijk kunnen herstellen.

Punt 2 heb ik nog niet kunnen verifieren omdat ik dat probleem zelf niet heb. Punt 1 heb ik wel kunnen zien dat het werkt, bij wifi interrupties. Zie plaatje hieronder. Homewizard sensoren hebben een onderbreking, terwijl de proxy+Zendure geen onderbrekening heeft. Deze gaan beide over dezelfde verbinding (een tijdelijke wireless bridge).

[Gramser]

Dan gaan we die binnenkort maar eens deployen! Moet ik ook Gielz maar weer eens updaten.

Niettemin: sinds ik de Zendure P1-meter heb verwijderd volgen mijn torentjes keurig de meter 😍

[abaart]

gast777 schreef op vrijdag 5 juni 2026 @ 18:02:
NB, zojuist heb ik ook een nieuwe versie van de Node-RED Proxy gepost (20260605), die ook als doel heeft om genoemd probleem/symptoom te adresseren.

Als iemand die dergelijke problemen ervaart die wil installeren en terugkoppelen of er symptomen verdwenen zijn en wat er eventueel nog over is, dan hoor ik het graag.

Wat nieuw is toegevoegd: Detectie of er een communicatieprobleem is tussen de proxy en de Zendures. Zo ja, stuur 15 seconden geen HTTP packets naar de Zendures. In plaats daarvan, stuur de laatste GET Response (uit cache) nog een keer naar HA.

Wat dit oplost:

1) HA zal geen onderbrekingen in de grafieken meer tonen als de communicatie naar de Zendures tijdelijk om wat voor reden dan ook niet werkt.

2) Als een Zendure HTTP server in een problematische staat is, zou deze mogelijk kunnen herstellen.

Punt 2 heb ik nog niet kunnen verifieren omdat ik dat probleem zelf niet heb. Punt 1 heb ik wel kunnen zien dat het werkt, bij wifi interrupties. Zie plaatje hieronder. Homewizard sensoren hebben een onderbreking, terwijl de proxy+Zendure geen onderbrekening heeft. Deze gaan beide over dezelfde verbinding (een tijdelijke wireless bridge).

[Afbeelding]

Ik verwacht dat dit inderdaad grotendeels een oplossing kan zijn. Het voorkomt alleen niet de 'overload' state. Maar als het gebeurt, gaat in ieder geval niet direct HA naar unavailable en krijgt de Zendure even rust om te 'herstellen'. Evt als het nodig blijkt kan die 15 seconden backoff periode natuurlijk ook wat langer worden.

[DaanVervacke]

ctrl-tab schreef op zaterdag 30 mei 2026 @ 00:14:
[...]

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! :)

Ik liep zelf ook tegen dit probleem aan... mijn SolarFlow 2400AC die om en rond de 12-15 minuten uptime besloot om zichzelf van mn netwerk te verwijderen. Ik heb er mij de voorbije dagen eens grondig in verdiept en heb met reverse engineering een oplossing uitgewerkt. Waardoor ik nu mijn unit in een isolated VLAN heb zitten, zonder internet toegang en zonder dat hij elke 12-15 minuten disconnect omdat hij niet met de AWS broker van Zendure kan praten. Ik zoek nog testers, heb geen idee welke andere modellen ook dezelfde firmware draaien en dus ook dit probleem hebben, dus stuur mij gerust een PM. Eens ik kan valideren dat dit ook voor andere mensen werkt ben ik van plan om dit werk dan te open-sourcen.

Edit: als ik deze thread eens doorlees vermoed ik dat er toch veel mensen zijn met dit probleem

[DeadMetal]

@abaart ik zie waar het fout gaat. In addon_configs/a0d7b954_appdaemon/appdeamon.yaml, direct na installatie als app (addon) in HA, ontbreekt de volgende regel in de standaardinstellingen:

YAML:

  app_dir: /homeassistant/appdaemon/apps

En daardoor kijkt Appdeamon dus niet in de map waar HACS jouw pakketje installeerde.

Verder is het me niet duidelijk wat in te vullen bij server_port? Standaardwaarde lijkt me prima maar je documentatie zegt 'Voor een eerste test hoef je meestal alleen ip_zendure_1, ip_zendure_2, ip_zendure_3, server_host, en server_port aan te passen'
0.0.0.0 en 8120 is in principe gewoon prima?

[ Voor 31% gewijzigd door DeadMetal op 05-06-2026 19:33 ]

[Devke]

gast777 schreef op vrijdag 5 juni 2026 @ 18:02:
NB, zojuist heb ik ook een nieuwe versie van de Node-RED Proxy gepost (20260605), die ook als doel heeft om genoemd probleem/symptoom te adresseren.

Als iemand die dergelijke problemen ervaart die wil installeren en terugkoppelen of er symptomen verdwenen zijn en wat er eventueel nog over is, dan hoor ik het graag.

Wat nieuw is toegevoegd: Detectie of er een communicatieprobleem is tussen de proxy en de Zendures. Zo ja, stuur 15 seconden geen HTTP packets naar de Zendures. In plaats daarvan, stuur de laatste GET Response (uit cache) nog een keer naar HA.

Wat dit oplost:

1) HA zal geen onderbrekingen in de grafieken meer tonen als de communicatie naar de Zendures tijdelijk om wat voor reden dan ook niet werkt.

2) Als een Zendure HTTP server in een problematische staat is, zou deze mogelijk kunnen herstellen.

Punt 2 heb ik nog niet kunnen verifieren omdat ik dat probleem zelf niet heb. Punt 1 heb ik wel kunnen zien dat het werkt, bij wifi interrupties. Zie plaatje hieronder. Homewizard sensoren hebben een onderbreking, terwijl de proxy+Zendure geen onderbrekening heeft. Deze gaan beide over dezelfde verbinding (een tijdelijke wireless bridge).

[Afbeelding]

Ik zie je werk. Ga hem zeker uitproberen. Ik moet eerst ff weer wat vertrouwen opbouwen in mijn netwerk. . Als gielz netjes blijft draaien, kan ik weer stapje verder. Heb er net in het andere topic over geschreven. Misschien lag een corrupte container in HA wel ten grondslag?

[abaart]

DeadMetal schreef op vrijdag 5 juni 2026 @ 15:33:
[...]

@abaart ik reageer liever in dit topic. Ik wilde eens experimenteren met wat je gemaakt heb, maar ik loop vast. Je 'AppDaemon via HACS' stappenplan op https://github.com/abaart/Zendure-zenSDK-proxy is iets te beknopt voor me, hopelijk kan je laten zien wat ik fout doe. Appdeamon is nieuw voor me. HACS heb ik al.

Stap 1 t/m 7 heb ik gedaan, ging makkelijk
Stap 8 & 9, zit dat dan hier? /addon_configs/a0d7b954_appdaemon/appdaemon.yaml

YAML:

---
appdaemon:
  production_mode: true
  latitude: 52.379189
  longitude: 4.899431
  elevation: 2
  time_zone: Europe/Amsterdam
  plugins:
    HASS:
      type: hass
      token: !env_var SUPERVISOR_TOKEN
http:
  url: http://0.0.0.0:5050
admin:
api:
hadashboard:

Stap 10, zit dat dan hier? /addon_configs/a0d7b954_appdaemon/apps/apps.yaml
Daar heb ik de code toegevoegd van examples/apps.yaml (toegevoegd aan apps.yaml die enkel iets over hello world bevatte), de 2 Zendure ip-adressen aangepast, verder niks, en opgeslagen.

Als ik dan stap 13 uitvoer, de appdeamon app (addon) herstart, dan zie ik in de addon logs

code:

ModuleNotFoundError: No module named 'zendure_proxy'

En uitgebreider:

code:

[15:13:36] INFO: Starting AppDaemon...
s6-rc: info: service legacy-services successfully started
2026-06-05 15:13:56.016630 INFO AppDaemon: ------------------------------------------------------------
2026-06-05 15:13:56.017709 INFO AppDaemon: AppDaemon Version 4.5.13 starting
2026-06-05 15:13:56.018727 INFO AppDaemon: ------------------------------------------------------------
2026-06-05 15:13:56.019641 INFO AppDaemon: Python version is 3.12.13
2026-06-05 15:13:56.020515 INFO AppDaemon: Configuration read from: /config/appdaemon.yaml
2026-06-05 15:13:56.023907 INFO AppDaemon: Using /config/apps as app_dir
2026-06-05 15:13:56.029723 INFO AppDaemon: Loading built-in plugin 'HASS' using 'HassPlugin' from 'appdaemon.plugins.hass.hassplugin'
2026-06-05 15:13:56.031560 INFO HASS: HASS Plugin initialization complete
2026-06-05 15:13:56.033203 INFO AppDaemon: Initializing HTTP
2026-06-05 15:13:56.035259 INFO AppDaemon: Using 'ws' for event stream
2026-06-05 15:13:56.047815 INFO AppDaemon: Starting API
2026-06-05 15:13:56.055865 INFO AppDaemon: Starting Admin Interface
2026-06-05 15:13:56.057227 INFO AppDaemon: Starting Dashboards
2026-06-05 15:13:56.133217 INFO AppDaemon: Starting apps with 2 worker threads. Apps will all be assigned threads and pinned to them.
2026-06-05 15:13:56.148062 INFO AppDaemon: Running on port 5050
2026-06-05 15:13:56.150663 INFO AppDaemon: Waiting for plugins to be ready
2026-06-05 15:13:56.171739 INFO HASS: Connected to Home Assistant 2026.6.0 with aiohttp websocket
2026-06-05 15:13:56.176007 INFO HASS: Authenticated to Home Assistant 2026.6.0
2026-06-05 15:13:56.191319 INFO HASS: Waiting for Home Assistant to start
2026-06-05 15:13:56.214043 INFO AppDaemon: All plugins ready
2026-06-05 15:13:56.277149 INFO AppDaemon: Scheduler running in realtime
2026-06-05 15:13:56.320442 ERROR Error: =====  Error importing 'zendure_proxy'  ===================================
2026-06-05 15:13:56.327158 ERROR Error: FailedImport: Failed to import 'zendure_proxy'
2026-06-05 15:13:56.328331 ERROR Error:   Import paths:
2026-06-05 15:13:56.329586 ERROR Error:     /config/apps
2026-06-05 15:13:56.337200 ERROR Error:   ModuleNotFoundError: No module named 'zendure_proxy'
2026-06-05 15:13:56.343161 ERROR Error: ===========================================================================
2026-06-05 15:13:56.346098 WARNING AppDaemon: Failed to start apps: {'zendure_proxy'}
2026-06-05 15:13:56.356672 INFO AppDaemon: Starting apps: ['hello_world']
2026-06-05 15:13:56.421955 INFO AppDaemon: Calling initialize() for hello_world
2026-06-05 15:13:56.428329 INFO HASS: Completed initialization in 363ms
2026-06-05 15:13:56.716936 INFO hello_world: Hello from AppDaemon
2026-06-05 15:13:56.720641 INFO hello_world: You are now ready to run Apps!
2026-06-05 15:13:56.724506 INFO AppDaemon: App initialization complete

Ik denk dat mijn installatie niet helemaal meer is zoals die out-of-the-box is met HACS en appdaemon. Daardoor werken de instructies inderdaad wel bij mij, maar niet bij jou.

Als het goed is heeft HACS de proxy gezet in /homeassistant/appdaemon/apps
Om dat te checken zou je in de terminal op je HA kunnen draaien:

code:

find /config/appdaemon/apps -maxdepth 3 -type f \( -name 'apps.yaml' -o -name 'zendure_proxy*.py' \) -print | sort

Als dat inderdaad het juiste pad is, zou je kunnen proberen om je yaml aan te passen:

code:

appdaemon:
  production_mode: true
  app_dir: /homeassistant/appdaemon/apps
....

Daarna AppDaemon herstarten.
Hopelijk lost dit het op! Ik pas ook de README aan op GitHub.

Edit: al zelf opgelost zag ik..

[abaart]

DeadMetal schreef op vrijdag 5 juni 2026 @ 19:18:
@abaart ik zie waar het fout gaat. In addon_configs/a0d7b954_appdaemon/appdeamon.yaml, direct na installatie als app (addon) in HA, ontbreekt de volgende regel in de standaardinstellingen:

YAML:

  app_dir: /homeassistant/appdaemon/apps

En daardoor kijkt Appdeamon dus niet in de map waar HACS jouw pakketje installeerde.

Verder is het me niet duidelijk wat in te vullen bij server_port? Standaardwaarde lijkt me prima maar je documentatie zegt 'Voor een eerste test hoef je meestal alleen ip_zendure_1, ip_zendure_2, ip_zendure_3, server_host, en server_port aan te passen'
0.0.0.0 en 8120 is in principe gewoon prima?

Ja dat is prima. Zo draai ik het ook. LLM tekst
Heb de README omgebouwd naar engels en wat anders geordend. En server_host en server_port duidelijker gemaakt, dat die inderdaad niet veranderd hoeven te worden.

[Tiesert]

Ik heb weer dat de 2400AC+ met standaard FireSon Zendure integratie helemaal volgeladen is, maar niet meer omschakelt naar laden. Dan komt er dus stroom van het grid zonder dat de batterij bijspringt door te gaan ontladen. Hij blijft op status Sleeping. Echt balen.

[gielz]

Tiesert schreef op vrijdag 5 juni 2026 @ 22:18:
Ik heb weer dat de 2400AC+ met standaard FireSon Zendure integratie helemaal volgeladen is, maar niet meer omschakelt naar laden. Dan komt er dus stroom van het grid zonder dat de batterij bijspringt door te gaan ontladen. Hij blijft op status Sleeping. Echt balen.[Afbeelding]

Zie je dan wel in http://<IPZENDURE>/properties/report de vermogensopdrachten voorbij komen of is hij volledig tot stilstand gekomen? Als hij de vermogensopdrachten wel ontvangt maar niet uitvoert is het een Zendure supportticket en anders een issue bij Zendure HA op de github.

[DeadMetal]

/edit: een herstart van Node-RED verhielp het probleem

Ik sta even voor een raadsel. Ik wilde mijn DSMR reader addon verwijderen uit HA (als addon/app), en switchen naar de DSMR Smart meter integratie in HA. Oftewel, dan gaat die addon er tussenuit, en dus minder vertraging tot de P1 meetwaarden in HA aankomen. Vervolgens heb ik een template sensor aangemaakt 'sensor.huidig_netto_vermogen' en deze ingesteld op het configuratietabblad van de gielz bij 'Afwijkende P1 sensor'. So far so good, ik zie na het starten van de automatisering ook netjes dat de P1 data weer goed binnenkomt (zie de 223 watt rechtsboven, en die wijzigt ook elke paar seconden):


Maar de batterij doet verder niks. En diverse sensoren staan plotseling op Niet beschikbaar:



Zelfs de 'Modus'. En ook de communicatie met de proxy (de gast777 danwel de abaart) lijkt er niet meer in te zitten:



De automatisering draait, de laatste hartbeat controle is steeds van de huidige/vorige minuut)

[ Voor 3% gewijzigd door DeadMetal op 05-06-2026 23:17 ]

[Tiesert]

gielz schreef op vrijdag 5 juni 2026 @ 22:25:
[...]


Zie je dan wel in http://<IPZENDURE>/properties/report de vermogensopdrachten voorbij komen of is hij volledig tot stilstand gekomen? Als hij de vermogensopdrachten wel ontvangt maar niet uitvoert is het een Zendure supportticket en anders een issue bij Zendure HA op de github.

Dank je voor het meedenken. Ik zie op /properties/report wel de timestamp en de messageid oplopen, maar verder zie ik volgens mij alleen instellingen en serienummers. Zo blijven inputLimit":0,"outputLimit":0 ongewijzigd staan. Net als: heatState":0,"packInputPower":0,"outputPackPower":0,"outputHomePower":0,"remainOutTime":59940,"packState":0,"electricLevel":100,"gridInputPower":0,"solarInputPower":0

De status is Sleeping met Laden en Ontladen op 0, maar bij de Integratie zie ik bij de Zendure Manager de State op Charging staan met Power -300W. Dit verandert niet, hij zit dus helemaal vast. Ik laad op 2400W op aparte groep en de batterij is 100% vol. Dit is tot op heden altijd het geval wanneer dit probleem zich voordoet.

De AC+ uitgezet (rode bliksemflitsje knippert), stekker er uit en na 30s er weer in. In HA lijkt niets verandert. Alles wat hier boven staat is nog steeds zo zichtbaar.

Als ik dan HA herstart staat hij daarna nog steeds op sleeping. Maar bij de Zendure Manager is iets veranderd. Daar staan Beschikbare Energie, Power en State op Unknown. De Totale Batterij Capaciteit is wel bekend. Alle andere sensoren zijn gewoon gevuld (geen unknown of unavailable). Wisselen tussen de Modus Off en Modus Smart Matching maakt de boel niet los.

Op het netwerk zie ik de Zendure wisselen tussen 0 en 15kbps upload en 0 en 1kbps download. Er gebeurt weinig. Het netwerk herstart, maar dat heeft ook geen effect.

Toen in de Zendure App bij Instellingen voor Netaansluiting de Output (naar woning) van 0 naar 465W (willekeurig) gezet en hij begint te ontladen. in HA zie ik dat Sleeping verandert in Discharging en inderdaad Ontladen met 465W. Alleen als ik dan bij de Zendure Manager weer kies voor Smart Matching neemt HA de regie niet over. Hij blijft op een vaste waarde van 465W ontladen. In de Zendure Manager staan Beschikbare Energie, Power en State nog steeds op Unknown.

Weet verder niet wat ik nog kan doen. HA lijkt wel goed de Zendure uit te lezen (op drie sensoren in de Zendure Manager na), maar kan niets naar de Zendure schrijven. Alle opdrachten worden genegeerd. Echt balen, als ik dit soort gedoe wilde had ik wel een Marstek gekocht....

Update: na nog een keer herstarten van eerst de Zendure en daarna HA werk alles weer.

[gielz]

Tiesert schreef op zaterdag 6 juni 2026 @ 00:20:
[...]

Dank je voor het meedenken. Ik zie op /properties/report wel de timestamp en de messageid oplopen, maar verder zie ik volgens mij alleen instellingen en serienummers. Zo blijven inputLimit":0,"outputLimit":0 ongewijzigd staan. Net als: heatState":0,"packInputPower":0,"outputPackPower":0,"outputHomePower":0,"remainOutTime":59940,"packState":0,"electricLevel":100,"gridInputPower":0,"solarInputPower":0

De status is Sleeping met Laden en Ontladen op 0, maar bij de Integratie zie ik bij de Zendure Manager de State op Charging staan met Power -300W. Dit verandert niet, hij zit dus helemaal vast. Ik laad op 2400W op aparte groep en de batterij is 100% vol. Dit is tot op heden altijd het geval wanneer dit probleem zich voordoet.

De AC+ uitgezet (rode bliksemflitsje knippert), stekker er uit en na 30s er weer in. In HA lijkt niets verandert. Alles wat hier boven staat is nog steeds zo zichtbaar.

Als ik dan HA herstart staat hij daarna nog steeds op sleeping. Maar bij de Zendure Manager is iets veranderd. Daar staan Beschikbare Energie, Power en State op Unknown. De Totale Batterij Capaciteit is wel bekend. Alle andere sensoren zijn gewoon gevuld (geen unknown of unavailable). Wisselen tussen de Modus Off en Modus Smart Matching maakt de boel niet los.

Op het netwerk zie ik de Zendure wisselen tussen 0 en 15kbps upload en 0 en 1kbps download. Er gebeurt weinig. Het netwerk herstart, maar dat heeft ook geen effect.

Toen in de Zendure App bij Instellingen voor Netaansluiting de Output (naar woning) van 0 naar 465W (willekeurig) gezet en hij begint te ontladen. in HA zie ik dat Sleeping verandert in Discharging en inderdaad Ontladen met 465W. Alleen als ik dan bij de Zendure Manager weer kies voor Smart Matching neemt HA de regie niet over. Hij blijft op een vaste waarde van 465W ontladen. In de Zendure Manager staan Beschikbare Energie, Power en State nog steeds op Unknown.

Weet verder niet wat ik nog kan doen. HA lijkt wel goed de Zendure uit te lezen (op drie sensoren in de Zendure Manager na), maar kan niets naar de Zendure schrijven. Alle opdrachten worden genegeerd. Echt balen, als ik dit soort gedoe wilde had ik wel een Marstek gekocht....

Update: na nog een keer herstarten van eerst de Zendure en daarna HA werk alles weer.

Lijkt mij op een standaard communicatie probleem tussen HA en de batterij. Kan het zelf hier niet nabootsen want de batterij heeft de afgelopen 13 maanden nooit mij in de steek gelaten. Mocht hij ooit bevriezen dan zal ik kijken of ik hem actief krijg via zenSDK.

Je zou eventueel een eigen restcommando kunnen schrijven via zenSDK om te kijken of je hem zelf wel actief krijgt. Of een andere integratie kunnen gebruiken die iets minder overhead heeft om te zien of dat beter werkt.