Zendure producten in Home Assistant integreren deel 2

[Gramser]

ppaulv schreef op vrijdag 30 oktober 2026 @ 12:26:
[...]

nee, staan naast elkaar in hetzelfde wifi netwerk via hetzelfde AP. Dus dat is het niet.[Afbeelding] En beide hebben lange tijd (maanden) los van elkaar met alleen Gielz prima gefunctioneerd. Pas sinds ik ze allebei aan heb staan en via NR aanstuur gebeurt dit af en toe.

Dus beide zendures op een accesspoint, en alleen die zendures zitten daarop? En dat accesspoint is bekabeld op je router aangesloten? Dit lijkt namelijk erg op wat ik eerst ook had: de boel bleef vastlopen voordat ik de zendures op een separaat accesspoint had gezet. Ook heb ik de cached responsetijd in NR naar 2 minuten gezet.

[ppaulv]

Fire71 schreef op vrijdag 30 oktober 2026 @ 13:20:
[...]

TX retries worden gedaan als er geen bevestiging van connectie komt van de tegenpartij. Een teken van een slechte connectie dus.

Als er geen connectie is kan de2400+ ook niet reageren op vermogensinstructruties. En ook geen connectie maken met een P1 meter.

Zit de antenne goed vastgeschroeft? Heb je in de router aangegeven dat de Zendure alleen mag connecteren met die specifieke AP? En dus nooit met andere AP? Ik heb Asus AI mesh routers en zorg ervoor dat mijn Zendures alleen met het garage AP mogen connecteren.

Waarom de 2400 AC bevriest weet ik niet. Worden ze samen aangestuurd met omnibatterij of Gielz/NR oid?

Met antenne is niks mis voor zover ik kan zien, de AC+ staat letterlijk naast de AC en is hoger dus steekt er bovenuit. Ik beide een vast IP adres gegeven maar niet gedwongen aan één AP, die hebben ze zelf gekozen.
Heel vreemd maar ik kan dan niet verklaren waarom de NR van gast777 bevriest. Want daar lijkt het op. Als ik nou zou zien dat de power commando's van Gielz/Gast777 veranderen maar de accu's reageren niet, dan ligt het vrij zeker aan de Zendures.
Maar als ik in Gielz de modus verander in Manual of Stanby, verandert er niets in de commando's die ik van Gast777 zie.
Ik bedoel deze:

[ppaulv]

Gramser schreef op vrijdag 30 oktober 2026 @ 13:26:
[...]

Dus beide zendures op een accesspoint, en alleen die zendures zitten daarop? En dat accesspoint is bekabeld op je router aangesloten? Dit lijkt namelijk erg op wat ik eerst ook had: de boel bleef vastlopen voordat ik de zendures op een separaat accesspoint had gezet. Ook heb ik de cached responsetijd in NR naar 2 minuten gezet.

Nee er zit vanalles op dat AP (8 stuks) en zeker op dat wifi netwerk (32). Maar AP is wel bekabeld.
Ben geen expert maar op een van de pieken van afgelopen etmaal zie ik weinig problemen.


Hoe zet je die cached responsetijd anders? En waarom zou dat helpen?

[ Voor 5% gewijzigd door ppaulv op 30-10-2026 13:35 ]

[Gramser]

Ik weet niet precies hoe die cached responsetijd werkt, maar voor mezelf verklaar ik het als volgt: NR geeft continu opdrachten aan de zendures en vergaloppeert zich soms. Met de cached responsetijd breng je er weer even wat rust in door een aantal seconden/minuten de opdrachten te negeren.

Je vindt het in NR in het scherm waar je ook de ip adressen ingeeft. Beetje naar onderen scrollen en daar vind je wat aanpasbare variabelen. Het heet daar geen cached response uit mn hoofd, maar staat wel op 15 sec. Daar herken je ‘m ook aan.

Maar een puur dedicated AP kan ook helpen.

[Fire71]

ppaulv schreef op vrijdag 30 oktober 2026 @ 13:28:
[...]

Met antenne is niks mis voor zover ik kan zien, de AC+ staat letterlijk naast de AC en is hoger dus steekt er bovenuit. Ik beide een vast IP adres gegeven maar niet gedwongen aan één AP, die hebben ze zelf gekozen.
Heel vreemd maar ik kan dan niet verklaren waarom de NR van gast777 bevriest. Want daar lijkt het op. Als ik nou zou zien dat de power commando's van Gielz/Gast777 veranderen maar de accu's reageren niet, dan ligt het vrij zeker aan de Zendures.
Maar als ik in Gielz de modus verander in Manual of Stanby, verandert er niets in de commando's die ik van Gast777 zie.
Ik bedoel deze:
[Afbeelding]

Dat heb ik ook laatst gehad, dat van dat schijnbaar bevriezen. HA herstart hielp niet. En ook niet wifi herstarten.

Alleen een reboot van de Zendures hielp. Trek de stekker uit stopcontact. Druk minimaal zes seconden op de knop. Lange piep, dan is Zendure uit. Daarna stekker weer in stopcontact en de Zendure start automatisch.

Achteraf had ik het vermoeden dat het gebeurd is na een upgrade van Node Red in HA. Maar dat is maar een vermoeden. Kan heel goed iets anders geweest zijn.

Vraag: Doet de Gast777 flow het automatisch weer na een update van Node Red?

[Polvo176]

SamWjjchen schreef op vrijdag 30 oktober 2026 @ 13:14:
[...]

Dank... Wifi reset in de zendure app een optie?

In de Zendure app zal waarschijnlijk het zelfde adres staan wat ook in de router staat, dus nee, dat gaat niet helpen.

[ppaulv]

Fire71 schreef op vrijdag 30 oktober 2026 @ 13:48:
[...]

Dat heb ik ook laatst gehad, dat van dat schijnbaar bevriezen. HA herstart hielp niet. En ook niet wifi herstarten.

Alleen een reboot van de Zendures hielp. Trek de stekker uit stopcontact. Druk minimaal zes seconden op de knop. Lange piep, dan is Zendure uit. Daarna stekker weer in stopcontact en de Zendure start automatisch.

Achteraf had ik het vermoeden dat het gebeurd is na een upgrade van Node Red in HA. Maar dat is maar een vermoeden. Kan heel goed iets anders geweest zijn.

Vraag: Doet de Gast777 flow het automatisch weer na een update van Node Red?

een reboot van beide Zendures hielp bij mij dus niet.
Het is mijn eerste installatie van NR, heb nog niets ge-update. En HA en NR staan dus los van elkaar, beide in hun eigen Docker container.

[Luuk741]

NWE schreef op vrijdag 30 oktober 2026 @ 12:39:
[...]

Is er echt geen andere mogelijkheid om de SF3000 in HA "uit te lezen", op dezelfde manier als ik de HW P1 meter uitlees, de de Enphase Envoy "controller" in HomeAssistant ?? Ik heb dan 1 simpel dashboard met alle belangrijke spelers (op mijn PC) . Het managen van de batterij kan ik dan, indien noodzakelijk , nog vanaf mijn friemelscherpje-iPhone doen.

En als je gielz gebruikt, maar de automation die de aansturing regelt niet installeert of inschakelt? Ik weet het niet zeker hoor, maar wellicht het proberen waard. Aan de andere kant kun je hem net zo goed aansturen via Gielz ipv de Zendure app, als je dat dan toch al ingesteld heb

[PaulC]

Gramser schreef op vrijdag 30 oktober 2026 @ 13:26:
[...]

Dus beide zendures op een accesspoint, en alleen die zendures zitten daarop? En dat accesspoint is bekabeld op je router aangesloten? Dit lijkt namelijk erg op wat ik eerst ook had: de boel bleef vastlopen voordat ik de zendures op een separaat accesspoint had gezet. Ook heb ik de cached responsetijd in NR naar 2 minuten gezet.

Aangezien ik ook nogal veel iot apparaten heb en het issue ivm wifi verbindingen hier regelmatig opduikt, zie hier de (met 50% ai hulp ooit samengesteld, i admit) summary die ik in mijn docu staan heb ivm wifi (6) verbindingen (in mijn geval ASUS, maar een groot deel is ook applicable op andere merken zonder meer (alleen kan een setting dan beetje anders noemen of niet aanwezig zijn)

Bij Wi-Fi 6 (802.11ax) routers – en specifiek bij merken zoals ASUS – duikt er af en toe een bekend compatibiliteitsprobleem op dat vooral te maken heeft met oudere clients en slimme huishoudelijke apparaten (IoT).

​Hoewel Wi-Fi 6 volledig achterwaarts compatibel is met oudere standaarden zoals Wi-Fi 5 (802.11ac) en 802.11n, kan de agressieve implementatie van nieuwe Wi-Fi 6-technologieën in de routerfirmware soms voor wrijving zorgen.

​Kuren met Smart Home / IoT-apparaten: Veel slimme stekkers, lampen, oudere IP-camera's of smart home hubs die enkel op 2.4 GHz draaien, raken in de war van moderne Wi-Fi 6-features en vertikken het om te verbinden of verliezen continu hun signaal.

​Welke specifieke instellingen veroorzaken dit?

(​ASUS-)routers hebben een aantal geavanceerde Wi-Fi 6-optimalisaties ingebouwd die dit veroorzaken. Als je merkt dat apparaten verbindingsproblemen hebben, moet je die in de webinterface handmatig uitschakelen of aanpassen:

• ​Target Wake Time (TWT): Een Wi-Fi 6 feature die energie bespaart voor mobiele apparaten door de slaapstand van de Wi-Fi-chip te timen. Oudere of vaste apparaten trekken dit slecht en vallen offline.
• ​Protected Management Frames (PMF): Soms incompatibel met oudere clients.
• ​Wi-Fi Agile Multiband / Roaming-assistenten: Kunnen oudere apparaten "wegduwen" of in een loop van connectie-pogingen laten belanden.
• ​Smart Connect (de bandsteering): Waarbij 2.4 GHz en 5 GHz onder één SSID worden samengevoegd; slimme apparaten weten dan vaak niet op welke frequentie ze moeten vastberaden.

​De oplossingen (in ASUSWRT)

​Mocht je tegen zo'n compatibiliteitsprobleem aanlopen, dan biedt ASUS gelukkig de volledige controle om dit op te lossen (in tegenstelling tot gesloten systemen):

• ​Je kunt per frequentie de 802.11ax / Wi-Fi 6 mode tijdelijk uitschakelen of finetunen voor specifieke netwerken.
• ​Je kunt een apart, geïsoleerd 2.4 GHz gastennetwerk of IoT-netwerk aanmaken waarbij je geavanceerde ax-features uitzet, zodat je oudere apparaten probleemloos verbinding maken, terwijl je hoofdnetwerk vol openstaat voor moderne Wi-Fi 6 apparatuur.

IoT-apparaten locken op een vaste node

​Standaard zijn mesh-systemen heel "agressief": ze proberen apparaten voortdurend te verplaatsen naar de node met het sterkste signaal. Veel statische IoT-apparaten (zoals slimme lampen of thermostaten) raken daar de weg door kwijt.

​In ASUSWRT kun je dit oplossen:

1. ​Via AiMesh Device Control (De officiële manier):
   • ​Log in op je webinterface en ga links naar AiMesh.
   • ​Klik op het tabblad Topology (Topologie) en klik op de node waar je het apparaat op wilt vastzetten.
   • ​Aan de rechterkant verschijnt een paneel met de gekoppelde clients onder die node.
   • ​Klik op het apparaat en zet de optie Binding (of Roaming Block) aan. Hiermee dwing je het apparaat om uitsluitend verbinding te maken met deze specifieke node en niet meer te gaan zwerven naar een andere node.
2. ​Via een apart IoT-netwerk (De robuuste aanpak):
   • ​Als je gebruikmaakt van Guest Network Pro (SDN) op je (ASUS-)router, kun je een apart 2.4 GHz-netwerk aanmaken dat je optioneel op een specifieke node of juist over het hele bereik laat uitzenden, afgeschermd van je hoofdnetwerk

Welk vast kanaal is het beste voor 2.4 GHz IoT?

​Voor de 2.4 GHz-band (waar nagenoeg al het IoT op draait) is automatische kanaalkeuze vaak een ramp, omdat omringende Wi-Fi-netwerken van buren er doorheen storen.

​De gulden regel voor de 2.4 GHz-band is dat je alleen kanaal 1, 6 of 11 mag gebruiken. Dit zijn de enige drie kanalen die elkaar niet overlappen.

• ​Waarom deze? Om te bepalen welke van de twee het rustigste is, kun je op je telefoon een gratis wifi-analyzer app installeren. Kies het kanaal waar de buren het minst op zitten.
• ​Belangrijke instelling (Kanaalbreedte): Zet de kanaalbreedte (Channel Bandwidth) voor de 2.4 GHz-band vast op 20 MHz (en dus niet op 20/40 MHz).
  • ​Waarom? De 2.4 GHz-band is erg smal. Als je 40 MHz kiest, pak je dubbel zoveel bandbreedte van de buren mee, wat zorgt voor gigantisch veel interferentie en wegvallende IoT-verbindingen. 20 MHz is trager, maar rotsvast en storingsvrij voor slimme apparaten.

[raven22]

Fire71 schreef op vrijdag 30 oktober 2026 @ 12:46:
[...]

Wel een opvallend groot verschil in wifi connectie sterkte (-46 vs -73 dbm) voor apparaten die naast elkaar staan. Een sterkte van -73 dbm is echt op het randje van bruikbaar.  Staat de wifi antenne van de 2400+ wel overeind? Zit er geen metaal tussen de AP en de 2400+?

Ter vergelijk, mijn 2 x 2400 pro staan ook naast elkaar, onder mijn AP, en hebben -31 en -34 dbm.

Mijn SF 800 plus staat achter in de tuin onder een overkapping. -84 tot 80db op zijn best.
Slechts een hele enkele keer is de batterij even niet bereikbaar, maar binnen het uur is dat weer hersteld.

[HiBe]

fv schreef op maandag 14 september 2026 @ 17:09:
Ik gebruik de Gielz integratie in HA met twee Zendure 3000 Mix'en ongeveer een maand, maar merk toch wel heel veel overshoot tijdens laden/ontladen waardoor je of teveel ontlaad t.o.v. huidig verbruik of teveel laad uit het net tijdens laden bij zonneovershot. Maar ook s'nacht bij vrij constant verbruik zijn er teveel (hoge) uitschieters (naar boven en beneden). Die zie je trouwens niet in het dashboard van de integratie aangezien deze een smoothing van data laten zien.
Ik gebruik overigens niet de "Dynamische" opties, puur alleen om zonneoverschot op te slaan en s'avond/s'nachts te gebruiken of voor Smart Matching.

Het systeem regelt dus, naar mijn bevinding, te laat. Ik kon dit eerst verklaren doordat de P1 data per 10 sec. verandert (wel DSMR5 meter, dus iedere 1 sec. zenden, maar nieuwe data gaat per 10 sec.:(). Na installatie van een Shelly Pro 3EM wordt de integratie getriggerd door verbruik verandering (tussen 1 a 3 sec.) of iedere 5 sec. automatisch indien geen verbruik verandering. Dit verbeterde de regeling beter, maar kan voor mijn gevoel nog beter. Heb ook wat zitten tunen aan de laad en ontlaad-factor in de laad/ontlaad routine in integratie. Is dit bovenstaande door ander gebruikers ook herkenbaar?

Tevens heb ik de integratie door Claude laten analyseren (niet geschoten altijd mis) of de logica ervan correct is. Hier kwamen wel wat belangrijke punten naar boven en na eigen analyse kan de code ook simpeler/anders op meerdere plekken.
Het beste zou zijn denk ik als de laad/ontlaad logica wordt vervangen door een goed getunde PI(D) regeling. Hier ben ik ook al mee aan het experimenteren...

@fv heb je nog voortgang geboekt met een PID regeling ?

[m-vw]

NWE schreef op vrijdag 30 oktober 2026 @ 12:39:
[...]

Is er echt geen andere mogelijkheid om de SF3000 in HA "uit te lezen", op dezelfde manier als ik de HW P1 meter uitlees, de de Enphase Envoy "controller" in HomeAssistant ?? Ik heb dan 1 simpel dashboard met alle belangrijke spelers (op mijn PC) . Het managen van de batterij kan ik dan, indien noodzakelijk , nog vanaf mijn friemelscherpje-iPhone doen.

Een paar posts onder mijn post is gereageerd dat Gielz ook gewoon de waardes weergeeft als je de automatisering verder niet gebruikt. De entiteiten die door Gielz gecreëerd worden kan je overigens ook op andere dashboarden gebruiken.

[fv]

HiBe schreef op vrijdag 30 oktober 2026 @ 15:12:
[...]

@fv heb je nog voortgang geboekt met een PID regeling ?

Nee, na wat geëxperimenteer het project voorlopig even laten liggen. Kreeg de regeling nog niet stabiel genoeg.

Door de laad/ontlaad factor in de Gielz integratie te kunnen aanpassen via HA ben ik wel tot betere resultaten gekomen en gebruik een Shelly 3-fase stroommeting die veel sneller data genereert dan via de P1 ondanks DSMR5 meter.

We gaan de winter in en dan gaan de accu's ook niet zoveel meer doen icm. zonnecellen (ik doe geen dynamische regeling, heb nog een vast contract tot einde 2027).

[ Voor 12% gewijzigd door fv op 30-10-2026 16:01 . Reden: Aanvulling ]

[ppaulv]

Vandaag doet ie het weer anders. De AC staat volle bak op te laden, de AC+ doet niets en de aansturing zegt 'm dat ie moet terugleveren ....



De vorige keer was het (meen ik) de AC+ die bleef hangen. En daarvoor beide samen.
Ga dadelijk weer eens snuffelen .... Niets te ruiken.

Heb de AC weer in de Zendure HEMS gehangen, policy opnieuw geselecteerd en meteen gaat ie op Standby (dat is de policy). Weer uit HEMS gehaald.

NR van @gast777 blijft zo te zien hangen. De bovenste 3 regels zij al 13 minuten onveranderd (en slaan nergens op overigens)

[ Voor 34% gewijzigd door ppaulv op 30-10-2026 17:21 ]

[Gramser]

Je hebt dus een 2400 en een 2400+ samen in Gielz via gast777? Is dat een use case? Ik meende (maar weet het niet zeker) dat gast777 bedoeld was voor dezelfde modellen?

[RemmyB83]

Gramser schreef op vrijdag 30 oktober 2026 @ 17:15:
Je hebt dus een 2400 en een 2400+ samen in Gielz via gast777? Is dat een use case? Ik meende (maar weet het niet zeker) dat gast777 bedoeld was voor dezelfde modellen?

Nee, gaat erom dat het vermogen gelijk is.
2400 en 2400 gaat goed.
Maar geen 800 en 2400.

[Spikydog]

RemmyB83 schreef op vrijdag 30 oktober 2026 @ 18:14:
[...]

Nee, gaat erom dat het vermogen gelijk is.
2400 en 2400 gaat goed.
Maar geen 800 en 2400.

Gaat wel hoor, hier 2 x 800+ en 1 x 2400AC+, geen enkel probleem

[RemmyB83]

Spikydog schreef op vrijdag 30 oktober 2026 @ 18:59:
[...]

Gaat wel hoor, hier 2 x 800+ en 1 x 2400AC+, geen enkel probleem

Dan heb je denk ik de NR aangepast?

[ppaulv]

En een half uur geleden zat ie weer vast. Bleven ze samen maximaal ontladen. Via Zendure app en HEMS weer op STandby gekregen.
En nu net weer de AC die vol ging ontladen en nergens meer op reageerde. Zelfde 'oplossing'.
Ik heb nu NR gestopt en ga de batterijen nu geheel geïsoleerd met Gielz aansturen. Kijken of een van de twee weer de fout in gaat. Dit werkt zo niet.
Zijn er overiens alternatieven voor de NR proxy? Gielz zelf wil ik niet graag kwijt denk ik maar ik begin open te staan voor opties ....

[Gramser]

Is Omnibattery niks voor jou?

[ppaulv]

Gramser schreef op vrijdag 30 oktober 2026 @ 20:18:
Is Omnibattery niks voor jou?

Misschien wel maar waarom doet de Gast777 proxy het bij mij zo raar? Als dat niks met die proxy te maken heeft verschuift het probleem dan alleen maar.
Als het daar wèl mee te maken heeft, waarom ben ik dan 'de enige' die dit ziet gebeuren?
Ik wordt hier niet blij van.
Heb nu de AC+ op Standby en de AC als enig in Gielz en laat het zo even een dagje draaien.

[Gramser]

Ik weet het ook niet - misschien kun je eea loggen en aan @gast777 voorleggen zodat hij misschien kan zien wat er misgaat?

[ppaulv]

dat is een van de moeilijkheden. Ik heb in NR gezocht naar logging om te kunnen zien of de berichten vanuit Gielz daar wel aankomen en of de berichting van NR wel succesvol naar de batterijen gestuurd worden. Maar kan niet vinden waar dat zou moeten staan en waar ik moet kijken (volgens AI) staat niets.