Zendure producten in Home Assistant integreren deel 2

[DrNickB]

gielz schreef op zondag 17 mei 2026 @ 08:05:
[...]


@denneappel @DrNickB jullie hebben toch ook een 800? Hebben jullie dan ook problemen doordat mogelijk de hardware trager is?

Nee, tenminste niet waar ik iets aan kan merken.
Gebruik toevallig ook UniFi, staat bij mij op einde terras, terwijl Sf800Pro in de schuur achter een stalen deur staat.
Mijn signaal is gemiddeld goed, maar her en der ook zwak en uitstekend (Deur open).
Heb eigenlijk nooit een freeze of iets dergelijks gemerkt, draai al vanaf september en altijd op gielz.
Niks anders, geen eigen extra polls, heb mijn eigen entiteiten allemaal verwerkt binnen de gielz package, zodat alles loopt via die ene rest call.

[denneappel]

gielz schreef op zondag 17 mei 2026 @ 08:05:
[...]


@denneappel @DrNickB jullie hebben toch ook een 800? Hebben jullie dan ook problemen doordat mogelijk de hardware trager is?

Ik heb eigenlijk geen connectie problemen.

2 sf800pro's in de hooischuur met een Unifi accespoint en 1 sf800pro in mijn kantoor op een iets drukker Unifi accespoint.

Ik gebruik Uptime Kuma waarbij ze in een groep zitten. Over ICMP heb ik een uptime van 99.72% (24h) en 99.37% (30d). Zodra 1 unit onbereikbaar is dan geldt dat voor de hele groep.

De discussie heeft mij wel aan het denken gezet. Ik ga even een monitor aanmaken die over http loopt om te zien of de webserver specifiek misschien minder presteert.

[DrNickB]

hemertje schreef op vrijdag 15 mei 2026 @ 20:23:
Update t.o.v. de eerdere versie

Voor wie z'n Zendure inverters wil koelen met externe ventilatoren via de offgrid socket: kant-en-klare HA package + dashboard kaart, werkt out-of-the-box met Gielz + gast777 (EN). Pas alleen je temp_on/temp_off thresholds aan.

[...]


[...]


En de bijbehorende helpers + automations package


[...]


[Afbeelding]

Kan het zijn dat ik in je code, wat daadwerkelijke acties mis naar de zendure toe? of lees ik er zwaar over heen.

Zelf gebruik ik de zelfde structuur, echter in uw code (met gebruikers) kun je de aan/uit waardes zo in stellen dat hij nooit aan gaat of nooit uit gaat

[Hippe Lip]

Mijn twee stacks zijn weer via de proxy van @gast777 verbonden met de zenSDK van @gielz en het gehakkel is weer begonnen.

Als ik het zo met mij (leken)oog bekijk lijkt processorcapaciteit of geheugen niet het probleem. En WiFi hadden we al uitgesloten.
Wie waagt zich aan een analyse?

[ Voor 11% gewijzigd door Hippe Lip op 17-05-2026 10:17 ]

[Pakhaas]

@Hippe Lip om te achterhalen wat er mis gaat met de proxy, moet je een debug file maken. @gast777 heeft daar een dashboard voor gemaakt zodat dat heel simpel is. Je moet wel even de proxy naar de laatste versie updaten.

[gielz]

Hippe Lip schreef op zondag 17 mei 2026 @ 10:15:
Mijn twee stacks zijn weer via de proxy van @gast777 verbonden met de zenSDK van @gielz en het gehakkel is weer begonnen.

Als ik het zo met mij (leken)oog bekijk lijkt processorcapaciteit of geheugen niet het probleem. En WiFi hadden we al uitgesloten.
Wie waagt zich aan een analyse?

[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Had je ook al in de Zendure app zelf gekeken onder Devices > Zendure kiezen > Statistics en dan helemaal onderaan naar het battery charge level. Hoe ziet deze grafiek daar er uit? Heb je daar een screenshot van.

Wellicht zo?

[Maarten60]

@gielz @hemertje

[...] deze foutmelding ook elke keer dat Home Assistant opnieuw opstart?

"Error fetching data: http://unknown/api/v1/data failed"
"Error fetching data: http://unknown/properties/report failed"

Ik denk dat melden bij Home Assistant Core wel zinvol is, maar niet als specifieke Zendure/Gielz bug.

De kern lijkt breder: een REST resource_template kan bij HA startup al geëvalueerd worden terwijl helpers zoals input_text nog tijdelijk unknown zijn. Daardoor ontstaat een call naar http://unknown/... en dus een logfout, terwijl de configuratie later gewoon goed werkt.

Van de voorgestelde HA Core-oplossingen lijkt optie A mij het netst: een availability_template op REST block-niveau. Dan kun je declaratief voorkomen dat de REST poll start zolang de benodigde helper nog geen geldige waarde heeft. Dat sluit beter aan bij bestaande HA-conventies dan stilzwijgend unknown URL’s negeren.

Ik denk ook niet dat de technische complexiteit per definitie heel groot hoeft te zijn. De echte vraag is vooral welk gedrag HA wil hanteren voor REST resources die tijdens startup nog geen geldige templatewaarde hebben. Andere HA componenten kennen immers al vergelijkbare mechanismen, zoals availability_template.

[Maarten60]

@gielz
Voor mijn eigen installatie heb ik het opgelost door de REST reads via een statische resource: !secret ... te laten lopen. Dat geeft een schoon log, maar is minder flexibel omdat het IP-adres dan niet meer via een helper/dashboard instelbaar is.

Ik begrijp de afweging om dit niet als standaardoplossing in de package op te nemen, omdat secrets.yaml voor sommige gebruikers weer een extra stap is. Tegelijkertijd is de wijziging, zodra secrets.yaml al gebruikt wordt, juist erg klein en levert het wel een schoon log op zonder startup REST errors.

Misschien is daarom een tussenweg handig: de !secret variant standaard als commentaar opnemen direct onder de bestaande resource_template regel. Dan kunnen gebruikers die al met secrets.yaml werken de startup-safe variant eenmalig configureren en daarna eenvoudig activeren.

Bijvoorbeeld:

code:

# standaard 
resource_template: "http://{{ states('input_text.homewizard_p1_ip_adres') }}/api/v1/data" 
# optionele variant via secrets.yaml om startup errors te voorkomen
# resource: !secret homewizard_p1_api_url

en

code:

# standaard 
resource_template: "http://{{ states('input_text.zendure_unit_1_ip') }}/properties/report" 
# optionele variant via secrets.yaml om startup errors te voorkomen
# resource: !secret zendure_report_url

Dan blijft de standaardconfiguratie eenvoudig, maar is de workaround voor gebruikers met startup logfouten wel direct beschikbaar en update-proof gedocumenteerd.

[naftebakje]

Ik heb net de Gielz zendure upgedate, en omdat ik nu de aparte file onder packages gebruik (had het ervoor rechtstreeks in configuration.yaml gezet) moest ik opnieuw configureren.

Ik gebruik een DSMR power meter (via een helper), maar hij neemt hem nu niet meer. De helper sensor werkt gewoon, ziet elke 5 seconden netjes een nieuwe waarde, maar in de integratie zie je geen waarde bij "home energy meter power" (die is niet beschikaar).

Is dit een bugje? Iemand anders die ook een "eigen" P1 gebruikt die wel werkt?

Oeps, sensornaam verkeerd, . ipv _

[ Voor 5% gewijzigd door naftebakje op 17-05-2026 11:57 ]

[Hippe Lip]

gielz schreef op zondag 17 mei 2026 @ 10:40:
Had je ook al in de Zendure app zelf gekeken onder Devices > Zendure kiezen > Statistics en dan helemaal onderaan naar het battery charge level. Hoe ziet deze grafiek daar er uit? Heb je daar een screenshot van.

Die mogelijkheid lijk ik niet te hebben. Alsnik op het woord ‘Zendure’ druk gebeurt er nix.

[ZuinigeRijder]

@Hippe Lip Je moet één van de twee Solarflow 2400 AC+ kiezen, dan kun je de statistieken van die omvormer/batterijen kiezen.

[ Voor 6% gewijzigd door ZuinigeRijder op 17-05-2026 13:17 ]

[DrNickB]

Hippe Lip schreef op zondag 17 mei 2026 @ 13:10:
[...]

Die mogelijkheid lijk ik niet te hebben. Alsnik op het woord ‘Zendure’ druk gebeurt er nix.

[Afbeelding]

Klik op 1 van je 2 2400+ en dan op Statistics (De gene met mogelijk meeste problemen).
Kun je ook nog dagen heen en weer.

Als je gaten in deze grafieken ziet, zoals hierboven ergens aangegeven, dan is het hoogst waarschijnlijk wifi/cloud communicatie die de waardes niet goed door geeft.