Zendure producten in Home Assistant integreren deel 2

[YvonneVP]

Hippe Lip schreef op zondag 10 mei 2026 @ 08:43:
[...]

Dat verschil moet je me even uitleggen…

Ik ga daar niet nog een keer over verder. Ik denk dat dit nu al voldoende bediscussieert is in eerdere berichten.

[YvonneVP]

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

Dan kijk ik er overheen…
Hierboven staan alleen eigen dashboards.

[Afbeelding]

Dan heb je die waarschijnlijk uit gezet in je instellingen onder HomeAssistant bij de optie 'Change the order and hide items from the sidebar.' en dat je daar 'history' dus onzichtbaar hebt gemaakt in de sidebar.

[wautah91]

Mistraller schreef op zaterdag 9 mei 2026 @ 01:15:
[...]


[...]

Waar doe je dat?
[...]

In de gielz package (NL versie) regel 1456

YAML:

rest:
  - resource_template: "http://{{ states('input_text.zendure_2400_ac_ip_adres') }}/properties/report"
    scan_interval: 1
    sensor:

[DeadMetal]

@gast777 ik probeer je laatste versie van de Proxy te installeren, maar dat gaat toch niet lekker. Ik heb namelijk niet de 'node-red-dashboard' package niet. En dat wil ik ook niet, want NR raadt die nu zelfs expliciet af in de 'manage palette' en op https://flows.nodered.org/node/node-red-dashboard

No longer maintained - please look at alternatives such as @flowfuse/node-red-dashboard or node-red-contrib-uibuilder

Maar als ik '@flowfuse/node-red-dashboard' installeer en NR herstart, ook dan wil jouw package niet deployen (en hij heeft een reeks configuration entities aangemaakt die ik een voor een er weer uit moet gooien). Wat nu te doen? En kan dit deel wellicht optioneel gemaakt worden als een aparte flow o.i.d?

[ Voor 12% gewijzigd door DeadMetal op 11-05-2026 09:58 ]

[Ben(V)]

Hippe Lip schreef op zondag 10 mei 2026 @ 16:50:
[...]

Ik zie meerdere access points (AP’s) met dezelfde SSID en hetzelfde wachtwoord en waarbij de handover van AP naar AP centraal geregeld wordt als mesh netwerk.

Centrale handover van AP naar AP bestaat niet, roaming wordt door de clients zelf gedaan.
En een SSID met een wachtwoord is gewoon een functie van wifi en heeft niets met mesh te maken
Zoals ik al zei, mesh is niets anders dan een marketing kreet voor wireless backhaul.

En als je ziet dat de Zendure niet naar de dichtstbijzijnde AP verbind dan heb je simpelweg te veel AP's.
Voor een goed wifi netwerk moet je er voor zorgen dat het bereik van je AP's elkaar maar net overlappen, als dat te veel is, hebben de clients moeite om te kiezen en loop je de kans dat ze heen en weer gaan switchen of aan het verkeerde AP blijven plakken en dat geeft hetzelfde effect als die "auto" mode van AP's die van kanaal wisselen.

[ Voor 36% gewijzigd door Ben(V) op 11-05-2026 09:32 ]

[ppaulv]

Ben(V) schreef op maandag 11 mei 2026 @ 09:16:
[...]

Centrale handover van AP naar AP bestaat niet, roaming wordt door de clients zelf gedaan.
En een SSID met een wachtwoord is gewoon een functie van wifi en heeft niets met mesh te maken
Zoals ik al zei, mesh is niets anders dan een marketing kreet voor wireless backhaul.

En als je ziet dat de Zendure niet naar de dichtstbijzijnde AP verbind dan heb je simpelweg te veel AP's.
Voor een goed wifi netwerk moet je er voor zorgen dat het bereik van je AP's elkaar maar net overlappen, als dat te veel is, hebben de clients moeite om te kiezen en loop je de kans dat ze heen en weer gaan switchen of aan het verkeerde AP blijven plakken en dat geeft hetzelfde effect als die "auto" mode van AP's die van kanaal wisselen.

@Hippe Lip met het gevaar dat ik me op glad ijs beweeg .... in mijn router (die alle netwerkverkeer regelt) kan ik per gebruiker/client aangeven of ik 'm wil vastpinnen op één specifieke AP of het hem zelf laat uitzoeken. Ook kan ik aangeven of een gebruiker wel/niet/snel/langzaam moet wisselen van 5GHz naar 2.4GHz, en nog wat van die zaken. Maar dat is eigenlijk alleen van belang als de gebruiker en de AP ten opzichte van elkaar gaan bewegen. Neem aan dat beide (AP en Zendure) niet door het huis wandelen dus dat dat niet relevant is.
Maar het vastpinnen op één AP heb ik ook gedaan bij diverse gebruikers om te voorkomen dat bij een hickup of herstart van de gebruikte AP de accu switched naar een verderweg gelegen AP (met storingen) en daarna niet meer vanzelf terug-switcht. Ik heb 4 AP's in huis en heb daar best wat issues mee gehad (maar nu niet meer)

[Ben(V)]

Vast pinnen op een AP kan bij de meeste merken helemaal niet en werkt voor mobiele client (niet zendure dus) dus contra productief.

Zorg gewoon voor een goed wifi netwerk met voldoende maar niet te veel AP's.

PS
Vier AP's is voor een normaal huis te veel, waardoor je terug met vallen op dit soort trucs.

[ppaulv]

Ben(V) schreef op maandag 11 mei 2026 @ 10:49:
Vast pinnen op een AP kan bij de meeste merken helemaal niet en werkt voor mobiele client (niet zendure dus) dus contra productief.

Zorg gewoon voor een goed wifi netwerk met voldoende maar niet te veel AP's.

PS
Vier AP's is voor een normaal huis te veel, waardoor je terug met vallen op dit soort trucs.

Klopt, mijn huis is van dikke beton en dikke muren gemaakt, eerst dacht ik aan 2 genoeg te hebben maar helaas, teveel apparaten verloren constant hun verbinding.

[koboy]

Hippe Lip schreef op zondag 10 mei 2026 @ 16:52:
[...]

@TBird484
Hoe doe ik dat? Die functie ken ik nog niet.

Ik heb even wat voor je lopen zoeken, maar het blijkt dat veel mesh oplossingen geen mogelijkheidheid hebben om een apparaat op een specifiek AP vast te pinnen. Fritzbox lijkt daar 1 van te zijn.

Beetje smerige hack, maar je zou een los AP vlak bij de Zendure's kunnen opstellen met een eigen SSID naam, specifiek voor de Zendure's. Omdat een AP hoort te werken op (wireless) ethernet niveau hoef je buiten het SSID in de Zendure's niets meer aan te passen. Afgezien van de configuratie van het AP natuurlijk.

[Tortelli]

Als ik de Gielz integratie (en de proxy) wil updaten moet ik feitelijk gewoon alle bestanden overschrijven toch?

[gast777]

DeadMetal schreef op maandag 11 mei 2026 @ 08:56:
@gast777 ik probeer je laatste versie van de Proxy te installeren, maar dat gaat toch niet lekker. Ik heb namelijk niet de 'node-red-dashboard' package niet. En dat wil ik ook niet, want NR raadt die nu zelfs expliciet af in de 'manage palette' en op https://flows.nodered.org/node/node-red-dashboard

[...]

Maar als ik '@flowfuse/node-red-dashboard' installeer en NR herstart, ook dan wil jouw package niet deployen (en hij heeft een reeks configuration entities aangemaakt die ik een voor een er weer uit moet gooien). Wat nu te doen? En kan dit deel wellicht optioneel gemaakt worden als een aparte flow o.i.d?

Flowfuse is de "Dashboard 2". Wat ik heb gebruikt in de flow is de "Dashboard" nodes die bij gebruik van HomeAssistant al standaard geinstalleerd zijn in Node-RED.

Ik kan die nodes gemakkelijk vervangen door Dashboard 2 nodes (ze zijn grotendeels identiek), maar dan moet dus iedereen die installeren.

Aangezien Dashboard (1) officieel deprecated is, zal ik hem binnenkort denk ik toch overzetten op Dashboard 2 nodes. Voordeel is ook dat Dashboard 2 van Flowfuse weer meer mogelijkheden heeft.

[gast777]

Als je het dashboard per se niet wil installeren, dan kun je alle dashboard nodes deleten, dan zal de flow gewoon deployen. Die nodes plus andere die alleen voor het dashboard gebruikt worden zitten hier binnen de rode markeringen. Die kun je gerust verwijderen als je zou willen. De rest is hier niet van afhankelijk.

[gast777]

Tortelli schreef op maandag 11 mei 2026 @ 12:10:
Als ik de Gielz integratie (en de proxy) wil updaten moet ik feitelijk gewoon alle bestanden overschrijven toch?

Klopt. Zelfde als nieuwe installatie.

[Ben(V)]

koboy schreef op maandag 11 mei 2026 @ 12:09:
[...]

Ik heb even wat voor je lopen zoeken, maar het blijkt dat veel mesh oplossingen geen mogelijkheidheid hebben om een apparaat op een specifiek AP vast te pinnen. Fritzbox lijkt daar 1 van te zijn.

Beetje smerige hack, maar je zou een los AP vlak bij de Zendure's kunnen opstellen met een eigen SSID naam, specifiek voor de Zendure's. Omdat een AP hoort te werken op (wireless) ethernet niveau hoef je buiten het SSID in de Zendure's niets meer aan te passen. Afgezien van de configuratie van het AP natuurlijk.

Helemaal geen smerige hack, maar een prima oplossing als je AP's dat ondersteunen.
Als die dingen als mesh geconfigureerd zijn willen ze echter meestal alle SSID's delen over alle AP's.

Maar aangezien @Hippe Lip z'n AP's bedraad heeft aangesloten kan hij de boel gewoon in AP mode zetten in plaats van Mesh mode, is hij meteen die mesh overhead op z'n wifi kwijt.

[gast777]

En kan dit deel wellicht optioneel gemaakt worden als een aparte flow o.i.d?

Ik zal ook overwegen om de dashboard gerelateerde nodes in een aparte flow te zetten.

Het is vooral voor het debuggen en wegschrijven van de data voor offline analyse. Als dat nodig is kan ik altijd nog aan de gebruiker vragen om die extra flow te installeren.

[Maarten60]

Tortelli schreef op maandag 11 mei 2026 @ 12:10:
Als ik de Gielz integratie (en de proxy) wil updaten moet ik feitelijk gewoon alle bestanden overschrijven toch?

Even zoeken geeft dit resultaat https://gathering.tweaker...message/85230710#85230710

[Michaf]

Verkeerd topic 😬

[ Voor 93% gewijzigd door Michaf op 11-05-2026 14:31 ]

[YvonneVP]

Ben(V) schreef op maandag 11 mei 2026 @ 10:49:
Vast pinnen op een AP kan bij de meeste merken helemaal niet en werkt voor mobiele client (niet zendure dus) dus contra productief.

Zorg gewoon voor een goed wifi netwerk met voldoende maar niet te veel AP's.

PS
Vier AP's is voor een normaal huis te veel, waardoor je terug met vallen op dit soort trucs.

Dat is dus waarom ik oude coax kabels eruit heb gehaald en daar een router per etage heb neergezet. Elke etage heeft dus zijn eigen Wifi, en dat levert geen problemen op, althans, hier bij mij niet.

[remcoXP]

de update van mijn android app had hem in HEMS gezet , opgelost

ik probeer mijn batterij nu op te laden maar hij gaat maar heel even op een gekozen stand en dan weer snel naar standby. Zie ik iets over het hoofd.
heb ook met het limiet aan/uit gespeeld. en ik draai de laatste versie.

[ Voor 4% gewijzigd door remcoXP op 11-05-2026 18:52 ]

[Tortelli]

gast777 schreef op maandag 11 mei 2026 @ 13:21:
[...]

Klopt. Zelfde als nieuwe installatie.

Gielz lukte me eenvoudig, alleen hoe krijg ik jou rednode flow geupdate?

edit:
lijkt erop dat een nieuwe importeren de mogelijkheid geeft de oude te verwijderen.

Kom toch niet verder:

Volgens mij heb ik alles geupdate maar toch werkt er het eea niet lekker.
Gebruik de P1 meter van Home Assistant zelf (gekoppeld via USB aan mijn Proxmox NUC).

[ Voor 60% gewijzigd door Tortelli op 11-05-2026 22:11 ]

[Nico322]

Hallo allemaal.

Ik heb een probleem met het integreren van mijn Zendure P1 meter. Hij wil deze niet herkennen.

Ik kan echter wel de waarde van P1 zendure api ontvangen.

Kan iemand mij hierbij verder helpen?

[ Voor 43% gewijzigd door Nico322 op 11-05-2026 23:31 ]

[ctrl-tab]

Nico322 schreef op maandag 11 mei 2026 @ 22:10:
Hallo allemaal.

Ik heb een probleem met het integreren van mijn Zendure P1 meter. Hij wil deze niet herkennen.

[Afbeelding]

Ik kan echter wel de waarde van P1 zendure api ontvangen.

Kan iemand mij hierbij verder helpen?

automation al geupdate?

[Nico322]

ctrl-tab schreef op maandag 11 mei 2026 @ 22:11:
[...]

automation al geupdate?

Ja, ik heb de laatste versie

[gielz]

Nico322 schreef op maandag 11 mei 2026 @ 22:10:
Hallo allemaal.

Ik heb een probleem met het integreren van mijn Zendure P1 meter. Hij wil deze niet herkennen.

[Afbeelding]

Ik kan echter wel de waarde van P1 zendure api ontvangen.

Kan iemand mij hierbij verder helpen?

Je moet voor een afwijkende P1 sensor een entiteit invullen en geen IP-adres. Voeg even de onderstaande code toe aan bijvoorbeeld je configuration.yaml met het juiste IP. Vervolgens is de afwijkende P1 sensor; sensor.p1_zendure_api

code:

rest:
  - resource: http://<IP-ZENDURE-P1>/properties/report
    scan_interval: 1
    sensor:
      - name: "P1 Zendure API"
        value_template: "{{ value_json.total_power | float }}"
        unique_id: P1_Zendure_API
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

Vervolgens je automatisering nog toevoegen/aanzetten of alleen uitlezen en HEMS gebruiken.

[Nico322]

gielz schreef op maandag 11 mei 2026 @ 22:14:
[...]

Je moet voor een afwijkende P1 sensor een entiteit invullen en geen IP-adres. Voeg even de onderstaande code toe aan bijvoorbeeld je configuration.yaml met het juiste IP. Vervolgens is de afwijkende P1 sensor; sensor.p1_zendure_api

code:

rest:
  - resource: http://<IP-ZENDURE-P1>/properties/report
    scan_interval: 1
    sensor:
      - name: "P1 Zendure API"
        value_template: "{{ value_json.total_power | float }}"
        unique_id: P1_Zendure_API
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

Vervolgens je automatisering nog toevoegen/aanzetten of alleen uitlezen en HEMS gebruiken.

Ik zie de P1-waarde nu verschijnen, maar heb nog steeds een rood kruis en kan ook NOM niet activeren. Ik heb HEMS uitgeschakeld in de app, maar in de instellingen is er nu eentje voor de netaansluiting (netinvoermodus of netuitvoermodus). Als ik daar een wattage invul, voert hij dit uit. Zeer vreemd.

[ctrl-tab]

Nico322 schreef op maandag 11 mei 2026 @ 22:14:
[...]

Ja, ik heb de laatste versie

ok ik had het rode kruis ook na de update naar de laatste versie, maar had de automation nog niet bijgewerkt naar de laatste versie. Daarna werkte het.

[Nico322]

ctrl-tab schreef op maandag 11 mei 2026 @ 22:39:
[...]

ok ik had het rode kruis ook na de update naar de laatste versie, maar had de automation nog niet bijgewerkt naar de laatste versie. Daarna werkte het.

Ik heb nu juist de automatisatie verwijderd en terug toegevoegd en alles werkt nu.

Bedankt voor alle hulp!

[hemertje]

DAO + Zendure SolarFlow 2400 AC+ — bang-bang NoM controller — feedback gevraagd

Hoi allemaal,

Ik gebruik DAO (Day Ahead Optimizer van corneel27) in combinatie met 3× Zendure SolarFlow 2400 AC+ en wilde graag delen wat ik gebouwd heb — en jullie feedback vragen.

Waarom DAO naast @gielz + @gast777 ?

Gielz + gast777 is een uitstekende uitvoerlaag. Je kunt prijssturing ook handmatig instellen met tijdschema's, maar DAO haalt dagelijks automatisch de Nordpool day-ahead prijzen op en herberekent elk kwartier het optimum — zonder handmatig onderhoud.

DAO voegt toe:

• [] Automatische dagelijkse heroptimalisatie op actuele prijzen [] Negatieve prijzen → PV curtailment automatisch [] Warmtepomp en boiler meenemen in de optimalisatie [] ML baseload forecast op basis van eigen historische data

Het probleem dat ik tegenkwam

Zendure heeft — in tegenstelling tot Victron of GoodWe — geen ingebouwde zero-export logica. Zodra DAO de batterij in "balance mode" zet voor nul op de meter, stopt het schrijven van setpoints. Resultaat: ongecontroleerde import/export.

De oplossing: bang-bang NoM controller

Een HA package die:

• [] Elke 6 seconden de P1 meter uitleest [] Bij te veel import (>80W): na 10s hysterese → ontladen [] Bij te veel export (>200W): na 10s hysterese → laden [] SoC-aware power limits (3000W → 60W afhankelijk van SoC) [] EV-guard: pauzeert tijdens EV laden [] Dagelijkse health check (20:00) die stille storingen detecteert

Werkt via het @KC27 dubbele-helper pattern: DAO schrijft naar helper 1, bang-bang schrijft naar helper 2, Gielz pikt helper 2 op. DAO en de NoM-controller werken zo nooit tegen elkaar.

ROI monitoring

Om de werkelijke waarde van de setup te meten gebruik ik 4 template sensoren die het batterijvermogen opsplitsen in:

• [] Laden van zonnepanelen vs laden van grid [] Ontladen voor eigen verbruik vs ontladen naar net

Gecombineerd met Dynamic Energy Cost (HACS) + Tibber prijssensor geeft dit dagelijks inzicht in de netto ROI per categorie.

Openstaande uitdaging — PV forecast

Wat ik merk: overdag gaat PV-overschot naar het net terwijl de accu leeg blijft, terwijl avondprijzen hoog zijn. De oorzaak lijkt de DAO PV-forecast te zijn — als die de zonnepiek onderschat, plant DAO de accu niet voor laden tijdens die uren. Herkennen Zendure gebruikers dit? Ervaringen met Forecast.Solar als externe bron?

Status: Fase 4 STABIEL — draait sinds begin mei zonder problemen. Legacy PID controller geprobeerd maar verwijderd, bang-bang is simpeler en stabieler gebleken.

GitHub: https://github.com/hemertje/home-assistant-dao-zendure-nom-controller Inclusief DAO_options_TEMPLATE.json als startpunt voor de DAO configuratie.

Vragen aan jullie:

• [] Gebruiken er meer DAO? [] Herkennen jullie het balance-mode probleem met Zendure? [] Verbeterpunten in de hysterese-logica of thresholds? [] PV-forecast accuraatheid — hoe lossen jullie dit op? [] Gebruikt iemand Forecast.Solar als vergelijking of vervanging?

Alle feedback is welkom!

[DeadMetal]

hemertje schreef op maandag 11 mei 2026 @ 22:58:
DAO + Zendure SolarFlow 2400 AC+ — bang-bang NoM controller — feedback gevraagd

Vragen aan jullie:

• [] Gebruiken er meer DAO?
  [] Herkennen jullie het balance-mode probleem met Zendure?
  [] Verbeterpunten in de hysterese-logica of thresholds?
  [] PV-forecast accuraatheid — hoe lossen jullie dit op?
  [] Gebruikt iemand Forecast.Solar als vergelijking of vervanging?

Alle feedback is welkom!

Ik gebruik de gielz+gast777, en wil nog gaan kijken naar DAO. Daar ben ik helaas nog niet bekend mee.
Maar mijn eerste feedback is eigenlijk dat ik jouw bericht (en dus oplossing) niet begrijp door de vele Engelse termen/jargon. 'Setpoints', 'zero-export logica, 'bang-bang', 'legacy PID controller'.

[wmc]

hemertje schreef op maandag 11 mei 2026 @ 22:58:
DAO + Zendure SolarFlow 2400 AC+ — bang-bang NoM controller — feedback gevraagd


Het probleem dat ik tegenkwam

Zendure heeft — in tegenstelling tot Victron of GoodWe — geen ingebouwde zero-export logica. Zodra DAO de batterij in "balance mode" zet voor nul op de meter, stopt het schrijven van setpoints. Resultaat: ongecontroleerde import/export.

Dit is gewoon niet waar, als de Fireson integratie op smart matching staat en je P1 meter juist is staat gekoppeld probeert de integratie NOM te houden. Een voorbeeld van mijn setup, waarbij smart matching aan staat tussen 630u en 730u. Je ziet alsnog pieken (koffie machine, waterkoker), maar het wordt zo goed als mogelijk op nul gehouden.

[Tortelli]

Blijf een probleem houden na de update, HA reboot en volgens mij heb ik alle bestanden (automatisering, dashboard en het script in de automation map) geupdate.

Toch krijg ik een melding alsof ik niet de laatste versie draai en een kruis. Systeem functioneert overigens wel gewoon. Alleen ziet hij een paar accu's niet.



Iemand enig idee wat ik verkeerd gedaan heb?

[ctrl-tab]

Tortelli schreef op dinsdag 12 mei 2026 @ 09:10:
Blijf een probleem houden na de update, HA reboot en volgens mij heb ik alle bestanden (automatisering, dashboard en het script in de automation map) geupdate.

Toch krijg ik een melding alsof ik niet de laatste versie draai en een kruis. Systeem functioneert overigens wel gewoon. Alleen ziet hij een paar accu's niet.

[Afbeelding]

Iemand enig idee wat ik verkeerd gedaan heb?

heb je de automation ge-update?

[gielz]

Tortelli schreef op dinsdag 12 mei 2026 @ 09:10:
Blijf een probleem houden na de update, HA reboot en volgens mij heb ik alle bestanden (automatisering, dashboard en het script in de automation map) geupdate.

Toch krijg ik een melding alsof ik niet de laatste versie draai en een kruis. Systeem functioneert overigens wel gewoon. Alleen ziet hij een paar accu's niet.

[Afbeelding]

Iemand enig idee wat ik verkeerd gedaan heb?

De package draait op de oude versie, je mist de nieuwe entiteiten en het versienummer is nog verkeerd.

[Tortelli]

gielz schreef op dinsdag 12 mei 2026 @ 09:18:
[...]


De package draait op de oude versie, je mist de nieuwe entiteiten en het versienummer is nog verkeerd.

Maar wat moet ik dan nog updaten?
zendure_gielz1986_nl.yaml heb ik volgens mij vervangen (via de fileeditor).

[gielz]

Tortelli schreef op dinsdag 12 mei 2026 @ 09:46:
[...]

Maar wat moet ik dan nog updaten?
zendure_gielz1986_nl.yaml heb ik volgens mij vervangen (via de fileeditor).

Herstart van ha gedaan? Want je ziet dat je bijvoorbeeld entiteiten mist voor je laadpercentage op je dashboard. En die zijn nieuw. En de configuratie versie zit ook in die yaml als je daar op zoekt.

[Isdatzo]

hemertje schreef op maandag 11 mei 2026 @ 22:58:


Zendure heeft — in tegenstelling tot Victron of GoodWe — geen ingebouwde zero-export logica. Zodra DAO de batterij in "balance mode" zet voor nul op de meter, stopt het schrijven van setpoints. Resultaat: ongecontroleerde import/export.

Dit klopt niet: Zendure heeft een prima "balance mode". Ik gebruik de Fireson-integratie en daar kan je in de Zendure Manager (select.zendure_manager_operation) kiezen voor:
- Smart Matching ('nul op de meter')
- Smart Discharge only (consumptie afdekken en overschot zonnestroom terugleveren)
- Smart Charge only (teruglevering voorkomen)

Dit werkt uitstekend samen met DAO: je maakt een input boolean aan die je door DAO laat aansturen, en vervolgens koppel je daar een automation aan die de Zendure Manager aanstuurt.

Openstaande uitdaging — PV forecast

Wat ik merk: overdag gaat PV-overschot naar het net terwijl de accu leeg blijft, terwijl avondprijzen hoog zijn. De oorzaak lijkt de DAO PV-forecast te zijn — als die de zonnepiek onderschat, plant DAO de accu niet voor laden tijdens die uren. Herkennen Zendure gebruikers dit? Ervaringen met Forecast.Solar als externe bron?

DAO heeft de mogelijkheid om een model te trainen op basis van je PV-productie en de gemeten straling (KNMI). Zie: https://github.com/cornee...ratie#ml-modellen-trainen . Overigens draai ik ook Forecast.Solar en de DAO-voorspellingen zijn doorgaans een heel stuk beter. Niet zo gek: dat model is getraind op mijn historische PV-opwek in plaats van een inschatting alleen op basis van verwachte straling en oriëntatie van de panelen.

Volgens mij ben je nu allemaal oplossingen aan het verzinnen voor niet-bestaande problemen. Ik zou zeggen: probeer eerst eens goed te begrijpen wat DAO wel en niet doet, en hoe je e.e.a. fatsoenlijk configureert. Lees een tijdje mee in het DAO-topic en stel daar je vragen nadat je de documentatie doorgenomen hebt, dan komt het allemaal goed.

[ Voor 3% gewijzigd door Isdatzo op 12-05-2026 10:32 ]

[Tortelli]

@gielz nog een keer erin gezet, lijkt dit keer wel te hebben geholpen. Probleem is opgelost volgens mij.

Lijkt wel alsof de file editor het gewoon niet goed opgeslagen heeft want ik weet 100% zeker dat ik hem er gisteravond gewoon vervangen heb.

[MikeyMan]

Op basis van de code van @ctrl-tab en een beetje hulp van Claude de volgende yaml in elkaar geknutseld voor de standaard (fireson) integratie...

code:

template:
  - sensor:
      - name: "Zendure Meterkast Boven Weerstand"
        unique_id: zendure_meterkast_boven_resistance
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:omega
        state: >
          {% set i_total = (
            states('sensor.ab3000_03689_batcur') | float(0) +
            states('sensor.ab3000_15312_batcur') | float(0) +
            states('sensor.ab3000_03694_batcur') | float(0)
          ) | abs %}
          {% if i_total > 2.0 %}
            {% set v_pack = states('sensor.ab3000_03689_total_vol') | float(0) %}
            {% set v_bus  = states('sensor.solarflow_2400_ac_meterkast_bat_volt') | float(0) %}
            {{ [((v_pack - v_bus) | abs / i_total * 1000), 0] | max | round(1) }}
          {% else %}
            unavailable
          {% endif %}

      - name: "Zendure Meterkast Midden Weerstand"
        unique_id: zendure_meterkast_midden_resistance
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:omega
        state: >
          {% set i_total = (
            states('sensor.ab3000_03689_batcur') | float(0) +
            states('sensor.ab3000_15312_batcur') | float(0) +
            states('sensor.ab3000_03694_batcur') | float(0)
          ) | abs %}
          {% if i_total > 2.0 %}
            {% set v_pack = states('sensor.ab3000_15312_total_vol') | float(0) %}
            {% set v_bus  = states('sensor.solarflow_2400_ac_meterkast_bat_volt') | float(0) %}
            {{ [((v_pack - v_bus) | abs / i_total * 1000), 0] | max | round(1) }}
          {% else %}
            unavailable
          {% endif %}

      - name: "Zendure Meterkast Onder Weerstand"
        unique_id: zendure_meterkast_onder_resistance
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:omega
        state: >
          {% set i_total = (
            states('sensor.ab3000_03689_batcur') | float(0) +
            states('sensor.ab3000_15312_batcur') | float(0) +
            states('sensor.ab3000_03694_batcur') | float(0)
          ) | abs %}
          {% if i_total > 2.0 %}
            {% set v_pack = states('sensor.ab3000_03694_total_vol') | float(0) %}
            {% set v_bus  = states('sensor.solarflow_2400_ac_meterkast_bat_volt') | float(0) %}
            {{ [((v_pack - v_bus) | abs / i_total * 1000), 0] | max | round(1) }}
          {% else %}
            unavailable
          {% endif %}

      - name: "Zendure Schuur Boven Weerstand"
        unique_id: zendure_schuur_boven_resistance
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:omega
        state: >
          {% set i_total = (
            states('sensor.ab3000_03697_batcur') | float(0) +
            states('sensor.ab3000_03690_batcur') | float(0)
          ) | abs %}
          {% if i_total > 2.0 %}
            {% set v_pack = states('sensor.ab3000_03697_total_vol') | float(0) %}
            {% set v_bus  = states('sensor.solarflow_2400_ac_schuur_bat_volt') | float(0) %}
            {{ [((v_pack - v_bus) | abs / i_total * 1000), 0] | max | round(1) }}
          {% else %}
            unavailable
          {% endif %}

      - name: "Zendure Schuur Onder Weerstand"
        unique_id: zendure_schuur_onder_resistance
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:omega
        state: >
          {% set i_total = (
            states('sensor.ab3000_03697_batcur') | float(0) +
            states('sensor.ab3000_03690_batcur') | float(0)
          ) | abs %}
          {% if i_total > 2.0 %}
            {% set v_pack = states('sensor.ab3000_03690_total_vol') | float(0) %}
            {% set v_bus  = states('sensor.solarflow_2400_ac_schuur_bat_volt') | float(0) %}
            {{ [((v_pack - v_bus) | abs / i_total * 1000), 0] | max | round(1) }}
          {% else %}
            unavailable
          {% endif %}

      - name: "Zendure Meterkast Boven Weerstand Afwijking"
        unique_id: zendure_meterkast_boven_resistance_dev
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:alert-circle-outline
        state: >
          {% set r1 = states('sensor.zendure_meterkast_boven_weerstand') | float(none) %}
          {% set r2 = states('sensor.zendure_meterkast_midden_weerstand') | float(none) %}
          {% set r3 = states('sensor.zendure_meterkast_onder_weerstand') | float(none) %}
          {% if r1 is not none and r2 is not none and r3 is not none %}
            {% set avg = (r1 + r2 + r3) / 3 %}
            {{ (r1 - avg) | round(1) }}
          {% else %}
            unavailable
          {% endif %}

      - name: "Zendure Meterkast Midden Weerstand Afwijking"
        unique_id: zendure_meterkast_midden_resistance_dev
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:alert-circle-outline
        state: >
          {% set r1 = states('sensor.zendure_meterkast_boven_weerstand') | float(none) %}
          {% set r2 = states('sensor.zendure_meterkast_midden_weerstand') | float(none) %}
          {% set r3 = states('sensor.zendure_meterkast_onder_weerstand') | float(none) %}
          {% if r1 is not none and r2 is not none and r3 is not none %}
            {% set avg = (r1 + r2 + r3) / 3 %}
            {{ (r2 - avg) | round(1) }}
          {% else %}
            unavailable
          {% endif %}

      - name: "Zendure Meterkast Onder Weerstand Afwijking"
        unique_id: zendure_meterkast_onder_resistance_dev
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:alert-circle-outline
        state: >
          {% set r1 = states('sensor.zendure_meterkast_boven_weerstand') | float(none) %}
          {% set r2 = states('sensor.zendure_meterkast_midden_weerstand') | float(none) %}
          {% set r3 = states('sensor.zendure_meterkast_onder_weerstand') | float(none) %}
          {% if r1 is not none and r2 is not none and r3 is not none %}
            {% set avg = (r1 + r2 + r3) / 3 %}
            {{ (r3 - avg) | round(1) }}
          {% else %}
            unavailable
          {% endif %}

      - name: "Zendure Schuur Boven Weerstand Afwijking"
        unique_id: zendure_schuur_boven_resistance_dev
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:alert-circle-outline
        state: >
          {% set r1 = states('sensor.zendure_schuur_boven_weerstand') | float(none) %}
          {% set r2 = states('sensor.zendure_schuur_onder_weerstand') | float(none) %}
          {% if r1 is not none and r2 is not none %}
            {% set avg = (r1 + r2) / 2 %}
            {{ (r1 - avg) | round(1) }}
          {% else %}
            unavailable
          {% endif %}

      - name: "Zendure Schuur Onder Weerstand Afwijking"
        unique_id: zendure_schuur_onder_resistance_dev
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:alert-circle-outline
        state: >
          {% set r1 = states('sensor.zendure_schuur_boven_weerstand') | float(none) %}
          {% set r2 = states('sensor.zendure_schuur_onder_weerstand') | float(none) %}
          {% if r1 is not none and r2 is not none %}
            {% set avg = (r1 + r2) / 2 %}
            {{ (r2 - avg) | round(1) }}
          {% else %}
            unavailable
          {% endif %}

      - name: "Zendure Meterkast Connector Waarschuwing"
        unique_id: zendure_meterkast_connector_warning
        icon: mdi:fire-alert
        state: >
          {% set threshold_dev = 15 %}
          {% set threshold_temp = 45 %}
          {% set devs = [
            states('sensor.zendure_meterkast_boven_weerstand_afwijking') | float(0),
            states('sensor.zendure_meterkast_midden_weerstand_afwijking') | float(0),
            states('sensor.zendure_meterkast_onder_weerstand_afwijking') | float(0)
          ] %}
          {% set temps = [
            states('sensor.ab3000_03689_max_temp') | float(0),
            states('sensor.ab3000_15312_max_temp') | float(0),
            states('sensor.ab3000_03694_max_temp') | float(0)
          ] %}
          {% set worst_dev = devs | max %}
          {% set worst_temp = temps | max %}
          {% if worst_dev > threshold_dev and worst_temp > threshold_temp %}
            KRITIEK
          {% elif worst_dev > threshold_dev %}
            WAARSCHUWING
          {% else %}
            OK
          {% endif %}

      - name: "Zendure Schuur Connector Waarschuwing"
        unique_id: zendure_schuur_connector_warning
        icon: mdi:fire-alert
        state: >
          {% set threshold_dev = 15 %}
          {% set threshold_temp = 45 %}
          {% set devs = [
            states('sensor.zendure_schuur_boven_weerstand_afwijking') | float(0),
            states('sensor.zendure_schuur_onder_weerstand_afwijking') | float(0)
          ] %}
          {% set temps = [
            states('sensor.ab3000_03697_max_temp') | float(0),
            states('sensor.ab3000_03690_max_temp') | float(0)
          ] %}
          {% set worst_dev = devs | max %}
          {% set worst_temp = temps | max %}
          {% if worst_dev > threshold_dev and worst_temp > threshold_temp %}
            KRITIEK
          {% elif worst_dev > threshold_dev %}
            WAARSCHUWING
          {% else %}
            OK
          {% endif %}

Zal nog wel wat finetuning nodig hebben...

[ Voor 8% gewijzigd door MikeyMan op 12-05-2026 10:48 ]

[wmc]

Isdatzo schreef op dinsdag 12 mei 2026 @ 10:29:
[...]


Dit klopt niet: Zendure heeft een prima "balance mode". Ik gebruik de Fireson-integratie en daar kan je in de Zendure Manager (select.zendure_manager_operation) kiezen voor:
- Smart Matching ('nul op de meter')
- Smart Discharge only (consumptie afdekken en overschot zonnestroom terugleveren)
- Smart Charge only (teruglevering voorkomen)

Dit werkt uitstekend samen met DAO: je maakt een input boolean aan die je door DAO laat aansturen, en vervolgens koppel je daar een automation aan die de Zendure Manager aanstuurt.


[...]


DAO heeft de mogelijkheid om een model te trainen op basis van je PV-productie en de gemeten straling (KNMI). Zie: https://github.com/cornee...ratie#ml-modellen-trainen . Overigens draai ik ook Forecast.Solar en de DAO-voorspellingen zijn doorgaans een heel stuk beter. Niet zo gek: dat model is getraind op mijn historische PV-opwek in plaats van een inschatting alleen op basis van verwachte straling en oriëntatie van de panelen.

Volgens mij ben je nu allemaal oplossingen aan het verzinnen voor niet-bestaande problemen. Ik zou zeggen: probeer eerst eens goed te begrijpen wat DAO wel en niet doet, en hoe je e.e.a. fatsoenlijk configureert. Lees een tijdje mee in het DAO-topic en stel daar je vragen nadat je de documentatie doorgenomen hebt, dan komt het allemaal goed.

Mijn automation om de Zendure integratie aan te sturen heb ik al eens gedeeld in het DAO topic. Dit werkt inderdaad prima.

[gast777]

DeadMetal schreef op maandag 11 mei 2026 @ 08:56:
@gast777 ik probeer je laatste versie van de Proxy te installeren, maar dat gaat toch niet lekker. Ik heb namelijk niet de 'node-red-dashboard' package niet. En dat wil ik ook niet, want NR raadt die nu zelfs expliciet af in de 'manage palette' en op https://flows.nodered.org/node/node-red-dashboard

In de nieuwste versie van de Proxy maakt het dashboard gebruik van Flowfuse.

De dashboard in een aparte flow zetten was helaas niet doenbaar. Maar hij gebruikt verwacht ik weinig resources. CPU load gaat niet merkbaar omhoog zolang de live debug niet loopt.

Hiervoor moeten gebruikers nu wel eenmalig Flowfuse installeren middels deze popup die vanzelf verschijnt (of anders via 'Manage palette'):




Ik ben nog van plan om wat documentatie toe te voegen over de debug dashboard. Meestal is het niet nodig, maar je kunt hiermee mooi inzicht krijgen in alle json data die tussen Gielz en de Zendures heen en weer gaan, wat soms nodig is voor debuggen.

Naar file loggen van de data werkt alleen als Node-RED als App bij Home Assistant geïnstalleerd is (of je moet zelf het pad veranderen in de write file node).

[gast777]

NB: het debug dashboard kan eventueel ook in HA in een dashboard gezet worden (dashboard toevoegen, webpagina als dashboard, vul daar de URL in).

[gast777]

Impressie:

[Mscroos]

Vraag: Ik heb drie zendure 2400+ torens met Gielz- en Node-RED-integratie van Gast777. (GEWELDIG!!) Ik monitor nu mijn relays en experimenteer met variabelen om ze te beperken. In dit dashboarditem is het doel voor relays 100. Verwijst dit naar de drie items samen of naar elke toren afzonderlijk? Of zou deze waarde in mijn geval 300 moeten zijn? (Als iemand suggesties heeft over hoe ik het aantal relays switches kan verminderen, zou ik dat zeer waarderen. Ik heb het forum uitgebreid doorzocht, maar niets gevonden; zit nog in een vrij stijle leercurve.)

[ Voor 72% gewijzigd door Mscroos op 12-05-2026 17:20 ]

[Mistraller]

vraagje over de relais schakelingen; ik heb, vergeleken met anderen, heel hoge waardes in mijn HA. Vandaag alweer 1359. Terwijl de 2 zendures gewoon rustig staan te laden (om en om, door de proxy), en ik hoor ook niet veel klikjes. Wat ik wel in HA zie, is dat ie vaak heel even staat te wachten, dan staan alle sensoren even op "niet beschikbaar" om daarna direct weer gevuld te worden.

Ik weet dat mijn HA op oudere hardware draait en de connectie niet optimaal, dus ik denk dat de data verkeerd geïnterpreteerd wordt, want na een "niet beschikbaar" is het aantal schakelingen altijd hoger. (tenzij de batterij op standby staat)
Zou dat kunnen kloppen? Want ik begreep al dat ie geen echte tellingen kan doen mbt schakelingen.

[Pakhaas]

Mistraller schreef op dinsdag 12 mei 2026 @ 17:11:
vraagje over de relais schakelingen; ik heb, vergeleken met anderen, heel hoge waardes in mijn HA. Vandaag alweer 1359. Terwijl de 2 zendures gewoon rustig staan te laden (om en om, door de proxy), en ik hoor ook niet veel klikjes. Wat ik wel in HA zie, is dat ie vaak heel even staat te wachten, dan staan alle sensoren even op "niet beschikbaar" om daarna direct weer gevuld te worden.

Ik weet dat mijn HA op oudere hardware draait en de connectie niet optimaal, dus ik denk dat de data verkeerd geïnterpreteerd wordt, want na een "niet beschikbaar" is het aantal schakelingen altijd hoger. (tenzij de batterij op standby staat)
Zou dat kunnen kloppen? Want ik begreep al dat ie geen echte tellingen kan doen mbt schakelingen.

Kijk eens naar je wifi signaal. Kan je ook zien in HA. Klinkt als dat hij steeds kort de verbinding kwijt is.

[klump4u]

Mistraller schreef op dinsdag 12 mei 2026 @ 17:11:
vraagje over de relais schakelingen; ik heb, vergeleken met anderen, heel hoge waardes in mijn HA. Vandaag alweer 1359. Terwijl de 2 zendures gewoon rustig staan te laden (om en om, door de proxy), en ik hoor ook niet veel klikjes. Wat ik wel in HA zie, is dat ie vaak heel even staat te wachten, dan staan alle sensoren even op "niet beschikbaar" om daarna direct weer gevuld te worden.

Ik weet dat mijn HA op oudere hardware draait en de connectie niet optimaal, dus ik denk dat de data verkeerd geïnterpreteerd wordt, want na een "niet beschikbaar" is het aantal schakelingen altijd hoger. (tenzij de batterij op standby staat)
Zou dat kunnen kloppen? Want ik begreep al dat ie geen echte tellingen kan doen mbt schakelingen.

Daar kun je alleen maar achter komen door geschikte hardware te gebruiken, zorg eerst eens dat dat op orde is en kijk dan nog een keer.

[Aardedraadje]

Mistraller schreef op dinsdag 12 mei 2026 @ 17:11:
vraagje over de relais schakelingen; ik heb, vergeleken met anderen, heel hoge waardes in mijn HA. Vandaag alweer 1359. Terwijl de 2 zendures gewoon rustig staan te laden (om en om, door de proxy), en ik hoor ook niet veel klikjes. Wat ik wel in HA zie, is dat ie vaak heel even staat te wachten, dan staan alle sensoren even op "niet beschikbaar" om daarna direct weer gevuld te worden.

Ik weet dat mijn HA op oudere hardware draait en de connectie niet optimaal, dus ik denk dat de data verkeerd geïnterpreteerd wordt, want na een "niet beschikbaar" is het aantal schakelingen altijd hoger. (tenzij de batterij op standby staat)
Zou dat kunnen kloppen? Want ik begreep al dat ie geen echte tellingen kan doen mbt schakelingen.

@Mistraller in de Home Assistant OS github issues staat een report waarbij sinds 17.2 het systeem erg traag reageert. Ik leg nu pas de link met jouw problemen, namelijk dat je HASS sinds ingebruikname van Gielz' aansturing traag reageert? Is het niet zo dat je toevallig ook onlangs bijgewerkt hebt naar HAOS 17.2 of 17.3?

[Mistraller]

Pakhaas schreef op dinsdag 12 mei 2026 @ 17:26:
[...]

Kijk eens naar je wifi signaal. Kan je ook zien in HA. Klinkt als dat hij steeds kort de verbinding kwijt is.

signaal is perfect zegt ie. Maar daar ligt het niet aan, daar was ik al achter.

klump4u schreef op dinsdag 12 mei 2026 @ 18:15:
[...]

Daar kun je alleen maar achter komen door geschikte hardware te gebruiken, zorg eerst eens dat dat op orde is en kijk dan nog een keer.

Zoals Gielz zelf al zei, zou deze integratie op model aardappel nog moeten draaien.
Dus als er even geen data is, zou de integratie dat niet als een schakelmoment mogen beschouwen. Van een Unknown state naar Known is geen statusovergang.
We hebben daar zakelijk ook vaak mee te maken, als er in de nacht bij op de zaak soms eens een meting mist in Grafana, door backup traffic of whatever, dan wil je niet je bed uit gebeld worden. (Meestal gebruiken we dan "keep last state")

Het is niet dat ik wil dat MIJN cijfers beter worden, maar dat de integratie nóg betrouwbaarder wordt. Ik vermoed namelijk dat ie cijfers presenteert die niet kloppen.

Aardedraadje schreef op dinsdag 12 mei 2026 @ 19:18:
[...]

@Mistraller in de Home Assistant OS github issues staat een report waarbij sinds 17.2 het systeem erg traag reageert. Ik leg nu pas de link met jouw problemen, namelijk dat je HASS sinds ingebruikname van Gielz' aansturing traag reageert? Is het niet zo dat je toevallig ook onlangs bijgewerkt hebt naar HAOS 17.2 of 17.3?

Core
2026.5.1
Supervisor
2026.05.0
Operating System
17.3
Frontend
20260429.3

Ik zat inderdaad op 17.2 toen ik Gielz erop heb gezet. En nu 17.3

Maar met de range extender ertussen, NR op mijn NAS (die is snel zat) is het best acceptabel. Maar desondanks ga ik wel de hardware vervangen waar HA op draait. Vandaag toevallig powerusage nog eens gemeten van die ouwe laptop, en die zit op 15~20W.
Alleen af en toe even alle waardes kort op Niet beschikbaar en dan zie ik ook een kleine gap in de graphs op de Gielz dashboards. Ik ga daarom eens even de interval op 2 seconden zetten, benieuwd wat dit doet. Relais schakelingen waardes viel me toevallig vandaag op, want ik was in de garage en had helemaal geen kliks gehoord en toch liep de waarde op.

[ Voor 36% gewijzigd door Mistraller op 12-05-2026 19:32 ]

[hapklaar]

RemmyB83 schreef op zondag 10 mei 2026 @ 21:55:
[...]

Vandaag was hij hier ook even de weg kwijt.
Accu was leeg maar zodra de hij kon gaan opladen werden de accu's niet actief, en bleef hij alleen de opwek terugleveren van de twee aangesloten panelen. Pas toen ik hem om 11.50 in standby heb gezet en vervolgens op NOM, werd hij wakker en ging hij doen wat hij moest doen.

Ik heb de laatste tijd ook veel last van dat NOM schakeling bij tijd en wijle lijkt niet meer te werken, tot ik de modus even op standby zet en weer terug naar (in mijn geval) Dynamisch NOM. Ik heb voor de volledigheid ook even een issue op github aangemaakt hierover.

[roawser]

Nu het toch over relay switches gaat sluit ik even aan. Ook ik merk een hoog aantal relay switches in de gielz integratie, hoewel geen 1000. Het gielz dashboard zegt dat de wifi signaalsterkte "excellent" is. HA en de integratie zijn uptodate. Ik merk wel op dat HA mijn Zendure bijna met de regelmaat van de klok als 'unavailable' aanmerkt. Hoe kan dat komen? Hier een plaatje van de afgelopen ochtend:

[RemmyB83]

hapklaar schreef op dinsdag 12 mei 2026 @ 19:40:
[...]

Ik heb de laatste tijd ook veel last van dat NOM schakeling bij tijd en wijle lijkt niet meer te werken, tot ik de modus even op standby zet en weer terug naar (in mijn geval) Dynamisch NOM. Ik heb voor de volledigheid ook even een issue op github aangemaakt hierover.

Top, ik hoor er hier verder niemand over dus dacht dat het aan mijn setup lag. Vandaag was hij ook weer de weg kwijt. Rond 13.00 is batterij 1 vol en batterij 2 op 85%. Maar batterij 2 wordt niet meer verder opgeladen ookal was er meer dan genoeg zon.
Gekke is ook dat je tussen 13.00 en 16.00 zowel continue afname als teruglevering ziet. Iets wat eigenlijk niet mogelijk zou kunnen zijn.
Draai nu vanaf 16.00 de fireson integratie, om te zien of ik het daar ook bij heb.

[ Voor 3% gewijzigd door RemmyB83 op 12-05-2026 20:25 ]

[RemmyB83]

.

[ Voor 99% gewijzigd door RemmyB83 op 12-05-2026 20:24 ]

[gielz]

RemmyB83 schreef op dinsdag 12 mei 2026 @ 20:19:
[...]

Top, ik hoor er hier verder niemand over dus dacht dat het aan mijn setup lag. Vandaag was hij ook weer de weg kwijt. Rond 13.00 is batterij 1 vol en batterij 2 op 85%. Maar batterij 2 wordt niet meer verder opgeladen ookal was er meer dan genoeg zon.
Gekke is ook dat je tussen 13.00 en 16.00 zowel continue afname als teruglevering ziet. Iets wat eigenlijk niet mogelijk zou kunnen zijn.
Draai nu vanaf 16.00 de fireson integratie, om te zien of ik het daar ook bij heb.
[Afbeelding]

Heb je dit probleem ook zonder node-red? Tot nu toe weinig tot geen meldingen gehad dat NOM niet werkt met Gielz alleen.

[RemmyB83]

gielz schreef op dinsdag 12 mei 2026 @ 20:31:
[...]


Heb je dit probleem ook zonder node-red? Tot nu toe weinig tot geen meldingen gehad dat NOM niet werkt met Gielz alleen.

Geen idee. Vanaf dag 1 dat ik je integratie gebruik, gebruik ik ook NR voor beide batterijen. Ik denk ook dat het scheve laadpercentage komt doordat batterij 1 zonnepanelen heeft. Nu ik er over nadenk is dat wat je ziet boven de 0 lijn, als batterij 1 vol is. Dat is de opwek van de panelen op batterij 1, maar die wordt dus even niet gecombineerd met de p1 gegevens.

[gielz]

RemmyB83 schreef op dinsdag 12 mei 2026 @ 20:42:
[...]

Geen idee. Vanaf dag 1 dat ik je integratie gebruik, gebruik ik ook NR voor beide batterijen. Ik denk ook dat het scheve laadpercentage komt doordat batterij 1 zonnepanelen heeft. Nu ik er over nadenk is dat wat je ziet boven de 0 lijn, als batterij 1 vol is. Dat is de opwek van de panelen op batterij 1, maar die wordt dus even niet gecombineerd met de p1 gegevens.

Dan loop je nu hier tegen aan wat @gast777 heeft aangegeven "Zonnepanelen direct via DC aangesloten op de Zendures zijn niet getest. Het zou in principe wel moeten werken."

[RemmyB83]

gielz schreef op dinsdag 12 mei 2026 @ 20:45:
[...]


Dan loop je nu hier tegen aan wat @gast777 heeft aangegeven "Zonnepanelen direct via DC aangesloten op de Zendures zijn niet getest. Het zou in principe wel moeten werken."

Oke, dan weten we nu alvast in welke richting we moeten zoeken.
Zijn er nog dingen die ik kan doen om de integratie/proxy te helpen verbeteren?
@gast777

[Pakhaas]

roawser schreef op dinsdag 12 mei 2026 @ 20:15:
Nu het toch over relay switches gaat sluit ik even aan. Ook ik merk een hoog aantal relay switches in de gielz integratie, hoewel geen 1000. Het gielz dashboard zegt dat de wifi signaalsterkte "excellent" is. HA en de integratie zijn uptodate. Ik merk wel op dat HA mijn Zendure bijna met de regelmaat van de klok als 'unavailable' aanmerkt. Hoe kan dat komen? Hier een plaatje van de afgelopen ochtend:

[Afbeelding]

Dit is echt onstabiel wifi. Hij verliest dan kort even de verbinding. Ik heb dat ook maar dat is ongeveer 1x per 12u.

[gast777]

gielz schreef op dinsdag 12 mei 2026 @ 20:45:
[...]


Dan loop je nu hier tegen aan wat @gast777 heeft aangegeven "Zonnepanelen direct via DC aangesloten op de Zendures zijn niet getest. Het zou in principe wel moeten werken."

Volgens mij gebruikt @DrNickB ook Zonnepanelen op de Gielz. Ik weet niet of het met of zonder Proxy is. Misschien heeft hij een idee wat hier gebeurt.

Anders wat ik zou aanbevelen is de laatste versie van de Proxy erop zetten en daarmee via het node-red dashboard2 even een trace te loggen van alle json data tijdens het probleem. Dan weten we in ieder geval wat daar exact gebeurt. Dan zouden we kunnen checken of de Proxy de data van beide Zendures combineert zoals de bedoeling is en zoals Gielz het verwacht aangeleverd te krijgen (dus alsof het 1 Zendure is).

NB: documentatie voor de debug trace feature zal ik nog zsm maken en online zetten (het wijst zich grotendeels vanzelf, maar je moet even weten waar je het kunt vinden).

[ Voor 11% gewijzigd door gast777 op 12-05-2026 21:50 ]

[c0mplex1]

roawser schreef op dinsdag 12 mei 2026 @ 20:15:
Nu het toch over relay switches gaat sluit ik even aan. Ook ik merk een hoog aantal relay switches in de gielz integratie, hoewel geen 1000. Het gielz dashboard zegt dat de wifi signaalsterkte "excellent" is. HA en de integratie zijn uptodate. Ik merk wel op dat HA mijn Zendure bijna met de regelmaat van de klok als 'unavailable' aanmerkt. Hoe kan dat komen? Hier een plaatje van de afgelopen ochtend:

[Afbeelding]

Kijk eens in de log van je router/AP of je om de 8 minuten (om en nabij) een reconnect van de WiFi verbinding met de Zendure ziet?

Geen poorten of IP-adressen geblokkeerd? De Zendure kan zonder problemen verbinding met het internet maken?

[ Voor 6% gewijzigd door c0mplex1 op 12-05-2026 21:37 ]

[RemmyB83]

gast777 schreef op dinsdag 12 mei 2026 @ 21:21:
[...]

Volgens mij gebruikt @DrNickB ook Zonnepanelen op de Gielz. Ik weet niet of het met of zonder Proxy is. Misschien heeft hij een idee wat hier gebeurt.

Anders wat ik zou aanbevelen is de laatste versie van de Proxy erop zetten en daarmee via het node-red dashboard2 even een trace te loggen van alle json data tijdens het probleem. Dan weten we in ieder geval wat daar exact gebeurt. Dan zouden we kunnen checken of de Proxy de data van beide Zendures combineert zoals de bedoeling is en zoals Gielz het verwacht aangeleverd te krijgen (dus alsof het 1 Zendure is).

Ik heb mijn proxy zojuist geupdate. Oude versie was 20260430.
Maakt dashboard2 automatisch een log of moet ik iets aanzetten?

[gast777]

RemmyB83 schreef op dinsdag 12 mei 2026 @ 21:59:
[...]

Ik heb mijn proxy zojuist geupdate. Oude versie was 20260430.
Maakt dashboard2 automatisch een log of moet ik iets aanzetten?

Je kunt browsen naar http://<node-red_ip_adres>:1880/endpoint/dashboard/zenproxylivedataget




Dan zet je de debug aan door op "START LIVE DEBUG" te clicken". Zet dan ook schrijven naar file aan door te clicken op "WRITE TO FILE", zodat er "YES" komt te staan.

Wanneer je denkt dat er genoeg data is verzameld, click je op "DOWNLOAD DEBUG FILE" om de file te downloaden.

Dan kun je debug weer uitzetten. Als je dit vergeet, gaat hij na ongeveer een uur vanzelf uit.

[RemmyB83]

gast777 schreef op dinsdag 12 mei 2026 @ 22:08:
[...]

Je kunt browsen naar http://<node-red_ip_adres>:1880/endpoint/dashboard/zenproxylivedataget

[Afbeelding]


Dan zet je de debug aan door op "START LIVE DEBUG" te clicken". Zet dan ook schrijven naar file aan door te clicken op "WRITE TO FILE", zodat er "YES" komt te staan.

Wanneer je denkt dat er genoeg data is verzameld, click je op "DOWNLOAD DEBUG FILE" om de file te downloaden.

Dan kun je debug weer uitzetten. Als je dit vergeet, gaat hij na ongeveer een uur vanzelf uit.

Bedankt! Hij loopt

[gast777]

RemmyB83 schreef op dinsdag 12 mei 2026 @ 22:21:
[...]

Bedankt! Hij loopt

Nu is er geen zon, dus wellicht geen probleem, of wel?

Als ik je goed begrijp is het probleem zoiets: als de batterij van Zendure 1 vol is en de verbonden panelen produceren nog, maar Zendure 2 heeft nog battery% om te laden, dan wordt NOM niet correct meer gevolgd.

[RemmyB83]

gast777 schreef op dinsdag 12 mei 2026 @ 22:29:
[...]

Nu is er geen zon, dus wellicht geen probleem, of wel?

Als ik je goed begrijp is het probleem zoiets: als de batterij van Zendure 1 vol is en de verbonden panelen produceren nog, maar Zendure 2 heeft nog battery% om te laden, dan wordt NOM niet correct meer gevolgd.

Ja idd, en dit gedrag heb heb ik eerder gezien. Maar toen handmatig verder laten laden en zitten zoeken in de instellingen naar export enzo om te zien wat ik fout doe. Maar ook 10 mei was hij hier de kluts kwijt(zie afbeelding), en toen waren de accu's nog leeg. Dus het zijn denk ik niet alleen maar de zonnepanelen die rechtstreeks zijn aangesloten.

[hemertje]

DeadMetal schreef op dinsdag 12 mei 2026 @ 07:55:
[...]

Ik gebruik de gielz+gast777, en wil nog gaan kijken naar DAO. Daar ben ik helaas nog niet bekend mee.
Maar mijn eerste feedback is eigenlijk dat ik jouw bericht (en dus oplossing) niet begrijp door de vele Engelse termen/jargon. 'Setpoints', 'zero-export logica, 'bang-bang', 'legacy PID controller'.

@DeadMetal
Je hebt gelijk — ik realiseer me nu dat ik te veel in jargon ben verzonken.

Setpoint = ingestelde waarde,
bang-bang = aan/uit regeling (geen afstappen ertussen),
zero-export = niet terugleveren aan net.

Mijn fout! Wil je een versie in gewoon Nederlands?

[hemertje]

wmc schreef op dinsdag 12 mei 2026 @ 08:14:
[...]


Dit is gewoon niet waar, als de Fireson integratie op smart matching staat en je P1 meter juist is staat gekoppeld probeert de integratie NOM te houden. Een voorbeeld van mijn setup, waarbij smart matching aan staat tussen 630u en 730u. Je ziet alsnog pieken (koffie machine, waterkoker), maar het wordt zo goed als mogelijk op nul gehouden.


[Afbeelding]

@wmc

Dank voor de correctie — je hebt gelijk.

Mijn probleem was specifiek dat DAO naar mijn idee in "balance mode" stopt met setpoints schrijven, waardoor Fireson geen updates krijgt.

Mijn 'bang-bang' werkt als backup voor dat scenario.

Mooie grafiek! Herken je het schakelen rond 6:45 — werkt jouw setup stabieler met Fireson alleen?

[gast777]

RemmyB83 schreef op dinsdag 12 mei 2026 @ 22:44:
[...]

Ja idd, en dit gedrag heb heb ik eerder gezien. Maar toen handmatig verder laten laden en zitten zoeken in de instellingen naar export enzo om te zien wat ik fout doe. Maar ook 10 mei was hij hier de kluts kwijt(zie afbeelding), en toen waren de accu's nog leeg. Dus het zijn denk ik niet alleen maar de zonnepanelen die rechtstreeks zijn aangesloten.
[Afbeelding]

OK, stuur de data van tijdens het probleem maar even in een DM wanneer je het hebt. Graag ook met duidelijke grafieken en duidelijke tijdstippen wanneer het probleem gebeurt (Geschiedenis in HA met de relevante entiteiten graag, de Gielz dashboard grafiek zegt me vrij weinig).

Aangenomen dat de Gielz met 1 Zendure met aangesloten panelen wel goed werkt, is het in principe de bedoeling dat de proxy 1 (virtuele) Zendure presenteert/emuleert aan Gielz die zich exact zo gedraagt alsof het 1 Zendure was. Dan zou het gewoon moeten werken.

Heb je bypass aanstaan? Wat misschien zou kunnen is dat Zendure 1 aan het leveren is vanwege bypass en de Zendure 2 zou moeten laden. Dan krijg je laden en leveren tegelijk, waar Gielz geen rekening mee had gehouden en wat dan eventueel problemen kan veroorzaken. Maar ik zie graag de data tegemoet. Dan kunnen we zien wat er nou precies gebeurt. Dan kunnen we daar weer een oplossing voor verzinnen.

[hemertje]

@Isdatzo @wmc Dank voor de geduldige correcties.
Laat me eerlijk zijn over waar ik te snel ben gegaan.

Ik dacht dat Zendure geen zero-export had, maar Fireson Smart Matching doet dit dus wel. Ik dacht dat DAO alleen Forecast.Solar gebruikte, maar blijkbaar heeft DAO ML training op eigen data die ik (nog) niet heb geactiveerd? Ik dacht dat ik zelf een "bang-bang" moest bouwen voor balance mode, maar Smart Matching met een automation blijkt de standaard. En ik dacht dat setpoints de enige manier waren, maar mode-switch via input_boolean is dus de juiste weg.

Wat ik nog niet begrijp:

De DAO naar Zendure handover — DAO stopt setpoints in balance mode, maar blijft die input_boolean dan aansturen? Of moet ik iets in DAO configureren dat ik heb gemist?

De Gielz setpoint stroom — ik gebruik nu input_number.dao_set_power_feedin naar Gielz naar Zendure. Is dit verouderd? Moet ik direct via Fireson?

ML training — hoeveel historische data heb je minimaal nodig? En hoe lang duurt het trainen voordat het beter is dan Forecast.Solar?

Pass-through vs eigen berekening — ik heb dao_zendure_target_power gemaakt die tussen DAO en bang-bang schakelt. Is dit overbodig als ik Smart Matching gebruik?

En de hysteresis timers — ik heb 10-seconden timers voor import en export arm. Doet Smart Matching dit al intern, of is dit nog steeds nuttig voor korte pieken?

Kun je me een link geven naar jouw automation post wmc? Dan implementeer ik het correct en laat ik de eigen oplossingen achterwege.

Bedankt voor het terugfluiten — dit bespaart me veel tijd en miskopen.

[Mistraller]

Pakhaas schreef op dinsdag 12 mei 2026 @ 20:58:
[...]

Dit is echt onstabiel wifi. Hij verliest dan kort even de verbinding. Ik heb dat ook maar dat is ongeveer 1x per 12u.

Ik weet het nog altijd niet zeker of het puur wifi is. Wel een connectieprobleem, tot zover helemaal eens, maar toen het echt heel slecht werkte, bij verbinding rechtstreeks op mijn mesh, bleef de zendure app altijd werken, ook als de rest API in de zendure helemaal geen respons meer gaf. En dan kon ik nog gewoon ledje aan schakelen, vermogen regelen, offgrid etc via de app. /properties/report kreeg ik zelf in een browser geen response meer, en uiteraard HA of NR ook niet. Restart van Zendure was dan de oplossing. Kortom ik denk dat de webserver in de Zendure ook niet heel robuust is geconfigureerd. En iets bij mij triggert dit, dat is duidelijk
Ik zal eens kijken of ik het juist door de zendures te isoleren, kan verbeteren. De 2 seconden aanpassing heeft namelijk niet geholpen zag ik. Of nog eens wat meer aanprutsen op mijn Deco. Al weet ik daar niet meer zo goed wat ik daar nog kan veranderen eigenlijk.

[Pakhaas]

@Mistraller met deco had ik ook vaak dat de verbinding paar seconden wegviel. Heb een AP geplaatst bij de batterijen en rechtstreeks met kabel aangesloten met de router. Nu is het stabiel.

[ctrl-tab]

Een mesh lijkt me sowieso geen goed idee met de hoeveelheid api calls die plaats vinden.
Wifi is al discutabel, een mesh is discutabel in het kwadraat (latency>latency>latency)
Tenzij je bedrade access points hebt (en dus technisch geen mesh hebt, ik geloof dat er vendoren zijn je wifi netwerk altijd zo noemen - want hippe naam)

Zelf heb ik tp link omada, bedrade access points vrij ver van de units af , meerdere muren ertussen. Geen enkel issue vooralsnog. Dingen als roaming staan gewoon aan.

[DeadMetal]

ctrl-tab schreef op woensdag 13 mei 2026 @ 08:46:
Tenzij je bedrade access points hebt (en dus technisch geen mesh hebt, ik geloof dat er vendoren zijn je wifi netwerk altijd zo noemen - want hippe naam

offtopic:
M.i. betekent mesh meerdere access points die onderling samenwerken, aangestuurd door een centraal systeem, met naadloze roaming van clients tussen de access points. Hoe de backhaul geregeld is (draadloos of met kabel) is daarvoor niet relevant. Met kabel is doorgaans juist sneller en stabieler.

[Hippe Lip]

YvonneVP schreef op maandag 11 mei 2026 @ 17:12:
[...]

Dat is dus waarom ik oude coax kabels eruit heb gehaald en daar een router per etage heb neergezet. Elke etage heeft dus zijn eigen Wifi, en dat levert geen problemen op, althans, hier bij mij niet.

Dat had ik aanvankelijk ook, maar dan is de overstap van het ene naar het andere AP problematisch. Als je mobieltje bijvoorbeeld nog nét aan een klein, zwak puntje van je WiFi beneden blijjft hangen als je boven bent, dan stapt-ie niet over.
Sinds ik de mesh van Fritz gebruik is dit probleem over. ‘Iets’ zorgt ervoor dat elke gebruiker gebruik maakt van het sterkste AP binnen bereik en dat er niet vastgehouden wordt aan een zwakker AP.

[Mistraller]

@Pakhaas Het gekke is dat een budget repeater, ook van TPlink, aan mijn IoT ssid geen (of in elk geval fors minder) problemen geeft. En juist die repeater is nu wireless.
@ctrl-tab Mijn nodes hebben een wired backhaul. Deco is ook van TPlink

Ik heb gisteren nog wat geprutst, mesh uit, prioritering aangezet, fixed op 1 node, IoT netwerk doet alleen 2,4Ghz, ingesteld op 20Mhz, fixed channel etc etc. Toen de zendures weer in dat netwerk gehangen.
HA had er weer veel moeite mee. Wel viel het me op dat terwijl HA ermee worstelde, dat NR gewoon vlotte response gaf. Kortom, echt heel strak de vinger erachter krijgen lukt me nog niet; maar het zal me niks verbazen dat mijn Ha instance, kvm of ubuntu er ook nog mee samenhangt.

Dat wifi geen slim idee is voor dergelijke apparatuur of doeleinden ben ik 100% eens De 2.4Ghz band is bij mij al vrij druk, want ik heb ook een Zigbee mesh. Al zitten er juist bij de Zendures geen zigbee devices in de nabijheid.
En ja, Omada is wel een stapje hoger, maar om nu voor alleen de Zendures die bende weer om te zetten gaat me iets te ver haha. Eerder geen issues gehad met de Deco.

Maar goed, ik pruts vrolijk even verder. Vanuit de situatie dat het nu op zich lijkt te werken (op het vermoedelijke foute tellen van de relais schakelingen na) ben ik wel tevreden hoor.

[Ben(V)]

DeadMetal schreef op woensdag 13 mei 2026 @ 09:55:
[...]

offtopic:
M.i. betekent mesh meerdere access points die onderling samenwerken, aangestuurd door een centraal systeem, met naadloze roaming van clients tussen de access points. Hoe de backhaul geregeld is (draadloos of met kabel) is daarvoor niet relevant. Met kabel is doorgaans juist sneller en stabieler.

Dat is echt een foute marketing gestuurde aanname.

Roaming wordt uitsluitend door de client bepaalt en nergens anders door.
En mesh is echt enkel een andere naam voor wireless backhaul en helemaal niets meer.

Er is door een paar leveranciers een poging gedaan om en functionaliteit in te bouwen die sticky clients van hun AP af te schoppen, maar als die sticky client zelf niet goed kan roamen, keert die gewoon weer naar zijn oude AP terug want elke client heeft lichte voorkeur om de oude connectie in stand te houden.

Als je het wifi netwerk goed opbouwt hebt (vooral niet teveel AP's) zal je met moderne clients die je op de 5Ghz band gebruikt helemaal nooit meer last van sticky clients hebben.

[Ben(V)]

Mistraller schreef op woensdag 13 mei 2026 @ 10:19:
@Pakhaas Het gekke is dat een budget repeater, ook van TPlink, aan mijn IoT ssid geen (of in elk geval fors minder) problemen geeft. En juist die repeater is nu wireless.
@ctrl-tab Mijn nodes hebben een wired backhaul. Deco is ook van TPlink

Ik heb gisteren nog wat geprutst, mesh uit, prioritering aangezet, fixed op 1 node, IoT netwerk doet alleen 2,4Ghz, ingesteld op 20Mhz, fixed channel etc etc. Toen de zendures weer in dat netwerk gehangen.
HA had er weer veel moeite mee. Wel viel het me op dat terwijl HA ermee worstelde, dat NR gewoon vlotte response gaf. Kortom, echt heel strak de vinger erachter krijgen lukt me nog niet; maar het zal me niks verbazen dat mijn Ha instance, kvm of ubuntu er ook nog mee samenhangt.

Dat wifi geen slim idee is voor dergelijke apparatuur of doeleinden ben ik 100% eens De 2.4Ghz band is bij mij al vrij druk, want ik heb ook een Zigbee mesh. Al zitten er juist bij de Zendures geen zigbee devices in de nabijheid.
En ja, Omada is wel een stapje hoger, maar om nu voor alleen de Zendures die bende weer om te zetten gaat me iets te ver haha. Eerder geen issues gehad met de Deco.

Maar goed, ik pruts vrolijk even verder. Vanuit de situatie dat het nu op zich lijkt te werken (op het vermoedelijke foute tellen van de relais schakelingen na) ben ik wel tevreden hoor.

De 2,4Gh band gebruiken is helemaal geen goed idee ook niet voor iot.
Die band gebruik je enkel als nood als je echt helemaal geen bereik hebt op de 5Ghz band, of devices hebt die enkel 2,4Ghz hebben.

Zigbee zit tussen de wifi kanalen in en als je dus voor kanaal 1,6, of 11 kiest heb je daar geen last van.

Helaas kunnen de Zendure's niet op 5Ghz.

[ Voor 8% gewijzigd door Ben(V) op 13-05-2026 12:40 ]

[hremijn]

Welke Zendures doen 5GHz? De SF2400Pro is alleen 2.4GHz.

[Gramser]

Tsja. Zendure zelf raadt de 2.4Ghz-band aan. Ik heb die toch maar gebruikt.

[Hippe Lip]

Ben(V) schreef op maandag 11 mei 2026 @ 13:32:
[...]

Helemaal geen smerige hack, maar een prima oplossing als je AP's dat ondersteunen.
Als die dingen als mesh geconfigureerd zijn willen ze echter meestal alle SSID's delen over alle AP's.

Maar aangezien @Hippe Lip z'n AP's bedraad heeft aangesloten kan hij de boel gewoon in AP mode zetten in plaats van Mesh mode, is hij meteen die mesh overhead op z'n wifi kwijt.

Nou, @koboy en @Ben(V), ik heb het accesspoint (AP) op twee meter afstand van de twee Zendure-stacks een eigen SSID gegeven en de beide stacks daaraan gekoppeld. Nu zitten die twee op hun eigen AP en zit er echt niemand anders op dat AP. Er zijn twee buren nog zichtbaar, dus van een overvol WiFi-netwerk kan ik niet spreken.
Maar daarmee zijn mijn verbindingsproblemen zijn allerminst voorbij!

Ik zie regelmatig uitval van de verbinding. Het is echt telkens maar heel even. En de rest van de tijd staat die op Excellent.
Waar kan dat nou aan liggen?

Gisteravond zag ik nog al zoiets vreemds: Het laden tijdens de goedkope periode eerder die dag met de inmiddels bekende hakkels gegaan. Maar het ontladen in de avond ging werkelijk vlekkeloos.
Hoe kan dat nou?

[ Voor 12% gewijzigd door Hippe Lip op 13-05-2026 14:03 ]

[Ben(V)]

Hippe Lip schreef op woensdag 13 mei 2026 @ 12:24:
[...]

Nou, @koboy en @Ben(V), ik heb het accesspoint (AP) op twee meter afstand van de twee Zendure-stacks een eigen SSID gegeven en de beide stacks daaraan gekoppeld. Nu zitten die twee op hun eigen AP en zit er echt niemand anders op dat AP. Er zijn twee buren nog zichtbaar, dus van een overvol WiFi-netwerk kan ik niet spreken.
Maar daarmee zijn mijn verbindingsproblemen zijn allerminst voorbij!

Ik zie regelmatig uitval van de verbinding. Het is echt telkens maar heel even. En de rest van de tijd staat de op Excellent.
Waar kan dat nou aan liggen?

Gisteravond zag ik nog al zoiets vreemds: Het laden tijdens de goedkope periode eerder die dag met de inmiddels bekende hakkels gegaan. Maar het ontladen in de avond ging werkelijk vlekkeloos.
Hoe kan dat nou?

[Afbeelding]

[Afbeelding]

Zit er soms een andere stoorbron in de buurt (magnetron, babyfoon, Dect, beveling camera's)?

Heeft alleen de Zendure er last van of gebeurd dat elder in je netwerk ook?

[Pakhaas]

Hippe Lip schreef op woensdag 13 mei 2026 @ 12:24:
[...]

Nou, @koboy en @Ben(V), ik heb het accesspoint (AP) op twee meter afstand van de twee Zendure-stacks een eigen SSID gegeven en de beide stacks daaraan gekoppeld. Nu zitten die twee op hun eigen AP en zit er echt niemand anders op dat AP. Er zijn twee buren nog zichtbaar, dus van een overvol WiFi-netwerk kan ik niet spreken.
Maar daarmee zijn mijn verbindingsproblemen zijn allerminst voorbij!

Ik zie regelmatig uitval van de verbinding. Het is echt telkens maar heel even. En de rest van de tijd staat de op Excellent.
Waar kan dat nou aan liggen?

Dat heb ik hier ook. Er is geen pijl op te trekken wanneer het gebeurd. Net een uur geleden weer 1-2sec en daarvoor zat er weer 22uur tussen. Soms na 5u etc. Hier zitten ook alleen de Zendures op een AP en die hangt ernaast.

[ Voor 3% gewijzigd door Pakhaas op 13-05-2026 13:12 ]

[ctrl-tab]

Mistraller schreef op woensdag 13 mei 2026 @ 10:19:
@Pakhaas Het gekke is dat een budget repeater, ook van TPlink, aan mijn IoT ssid geen (of in elk geval fors minder) problemen geeft. En juist die repeater is nu wireless.
@ctrl-tab Mijn nodes hebben een wired backhaul. Deco is ook van TPlink

Ik heb gisteren nog wat geprutst, mesh uit, prioritering aangezet, fixed op 1 node, IoT netwerk doet alleen 2,4Ghz, ingesteld op 20Mhz, fixed channel etc etc. Toen de zendures weer in dat netwerk gehangen.
HA had er weer veel moeite mee. Wel viel het me op dat terwijl HA ermee worstelde, dat NR gewoon vlotte response gaf. Kortom, echt heel strak de vinger erachter krijgen lukt me nog niet; maar het zal me niks verbazen dat mijn Ha instance, kvm of ubuntu er ook nog mee samenhangt.

Dat wifi geen slim idee is voor dergelijke apparatuur of doeleinden ben ik 100% eens De 2.4Ghz band is bij mij al vrij druk, want ik heb ook een Zigbee mesh. Al zitten er juist bij de Zendures geen zigbee devices in de nabijheid.
En ja, Omada is wel een stapje hoger, maar om nu voor alleen de Zendures die bende weer om te zetten gaat me iets te ver haha. Eerder geen issues gehad met de Deco.

Maar goed, ik pruts vrolijk even verder. Vanuit de situatie dat het nu op zich lijkt te werken (op het vermoedelijke foute tellen van de relais schakelingen na) ben ik wel tevreden hoor.

Zigbee is inderdaad een mesh. Die bedrade access points zijn dat niet. Dat zijn bedrade acccesspoints met wat protocollen die trachten clients seamless over te laten schakelen tussen die access points.
Zigbee alleen gaat geen issues geven op je netwerk, dat geloof ik niet. Doe eens een wifi analyse met je telefoon om de frequenties te bekijken. en pak voor je wifi netwerk iets dat daarbuiten valt (en ook buiten je zigbee channel)
Of zet alles eens op AUTO/fabrieksinstellingen.

Je hebt een VM. migreer eens tijdelijk naar een performante host. Kijken wat dat doet. Kans is groot dat je constant tegen hypervisor en/of VM issues aan loopt. Dat gaf je eerder ook al aan. Die problemen zullen niet altijd transparant zijn. CPU's die gethrottled worden of memory gebrek, dan kan je onvoorspelbaar (onlogisch) gedrag krijgen.

[Ben(V)]

MikeyMan schreef op dinsdag 12 mei 2026 @ 10:42:
Op basis van de code van @ctrl-tab en een beetje hulp van Claude de volgende yaml in elkaar geknutseld voor de standaard (fireson) integratie...

[...]


[Afbeelding]

Zal nog wel wat finetuning nodig hebben...

Het is denk ik beter om het vermogen bij te houden in plaats van de weerstand, want dat wordt tenslotte omgezet in warmte.
Bij mij wordt er zo rond de 6W per batterij verbruikt als ik met 2400W ontlaad.

Ik heb even een paar simpele sensors gemaakt voor de Firesone integratie die dat doen.
Wel even de namen van de sensors aanpassen aan je eigen omgeving.

YAML:

template:
  - sensor:
      - name: Battery1
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set total_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack_voltage = states('sensor.ab3000_08242_total_vol') | float %}
          {% set pack1_current = states('sensor.ab3000_08242_batcur') | float %}
          {% set pack2_current = states('sensor.ab3000_02822_batcur') | float %}
          {% set pack3_current = states('sensor.ab3000_02866_batcur') | float %}
          {% set pack4_current = states('sensor.ab3000_03030_batcur') | float %}
          {{((total_voltage - pack_voltage) * (pack1_current + pack2_current + pack3_current + pack4_current)) | abs | round(3, default=0)}}
  - sensor:
      - name: Battery2
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set total_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack_voltage = states('sensor.ab3000_02822_total_vol') | float %}
          {% set pack2_current = states('sensor.ab3000_02822_batcur') | float %}
          {% set pack3_current = states('sensor.ab3000_02866_batcur') | float %}
          {% set pack4_current = states('sensor.ab3000_03030_batcur') | float %}
          {{((total_voltage - pack_voltage) * (pack2_current + pack3_current + pack4_current)) | abs | round(3, default=0)}}
  - sensor:
      - name: Battery3
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set total_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack_voltage = states('sensor.ab3000_02866_total_vol') | float %}
          {% set pack3_current = states('sensor.ab3000_02866_batcur') | float %}
          {% set pack4_current = states('sensor.ab3000_03030_batcur') | float %}
          {{((total_voltage - pack_voltage) * (pack3_current + pack4_current)) | abs | round(3, default=0)}}
  - sensor:
      - name: Battery4
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set total_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack_voltage = states('sensor.ab3000_03030_total_vol') | float %}
          {% set pack4_current  = states('sensor.ab3000_03030_batcur') | float %}
          {{((total_voltage - pack_voltage) * pack4_current) | abs | round(3, default=0)}}

[ Voor 22% gewijzigd door Ben(V) op 14-05-2026 12:00 ]

[Hippe Lip]

Ben(V) schreef op woensdag 13 mei 2026 @ 12:42:
[...]

Zit er soms een andere stoorbron in de buurt (magnetron, babyfoon, Dect, beveling camera's)?

Heeft alleen de Zendure er last van of gebeurd dat elder in je netwerk ook?

De stacks staan op zolder. Geen magnetron, geen babyfoon, geen byzondere WiFi-dingen. Alleen een warmtepomp. Maar die draait in deze tijd van het jaar niet lang achtereen. Dus al die hakkels in de hele tijd van het laden kan daar ook niet aan liggen.

Echt, ik kan er maar niet achter komen wat dit kan zijn…

[Hippe Lip]

Pakhaas schreef op woensdag 13 mei 2026 @ 13:12:
[...]

Dat heb ik hier ook. Er is geen pijl peil op te trekken wanneer het gebeurd. Net een uur geleden weer 1-2sec en daarvoor zat er weer 22uur tussen. Soms na 5u etc. Hier zitten ook alleen de Zendures op een AP en die hangt ernaast.

Ja, die verbinding is echt het zwakste punt van die dingen. Ik heb er een lief ding voor over om er een bedrade verbinding mee te kunnen maken. Dan zijn we van dit soort ellende af.

[Ben(V)]

Ik heb hier nooit last van.
De Zendure staat op Zolder en de dichtbij zijnde AP hangt een verdieping lager terwijl de vloer van de zolder betonplaten zijn, is dus alle wifi signalen moeten via het trapgat.

Misschien overstuur je de boel wel juist omdat je de AP er vlak bij hebt staan (is maar een gok).

Weet je zeker dat het aan de wifi ligt?
Hoe constateer je dat hij de verbinding verliest?

[ Voor 13% gewijzigd door Ben(V) op 13-05-2026 14:21 ]

[RemmyB83]

Hippe Lip schreef op woensdag 13 mei 2026 @ 14:05:
[...]

De stacks staan op zolder. Geen magnetron, geen babyfoon, geen byzondere WiFi-dingen. Alleen een warmtepomp. Maar die draait in deze tijd van het jaar niet lang achtereen. Dus al die hakkels in de hele tijd van het laden kan daar ook niet aan liggen.

Echt, ik kan er maar niet achter komen wat dit kan zijn…

Ik heb het geheel niet helemaal gelezen.
Maar ik had pas geleden hetzelfde.
Ik kreeg toen de tip van @gast777 om de MQTT van mijn Zendure uit te zetten (in de zendure app)als die aanstond. Deze had ik toen idd aanstaan, en heb ik uitgezet. Probleem zou te veel data zijn, die niet goed verwerkt kon worden. Nu heb ik nog maar een enkele onderbreking.

[Mscroos]

Ben(V) schreef op woensdag 13 mei 2026 @ 11:21:
[...]

Dat is echt een foute marketing gestuurde aanname.

Roaming wordt uitsluitend door de client bepaalt en nergens anders door.
En mesh is echt enkel een andere naam voor wireless backhaul en helemaal niets meer.

Er is door een paar leveranciers een poging gedaan om en functionaliteit in te bouwen die sticky clients van hun AP af te schoppen, maar als die sticky client zelf niet goed kan roamen, keert die gewoon weer naar zijn oude AP terug want elke client heeft lichte voorkeur om de oude connectie in stand te houden.

Als je het wifi netwerk goed opbouwt hebt (vooral niet teveel AP's) zal je met moderne clients die je op de 5Ghz band gebruikt helemaal nooit meer last van sticky clients hebben.

Ik heb mijn Zendure accu's vastgemaakt aan 1 access point via Unifi, dus hoewel roaming door de client bepaald kan worden kan ik andersom wel bepalen dat een client maar aan 1 access point vast zit. Bij mij ging hij vreemd genoeg naar een heel onlogisch point connecten, met een slechte verbinding als gevolg.

[Mistraller]

Ben(V) schreef op woensdag 13 mei 2026 @ 11:30:
[...]

De 2,4Gh band gebruiken is helemaal geen goed idee ook niet voor iot.
Die band gebruik je enkel als nood als je echt helemaal geen bereik hebt op de 5Ghz band, of devices hebt die enkel 2,4Ghz hebben.

Zigbee zit tussen de wifi kanalen in en als je dus voor kanaal 1,6, of 11 kiest heb je daar geen last van.

Helaas kunnen de Zendure's niet op 5Ghz.

Er is hier geen enkel IoT device in de 5Ghz band.
Heatmeisters, camera's, wat lampen (voor zover niet zigbee), zendures; allemaal uitsluitend 2.4.

Logisch ook want de snelheid is minder van belang, maar de range van 5Ghz is minder, muren zijn sneller een probleem etc.
Met 2.4Ghz breedte 20Mhz kanaal 1, 6 of 11 heb je theoretisch de hoogste betrouwbaarheid. Alsnog geen verbetering gezien.

(enige suffe is dat Deco helemaal geen vlan tagging doet op het IoT netwerk dus buiten SSID naam/pass en bandbreedte is er niet veel verschil) Apparaten die niet naar buiten mogen praten block ik daarom op een andere manier.

Maar goed, ieder huis heeft z'n eigen eigenaardigheden mbt wifi dekking denk ik.

[Ben(V)]

Vlan over wifi is niets anders dan een apart SSID voor dat vlan te maken.
Dus als je deco dat niet ondersteund, dan kun je dat zelf maken met verschillende SSID's.
Echte vlan tagging kan niet over wifi, want wifi is een shared medium.

En 2,4Ghz heeft wel meer bereik, maar is daardoor ook storing gevoeliger.

[MikeyMan]

Ben(V) schreef op woensdag 13 mei 2026 @ 11:30:
[...]

De 2,4Gh band gebruiken is helemaal geen goed idee ook niet voor iot.
Die band gebruik je enkel als nood als je echt helemaal geen bereik hebt op de 5Ghz band, of devices hebt die enkel 2,4Ghz hebben.

Zigbee zit tussen de wifi kanalen in en als je dus voor kanaal 1,6, of 11 kiest heb je daar geen last van.

Helaas kunnen de Zendure's niet op 5Ghz.

Ubiquiti staat voor iot netwerken niets anders toe dan 2,4Ghz.

[Ben(V)]

Dat is natuurlijk onzin.
Er bestaat in de wifi wereld niet zoiets als een iot netwerk, dat is enkel een naamgeving van een SSID.

[MikeyMan]

Ben(V) schreef op woensdag 13 mei 2026 @ 13:57:
[...]

Het is denk ik beter om het vermogen bij te houden in plaats van de weerstand, want dat wordt tenslotte omgezet in warmte.
Bij mij wordt er zo rond de 6W per batterij verbruikt als ik met 2400W ontlaad.

Ik heb even een paar simpele sensors gemaakt voor de Firesone integratie die dat doen.
Wel even de namen van de sensors aanpassen aan je eigen omgeving.

YAML:

template:
  - sensor:
      - name: Battery1
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set battery_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack1_current  = states('sensor.ab3000_08242_batcur') | float %}
          {% set pack1_voltage = states('sensor.ab3000_08242_total_vol') | float %}
          {{((battery_voltage - pack1_voltage) * pack1_current) | abs | round(3, default=0)}}
  - sensor:
      - name: Battery2
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set battery_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack1_current  = states('sensor.ab3000_02822_batcur') | float %}
          {% set pack1_voltage = states('sensor.ab3000_02822_total_vol') | float %}
          {{((battery_voltage - pack1_voltage) * pack1_current) | abs | round(3, default=0)}}
  - sensor:
      - name: Battery3
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set battery_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack3_current  = states('sensor.ab3000_02866_batcur') | float %}
          {% set pack3_voltage = states('sensor.ab3000_02866_total_vol') | float %}
          {{((battery_voltage - pack3_voltage) * pack3_current) | abs | round(3, default=0)}}
  - sensor:
      - name: Battery4
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set battery_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack4_current  = states('sensor.ab3000_03030_batcur') | float %}
          {% set pack4_voltage = states('sensor.ab3000_03030_total_vol') | float %}
          {{((battery_voltage - pack4_voltage) * pack4_current) | abs | round(3, default=0)}}

Kan nooit kwaad om toe te voegen. Was uitgegaan van @ctrl-tab... En Claude zag er ook wat in

[Mistraller]

Ben(V) schreef op woensdag 13 mei 2026 @ 15:55:
Vlan over wifi is niets anders dan een apart SSID voor dat vlan te maken.
Dus als je deco dat niet ondersteund, dan kun je dat zelf maken met verschillende SSID's.
Echte vlan tagging kan niet over wifi, want wifi is een shared medium.

En 2,4Ghz heeft wel meer bereik, maar is daardoor ook storing gevoeliger.

Ja maar dan zou het wel net zijn als je router het verkeer dat over dat specifieke SSID binnenkomt ook tagt. Dat doet deco dus helemaal niet. (kan wel voor je guest network) Maar we gaan offtopic.

[ctrl-tab]

Ben(V) schreef op woensdag 13 mei 2026 @ 13:57:
[...]

Het is denk ik beter om het vermogen bij te houden in plaats van de weerstand, want dat wordt tenslotte omgezet in warmte.
Bij mij wordt er zo rond de 6W per batterij verbruikt als ik met 2400W ontlaad.

Ik heb even een paar simpele sensors gemaakt voor de Firesone integratie die dat doen.
Wel even de namen van de sensors aanpassen aan je eigen omgeving.

YAML:

template:
  - sensor:
      - name: Battery1
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set battery_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack1_current  = states('sensor.ab3000_08242_batcur') | float %}
          {% set pack1_voltage = states('sensor.ab3000_08242_total_vol') | float %}
          {{((battery_voltage - pack1_voltage) * pack1_current) | abs | round(3, default=0)}}
  - sensor:
      - name: Battery2
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set battery_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack1_current  = states('sensor.ab3000_02822_batcur') | float %}
          {% set pack1_voltage = states('sensor.ab3000_02822_total_vol') | float %}
          {{((battery_voltage - pack1_voltage) * pack1_current) | abs | round(3, default=0)}}
  - sensor:
      - name: Battery3
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set battery_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack3_current  = states('sensor.ab3000_02866_batcur') | float %}
          {% set pack3_voltage = states('sensor.ab3000_02866_total_vol') | float %}
          {{((battery_voltage - pack3_voltage) * pack3_current) | abs | round(3, default=0)}}
  - sensor:
      - name: Battery4
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set battery_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack4_current  = states('sensor.ab3000_03030_batcur') | float %}
          {% set pack4_voltage = states('sensor.ab3000_03030_total_vol') | float %}
          {{((battery_voltage - pack4_voltage) * pack4_current) | abs | round(3, default=0)}}

Opzich is watt een wat makkelijkere eenheid die meer zegt (in elk geval wat intuitiever)

Ik zit wel te denken, het meest relevant is de eerste connectie (invertor>batterij 1).
Ik weet niet hoe die battery packs technisch doorgelust zijn, maar het klopt niet als we batterij 3 op dezelfde manier berekenen als batterij1. Batterij 3 heeft 3x een connector gehad, dus 3x weerstand?

edit; antwoord op mezelf; je weet niet exact de volgorde dus alle 3 is prima.
Heb ze ook even toegevoegd. Zendure 1 is aan het onladen, en de getalletjes zijn wat je ongeveer zou verwachten (volgorde klopt in deze). In feite zou je , als je zeker bent van de volgorde, de packs van elkaar kunnen aftrekken. Maar gezien alleen de eerste eigenlijk belangrijk is, is het prima om alles met de invertor te verrekenen, dan zit je er nooit langs , mocht de fysieke volgorde niet kloppen met de digitale volgorde.

Van de andere kant, als waarde 3 te hoog is, en dit betreft fysieke batterij 3, dan hoef er geen issue te zijn.
Als he batterij 1 zou zijn, zou dat in theorie wel kunnen. Denk dat die volgorde daadwerkelijk van belang is!

.

[ Voor 14% gewijzigd door ctrl-tab op 13-05-2026 20:41 ]

[koboy]

Hippe Lip schreef op woensdag 13 mei 2026 @ 14:05:
[...]

De stacks staan op zolder. Geen magnetron, geen babyfoon, geen byzondere WiFi-dingen. Alleen een warmtepomp. Maar die draait in deze tijd van het jaar niet lang achtereen. Dus al die hakkels in de hele tijd van het laden kan daar ook niet aan liggen.

Echt, ik kan er maar niet achter komen wat dit kan zijn…

Het punt dat het alleen bij opladen gebeurt lijkt een verbindingsprobleem uit te sluiten. Ik zit dan eerder te denken aan dat er ergens in de keten iets is dat zegt dat je te veel afneemt....
Dus een verkeerd ingestelde hoofdzekering waarde ofzo, dat dan gecombineerd met een pulserende load ergens (Quooker?) zou het kunnen verklaren.

Kun je wat meer gegevens delen over je aansluiting? Wat voor slimme meter hangt er?

Je had 2x een 2400AC plus toch?

[Ben(V)]

ctrl-tab schreef op woensdag 13 mei 2026 @ 20:01:
[...]


Opzich is watt een wat makkelijkere eenheid die meer zegt (in elk geval wat intuitiever)

Ik zit wel te denken, het meest relevant is de eerste connectie (invertor>batterij 1).
Ik weet niet hoe die battery packs technisch doorgelust zijn, maar het klopt niet als we batterij 3 op dezelfde manier berekenen als batterij1. Batterij 3 heeft 3x een connector gehad, dus 3x weerstand?

edit; antwoord op mezelf; je weet niet exact de volgorde dus alle 3 is prima.
Heb ze ook even toegevoegd. Zendure 1 is aan het onladen, en de getalletjes zijn wat je ongeveer zou verwachten (volgorde klopt in deze). In feite zou je , als je zeker bent van de volgorde, de packs van elkaar kunnen aftrekken. Maar gezien alleen de eerste eigenlijk belangrijk is, is het prima om alles met de invertor te verrekenen, dan zit je er nooit langs , mocht de fysieke volgorde niet kloppen met de digitale volgorde.

Van de andere kant, als waarde 3 te hoog is, en dit betreft fysieke batterij 3, dan hoef er geen issue te zijn.
Als he batterij 1 zou zijn, zou dat in theorie wel kunnen. Denk dat die volgorde daadwerkelijk van belang is!

[Afbeelding].

Heb even vluchtig over jullie code gekeken, maar ik dacht dat ik zag dat jullie de stromen van alle batterijen bij elkaar nemen.
Elke batterij heeft een eigen stroom en die vermenigvuldig ik met het verschil van de totale spanning en de batterij spanning, dan zie je welke vermogen verlies er per batterij is.

Als je het vermogen verlies per connector wil weten moet je bij de eerste batterij alle stromen optellen, bij de twee die totalisering verminderen met de stroom naar de eeste batterij enz.

[ Voor 13% gewijzigd door Ben(V) op 13-05-2026 22:01 ]

[DrNickB]

gast777 schreef op dinsdag 12 mei 2026 @ 21:21:
[...]

Volgens mij gebruikt @DrNickB ook Zonnepanelen op de Gielz. Ik weet niet of het met of zonder Proxy is. Misschien heeft hij een idee wat hier gebeurt.

Anders wat ik zou aanbevelen is de laatste versie van de Proxy erop zetten en daarmee via het node-red dashboard2 even een trace te loggen van alle json data tijdens het probleem. Dan weten we in ieder geval wat daar exact gebeurt. Dan zouden we kunnen checken of de Proxy de data van beide Zendures combineert zoals de bedoeling is en zoals Gielz het verwacht aangeleverd te krijgen (dus alsof het 1 Zendure is).

NB: documentatie voor de debug trace feature zal ik nog zsm maken en online zetten (het wijst zich grotendeels vanzelf, maar je moet even weten waar je het kunt vinden).

Late reactie, even snel terug gelezen, ja wel met panelen en gielz, maar zonder NR.

Als ik het lees snap ik het wel. De ene zit vol en gaat ontladen, pv overschot, Maar wordtniet als 'vraag' gezien. Opladen commando zal niet veel doen op de ene die vol zit, geen idee waarom de 2de dit niet ziet.

[ctrl-tab]

Ben(V) schreef op woensdag 13 mei 2026 @ 21:31:
[...]

Heb even vluchtig over jullie code gekeken, maar ik dacht dat ik zag dat jullie de stromen van alle batterijen bij elkaar nemen en dat is niet goed.
Elke batterij heeft een eigen stroom en die moet je vermenigvuldigen met het verschil van de totale spanning en de batterij spanning.

Dus (Vtot - Vbat1)*Ibat1 en niet (Vtot - Vbat1)* (Ibat1 +Ibat2 +Ibat3)

Ja precies, dan klopt het.
Ik kwam zojuist wel nog een issue tegen, en dat zat in mijn batterij volgorde. Als je de Zendure 1 bekijjkt zie je dat die wattages logisch verlopen. LAAG-MIDDEN-HOOG
Bij Zendure2 is het andersom.
Ik zag op basis van de serienummers dat de laatste 2 batterijen verkeerd om in de Zendure App (en dus ook in Gielz stonden). Heb ze (5 en 6) nu omgedraaid. Heb ze nu gecorrigeerd in de gielz settings. Alleen kloppen de verhoudingen van Zendure2 nog steeds niet helemaal. Dat zal een 'gewone' afwijking zijn.

Maar dan kom ik op wat ik net bedoelde, als je het verlies en wattage op de connector wilt weten, moet je het verschil tussen de battery units (in mijn geval 2- en 3-) meten , en niet de invertor als startpunt nemen. Het draait immers om de connectors
Als de volgorde in de Zendure invertor niet niet klopt, klopt ook die berekening niet. Ok er zijn geen issues bekend tussen 2 batterijen (altijd issues tussen invertor en batterij 1. Maar ook batterij 1 zou in theorie een mismatch kunnen zijn qua serienummer. Dus wel zinnig even te checken in de serienummer sensor en de plakkertjes op de batterijen of die kloppen.

[Ben(V)]

Heb mijn post even verbeterd, lees hem nog even.

Ga morgen nog wel even een template maken die beide invalshoeken weergeeft.

[ Voor 45% gewijzigd door Ben(V) op 13-05-2026 22:03 ]