Zendure producten in Home Assistant integreren deel 2

[ctrl-tab]

Weet er iemand hoe het komt dat de volgorde van de batterijen binnen de Zendure kan afwijken van de fysieke volgorde? Kwam er nl achter dat er 2 bij mij niet overeenkomen.
Aangepast in Gielz inegratie. Maar kan dit nog veranderen? Of gewoon iets met een eerste initialisatie?

[ctrl-tab]

Ben(V) schreef op woensdag 13 mei 2026 @ 22:02:
Heb mijn post even verbeterd, lees hem nog even.

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

Heb het nu voor de gielz integratie aangepast. nu wordt het verschil tussen de batterijen (en dus de connector ertussen) berekend, en niet alles vanuit perspectief van de invertor.
Dit vereist dus wel da je interne volgorde correct is! Dit was bij mij niet zo (en zal vaker voorkomen, gezien de Gielz setting die je helpt dat te corrigeren)



Sensoren (plaatsen in gielz package)

code:

# ── INVERTER 1 REST SENSOR BLOCK ─────────────────────────────────────────────

      - name: "Zendure Inverter 1 Connector Inv-Pack0 Resistance"
        value_template: >
          {% set volgorde_raw = states('input_text.zendure_setting_battery_order') %}
          {% set volgorde = volgorde_raw.split(';') if volgorde_raw not in ['unknown', 'unavailable', ''] else ['1','2','3','4','5','6'] %}
          {% set ns = namespace(total_current=0) %}
          {% for i in [0, 1, 2] %}
            {% set idx = (volgorde[i] | int) - 1 %}
            {% set raw = value_json['packData'][idx]['batcur'] | int %}
            {% set ns.total_current = ns.total_current + ((raw if raw <= 32767 else raw - 65536) / 10.0) %}
          {% endfor %}
          {% set total_current = ns.total_current | abs %}
          {% if total_current > 0 %}
            {% set bat_volt = states('sensor.zendure_inverter_1_battery_voltage') | float(0) * 100 %}
            {% set pack_index = (volgorde[0] | int) - 1 %}
            {% set pack_volt = value_json['packData'][pack_index]['totalVol'] | float %}
            {{ ((pack_volt - bat_volt) | abs / 100.0 / total_current * 1000) | round(2) }}
          {% else %}
            unavailable
          {% endif %}
        unique_id: zendure_inverter_1_connector_inv_pack0_resistance
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:omega

      - name: "Zendure Inverter 1 Connector Inv-Pack0 Heat Loss"
        value_template: >
          {% set volgorde_raw = states('input_text.zendure_setting_battery_order') %}
          {% set volgorde = volgorde_raw.split(';') if volgorde_raw not in ['unknown', 'unavailable', ''] else ['1','2','3','4','5','6'] %}
          {% set ns = namespace(total_current=0) %}
          {% for i in [0, 1, 2] %}
            {% set idx = (volgorde[i] | int) - 1 %}
            {% set raw = value_json['packData'][idx]['batcur'] | int %}
            {% set ns.total_current = ns.total_current + ((raw if raw <= 32767 else raw - 65536) / 10.0) %}
          {% endfor %}
          {% set total_current = ns.total_current | abs %}
          {% if total_current > 0 %}
            {% set bat_volt = states('sensor.zendure_inverter_1_battery_voltage') | float(0) * 100 %}
            {% set pack_index = (volgorde[0] | int) - 1 %}
            {% set pack_volt = value_json['packData'][pack_index]['totalVol'] | float %}
            {{ ((pack_volt - bat_volt) | abs / 100.0 * total_current) | round(2) }}
          {% else %}
            unavailable
          {% endif %}
        unique_id: zendure_inverter_1_connector_inv_pack0_heat_loss
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
        icon: mdi:heat-wave

      - name: "Zendure Inverter 1 Connector Pack0-Pack1 Resistance"
        value_template: >
          {% set volgorde_raw = states('input_text.zendure_setting_battery_order') %}
          {% set volgorde = volgorde_raw.split(';') if volgorde_raw not in ['unknown', 'unavailable', ''] else ['1','2','3','4','5','6'] %}
          {% set ns = namespace(total_current=0) %}
          {% for i in [1, 2] %}
            {% set idx = (volgorde[i] | int) - 1 %}
            {% set raw = value_json['packData'][idx]['batcur'] | int %}
            {% set ns.total_current = ns.total_current + ((raw if raw <= 32767 else raw - 65536) / 10.0) %}
          {% endfor %}
          {% set total_current = ns.total_current | abs %}
          {% if total_current > 0 %}
            {% set idx0 = (volgorde[0] | int) - 1 %}
            {% set idx1 = (volgorde[1] | int) - 1 %}
            {% set volt0 = value_json['packData'][idx0]['totalVol'] | float %}
            {% set volt1 = value_json['packData'][idx1]['totalVol'] | float %}
            {{ ((volt0 - volt1) | abs / 100.0 / total_current * 1000) | round(2) }}
          {% else %}
            unavailable
          {% endif %}
        unique_id: zendure_inverter_1_connector_pack0_pack1_resistance
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:omega

      - name: "Zendure Inverter 1 Connector Pack0-Pack1 Heat Loss"
        value_template: >
          {% set volgorde_raw = states('input_text.zendure_setting_battery_order') %}
          {% set volgorde = volgorde_raw.split(';') if volgorde_raw not in ['unknown', 'unavailable', ''] else ['1','2','3','4','5','6'] %}
          {% set ns = namespace(total_current=0) %}
          {% for i in [1, 2] %}
            {% set idx = (volgorde[i] | int) - 1 %}
            {% set raw = value_json['packData'][idx]['batcur'] | int %}
            {% set ns.total_current = ns.total_current + ((raw if raw <= 32767 else raw - 65536) / 10.0) %}
          {% endfor %}
          {% set total_current = ns.total_current | abs %}
          {% if total_current > 0 %}
            {% set idx0 = (volgorde[0] | int) - 1 %}
            {% set idx1 = (volgorde[1] | int) - 1 %}
            {% set volt0 = value_json['packData'][idx0]['totalVol'] | float %}
            {% set volt1 = value_json['packData'][idx1]['totalVol'] | float %}
            {{ ((volt0 - volt1) | abs / 100.0 * total_current) | round(2) }}
          {% else %}
            unavailable
          {% endif %}
        unique_id: zendure_inverter_1_connector_pack0_pack1_heat_loss
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
        icon: mdi:heat-wave

      - name: "Zendure Inverter 1 Connector Pack1-Pack2 Resistance"
        value_template: >
          {% set volgorde_raw = states('input_text.zendure_setting_battery_order') %}
          {% set volgorde = volgorde_raw.split(';') if volgorde_raw not in ['unknown', 'unavailable', ''] else ['1','2','3','4','5','6'] %}
          {% set ns = namespace(total_current=0) %}
          {% for i in [2] %}
            {% set idx = (volgorde[i] | int) - 1 %}
            {% set raw = value_json['packData'][idx]['batcur'] | int %}
            {% set ns.total_current = ns.total_current + ((raw if raw <= 32767 else raw - 65536) / 10.0) %}
          {% endfor %}
          {% set total_current = ns.total_current | abs %}
          {% if total_current > 0 %}
            {% set idx1 = (volgorde[1] | int) - 1 %}
            {% set idx2 = (volgorde[2] | int) - 1 %}
            {% set volt1 = value_json['packData'][idx1]['totalVol'] | float %}
            {% set volt2 = value_json['packData'][idx2]['totalVol'] | float %}
            {{ ((volt1 - volt2) | abs / 100.0 / total_current * 1000) | round(2) }}
          {% else %}
            unavailable
          {% endif %}
        unique_id: zendure_inverter_1_connector_pack1_pack2_resistance
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:omega

      - name: "Zendure Inverter 1 Connector Pack1-Pack2 Heat Loss"
        value_template: >
          {% set volgorde_raw = states('input_text.zendure_setting_battery_order') %}
          {% set volgorde = volgorde_raw.split(';') if volgorde_raw not in ['unknown', 'unavailable', ''] else ['1','2','3','4','5','6'] %}
          {% set ns = namespace(total_current=0) %}
          {% for i in [2] %}
            {% set idx = (volgorde[i] | int) - 1 %}
            {% set raw = value_json['packData'][idx]['batcur'] | int %}
            {% set ns.total_current = ns.total_current + ((raw if raw <= 32767 else raw - 65536) / 10.0) %}
          {% endfor %}
          {% set total_current = ns.total_current | abs %}
          {% if total_current > 0 %}
            {% set idx1 = (volgorde[1] | int) - 1 %}
            {% set idx2 = (volgorde[2] | int) - 1 %}
            {% set volt1 = value_json['packData'][idx1]['totalVol'] | float %}
            {% set volt2 = value_json['packData'][idx2]['totalVol'] | float %}
            {{ ((volt1 - volt2) | abs / 100.0 * total_current) | round(2) }}
          {% else %}
            unavailable
          {% endif %}
        unique_id: zendure_inverter_1_connector_pack1_pack2_heat_loss
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
        icon: mdi:heat-wave

# ── INVERTER 2 REST SENSOR BLOCK ─────────────────────────────────────────────

      - name: "Zendure Inverter 2 Connector Inv-Pack0 Resistance"
        value_template: >
          {% set volgorde_raw = states('input_text.zendure_setting_battery_order') %}
          {% set volgorde = volgorde_raw.split(';') if volgorde_raw not in ['unknown', 'unavailable', ''] else ['1','2','3','4','5','6'] %}
          {% set ns = namespace(total_current=0) %}
          {% for i in [3, 4, 5] %}
            {% set idx = (volgorde[i] | int) - 1 %}
            {% set raw = value_json['packData'][idx]['batcur'] | int %}
            {% set ns.total_current = ns.total_current + ((raw if raw <= 32767 else raw - 65536) / 10.0) %}
          {% endfor %}
          {% set total_current = ns.total_current | abs %}
          {% if total_current > 0 %}
            {% set bat_volt = states('sensor.zendure_inverter_2_battery_voltage') | float(0) * 100 %}
            {% set pack_index = (volgorde[3] | int) - 1 %}
            {% set pack_volt = value_json['packData'][pack_index]['totalVol'] | float %}
            {{ ((pack_volt - bat_volt) | abs / 100.0 / total_current * 1000) | round(2) }}
          {% else %}
            unavailable
          {% endif %}
        unique_id: zendure_inverter_2_connector_inv_pack0_resistance
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:omega

      - name: "Zendure Inverter 2 Connector Inv-Pack0 Heat Loss"
        value_template: >
          {% set volgorde_raw = states('input_text.zendure_setting_battery_order') %}
          {% set volgorde = volgorde_raw.split(';') if volgorde_raw not in ['unknown', 'unavailable', ''] else ['1','2','3','4','5','6'] %}
          {% set ns = namespace(total_current=0) %}
          {% for i in [3, 4, 5] %}
            {% set idx = (volgorde[i] | int) - 1 %}
            {% set raw = value_json['packData'][idx]['batcur'] | int %}
            {% set ns.total_current = ns.total_current + ((raw if raw <= 32767 else raw - 65536) / 10.0) %}
          {% endfor %}
          {% set total_current = ns.total_current | abs %}
          {% if total_current > 0 %}
            {% set bat_volt = states('sensor.zendure_inverter_2_battery_voltage') | float(0) * 100 %}
            {% set pack_index = (volgorde[3] | int) - 1 %}
            {% set pack_volt = value_json['packData'][pack_index]['totalVol'] | float %}
            {{ ((pack_volt - bat_volt) | abs / 100.0 * total_current) | round(2) }}
          {% else %}
            unavailable
          {% endif %}
        unique_id: zendure_inverter_2_connector_inv_pack0_heat_loss
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
        icon: mdi:heat-wave

      - name: "Zendure Inverter 2 Connector Pack0-Pack1 Resistance"
        value_template: >
          {% set volgorde_raw = states('input_text.zendure_setting_battery_order') %}
          {% set volgorde = volgorde_raw.split(';') if volgorde_raw not in ['unknown', 'unavailable', ''] else ['1','2','3','4','5','6'] %}
          {% set ns = namespace(total_current=0) %}
          {% for i in [4, 5] %}
            {% set idx = (volgorde[i] | int) - 1 %}
            {% set raw = value_json['packData'][idx]['batcur'] | int %}
            {% set ns.total_current = ns.total_current + ((raw if raw <= 32767 else raw - 65536) / 10.0) %}
          {% endfor %}
          {% set total_current = ns.total_current | abs %}
          {% if total_current > 0 %}
            {% set idx0 = (volgorde[3] | int) - 1 %}
            {% set idx1 = (volgorde[4] | int) - 1 %}
            {% set volt0 = value_json['packData'][idx0]['totalVol'] | float %}
            {% set volt1 = value_json['packData'][idx1]['totalVol'] | float %}
            {{ ((volt0 - volt1) | abs / 100.0 / total_current * 1000) | round(2) }}
          {% else %}
            unavailable
          {% endif %}
        unique_id: zendure_inverter_2_connector_pack0_pack1_resistance
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:omega

      - name: "Zendure Inverter 2 Connector Pack0-Pack1 Heat Loss"
        value_template: >
          {% set volgorde_raw = states('input_text.zendure_setting_battery_order') %}
          {% set volgorde = volgorde_raw.split(';') if volgorde_raw not in ['unknown', 'unavailable', ''] else ['1','2','3','4','5','6'] %}
          {% set ns = namespace(total_current=0) %}
          {% for i in [4, 5] %}
            {% set idx = (volgorde[i] | int) - 1 %}
            {% set raw = value_json['packData'][idx]['batcur'] | int %}
            {% set ns.total_current = ns.total_current + ((raw if raw <= 32767 else raw - 65536) / 10.0) %}
          {% endfor %}
          {% set total_current = ns.total_current | abs %}
          {% if total_current > 0 %}
            {% set idx0 = (volgorde[3] | int) - 1 %}
            {% set idx1 = (volgorde[4] | int) - 1 %}
            {% set volt0 = value_json['packData'][idx0]['totalVol'] | float %}
            {% set volt1 = value_json['packData'][idx1]['totalVol'] | float %}
            {{ ((volt0 - volt1) | abs / 100.0 * total_current) | round(2) }}
          {% else %}
            unavailable
          {% endif %}
        unique_id: zendure_inverter_2_connector_pack0_pack1_heat_loss
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
        icon: mdi:heat-wave

      - name: "Zendure Inverter 2 Connector Pack1-Pack2 Resistance"
        value_template: >
          {% set volgorde_raw = states('input_text.zendure_setting_battery_order') %}
          {% set volgorde = volgorde_raw.split(';') if volgorde_raw not in ['unknown', 'unavailable', ''] else ['1','2','3','4','5','6'] %}
          {% set ns = namespace(total_current=0) %}
          {% for i in [5] %}
            {% set idx = (volgorde[i] | int) - 1 %}
            {% set raw = value_json['packData'][idx]['batcur'] | int %}
            {% set ns.total_current = ns.total_current + ((raw if raw <= 32767 else raw - 65536) / 10.0) %}
          {% endfor %}
          {% set total_current = ns.total_current | abs %}
          {% if total_current > 0 %}
            {% set idx1 = (volgorde[4] | int) - 1 %}
            {% set idx2 = (volgorde[5] | int) - 1 %}
            {% set volt1 = value_json['packData'][idx1]['totalVol'] | float %}
            {% set volt2 = value_json['packData'][idx2]['totalVol'] | float %}
            {{ ((volt1 - volt2) | abs / 100.0 / total_current * 1000) | round(2) }}
          {% else %}
            unavailable
          {% endif %}
        unique_id: zendure_inverter_2_connector_pack1_pack2_resistance
        unit_of_measurement: "mΩ"
        state_class: measurement
        icon: mdi:omega

      - name: "Zendure Inverter 2 Connector Pack1-Pack2 Heat Loss"
        value_template: >
          {% set volgorde_raw = states('input_text.zendure_setting_battery_order') %}
          {% set volgorde = volgorde_raw.split(';') if volgorde_raw not in ['unknown', 'unavailable', ''] else ['1','2','3','4','5','6'] %}
          {% set ns = namespace(total_current=0) %}
          {% for i in [5] %}
            {% set idx = (volgorde[i] | int) - 1 %}
            {% set raw = value_json['packData'][idx]['batcur'] | int %}
            {% set ns.total_current = ns.total_current + ((raw if raw <= 32767 else raw - 65536) / 10.0) %}
          {% endfor %}
          {% set total_current = ns.total_current | abs %}
          {% if total_current > 0 %}
            {% set idx1 = (volgorde[4] | int) - 1 %}
            {% set idx2 = (volgorde[5] | int) - 1 %}
            {% set volt1 = value_json['packData'][idx1]['totalVol'] | float %}
            {% set volt2 = value_json['packData'][idx2]['totalVol'] | float %}
            {{ ((volt1 - volt2) | abs / 100.0 * total_current) | round(2) }}
          {% else %}
            unavailable
          {% endif %}
        unique_id: zendure_inverter_2_connector_pack1_pack2_heat_loss
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
        icon: mdi:heat-wave

rest sensoren voor voltage per invertor (in dit geval 2)

code:

  - resource: "http://IPADDRESS/properties/report"  # <-- Replace with IP of inverter 1
    scan_interval: 1
    sensor:
      - name: "Zendure Inverter 1 Battery Voltage"
        value_template: "{{ (value_json['properties']['BatVolt'] | float / 100) | round(2) }}"
        unique_id: zendure_inverter_1_battery_voltage
        unit_of_measurement: "V"
        state_class: measurement
        device_class: voltage
        icon: mdi:sine-wave

  - resource: "http://IPADDRESS/properties/report"  # <-- Replace with IP of inverter 2
    scan_interval: 1
    sensor:
      - name: "Zendure Inverter 2 Battery Voltage"
        value_template: "{{ (value_json['properties']['BatVolt'] | float / 100) | round(2) }}"
        unique_id: zendure_inverter_2_battery_voltage
        unit_of_measurement: "V"
        state_class: measurement
        device_class: voltage
        icon: mdi:sine-wave

[Hippe Lip]

Ben(V) schreef op woensdag 13 mei 2026 @ 11:21:
[...]
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.

Dat is leuke theorie, maar ik heb in mijn huis met betonnen vloeren nogal last van vervelende ‘dode’ zones als ik niet elke verdieping (BG, 1 en 2) van een eigen AP voorzie. Wel weg bij het trapgat.

[Hippe Lip]

RemmyB83 schreef op woensdag 13 mei 2026 @ 14:37:
[...]

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.

Als die standaard uit staat, is die nu nog steeds uit. Nooit wat met MQTT gedaan met de Zendures. Ik zou niet eens weten waar ik dat in de app aan of uit kan zetten. Net nog eens naar gekeken.

[Hippe Lip]

Ben(V) schreef op woensdag 13 mei 2026 @ 14:11:
Ik heb hier nooit last van.

Mazzelaar

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).

Wie weet …

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

Hoe zou ik dat kunnen weten? Ik weet dat de Gielz de verbinding gewoonlijk als Excellent kwalificeert, maar als ik daar een tijdje naar kijk, dan zie ik dat er onderbrekinkjes in de verbinding zijn.
Dat kan de WiFi zijn, dat kan de proxy zijn, dat kan de Gielz zijn. Als je het weet mag je het zeggen.

[emielbf]

ik heb ook een hele tijd connectie problemen gehad met mijn eigen HEMS script, perfecte wifi en toch problemen. Zendure gaf aan dat je niet meer dan 1 keer per 3 seconden de api mag bevragen. Throttle ingebouwd en geen problemen meer.

[gielz]

emielbf schreef op donderdag 14 mei 2026 @ 07:33:
ik heb ook een hele tijd connectie problemen gehad met mijn eigen HEMS script, perfecte wifi en toch problemen. Zendure gaf aan dat je niet meer dan 1 keer per 3 seconden de api mag bevragen. Throttle ingebouwd en geen problemen meer.

Ligt er dus aan wie je spreekt bij Zendure. 1x per seconden kan prima. Hier is het zelfs 2x per seconden omdat ik beide talen draai. En dat zonder problemen. Een AP paar meter van de locatie werd aangeraden.

Zodra je meerdere dingen gaat combineren gaat het mis; MQTT en ZenSDK of POST commands spammen.

[Ben(V)]

ctrl-tab schreef op woensdag 13 mei 2026 @ 22:50:
Weet er iemand hoe het komt dat de volgorde van de batterijen binnen de Zendure kan afwijken van de fysieke volgorde? Kwam er nl achter dat er 2 bij mij niet overeenkomen.
Aangepast in Gielz inegratie. Maar kan dit nog veranderen? Of gewoon iets met een eerste initialisatie?

Daar kunnen Gielz en Fireson niets aan doen, Zendure geeft die data in een willekeurige volgorde terug.

De simpelste manier om dat vast te stellen is even naar de stroom per batterij te kijken, die loopt namelijk van boven naar beneden altijd af, dus de bovenste batterij heeft altijd de meeste stroom en de onderste de minste.

[Hippe Lip]

Ben(V) schreef op donderdag 14 mei 2026 @ 10:07:
[...]

Daar kunnen Gielz en Fireson niets aan doen, Zendure geeft die data in een willekeurige volgorde terug.

De simpelste manier om dat vast te stellen is even naar de stroom per batterij te kijken, die loopt namelijk van boven naar beneden altijd af, dus de bovenste batterij heeft altijd de meeste stroom en de onderste de minste.

Dan valt het aangeven van de volgorde dus te automatiseren …

[Ben(V)]

Hippe Lip schreef op donderdag 14 mei 2026 @ 01:16:
[...]

Mazzelaar

[...]

Wie weet …

[...]

Hoe zou ik dat kunnen weten? Ik weet dat de Gielz de verbinding gewoonlijk als Excellent kwalificeert, maar als ik daar een tijdje naar kijk, dan zie ik dat er onderbrekinkjes in de verbinding zijn.
Dat kan de WiFi zijn, dat kan de proxy zijn, dat kan de Gielz zijn. Als je het weet mag je het zeggen.

Wat bedoel je precies met onderbrekingkjes, hoe lang zijn die en welk signaal bedoel je?
Ik heb geen Gielz maar kijk je bijvoorbeeld naar de rssi van de Zendure?

Bedenk dat wifi een shared medium is en dat daarom onderbrekingen normaal zijn, maar een Zendure is netwerk technisch gezien een enorm traag ding dus normale rssi fluctuaties zouden geen enkele invloed moeten hebben op de werking.

[Jules52]

Graag advies. Ik wil een 2400AC+ plus AB3000L module via de Gielz code integreren in Home Assistant. Daarin zitten al mijn pv installatie, laadpaal, DSMR etc. Heb ik nu goed begrepen dat ik eerst de nieuwe 2400AC+ middels de Zendure app moet aanmelden, het laad/ontlaad vermogen in deze app moet begrenzen en vervolgens HEMS moet 'disablen'. Hierna pas starten met stap 1 en 2 van de Gielz installatie instructie. Ik heb geen extra P1 dongle. De data is al beschikbaar via een seriële verbinding en de DSMR integratie. Morgen worden de Zendure modules geleverd. Ik ga ze in eerste instantie via een stopcontact in de garage verbinden. Later komt er wel een extra groep bij.

[R1chardTM]

Jules52 schreef op donderdag 14 mei 2026 @ 12:10:
Graag advies. Ik wil een 2400AC+ plus AB3000L module via de Gielz code integreren in Home Assistant. Daarin zitten al mijn pv installatie, laadpaal, DSMR etc. Heb ik nu goed begrepen dat ik eerst de nieuwe 2400AC+ middels de Zendure app moet aanmelden, het laad/ontlaad vermogen in deze app moet begrenzen en vervolgens HEMS moet 'disablen'. Hierna pas starten met stap 1 en 2 van de Gielz installatie instructie. Ik heb geen extra P1 dongle. De data is al beschikbaar via een seriële verbinding en de DSMR integratie. Morgen worden de Zendure modules geleverd. Ik ga ze in eerste instantie via een stopcontact in de garage verbinden. Later komt er wel een extra groep bij.

Gewoon eerst het proces volgen van de omvormer toevoegen in de Zendure app. Tijdens dit proces stel je ook het maximale laad/ontlaad vermogen in. Vervolgens de omvormer in de app niet in HEMS toevoegen, maar de Gielz integratie in Hom Assistant installeren en in gebruik nemen. Na de installatie de instellingen in de Gielz integratie goed zetten bekijk daar ook even het maximale laad/ontlaad vermogen. De Zendure app heb je verder eigenlijk niet nodig behalve voor firmware upgrades.

[ Voor 6% gewijzigd door R1chardTM op 14-05-2026 12:27 ]

[Mscroos]

Vandaag de situatie gehad dat 1 van de units een commando heeft gemist volgens mij... Ik keek in HA en zag daar dat ik continue aan het ontladen was. de mode stond op smart balancing. in het screenshot zie je dat de commandos van Gielz een tijdje hingen of zo..? zie het tijdsverschil tussen regel 3 en 2 in de logs.. HA liep gewoon. Iemand een idee?


hier zie je een relatief groot blok die op iets meer als 1000 stond te ontladen in de smart modus...




en hier zie je dat 1 accu vrij veel ontladen is.....

[gast777]

Laatste was 2:59:15 discharging balancing naar 0 Watt. Daarna geen opdrachten meer vanuit Gielz.

En je zit in Smart Matching mode, die dus gebaseerd is op je energiemeter shellypro in dit geval.

Ik zou even checken of de shellypro wel data heeft doorgegeven die periode.

[Pakhaas]

Ik heb 2x 2400AC met 2x3 batterijen. Dit stuur ik aan met @gielz Gielz en de Proxy van @gast777
Vandaag zag ik dat de ene omvormer al bij 60% werd geknepen. Met de debug proxy zag ik dat alles wel goed stond om maximaal te laden (2400w) maar de ene deed dat niet. Beide omvormers waren even warm tussen de 40 en 42 graden. Uiteindelijk is de omvormer die eerder begon te knijpen maar tot 92% gekomen binnen de goedkope kwartieren.

[Mscroos]

gast777 schreef op donderdag 14 mei 2026 @ 16:54:
Laatste was 2:59:15 discharging balancing naar 0 Watt. Daarna geen opdrachten meer vanuit Gielz.

En je zit in Smart Matching mode, die dus gebaseerd is op je energiemeter shellypro in dit geval.

Ik zou even checken of de shellypro wel data heeft doorgegeven die periode.

Shelly heeft gewoon data gegeven, is ook in de chart te zien. De home energy data werd gewoon doorgegeven. Het lijkt alsof hij op de voorlaatste waarde is blijven hangen.

[zagreus]

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]

Wat ik zelf gemerkt heb: af-en-toe een paar seconden wegvallen gebeurt (zal wel de WiFi zijn denk ik).

Maar daarbovenop: als ik de internet toegang van de zendure blokeer (in de router: drop alle uitgaande verkeer van MAC adres) dan heb ik elke ~10 minuten voor 10-50seconde geen response en dus unavailable. Geen idee waarom.

[gast777]

zagreus schreef op donderdag 14 mei 2026 @ 19:47:
[...]

Wat ik zelf gemerkt heb: af-en-toe een paar seconden wegvallen gebeurt (zal wel de WiFi zijn denk ik).

Maar daarbovenop: als ik de internet toegang van de zendure blokeer (in de router: drop alle uitgaande verkeer van MAC adres) dan heb ik elke ~10 minuten voor 10-50seconde geen response en dus unavailable. Geen idee waarom.

Dat was al eerder gemeld als een bekend probleem met SF2400+. Iemand meldde een workaround. Had met DNS lookups te maken geloof ik, maar moet je anders even zelf terugzoeken.

[ctrl-tab]

zagreus schreef op donderdag 14 mei 2026 @ 19:47:
[...]

Wat ik zelf gemerkt heb: af-en-toe een paar seconden wegvallen gebeurt (zal wel de WiFi zijn denk ik).

Maar daarbovenop: als ik de internet toegang van de zendure blokeer (in de router: drop alle uitgaande verkeer van MAC adres) dan heb ik elke ~10 minuten voor 10-50seconde geen response en dus unavailable. Geen idee waarom.

Is dit ook een issue voor ac2400? Staat nog op mijn lijstje om dicht te.zetten nl

[H3ras]

Bericht gewist wegens niet van toepassing.

[ Voor 98% gewijzigd door H3ras op 14-05-2026 22:50 ]

[Hippe Lip]

Ben(V) schreef op donderdag 14 mei 2026 @ 10:14:
Wat bedoel je precies met onderbrekingkjes, hoe lang zijn die en welk signaal bedoel je?

Bedenk dat wifi een shared medium is en dat daarom onderbrekingen normaal zijn, maar een Zendure is netwerk technisch gezien een enorm traag ding dus normale rssi fluctuaties zouden geen enkele invloed moeten hebben op de werking.

Nou, van de meeste signalen zie ik in HA een ‘normale’ grafiek, een voor het oog doorgetrokken lijn. Maar van de SoC van de Gielz bijvoorbeeld ziet dat er niet normaal uit. Dat zijn dus substantiële onderbrekingen. en dan heb ik het niet over het laatste stuk, want toen stond de boel gewoon even uit wegens werk hier.

Maar hoe zie ik nou wie dat veroorzaakt? In theorie kan het de Zendure zijn, de WiFi zijn en HA zijn. Ik kan dat onderscheid niet maken.

[koboy]

Hippe Lip schreef op donderdag 14 mei 2026 @ 23:51:
[...]

Nou, van de meeste signalen zie ik in HA een ‘normale’ grafiek, een voor het oog doorgetrokken lijn. Maar van de SoC van de Gielz bijvoorbeeld ziet dat er niet normaal uit. Dat zijn dus substantiële onderbrekingen. en dan heb ik het niet over het laatste stuk, want toen stond de boel gewoon even uit wegens werk hier.

Maar hoe zie ik nou wie dat veroorzaakt? In theorie kan het de Zendure zijn, de WiFi zijn en HA zijn. Ik kan dat onderscheid niet maken.

[Afbeelding]

Wat mij opvalt is dat de horizontale stukken er eigenlijk prima uitzien, maar dat het mis gaat op de schuine stukken. Hoe ziet het er uit als je maar 1 dataset (bijvoorbeeld stapel 1, of totaal) plot? Ik heb grafiek modules heel rare dingen zien doen in een product van 10k€+ per jaar aan licentie....

Blijven de onderbrekingen ook bij eenvoudige grafieken: wat gebeurt er als je een enkele stapel direct aanstuurt, dus zonder de proxy?

[BizzieBis]

koboy schreef op vrijdag 15 mei 2026 @ 00:08:
[...]

Wat mij opvalt is dat de horizontale stukken er eigenlijk prima uitzien, maar dat het mis gaat op de schuine stukken. Hoe ziet het er uit als je maar 1 dataset (bijvoorbeeld stapel 1, of totaal) plot? Ik heb grafiek modules heel rare dingen zien doen in een product van 10k€+ per jaar aan licentie....

Blijven de onderbrekingen ook bij eenvoudige grafieken: wat gebeurt er als je een enkele stapel direct aanstuurt, dus zonder de proxy?

Dat de horizontale stukken er prima uitzien komt door Home Assistant zelf. Als er een periode geen veranderingen plaatsvinden in de data dan trekt ie daar een mooie rechte lijn.

[Hippe Lip]

koboy schreef op vrijdag 15 mei 2026 @ 00:08:
Hoe ziet het er uit als je maar 1 dataset (bijvoorbeeld stapel 1, of totaal) plot?

Dan ziet het er echt niet anders uit…

[Mistraller]

Jules52 schreef op donderdag 14 mei 2026 @ 12:10:
Graag advies. Ik wil een 2400AC+ plus AB3000L module via de Gielz code integreren in Home Assistant. Daarin zitten al mijn pv installatie, laadpaal, DSMR etc. Heb ik nu goed begrepen dat ik eerst de nieuwe 2400AC+ middels de Zendure app moet aanmelden, het laad/ontlaad vermogen in deze app moet begrenzen en vervolgens HEMS moet 'disablen'. Hierna pas starten met stap 1 en 2 van de Gielz installatie instructie. Ik heb geen extra P1 dongle. De data is al beschikbaar via een seriële verbinding en de DSMR integratie. Morgen worden de Zendure modules geleverd. Ik ga ze in eerste instantie via een stopcontact in de garage verbinden. Later komt er wel een extra groep bij.

Vermogen hoef je in de app niet eens in te stellen.

Ik heb zelf ook geen dongle maar idd gewoon een ftdi kabel. Ik had alleen nog geen sensor met bruikbare waardes voor de integratie maar met een helper zo gefixed.

code:

{% set consumption = states('sensor.electricity_meter_energieverbruik') | float(0) %}
{% set production = states('sensor.electricity_meter_energieproductie') | float(0) %}
{{ (consumption - production) * 1000 }}

De naam van die helper sensor voeg je in "afwijkende P1 sensor" toe en dan werkt het.
Let erop dat je de P1 data vaak genoeg ververst. Kan je in de DSMR integratie instellen.

[Ben(V)]

Hippe Lip schreef op vrijdag 15 mei 2026 @ 01:21:
[...]

Dan ziet het er echt niet anders uit…

[Afbeelding]

Je kunt een pingplotter op je PC installeren en die een tijdje laten lopen.
Dan kun je zien of het een netwerk (inclusief wifi) probleem is.
Als het een netwerk probleem is zie je daarin ook gaten ontstaan.

https://ping-plotter.en.softonic.com/

[ Voor 5% gewijzigd door Ben(V) op 15-05-2026 11:03 ]

[DeadMetal]

Vanochtend zijn er 2 dingen veranderd in mijn setup:
- er is een upgrade geïnstalleerd van de Node-RED HA app (addon), 21.0.10 - lijkt me irrelevant want er werd enkel een package bijgewerkt die ik niet gebruik
- ik had in mijn router de internettoegang geblokkeerd van de Zendures (leek me niet meer nodig, alles wordt lokaal aangestuurd door de gielz via de gast777)

Plotseling heb ik het probleem dat alle entiteiten regelmatig naar unavailable gaan, elke paar minuten.
Ik heb de internettoegang weer toegestaan in de router, en spontaan is het weer opgelost.

Viel dit te verwachten?

[denneappel]

Ben(V) schreef op vrijdag 15 mei 2026 @ 11:03:
[...]

Je kunt een pingplotter op je PC installeren en die een tijdje laten lopen.
Dan kun je zien of het een netwerk (inclusief wifi) probleem is.
Als het een netwerk probleem is zie je daarin ook gaten ontstaan.

https://ping-plotter.en.softonic.com/

Ik zou het makkelijk houden en de Ping integratie van Home Assistant even aanzetten: https://www.home-assistant.io/integrations/ping/

[koboy]

Hippe Lip schreef op vrijdag 15 mei 2026 @ 01:21:
[...]

Dan ziet het er echt niet anders uit…

[Afbeelding]

Dit maakt het een stuk duidelijker, maar laat ook zien dat de gaten komen doot een glitch of verkeerd grafiektype/instelling. Ik zie allemaal stipjes op gelijke afstand, maar op 1 of andere manier lijkt het alsof alleen op de meest verticale stukken een streepje wordt getrokken.

Dat wil niet zeggen dat alles soepel loopt bij je. Een paar dagen geleden liet je zien dat het laden bij dynamisch handelen ontzettend hakkelend verliep, terwijl het ontladen mooi gelijkmatig ging.

[YvonneVP]

Hippe Lip schreef op woensdag 13 mei 2026 @ 10:15:
[...]

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.

Heb ik nooit last van. Hij pakt bij mij altijd het punt met het sterkste Wifi signaal, en ik heb geen mesh in mijn huis. Wel 3 etages, en veel beton.

[Hippe Lip]

koboy schreef op vrijdag 15 mei 2026 @ 11:11:
Dit maakt het een stuk duidelijker, maar laat ook zien dat de gaten komen doot een glitch of verkeerd grafiektype/instelling. Ik zie allemaal stipjes op gelijke afstand, maar op 1 of andere manier lijkt het alsof alleen op de meest verticale stukken een streepje wordt getrokken.

Die duidelijkheid is schijn. Hier zie je het resultaat als ik de grafiek wat uit elkaar trek. Soms wordt een heel trapje ononderbroken getoond, meestal ontbreken er stukken.

Dat wil niet zeggen dat alles soepel loopt bij je. Een paar dagen geleden liet je zien dat het laden bij dynamisch handelen ontzettend hakkelend verliep, terwijl het ontladen mooi gelijkmatig ging.

Dat hield me ook bezig en ik snap het verschil ook nog niet.
Zeker als de indicator van Gielz (en dus Zendure) zegt dat de signal strength sterk of excellent is, maar ik die dan toch zo nu en dan eventjes zie verspringen.
Ik beschik niet over de benodigde apparatuur daarvoor, maar ik zou het radiospectrum daar boven bij de batterijen wel eens willen analyseren.

[Ben(V)]

Instaleer een wifi analyzer op je telefoon, daar krijg je ook al veel info van.

[koboy]

Hippe Lip schreef op vrijdag 15 mei 2026 @ 11:34:
[...]

Die duidelijkheid is schijn. Hier zie je het resultaat als ik de grafiek wat uit elkaar trek. Soms wordt een heel trapje ononderbroken getoond, meestal ontbreken er stukken.

[Afbeelding]

[...]

Dat hield me ook bezig en ik snap het verschil ook nog niet.
Zeker als de indicator van Gielz (en dus Zendure) zegt dat de signal strength sterk of excellent is, maar ik die dan toch zo nu en dan eventjes zie verspringen.
Ik beschik niet over de benodigde apparatuur daarvoor, maar ik zou het radiospectrum daar boven bij de batterijen wel eens willen analyseren.

Juist omdat het ontladen wel soepel loopt heb ik eerder het idee dat het probleem niet in de wifi ligt.

Kun je een dag testen met maar 1 toren gekoppeld aan Gielz zonder de proxy te gebruiken? Dus met het IP adres van die toren in Gielz en niet het IP van de proxy?

Ongetwijfeld al een keer gedeeld, maar bij mij niet meer paraat: waarop draai je HA en de proxy? Wat voor slimme meter heb je? Zit de HA machine bedraad in het netwerk?

[KiberHD]

Vandaag zag ik dit, batterij 1 geeft onbalans aan. Kijk ik in de history dan valt mij op dat hij vanacht uitstekend was en naarmate de batterij verder werd opgeladen ging de status naar goed, lichte onbalans, onbalans. Error status geeft geen error aan en batterijspanning is 52V. Iemand een idee hoe ik erachter kom hoe groot deze onbalans is en of dit nu al reden voor aktie is?

[R1chardTM]

KiberHD schreef op vrijdag 15 mei 2026 @ 12:51:
[Afbeelding]

Vandaag zag ik dit, batterij 1 geeft onbalans aan. Kijk ik in de history dan valt mij op dat hij vanacht uitstekend was en naarmate de batterij verder werd opgeladen ging de status naar goed, lichte onbalans, onbalans. Error status geeft geen error aan en batterijspanning is 52V. Iemand een idee hoe ik erachter kom hoe groot deze onbalans is en of dit nu al reden voor aktie is?

Na het opladen is de batterij in onbalans, dat is normaal. Het BMS (Batterij Management Systeem) gaat de batterij rustig aan balanceren. Als jouw batterij de afgelopen tijd op uitstekend heeft gestaan zal die nu uiteindelijk ook wel weer op uitstekend uitkomen duurt alleen even. Je moet dit gegeven meer lange termijn zien, als die op een gegeven moment nooit meer op uitstekend komt is je batterij kwaliteit verslechterd.

[KiberHD]

R1chardTM schreef op vrijdag 15 mei 2026 @ 12:59:
[...]

Na het opladen is de batterij in onbalans, dat is normaal. Het BMS (Batterij Management Systeem) gaat de batterij rustig aan balanceren. Als jouw batterij de afgelopen tijd op uitstekend heeft gestaan zal die nu uiteindelijk ook wel weer op uitstekend uitkomen duurt alleen even. Je moet dit gegeven meer lange termijn zien, als die op een gegeven moment nooit meer op uitstekend komt is je batterij kwaliteit verslechterd.

Bedankt! Ik ga het in de gaten houden.

[BizzieBis]

DeadMetal schreef op vrijdag 15 mei 2026 @ 11:05:
Vanochtend zijn er 2 dingen veranderd in mijn setup:
- er is een upgrade geïnstalleerd van de Node-RED HA app (addon), 21.0.10 - lijkt me irrelevant want er werd enkel een package bijgewerkt die ik niet gebruik
- ik had in mijn router de internettoegang geblokkeerd van de Zendures (leek me niet meer nodig, alles wordt lokaal aangestuurd door de gielz via de gast777)

Plotseling heb ik het probleem dat alle entiteiten regelmatig naar unavailable gaan, elke paar minuten.
Ik heb de internettoegang weer toegestaan in de router, en spontaan is het weer opgelost.

Viel dit te verwachten?

Wellicht heeft de Zendure een watchdog functionaliteit ingebouwd die berust op pingen van de clouddiensten. Ping timeout? -> herstart controller.

[gast777]

Zie deze post. Is je DNS server een lokaal IP adres of op het internet?

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

[Henkoes]

gast777 schreef op vrijdag 15 mei 2026 @ 13:20:
Zie deze post. Is je DNS server een lokaal IP adres of op het internet?

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

Wel storend. We zijn dus niet compleet onafhankelijk van Zendure mochten ze ooit omvallen

[gast777]

Henkoes schreef op vrijdag 15 mei 2026 @ 14:22:
[...]

Wel storend. We zijn dus niet compleet onafhankelijk van Zendure mochten ze ooit omvallen

Misschien is dit een bug en kan nog door Zendure worden opgelost. Dan moet er wel een ticket bij Zendure voor worden aangemaakt door iemand die hier tegenaan loopt.

[Hippe Lip]

Mijn probleem van niet goed laden is toch wel vreemd.

Eerst zet ik de Gielz op Quick charge. Dan wordt er strak geladen.
Om 13:00 uur zet ik ‘m op Dynamic trading. Dat is tijdens de goedkope periode. Precies vanaf dat moment krijg ik de hakkels in het laden alsof er iets gevolgd wordt.

@gielz, wat kan hier aan de hand zijn? Waarom verschillen die twee modi?

[ Voor 3% gewijzigd door Hippe Lip op 15-05-2026 15:14 ]

[metalmarco]

Wat me opvalt, is dat er meerdere mensen soms last hebben van uitval van wifi. En dat het meestal gebruikers zijn van een tp-link deco. Ook ik heb het, en heb hier al verschillende dingen geprobeerd. Nu staat 1 van de mesh routers nog geen meter van de zendures af. Deze is nu niet via een backhaul verbonden. Maar nog af en toe dat hij even 1-2 seconden "unavailble" aangeeft en dan weer terug is en dit is zoals door meerderen aangeven héél wisselend. Soms na 2 uur, somds na 18 uur. Dus vermoed dat er toch iets is tussen de zendure en de tp-link aansturing wat botst.

Zelf hier een Xe75pro in gebruik.

[KiberHD]

metalmarco schreef op vrijdag 15 mei 2026 @ 15:13:
Wat me opvalt, is dat er meerdere mensen soms last hebben van uitval van wifi. En dat het meestal gebruikers zijn van een tp-link deco. Ook ik heb het, en heb hier al verschillende dingen geprobeerd. Nu staat 1 van de mesh routers nog geen meter van de zendures af. Deze is nu niet via een backhaul verbonden. Maar nog af en toe dat hij even 1-2 seconden "unavailble" aangeeft en dan weer terug is en dit is zoals door meerderen aangeven héél wisselend. Soms na 2 uur, somds na 18 uur. Dus vermoed dat er toch iets is tussen de zendure en de tp-link aansturing wat botst.

Zelf hier een Xe75pro in gebruik.

Ik gebruik zelf ook tp-link deco en heb 0 problemen. Ik moet er wel bij zeggen dat ze enkel als access-point fungeren dus de wifi en geen enkele DHCP zaken voor zich nemen. Daar heb ik een omada vpn router voor.
Wat misschien kan helpen is de Zendure te binden aan een access point zodat deze niet constant gaat switchen.

[metalmarco]

KiberHD schreef op vrijdag 15 mei 2026 @ 15:20:
[...]

Ik gebruik zelf ook tp-link deco en heb 0 problemen. Ik moet er wel bij zeggen dat ze enkel als access-point fungeren dus de wifi en geen enkele DHCP zaken voor zich nemen. Daar heb ik een omada vpn router voor.
Wat misschien kan helpen is de Zendure te binden aan een access point zodat deze niet constant gaat switchen.

Hier ook als accespoint en achter een switch die weer aan een fritz router zit, die de DHCP regelt. En ze staan al in een eigen IOT netwerk, alle "auto" staan uit (dus vast gepind op 2.4 ghz en op vaste deco). Tevens beam en roaming ook allemaal uit.

[Hippe Lip]

Ik heb de SSID van een accesspoint dat bekabeld aan een Fritzbox zit (mesh, volgens AVM) het 2,4 GHz-kanaal een andere naam gegeven en daaraan de twee stacks (2400AC+) gekoppeld. Nu weet ik zeker waaraan ze hangen en dat ze niet switchen.
En de Gielz zegt dat de WIFI Signal Strength Excellent is.

Tóch zie ik onderbrekingen. De ene keer kort …

… en anderhalve minuut later een stuk langer.

Wie weet waar dat nu aan kan liggen?
@gielz misschien?

[ Voor 19% gewijzigd door Hippe Lip op 15-05-2026 16:25 ]

[oeps]

Hi all,

Even zitten pielen om aanvullende grafiek te maken. Zwaar geïnspireerd op de bestaande Gielz grafieken waar je een 24 uur periode kunt kiezen om te bekijken.

Waarom? Ik wilde het volgende:

• Batterijpercentage ook in de grafiek (is nu verborgen in de bestaande Gielz grafiek). Met wat trucs heb ik ervoor gezorgd dat het batterijpercentage altijd in de onderste kwart van de grafiek leeft. Kan volgens mij ook op andere manieren met Apex-chart. Moet ik nog naar kijken.
• Makkelijk te knippen en plakken voor hergebruik (buren vragen naar ervaringen en de zin/onzin van een grote/kleine batterij is makkelijker te bespreken met een plaatje van de diverse dagen (zonnig, bewolkt, Warmtepomp aan/uit, etc, etc).
• Ik wilde het minimum en maximum percentage van de batterij erbij hebben. Dat kan niet met een 'brush' grafiek over 7 dagen omdat dan de min/max altijd over die periode worden getoond in plaats van de zichtbare periode. Daarom een datum selectie gemaakt.
• De teksten in de grafieken wat groter gemaakt, makkelijker leesbaar op een groot scherm of document/presentatie. Eenheden toegevoegd.
• Er zit wat code in om de geselecteerde datum te kunnen hergebruiken in de titel.

Niet gelukt:

• De maximum en minimum waarde van de linker y-as is hardcoded op 4000W. Het is me niet gelukt om dit dynamisch te maken. Helaas werken de y-as IDs niet goed in Apex-chart. Die worden min of meer genegeerd en je moet je y-assen definiëren in dezelfde volgorde als je de entiteiten opneemt in de grafiek. Helaas kun je niet twee entiteiten aan één y-as ID koppelen. Heb het gepoogd uit te rekenen met additionele code (met beperking: geen nieuwe entiteiten introduceren) maar het min en max uitrekenen voor de geselecteerde periode lukt me niet (geen kenner op dit gebied).
• Mooie code, mijn lokale qwen3.6 coding heeft me best goed geholpen.
• Niet echt bruikbaar op kleine schermen. Ik heb de hoogte van de grafiek (height: 700) aangepast op mijn 4k laptopscherm zodat scrollen niet nodig is.

Gebruiken om verder te pielen?

• Let op, ik heb dit gemaakt op basis van de Engelse versie (sorry, soort beroepsdeformatie uit het verleden)
• Maak een datum selector, ga naar Settings - Devices & Services - Helpers.
• Create helper - Klik op 'Date and/or time' in de lijst.
• Name: Chart date selector (een andere naam kan natuurlijk maar dan moet je dat ook in de dashboard code aanpassen). De entiteitnaam moet dan 'input_datetime.chart_date_selector' heten.
• Icon: mdi:calender-ouline. Elke andere is natuurlijk ook goed.
• What do you want to input: Date.
• Create.

Maak een extra tab aan in een bestaand dashboard.

• Selecteer het dashboard waar je de tab wilt toevoegen.
• Klik op het potlood icon (edit dashboard).
• Klik op ＋ naast de bestaande tabs.
• Klik op het hamburger menu ⋮ en kies edit in YAML.
• Kopieer de code en plak het het veld, vervang de bestaande stub code.
• Save en als het goed is werkt het direct.

De code:

YAML:

title: Batterijstatus in het verleden
path: energy-details
type: sections
sections:
  - cards:
      - type: entities
        title: Selecteer grafiekdatum
        entities:
          - entity: input_datetime.chart_date_selector
            name: " "
            icon: mdi:calendar
        show_header_toggle: false
        state_color: true
        grid_options:
          columns: 12
          rows: auto
  - cards:
      - type: heading
        heading: ""
      - type: custom:config-template-card
        layout_options:
          grid_columns: full
        entities:
          - input_datetime.chart_date_selector
        variables:
          - |
            (() => {
              const sel = new Date(states['input_datetime.chart_date_selector'].state);
              sel.setHours(0,0,0,0);
              const today = new Date();
              today.setHours(0,0,0,0);
              const diffMs = sel.getTime() - today.getTime();
              const diffDays = diffMs / 86400000;
              if (Math.abs(diffDays) < 0.1) return '+0m';
              return diffDays + 'd';
            })()
          - |
            (() => {
              const d = new Date(states['input_datetime.chart_date_selector'].state);
              const monthNames = ['januari','februari','maart','april','mei','juni','juli','augustus','september','oktober','november','december'];
              return '24 uur uit het leven van een thuisbatterij op ' + d.getDate() + ' ' + monthNames[d.getMonth()] + ' ' + d.getFullYear();
            })()
        card:
          type: custom:apexcharts-card
          experimental:
            hidden_by_default: true
            color_threshold: true
          cache: true
          update_interval: 10min
          stacked: true
          graph_span: 24h
          span:
            start: day
            offset: ${vars[0]}
          series:
            - entity: sensor.zendure_power
              name: Batterij, +ontladen of -laden
              extend_to: now
              yaxis_id: energy1
              statistics:
                period: 5minute
                type: mean
                align: start
              type: area
              transform: return -x;
              show:
                in_brush: true
                in_header: false
                in_legend: true
                legend_value: false
              stroke_width: 2
              opacity: 0.35
              color: "#11a180"
              float_precision: 0
              color_threshold:
                - value: -2000
                  opacity: 0.5
                - value: -1750
                  opacity: 0.45
                - value: -1500
                  opacity: 0.4
                - value: -1250
                  opacity: 0.35
                - value: -1000
                  opacity: 0.3
                - value: -750
                  opacity: 0.25
                - value: -500
                  opacity: 0.15
                - value: 0
                  opacity: 0.1
                - value: 500
                  opacity: 0.15
                - value: 750
                  opacity: 0.25
                - value: 1000
                  opacity: 0.3
                - value: 1250
                  opacity: 0.35
                - value: 1500
                  opacity: 0.4
                - value: 1750
                  opacity: 0.45
                - value: 2000
                  opacity: 0.5
            - entity: sensor.home_energy_meter_target
              name: Elektriciteitsnet, +gebruiken, -leveren
              statistics:
                period: 5minute
                type: mean
                align: start
              type: area
              stroke_width: 0
              opacity: 0.5
              extend_to: now
              color: "#c0c0c2"
              float_precision: 0
              yaxis_id: energy2
              show:
                in_brush: true
                in_header: false
                in_legend: true
                legend_value: false
            - entity: sensor.zendure_total_state_of_charge
              name: Batterij vullingspercentage
              statistics:
                period: 5minute
                type: max
                align: start
              type: line
              curve: smooth
              stroke_width: 1
              opacity: 1
              extend_to: now
              color: var(--accent-color)
              float_precision: 0
              yaxis_id: percentage
              show:
                in_header: false
                in_legend: true
                extremas: true
                legend_value: false
          apex_config:
            title:
              text: ${vars[1]}
              align: left
              margin: 20
              style:
                fontSize: 18px
                fontWeight: bold
                color: var(--primary-text-color)
            chart:
              height: 700
            legend:
              show: true
              floating: false
              horizontalAlign: left
              fontSize: 16px
            xaxis:
              type: datetime
              labels:
                format: HH:mm
                style:
                  fontSize: 16px
            yaxis:
              - id: energy1
                min: -4000
                max: 4000
                tickAmount: 8
                title:
                  text: +Gebruik, -Leveren (Watt)
                  style:
                    fontSize: 18px
                    fontWeight: 400
                decimalsInFloat: 0
                labels:
                  style:
                    colors: >-
                      color-mix(in srgb, var(--primary-text-color) 85%,
                      transparent)
                    fontSize: 16px
              - id: energy2
                show: false
                min: -4000
                max: 4000
              - id: percentage
                opposite: true
                min: 0
                max: 700
                tickAmount: 28
                decimalsInFloat: 0
                title:
                  text: >-
                    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
                    Batterij
                  style:
                    fontSize: 16px
                    fontWeight: 400
                    color: var(--accent-color)
                labels:
                  style:
                    fontSize: 16px
                    colors: var(--accent-color)
                  formatter: |
                    EVAL:function(value) {
                      if (value <= 100) return value + '%';
                      return '';
                    }
        view_layout:
          position: main
    column_span: 4
cards: []
max_columns: 4
icon: mdi:battery-clock-outline

[ Voor 0% gewijzigd door oeps op 15-05-2026 17:10 . Reden: [quote] leren toepassen :-) ]

[Hippe Lip]

koboy schreef op vrijdag 15 mei 2026 @ 11:51:
Juist omdat het ontladen wel soepel loopt heb ik eerder het idee dat het probleem niet in de wifi ligt.

Dat idee heb ik ook steeds meer, @koboy. Mijn gevoel zegt dat het ergens in de (niet-wifi) communicatie zit. Binnen de Gielz, binnen de proxy of de communicatie tussen die twee.
Zie ook mijn video’s hierboven, waar je ziet dat de WiFi Signal Strength echt perfect is en er tóch even (kort of iets langer) een onderbreking is.

Kun je een dag testen met maar 1 toren gekoppeld aan Gielz zonder de proxy te gebruiken? Dus met het IP adres van die toren in Gielz en niet het IP van de proxy?

Das wel een goed idee. Ga ik morgen doen, want de batterijen zijn net nokkie vol geladen om vanavond weer te spuien.
Daarna kan ik eens omschakelen.

Ongetwijfeld al een keer gedeeld, maar bij mij niet meer paraat: waarop draai je HA en de proxy?

Ik heb de batterijen gekocht om me voor te bereiden op de komende salderingsloze tijd; eerst eens ervaring mee opdoen.
Na aanschaf en installatie heb ik eerst de app van Zendure gebruikt, maar die heeft niet de functionele capaciteiten die ik graag zou hebben. Dat heeft @gielz een stuk beter voor elkaar.
En de proxy omdat ik twee torens (2x 2400AC+ met elk 3 extra batterijen eronder) heb. Dan stuur je ze samen als één aan.

Wat voor slimme meter heb je?

Ik heb een DSMR4-meter (dus elke 10s een telegram) en heb daarom speciaal voor deze batterijen een Shelly Pro 3EM geïnstalleerd. Die is bedraad op het LAN aangesloten, dus daar zal ik geen communicatieproblemen hebben.
Ik had een DSMR5-meter aangevraagd en de afspraak voor de wissel was al gemaakt, maar die heb ik weer afgezegd, want het draait als een zonnetje met die Shelly. Dat spaart me kosten en gedoe met allerlei registraties die dan de hik krijgen vanwege niet-aansluitende meterstanden.

Zit de HA machine bedraad in het netwerk?

Yep. HA draait hier op een Odroid N2+ die bedraad is aangesloten.

[roawser]

zagreus schreef op donderdag 14 mei 2026 @ 19:47:
[...]:als ik de internet toegang van de zendure blokeer

Verdraaid, dat heb ik ook. Dan ga ik toch eens kijken wat er gebeurt als ik 'm weer even loslaat.

[Hippe Lip]

oeps schreef op vrijdag 15 mei 2026 @ 16:41:
Hi all,

Even zitten pielen […]

Tip voor @oeps:
Als je die yaml-code in een quote (tussen [quote] en [/quote]) opneemt, dan krijg je niet zo’n ellelange post.

[oeps]

Hippe Lip schreef op vrijdag 15 mei 2026 @ 16:58:
[...]

Tip voor @oeps:
Als je die yaml-code in een quote (tussen [quote] en [/quote]) opneemt, dan krijg je niet zo’n ellelange post.

Dank! aangepast.
Had zelfs even door UBB zitten scrollen maar blijkbaar niet goed genoeg.

[Hippe Lip]

oeps schreef op vrijdag 15 mei 2026 @ 17:11:
[...]

Dank! aangepast.
Had zelfs even door UBB zitten scrollen maar blijkbaar niet goed genoeg.

@oeps
UBB?

[oeps]

Hippe Lip schreef op vrijdag 15 mei 2026 @ 17:12:
[...]

@oeps
UBB?

FAQ -GoT

[gielz]

Hippe Lip schreef op vrijdag 15 mei 2026 @ 15:13:
Mijn probleem van niet goed laden is toch wel vreemd.

Eerst zet ik de Gielz op Quick charge. Dan wordt er strak geladen.
Om 13:00 uur zet ik ‘m op Dynamic trading. Dat is tijdens de goedkope periode. Precies vanaf dat moment krijg ik de hakkels in het laden alsof er iets gevolgd wordt.

@gielz, wat kan hier aan de hand zijn? Waarom verschillen die twee modi?

[Afbeelding]

[Afbeelding]

Quick Charge en een Dynamische cyclus zijn totaal anders. Bij Quick Charge is het gewoon een domme actie "ga nu volladen" en bij een Dynamische cyclus gaat hij de cyclus opnieuw starten als er verandering is in de batterij;


Voor de volgende release zit hier een wijziging in;

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

Dit los wellicht deels je probleem op. Maar als een Zendure constant zijn netwerk verliest dan zou ik niet wachten op fixes van buiten af maar gewoon dit in huis gaan fixen.

[Hippe Lip]

gielz schreef op vrijdag 15 mei 2026 @ 17:39:
Quick Charge en een Dynamische cyclus zijn totaal anders. Bij Quick Charge is het gewoon een domme actie "ga nu volladen" en bij een Dynamische cyclus gaat hij de cyclus opnieuw starten als er verandering is in de batterij;
[Afbeelding]

OK, da’s duidelijk dan.

Voor de volgende release zit hier een wijziging in;

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

Dit los wellicht deels je probleem op. Maar als een Zendure constant zijn netwerk verliest dan zou ik niet wachten op fixes van buiten af maar gewoon dit in huis gaan fixen.

Daar kijk ik dan toch naar uit, @gielz. Zeker omdat ik al liet zien dat ik echt plotselinge onderbrekingen heb. Soms kort, soms 10-12s en die worden dan wel mooi overbrugd.
Heb je die post daarover gezien? Ik ben benieuwd naar je reactie daarop.

En morgen ga ik op voorstel van @koboy de proxy er even tussenuit halen om te zien of dat verschil maakt, want ik betwijfel of het de WiFi is. De verbinding springt van Excellent naar Unavailable en weer naar Excellent. Dat lijkt toch niet op WiFi-problemen?

[YvonneVP]

Hippe Lip schreef op vrijdag 15 mei 2026 @ 11:34:
[...]

Die duidelijkheid is schijn. Hier zie je het resultaat als ik de grafiek wat uit elkaar trek. Soms wordt een heel trapje ononderbroken getoond, meestal ontbreken er stukken.

[Afbeelding]

[...]

Dat hield me ook bezig en ik snap het verschil ook nog niet.
Zeker als de indicator van Gielz (en dus Zendure) zegt dat de signal strength sterk of excellent is, maar ik die dan toch zo nu en dan eventjes zie verspringen.
Ik beschik niet over de benodigde apparatuur daarvoor, maar ik zou het radiospectrum daar boven bij de batterijen wel eens willen analyseren.

Dergelijke grafieken heb ik ook al eens gehad met het standaard thema van HA, en dat was meer een grafiek dingetje waarin de weergave gewoon niet netjes was. Ik heb nu een ander thema voor mijn layout en zie dat gehakkel niet meer. Kun je dus eens proberen om het thema van de Gielz dashboard naar Graphite te zetten, en als je die nog niet in je HA hebt zitten via HACS toe te voegen en dan je dashboard op Graphite zetten om te kijken of je dan wel de grafiek zonder hakkeltjes ziet?

[DeadMetal]

gast777 schreef op vrijdag 15 mei 2026 @ 13:20:
Zie deze post. Is je DNS server een lokaal IP adres of op het internet?

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

Mijn DNS-server is lokaal, Adguard Home die als HA-app (addon) draait.

[gielz]

Hippe Lip schreef op vrijdag 15 mei 2026 @ 17:48:
[...]

OK, da’s duidelijk dan.

[...]

Daar kijk ik dan toch naar uit, @gielz. Zeker omdat ik al liet zien dat ik echt plotselinge onderbrekingen heb. Soms kort, soms 10-12s en die worden dan wel mooi overbrugd.
Heb je die post daarover gezien? Ik ben benieuwd naar je reactie daarop.

En morgen ga ik op voorstel van @koboy de proxy er even tussenuit halen om te zien of dat verschil maakt, want ik betwijfel of het de WiFi is. De verbinding springt van Excellent naar Unavailable en weer naar Excellent. Dat lijkt toch niet op WiFi-problemen?

Ik zou het eerst even zonder proxy proberen dan kun je iig kijken of het je proxy (node-red) integratie is die problemen veroorzaakt.

[hemertje]

Update t.o.v. de eerdere versie

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

# ============================================================
# Zendure Inverter Cooling Dashboard
# Werkt met: Gielz1986/Zendure-HA-zenSDK + gast777/Zendure-zenSDK-proxy (EN)
# ============================================================
# Vereiste helpers (maak deze 1× via Settings → Devices → Helpers,
# of plak het YAML-blok onderaan in een package file):
#
# input_number:
# zendure_cooling_temp_on (15..50 °C, default 35)
# zendure_cooling_temp_off (15..50 °C, default 30)
# zendure_cooling_on_delay (0..30 min, default 2)
# zendure_cooling_min_runtime (0..60 min, default 5)
# input_boolean:
# zendure_cooling_auto_mode (default on)
#
# Plus de bijbehorende automations om sockets aan/uit te schakelen
# o.b.v. inverter temperatuur (zie 2e blok onderaan).
# ============================================================

code:

type: vertical-stack
cards:
  - type: history-graph
    title: 🌡️ Zendure Inverter Koeling
    hours_to_show: 24
    refresh_interval: 60
    entities:
      - entity: sensor.zendure_1_inverter_temperature
        name: Inverter 1
      - entity: sensor.zendure_2_inverter_temperature
        name: Inverter 2
      - entity: sensor.zendure_3_inverter_temperature
        name: Inverter 3

  - type: entities
    entities:
      - entity: input_number.zendure_cooling_temp_on
        name: Fan AAN bij temp
        icon: mdi:fan-plus
      - entity: input_number.zendure_cooling_temp_off
        name: Fan UIT bij temp
        icon: mdi:fan-minus
      - entity: input_number.zendure_cooling_on_delay
        name: Wachttijd voor AAN
        icon: mdi:timer-sand
      - entity: input_number.zendure_cooling_min_runtime
        name: Min. looptijd
        icon: mdi:timer
      - entity: input_boolean.zendure_cooling_auto_mode
        name: AUTO modus (uit = handmatig)
        icon: mdi:auto-mode

      # Sockets — verbergen automatisch als de inverter niet bestaat
      - type: conditional
        conditions:
          - entity: sensor.zendure_1_inverter_temperature
            state_not: unavailable
        row:
          entity: switch.zendure_1_offgrid_socket
          name: Fan 1
          icon: mdi:power-socket-eu
      - type: conditional
        conditions:
          - entity: sensor.zendure_2_inverter_temperature
            state_not: unavailable
        row:
          entity: switch.zendure_2_offgrid_socket
          name: Fan 2
          icon: mdi:power-socket-eu
      - type: conditional
        conditions:
          - entity: sensor.zendure_3_inverter_temperature
            state_not: unavailable
        row:
          entity: switch.zendure_3_offgrid_socket
          name: Fan 3
          icon: mdi:power-socket-eu

En de bijbehorende helpers + automations package

code:

# /config/packages/zendure_cooling.yaml
input_number:
  zendure_cooling_temp_on:
    name: Zendure Cooling Temp ON
    min: 15
    max: 50
    step: 1
    initial: 35
    unit_of_measurement: "°C"
    icon: mdi:fan-plus
  zendure_cooling_temp_off:
    name: Zendure Cooling Temp OFF
    min: 15
    max: 50
    step: 1
    initial: 30
    unit_of_measurement: "°C"
    icon: mdi:fan-minus
  zendure_cooling_on_delay:
    name: Zendure Cooling ON Delay
    min: 0
    max: 30
    step: 1
    initial: 2
    unit_of_measurement: min
    icon: mdi:timer-sand
  zendure_cooling_min_runtime:
    name: Zendure Cooling Min Runtime
    min: 0
    max: 60
    step: 1
    initial: 5
    unit_of_measurement: min
    icon: mdi:timer

input_boolean:
  zendure_cooling_auto_mode:
    name: Zendure Cooling Auto Mode
    initial: true
    icon: mdi:auto-mode

input_datetime:
  zendure_cooling_started_1:
    has_date: true
    has_time: true
  zendure_cooling_started_2:
    has_date: true
    has_time: true
  zendure_cooling_started_3:
    has_date: true
    has_time: true

automation:
  # Fan AAN: temp boven threshold + delay verstreken + AUTO aan
  - alias: "Zendure Fan 1 - ON at temp"
    id: zendure_fan_1_on_temp
    mode: single
    trigger:
      - platform: numeric_state
        entity_id: sensor.zendure_1_inverter_temperature
        above: input_number.zendure_cooling_temp_on
        for:
          minutes: "{{ states('input_number.zendure_cooling_on_delay') | int(2) }}"
    condition:
      - condition: state
        entity_id: input_boolean.zendure_cooling_auto_mode
        state: "on"
      - condition: state
        entity_id: switch.zendure_1_offgrid_socket
        state: "off"
    action:
      - service: switch.turn_on
        target:
          entity_id: switch.zendure_1_offgrid_socket
      - service: input_datetime.set_datetime
        target:
          entity_id: input_datetime.zendure_cooling_started_1
        data:
          datetime: "{{ now() }}"

  # Fan UIT: temp onder threshold + min runtime verstreken
  - alias: "Zendure Fan 1 - OFF at temp"
    id: zendure_fan_1_off_temp
    mode: single
    trigger:
      - platform: numeric_state
        entity_id: sensor.zendure_1_inverter_temperature
        below: input_number.zendure_cooling_temp_off
    condition:
      - condition: state
        entity_id: input_boolean.zendure_cooling_auto_mode
        state: "on"
      - condition: state
        entity_id: switch.zendure_1_offgrid_socket
        state: "on"
      - condition: template
        value_template: >
          {% set started = states('input_datetime.zendure_cooling_started_1') %}
          {% set min_run = states('input_number.zendure_cooling_min_runtime') | int(5) %}
          {{ (now() - as_datetime(started)).total_seconds() / 60 >= min_run }}
    action:
      - service: switch.turn_off
        target:
          entity_id: switch.zendure_1_offgrid_socket

  # Herhaal hetzelfde patroon voor inverter 2 en 3
  # (dupliceer de 2 automations hierboven, vervang _1 door _2 / _3)

[hemertje]

Vraag aan andere Gielz-gebruikers:
krijgen jullie deze foutmelding ook elke keer dat Home Assistant opnieuw opstart?

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

Wat ik denk dat er gebeurt: Home Assistant kent het IP-adres van mijn Zendure en HomeWizard niet vanaf seconde nul, maar leest dat na een paar seconden in. Gielz vraagt ondertussen al elke seconde data op, en doet dat letterlijk naar "http://unknown/" — dat lukt natuurlijk niet. Zodra het echte IP-adres bekend is gaat alles wel goed, dus mijn batterij werkt prima, het zijn alleen 2 foutregels in het log.

Niet erg dus, maar wel rommelig in het log.
Herkent iemand dit?

En heeft iemand een nette manier om die 5 seconden te overbruggen, of is wachten op een Home Assistant update de enige weg?

[gielz]

hemertje schreef op vrijdag 15 mei 2026 @ 21:20:
Vraag aan andere Gielz-gebruikers:
krijgen jullie deze foutmelding ook elke keer dat Home Assistant opnieuw opstart?

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

Wat ik denk dat er gebeurt: Home Assistant kent het IP-adres van mijn Zendure en HomeWizard niet vanaf seconde nul, maar leest dat na een paar seconden in. Gielz vraagt ondertussen al elke seconde data op, en doet dat letterlijk naar "http://unknown/" — dat lukt natuurlijk niet. Zodra het echte IP-adres bekend is gaat alles wel goed, dus mijn batterij werkt prima, het zijn alleen 2 foutregels in het log.

Niet erg dus, maar wel rommelig in het log.
Herkent iemand dit?

En heeft iemand een nette manier om die 5 seconden te overbruggen, of is wachten op een Home Assistant update de enige weg?

Dit komt door de opstart volgorde van HA. Op GitHub heeft iemand dit op een simpele manier proberen op te lossen maar tot nu toe zonder plug-n-play resultaat; https://github.com/Gielz1986/Zendure-HA-zenSDK/issues/55

[hemertje]

Nog een vraag Giel...

krijgen je deze foutmelding ook elke keer dat Home Assistant opnieuw opstart, sinds de update naar Gielz v20260507?

"ZeroDivisionError: division by zero"
in entity 'sensor.zendure_indication_required_energy'

Wat ik denk dat er gebeurt: dit is een nieuwe sensor sinds v20260507. Die berekent hoeveel energie er nog nodig is om de batterij vol te laden, en deelt daarbij door de "effectieve efficiency" van de batterij. Bij het opstarten van Home Assistant is die efficiency-waarde nog nul (er is nog geen meet-data binnen), en delen door nul kan natuurlijk niet — vandaar de fout. Zodra er na een paar minuten echte efficiency-cijfers binnenkomen, werkt de sensor verder prima.

Niet erg dus, alleen 1 foutregel per herstart. Werking van de batterij wordt er niet door beïnvloed.

Een eenvoudige oplossing zou zijn om in de template eerst te checken of de efficiency wel groter is dan nul voordat de deling gedaan wordt — dan is de fout meteen weg. Vergelijkbaar met de "duurste_na_eerste_goedkope" template-bug die ik vorige week meldde.

Herkent iemand dit? En heeft iemand bezwaar als ik er een issue voor open op GitHub?

[hemertje]

gielz schreef op vrijdag 15 mei 2026 @ 21:26:
[...]


Dit komt door de opstart volgorde van HA. Op GitHub heeft iemand dit op een simpele manier proberen op te lossen maar tot nu toe zonder plug-n-play resultaat; https://github.com/Gielz1986/Zendure-HA-zenSDK/issues/55

@gielz
Bedankt voor de link naar issue #55 — gelezen, en de afweging snap ik volledig (veel extra code voor 1 logregel).

Ik heb Claude Code daarna nog laten kijken bij home-assistant/core of er al een feature request loopt voor dit gat in de REST integratie — niets gevonden.
Voor we er een open zouden willen we eerst checken of jullie (Gielz, andere ontwikkelaars die hiermee stoeien) zich kunnen vinden in de richting van de oplossing, want dit gat raakt veel community-integraties, niet alleen Zendure.

Claude Code zag twee mogelijke aanpakken die elkaar aanvullen:

Optie A — availability_template op REST block-niveau (opt-in). Net zoals command_line en template entities dat al hebben. Voordeel: declaratief, matcht bestaande HA conventie. Nadeel: vereist dat Gielz zijn package één regel update na de HA core release.

Optie B — silent skip wanneer resource_template ongeldig rendert (backwards-compatible). Als de URL leeg is of "unknown"/"unavailable" bevat, sla de poll stil over. Voordeel: bestaande Gielz/community-configs werken meteen schoon zonder enige aanpassing. Nadeel: kan oprechte config-fouten verbergen.

Voorstel van Claude Code: A + B combineren. B als snelle backstop voor iedereen, A als opt-in voor wie expliciete controle wil.

Vragen aan @gielz en andere ontwikkelaars:
vinden jullie deze richting logisch of zien jullie iets beters?

En bezwaar als we dit als feature request openen bij home-assistant/core, met verwijzing naar Gielz #55 als context?

[abaart]

Voor degenen die de proxy gebruiken en last hebben van uitval, dit GitHub issue is wellicht interessant om te volgen.
https://github.com/gast777/Zendure-zenSDK-proxy/issues/14

Het lijkt erop dat dit komt doordat de Zendure maar een beperkt aantal gelijktijdige HTTP connecties kan ondersteunen.

Met dank aan @gast777 voor het meedenken! Als dit inderdaad het probleem is dan is het een makkelijke fix

[gielz]

hemertje schreef op vrijdag 15 mei 2026 @ 21:40:
[...]


@gielz
Bedankt voor de link naar issue #55 — gelezen, en de afweging snap ik volledig (veel extra code voor 1 logregel).

Ik heb Claude Code daarna nog laten kijken bij home-assistant/core of er al een feature request loopt voor dit gat in de REST integratie — niets gevonden.
Voor we er een open zouden willen we eerst checken of jullie (Gielz, andere ontwikkelaars die hiermee stoeien) zich kunnen vinden in de richting van de oplossing, want dit gat raakt veel community-integraties, niet alleen Zendure.

Claude Code zag twee mogelijke aanpakken die elkaar aanvullen:

Optie A — availability_template op REST block-niveau (opt-in). Net zoals command_line en template entities dat al hebben. Voordeel: declaratief, matcht bestaande HA conventie. Nadeel: vereist dat Gielz zijn package één regel update na de HA core release.

Optie B — silent skip wanneer resource_template ongeldig rendert (backwards-compatible). Als de URL leeg is of "unknown"/"unavailable" bevat, sla de poll stil over. Voordeel: bestaande Gielz/community-configs werken meteen schoon zonder enige aanpassing. Nadeel: kan oprechte config-fouten verbergen.

Voorstel van Claude Code: A + B combineren. B als snelle backstop voor iedereen, A als opt-in voor wie expliciete controle wil.

Vragen aan @gielz en andere ontwikkelaars:
vinden jullie deze richting logisch of zien jullie iets beters?

En bezwaar als we dit als feature request openen bij home-assistant/core, met verwijzing naar Gielz #55 als context?

Denk zelf dat je bij HA zelf niet ver zult komen omdat het geen breaking bug is. Maar mocht je zelf een oplossing kunnen ontwikkelen dan hoor ik dat uiteraard graag.

[hemertje]

abaart schreef op vrijdag 15 mei 2026 @ 21:41:
Voor degenen die de proxy gebruiken en last hebben van uitval, dit GitHub issue is wellicht interessant om te volgen.
https://github.com/gast777/Zendure-zenSDK-proxy/issues/14

Het lijkt erop dat dit komt doordat de Zendure maar een beperkt aantal gelijktijdige HTTP connecties kan ondersteunen.

Met dank aan @gast777 voor het meedenken! Als dit inderdaad het probleem is dan is het een makkelijke fix

@abaart Net je analyse gelezen — top werk. Ik zie hetzelfde patroon in mijn logs (3x Zendure SolarFlow 2400 AC+ via Node-RED proxy v20260514): 3 uitval-momenten in de afgelopen 24 uur op 00:41, 03:19 en 08:35, telkens vielen alle ~30 Zendure-sensors tegelijk uit. Geen HA-restart op die momenten — past precies bij wat jij beschrijft.

Net keep-alive uitgezet op alle 11 http request nodes in de proxy flow (persist: false op zowel GET als POST naar de Zendures), Node-RED herstart, draait nu. Ga komende 24 uur opnieuw meten en laat hier weten of de uitval inderdaad verdwijnt.

Bedankt voor de root-cause analyse + de duidelijke test-matrix!

[koboy]

Hippe Lip schreef op vrijdag 15 mei 2026 @ 17:48:
[...]

OK, da’s duidelijk dan.

[...]

Daar kijk ik dan toch naar uit, @gielz. Zeker omdat ik al liet zien dat ik echt plotselinge onderbrekingen heb. Soms kort, soms 10-12s en die worden dan wel mooi overbrugd.
Heb je die post daarover gezien? Ik ben benieuwd naar je reactie daarop.

En morgen ga ik op voorstel van @koboy de proxy er even tussenuit halen om te zien of dat verschil maakt, want ik betwijfel of het de WiFi is. De verbinding springt van Excellent naar Unavailable en weer naar Excellent. Dat lijkt toch niet op WiFi-problemen?

Beetje mosterd na de maaltijd wellicht. @abaart heeft een paar posts wat info gedeeld over wegvallende zendures via de proxy en de oplossing daarvoor die hij met @gast777 heeft gevonden. In de issue log op Github wordt jij ook genoemd.

[hemertje]

gielz schreef op vrijdag 15 mei 2026 @ 21:55:
[...]


Denk zelf dat je bij HA zelf niet ver zult komen omdat het geen breaking bug is. Maar mocht je zelf een oplossing kunnen ontwikkelen dan hoor ik dat uiteraard graag.

Eerlijke inschatting, daar heb je gelijk in. Dit is geen kapotte boel maar gewoon wat lawaai in het log, en als niemand er nu een kant-en-klare code-oplossing naast legt zal het bij Home Assistant zelf inderdaad geen prioriteit krijgen.

Voor nu laat ik die twee regels in mijn log staan. Dank voor het meedenken en de eerlijkheid, het issue mag wat mij betreft dicht blijven.

[Hippe Lip]

YvonneVP schreef op vrijdag 15 mei 2026 @ 17:58:
Dergelijke grafieken heb ik ook al eens gehad met het standaard thema van HA, en dat was meer een grafiek dingetje waarin de weergave gewoon niet netjes was. Ik heb nu een ander thema voor mijn layout en zie dat gehakkel niet meer. Kun je dus eens proberen om het thema van de Gielz dashboard naar Graphite te zetten, en als je die nog niet in je HA hebt zitten via HACS toe te voegen en dan je dashboard op Graphite zetten om te kijken of je dan wel de grafiek zonder hakkeltjes ziet?

Graphite theme had ik er toevallig al op staan, maar nog nooit gebruikt.
Heb je een [code]voorbeeldje van een grafiekje voor me?
Snap ‘m nog niet zo.

[Pakhaas]

hemertje schreef op vrijdag 15 mei 2026 @ 22:10:
[...]


@abaart Net je analyse gelezen — top werk. Ik zie hetzelfde patroon in mijn logs (3x Zendure SolarFlow 2400 AC+ via Node-RED proxy v20260514): 3 uitval-momenten in de afgelopen 24 uur op 00:41, 03:19 en 08:35, telkens vielen alle ~30 Zendure-sensors tegelijk uit. Geen HA-restart op die momenten — past precies bij wat jij beschrijft.

Net keep-alive uitgezet op alle 11 http request nodes in de proxy flow (persist: false op zowel GET als POST naar de Zendures), Node-RED herstart, draait nu. Ga komende 24 uur opnieuw meten en laat hier weten of de uitval inderdaad verdwijnt.

Bedankt voor de root-cause analyse + de duidelijke test-matrix!

Ben benieuwd. Hou je ons op de hoogte?

[Hippe Lip]

koboy schreef op vrijdag 15 mei 2026 @ 22:15:
Beetje mosterd na de maaltijd wellicht. @abaart heeft een paar posts wat info gedeeld over wegvallende zendures via de proxy en de oplossing daarvoor die hij met @gast777 heeft gevonden. In de issue log op Github wordt jij ook genoemd.

Ik heb dat stuk op Github gelezen, maar kan het maar gedeeltelijk volgen. Sommige stukken gaan me boven de pet.

Is dat verschijnsel dat @abaart beschrijft hetzelfde als wat ik hierboven beschreef met twee filmpjes?

[Hippe Lip]

En vanavond gaat het ontladen probleemloos (stand: Dynamic trading) weer vlekkeloos

Vanmiddag (2e deel)!ging diezelfde dynamic trading bij het laden weer helemaal mis.
@gielz verschilt het laden en het ontladen erg in aantal commando’s?
Zou hier misschien (mogelijk, eventueel) het verschijnsel van @abaart kunnen spelen, of is dat niet erg waarschijnlijk?

[ Voor 3% gewijzigd door Hippe Lip op 15-05-2026 23:29 ]

[Mistraller]

koboy schreef op vrijdag 15 mei 2026 @ 22:15:
[...]

Beetje mosterd na de maaltijd wellicht. @abaart heeft een paar posts wat info gedeeld over wegvallende zendures via de proxy en de oplossing daarvoor die hij met @gast777 heeft gevonden. In de issue log op Github wordt jij ook genoemd.

Lijkt ook samen te hangen met wat ik aan mijn kant zag. Connection resets die van de zendure afkomen. Ben benieuwd wat hier uit komt!

[gielz]

Hippe Lip schreef op vrijdag 15 mei 2026 @ 23:27:
En vanavond gaat het ontladen probleemloos (stand: Dynamic trading) weer vlekkeloos

Vanmiddag (2e deel)!ging diezelfde dynamic trading bij het laden weer helemaal mis.
@gielz verschilt het laden en het ontladen erg in aantal commando’s?
Zou hier misschien (mogelijk, eventueel) het verschijnsel van @abaart kunnen spelen, of is dat niet erg waarschijnlijk?

[Afbeelding]

Nee het commando is identiek (1 start.commando). Er zijn ook tig gebruikers die de proxy gebruiken zonder problemen. Ik zou het eerst zonder node-red testen dan kun je iig dingen uitsluiten.

Het issue wat bij @gast777 openstaat is iig een lastige. Je moet eerst door een hele massa aan AI geneuzel lezen. Even via AI een issue maken en dan verwachten dat @gast777 het maar even fixt…

De meeste van dat soort issues verdwijnen in de prullenbak omdat de aangemaakte gebruiker na het vragen om dingen te testen als AI bot blijft reageren in de “wij” vorm.

Dit zie je omdat er gesproken word over acmode=0 wat niet bestaat, error=1 wat totaal anders werkt, hyper 2000 die geen zenSDK heeft en een zendure 800 plus met een totaal andere firmware dan een 2400 ac.

[hemertje]

te vroeg gereageerd...

[ Voor 103% gewijzigd door hemertje op 16-05-2026 10:52 ]

[hemertje]

...

[ Voor 99% gewijzigd door hemertje op 16-05-2026 10:52 ]

[Hippe Lip]

gielz schreef op zaterdag 16 mei 2026 @ 06:46:
Nee het commando is identiek (1 start.commando). Er zijn ook tig gebruikers die de proxy gebruiken zonder problemen. Ik zou het eerst zonder node-red testen dan kun je iig dingen uitsluiten.

Nou @gielz, zoals gezegd heb ik gisteravond de proxy van @gast777 er tussenuit gehaald en heb één stack rechtstreeks op jouw Zendure-HA-zenSDK aangesloten.

Ik heb Dynamic Trading aan staan en die is nu aan het laden. Resultaat: geen gehakkel meer bij het laden.

Voorzichtige, voorlopige conclusie: ergens in de proxy van @gast777 lijkt het mis te gaan. Het laden gaat nu strak en in de log is ook nix bijzonders te zien; die ziet er erg rustig uit.

Ik laat dit vandaag de hele dag zo op Dynamic Trading draaien. Dan laadt-ie nu en wordt er vanavond ontladen tot tegen 12 uur vannacht. Daarna is deze proef voorbij en zet ik de proxy weer aan.
Of denk je dat ik vanavond naar de andere stack moet omschakelen om er zeker van te zijn dat die ook 100% OK functioneert?

Ik denk dat WiFi-issues hiermee ook wel uitgesloten kunnen worden, toch?

Ook @YvonneVP hoeft niet verder te zoeken naar issues met de grafieken, want die zien er nu ook strak uit. Geen onderbrekingen meer.

Volgende vraag is nu: wat gaat er mis bij het gebruik van de proxy? Misschien kan @gast777 me een suggestie doen om iets specifieks te monitoren om dat boven water te krijgen?
En waarin zit het verschil tussen (dynamisch) laden, waarbij ik het gehakkel (onregelmatig vermogen) had, en het ontladen, dat steeds strak ging?
Wel opvallend daarbij: mijn grafieken van de SoC zagen er voor beide stacks onderbroken uit; daar zit dus ook geen continuïteit in bij gebruik van de proxy. En dat geldt voor elke van de stacks apart en voor de totaalgrafiek van de proxy. Daar gaat dus ook iets mis.

[ Voor 7% gewijzigd door Hippe Lip op 16-05-2026 14:18 ]

[hemertje]

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

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

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

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

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

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

[gast777]

Voordat er kromme conclusies worden getrokken en daar dan weer op wordt voorgeborduurd, zal ik even in mensentaal proberen uit te leggen wat de bevindingen en status zijn van de Issue die abaart had aangemaakt.

Wat ik even duidelijk wil stellen: Bij mijzelf thuis werkt alles prima, geen interrupties. Daardoor weet ik als feit dat als de omgeving in orde is, dat het prima werkt en dit dus geen probleem in de code en werking van de proxy is.
Mijn omgeving: 2x SF 2400 AC, HA en Node-RED als App in een VM op Proxmox met 2 CPU cores en 6GB geheugen toegewezen, Devolo Magic 2 wifi powerline naar de garage.

Wat wel zou kunnen is dat bij minder gunstige omstandigheden (bijv. packet loss) dat de Node-RED oplossing in combinatie met bepaalde modellen (of firmware) van Zendure gevoeliger zou kunnen zijn om wat interrupties te krijgen.

==== Over het issue dat abaart heeft aangemaakt:

De Issue van abaart is specifiek voor:
- SF 800 Pro
- Een omgeving met packet loss

Als je een van die twee niet hebt, dan heb je niet dit zelfde issue.

== Bevindingen:

Disclaimer: Dit is voor rekening van abaart en zijn AI tool. Ik heb zelf geen enkele harde data hierover gezien, alleen de AI gegenereerde tekst van abaart.

===> Een 'bevinding' is dat SF800Plus een limiet heeft van 6 TCP connecties (voor de ZenSDK HTTP server). Dat overschrijden zorgt voor extra interruptie.

Dit zal abaart met Zendure moeten verifieren of dat inderdaad zo is of niet. En eventueel zou Zendure die limiet dan kunnen verhogen op zijn verzoek.

Uitleg:

Bij enige packet loss (bijv door een wifi of netwerk probleem of te weinig server resources of Zendure servertje overbelasting), krijg je, zoals normaal is bij TCP, retransmissies om de data toch betrouwbaar over de lijn te krijgen. Dat geeft dan wel iets vertraging.

Op een gegeven moment zou Node-RED dan kennelijk (volgens de AI interpretatie van data die ik niet gezien heb) nieuwe extra TCP connecties opzetten terwijl de oude nog openstaan. Dan zou op een gegeven moment de limiet van 6 connecties bereikt worden en bij de 7e connectie meer connectieproblemen optreden omdat de data (GET Request) niet verstuurd kan worden.

Een mogelijke verbetering volgens een test van abaart (met een tooltje rechtstreeks naar de SF 800 Pro) zou zijn om niet 'connection keep-alive' te gebruiken. Daarmee zou de limiet van max 6 connecties misschien minder snel bereikt worden.

NB:
- Met connection keepalive, wordt steeds dezelfde TCP connectie (en source poort) gebruikt voor alle GET Request/Response uitwisselingen.
- Zonder connection keepalive wordt voor iedere GET request (dus iedere seconde) een nieuwe TCP connectie geopend (3-way handshake) en daarna afgesloten (4-way FIN handshake).

Na testen door abaart om de mogelijke verbetering te verifieren, rapporteerde hij dat dit niet hielp. Ik heb geen details of het resultaat beter, slechter of hetzelfde was, maar er was kennelijk nog een probleem.

Op zichzelf is dat ook logisch, want bij packet loss zal zo'n TCP connectie ook nu middels retransmissie proberen om de data over de lijn te krijgen en dus langer open blijven staan. Als dan voor de volgende GET weer nieuwe connecties worden geopend kun je ook >6 connecties krijgen en de 7e connectie geweigerd worden en de GET dus niet meer verstuurd kunnen worden.. Op zich zou het wel beter kunnen werken omdat iedere GET request dan zijn eigen TCP connectie heeft, zijn die onafhankelijk van elkaar en zal een vorige GET die door packet loss kwijt is geraakt de latere GET niet beinvloeden.

Dat is wat nu de status is.

Workaround/Mitigation: Zorg dat je omgeving optimaal is. Vooral de wifi verbinding moet goed zijn. <<<<<

Fix: zou van Zendure moeten komen. Iemand die dit issue heeft en harde data met bewijs voor te laag max aantal connecties voor ZenSDK op de SF 800 Pro, zou het ticket met Zendure kunnen openen.

[Hippe Lip]

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

Goed om te weten dat er meerdere gebruikers zijn die hiermee bezig zijn.

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

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

OK, da’s dan duidelijk dat het in de Node-RED zit. Dat beperkt het zoekveld. Dan hoef ik vanavond de test ook niet te herhalen met de andere stack.

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

Dat laatste snap ik niet helemaal. Verwar je Dynamic Trading misschien met Dynamic Trading + Smart Matching? Want daarbij wordt elke paar seconde inderdaad het vermogen aangepast vanwege de Smart Matching-component.

Bij Dynamic trading is het tijdens de goedkope periode full speed laden (no matter what) en tijdens de dure periode full speed ontladen (ook no matter what). Zie ik ook mijn eerdere post hierover. Daar had ik de Gielz eerst op Quick Charge staan en ging dat strak, even later op Dynamic Trading, waarbij je ziet dat het gehakkel ontstond.
En @gielz verklaarde dat:
“Quick Charge en een Dynamische cyclus zijn totaal anders. Bij Quick Charge is het gewoon een domme actie "ga nu volladen" en bij een Dynamische cyclus gaat hij de cyclus opnieuw starten als er verandering is in de batterij”.

De discharge-cyclus tijdens Dynamic trading is wat dat betreft identiek aan de charge-cyclus en daarom zou ik daar hetzelfde gehakkel verwachten, maar dat is er niet. Dat is misschien ook wel een aanwijzing voor @gast777 in de zoektocht naar wat er gebeurt? Want door het verschil tussen charge en discharge tijdens Dynamic Trading lijkt me dit wel een ander issue dan dat van abaart.

[ Voor 8% gewijzigd door Hippe Lip op 16-05-2026 13:55 ]

[Hippe Lip]

gast777 schreef op zaterdag 16 mei 2026 @ 13:37:
Voordat er kromme conclusies worden getrokken en daar dan weer op wordt voorgeborduurd, zal ik even in mensentaal proberen uit te leggen wat de bevindingen en status zijn van de Issue die abaart had aangemaakt.

[…]

Dat is wat nu de status is.

Workaround/Mitigation: Zorg dat je omgeving optimaal is. Vooral de wifi verbinding moet goed zijn. <<<<<

@gast777
Ik heb geen reden om aan te nemen dat mijn WiFi niet optimaal is. Ik heb getest met een AP op twee meter afstand en met een AP van een verdieping lager, beide met hetzelfde resultaat. Nu de Gielz met één stack draait gaat het strak, met gebruik van de proxy niet.

Bovendien krijg ik het gehakkel wel tijdens de laadcyclus van Dynamic Trading en niet tijdens de ontlaadcyclus van diezelfde Dynamic Trading.

Mijn hardware:
HA draait op een eigen platform, direct als HA OS, geen virtualisatie, geen andere apps dan HA op deze hardware, HA 2026.5.0 core.
Die is bedraad op het LAN aangesloten.

De meter is een Shelly Pro 3EM die ook bedraad op het LAN is aangesloten, maar dat is hierbij eigenlijk niet relevant.

Nog andere info nodig?

[ Voor 3% gewijzigd door Hippe Lip op 16-05-2026 14:16 ]

[koboy]

Hippe Lip schreef op zaterdag 16 mei 2026 @ 13:39:
[...]

Goed om te weten dat er meerdere gebruikers zijn die hiermee bezig zijn.

[...]

OK, da’s dan duidelijk dat het in de Node-RED zit. Dat beperkt het zoekveld. Dan hoef ik vanavond de test ook niet te herhalen met de andere stack.

[...]

Dat laatste snap ik niet helemaal. Verwar je Dynamic Trading misschien met Dynamic Trading + Smart Matching? Want daarbij wordt elke paar seconde inderdaad het vermogen aangepast vanwege de Smart Matching-component.

Bij Dynamic trading is het tijdens de goedkope periode full speed laden (no matter what) en tijdens de dure periode full speed ontladen (ook no matter what). Zie ik ook mijn eerdere post hierover. Daar had ik de Gielz eerst op Quick Charge staan en ging dat strak, even later op Dynamic Trading, waarbij je ziet dat het gehakkel ontstond.
En @gielz verklaarde dat:
“Quick Charge en een Dynamische cyclus zijn totaal anders. Bij Quick Charge is het gewoon een domme actie "ga nu volladen" en bij een Dynamische cyclus gaat hij de cyclus opnieuw starten als er verandering is in de batterij”.

De discharge-cyclus tijdens Dynamic trading is wat dat betreft identiek aan de charge-cyclus en daarom zou ik daar hetzelfde gehakkel verwachten, maar dat is er niet. Dat is misschien ook wel een aanwijzing voor @gast777 in de zoektocht naar wat er gebeurt? Want door het verschil tussen charge en discharge tijdens Dynamic Trading lijkt me dit wel een ander issue dan dat van abaart.

Nu gaat het ook wel even mijn oude vakgebied kriebelen.....

@gast777 draait in een proxmox VM, met waarschijnlijk een vlotte SSD.
Jij draait op een Odroid (met de koelribben naar boven neem ik aan...), maar vanaf een SD kaart of met een EMMC module?
@hemertje draait op een????

Als de node red logs geen directe aanwijzingen geven zou ik eens kijken naar de system resources met de system monitor integratie. Voorals de CPU usage, swap usage en PSI counters zijn dan in eerste instantie interessant.
Op deze manier kunnen we kijken of er tijdens de "uitval momenten" ergens een resource beperking zit. RAM zit ik niet direct aan te denken, maar een swap actie op een traag device kan een stotter in de performance geven.

[hemertje]

koboy schreef op zaterdag 16 mei 2026 @ 14:17:
[...]

Nu gaat het ook wel even mijn oude vakgebied kriebelen.....

@gast777 draait in een proxmox VM, met waarschijnlijk een vlotte SSD.
Jij draait op een Odroid (met de koelribben naar boven neem ik aan...), maar vanaf een SD kaart of met een EMMC module?
@hemertje draait op een????

Als de node red logs geen directe aanwijzingen geven zou ik eens kijken naar de system resources met de system monitor integratie. Voorals de CPU usage, swap usage en PSI counters zijn dan in eerste instantie interessant.
Op deze manier kunnen we kijken of er tijdens de "uitval momenten" ergens een resource beperking zit. RAM zit ik niet direct aan te denken, maar een swap actie op een traag device kan een stotter in de performance geven.

@koboy Goede vraag. Mijn opstelling:
- HP T520 Thin Client (AMD GX-212JC dual-core 1.2 GHz, 16 GB RAM, 128 GB SSD)
- HA OS direct op metal, geen virtualisatie
- LAN bedraad

Storage is SSD dus geen SD-bottleneck. RAM royaal. Wat opvalt is dat de CPU bescheiden is (2 cores, 1.2 GHz). Onder de gelijktijdige belasting van HA + Node-RED + DAO + Grafana + InfluxDB + Z-Wave JS + Zigbee2MQTT zou ik me kunnen voorstellen dat de event loop in Node-RED af en toe kortstondig blokkeert. Dat zou prima passen bij wat ik zie: spontane 5+ seconden timeout op de proxy terwijl de Zendures zelf in milliseconden reageren.

Ga vandaag de System Monitor integratie aanzetten (CPU, swap, PSI counters) en dan correleren met de timeouts.

Heb je nog specifieke metrics waar ik op moet letten?

[ Voor 28% gewijzigd door hemertje op 16-05-2026 15:15 ]

[Hippe Lip]

koboy schreef op zaterdag 16 mei 2026 @ 14:17:
Nu gaat het ook wel even mijn oude vakgebied kriebelen.....

@gast777 draait in een proxmox VM, met waarschijnlijk een vlotte SSD.
Jij draait op een Odroid (met de koelribben naar boven neem ik aan...), maar vanaf een SD kaart of met een EMMC module?

Mijn Odroid-doosje hangt verticaal met de koelribben naar de muur. Daar zit een kleine centimeter ruimte tussen voor ventilatie. Door de verticale opstelling verwacht ik dat daar trek ontstaat voor de koeling.

Een tijdje geleden las ik hier op Tweakers een artikel over hardware die uitstekend geschikt zou zijn om HA bare metal op te draaien, maar ik kan dat artikel helaas niet meer vinden. Dat ging mogelijk over een NUC, maar ik weet dat niet meer zeker.
Zou dat een goede verbetering opleveren? Als ik nu wijzigingen in mijn HA aanbreng en die herstart (check and restart), dan duurt het een hele minuut voordat alles weer draait, maar dat kan ook komen door de vele koppelingen, waar allemaal opnieuw contact mee gemaakt wordt bij het opstarten.

Als ik naar andere hardware overstap dan wil ik wel hard metal blijven draaien. Met virtualisatie, proxmox, weet-ik-wat, wordt het voor mij te complex.

[koboy]

hemertje schreef op zaterdag 16 mei 2026 @ 15:10:
[...]


@koboy Goede vraag. Mijn opstelling:
- HP T520 Thin Client (AMD GX-212JC dual-core 1.2 GHz, 16 GB RAM, 128 GB SSD)
- HA OS direct op metal, geen virtualisatie
- LAN bedraad

Storage is SSD dus geen SD-bottleneck. RAM royaal. Wat opvalt is dat de CPU bescheiden is (2 cores, 1.2 GHz). Onder de gelijktijdige belasting van HA + Node-RED + DAO + Grafana + InfluxDB + Z-Wave JS + Zigbee2MQTT zou ik me kunnen voorstellen dat de event loop in Node-RED af en toe kortstondig blokkeert. Dat zou prima passen bij wat ik zie: spontane 5+ seconden timeout op de proxy terwijl de Zendures zelf in milliseconden reageren.

Ga vandaag de System Monitor integratie aanzetten (CPU, swap, PSI counters) en dan correleren met de timeouts.

Heb je nog specifieke metrics waar ik op moet letten?

Het is geen "echte" dual core. 2 cores delen 1 FPU. Qua performance is hij een fractie sneller dan een Intel single core met hyperthreading uit die tijd.

Met de AMD architectuur uit die tijd in het achterhoofd zou ik primair naar de CPU usage kijken, of die piekt tijdens de uitval momenten.
De disk is zeer waarschijnlijk een SATA SSD, wat al snel flink sneller is dan SD of EMMC.
Andere counters dan CPU% op een zo kort mogelijke interval zou ik even buiten beschouwing laten, zeker gezien het een relatief zwakke CPU is (t.o.v. een rPi of Odroid).

[Hippe Lip]

koboy schreef op zaterdag 16 mei 2026 @ 14:17:
[...]
Als de node red logs geen directe aanwijzingen geven zou ik eens kijken naar de system resources met de system monitor integratie. Voorals de CPU usage, swap usage en PSI counters zijn dan in eerste instantie interessant.
Op deze manier kunnen we kijken of er tijdens de "uitval momenten" ergens een resource beperking zit. RAM zit ik niet direct aan te denken, maar een swap actie op een traag device kan een stotter in de performance geven.

Die integratie heb ik erin zitten. CPU usage en swap usage kan ik vinden, maar wat zijn die PSI counters, @koboy?

Ik heb overigens geen SD kaart maar een EMMC module in de Odroid. Die is sneller dan een SD-kaartje, neem ik aan?

Vanavond eerst nog de stack ontladen en dan kan de proxy er weer tussen. Dus morgen heb ik kans om het verschijnsel weer waar te nemen.

[ Voor 22% gewijzigd door Hippe Lip op 16-05-2026 15:35 ]

[koboy]

Hippe Lip schreef op zaterdag 16 mei 2026 @ 15:31:
[...]

Die integratie heb ik erin zitten. CPU usage en swap usage kan ik vinden, maar wat zijn die PSI counters, @koboy?

Ik heb overigens geen SD kaart maar een EMMC module in de Odroid. Die is sneller dan een SD-kaartje, neem ik aan?

Vanavond eerst nog de stack ontladen en dan kan de proxy er weer tussen. Dus morgen heb ik kans om het verschijnsel weer waar te nemen.

[Afbeelding]

De lijst met PSI counters kun je hier vinden. Maar als de koeling mogelijk wat gehinderd wordt kun je ook naar de CPU temp kijken.

Draai je HA vanaf een SD kaart of met een EMMC module (wat sneller maar vooral betrouwbaarder)?

Zou zelf vooral in eerste instantie kijken naar de node red / proxy logs. Wellicht dat daar al wat uitkomt. Zo niet dan moet de bottleneck gevonden worden die ook nog ergens in software kan liggen (iets van een update frequentie ofzo. Heb zelf geen node red draaien dus ken de ins en outs niet).

Voorlopig zou ik even niet kijken naar een hardware upgrade tot er echt duidelijkheid is zeker met het oog op de RAM en SSD prijzen van nu. Heb zelf al een paar jaar deze , met nu 2 (lichte) VMs draaien onder proxmox. 6% CPU belasting, 5 GiB RAM van de 16 in gebruik. HA kun je hier ook prima bare metal op draaien, naar dat is wat zonde van de rekenkracht. Belangrijkste eis voor mij was de passieve koeling.

[Hippe Lip]

koboy schreef op zaterdag 16 mei 2026 @ 15:54:
[...]

De lijst met PSI counters kun je hier vinden. Maar als de koeling mogelijk wat gehinderd wordt kun je ook naar de CPU temp kijken.

Dan houd ik het even bij de temperatuur.

Het gekke is overigens dat dit PSI wel staat genoemd in dat stuk dat je aanhaalt, maar vervolgens niet in hun dashboard staat dat ze je als voorbeeld geven.
Dat ziet er namelijk uit als dat System Monitor plaatje dat ik hierboven liet zien.

Draai je HA vanaf een SD kaart of met een EMMC module (wat sneller maar vooral betrouwbaarder)?

EMMC (stond hierboven al).

Zou zelf vooral in eerste instantie kijken naar de node red / proxy logs. Wellicht dat daar al wat uitkomt. Zo niet dan moet de bottleneck gevonden worden die ook nog ergens in software kan liggen (iets van een update frequentie ofzo. Heb zelf geen node red draaien dus ken de ins en outs niet).

OK

Voorlopig zou ik even niet kijken naar een hardware upgrade tot er echt duidelijkheid is zeker met het oog op de RAM en SSD prijzen van nu. Heb zelf al een paar jaar deze , met nu 2 (lichte) VMs draaien onder proxmox. 6% CPU belasting, 5 GiB RAM van de 16 in gebruik. HA kun je hier ook prima bare metal op draaien, naar dat is wat zonde van de rekenkracht. Belangrijkste eis voor mij was de passieve koeling.

Die ZBOX edge CI343 kost iets van 200 euro. Dat zou een optie zijn voor me als ik daarmee echt een veel snellere doos heb. Dan weet ik zeker dat ik van alle ellende af ben.
Of is die prijs. Zonder geheugen of moet ik dat (en nog iets?) er nog bij kopen? Hoeveel dan?
Dat doe ik dan alleen als ik zeker weet dat ik er écht op vooruit ga ten opzichte van de huidige Odroid.

[ Voor 6% gewijzigd door Hippe Lip op 16-05-2026 16:19 ]

[Flexiilex]

Hippe Lip schreef op zaterdag 16 mei 2026 @ 16:16:
[...]

Die ZBOX edge CI343 kost iets van 200 euro. Dat zou een optie zijn voor me als ik daarmee echt een veel snellere doos heb. Dan weet ik zeker dat ik van alle ellende af ben.
Of is die prijs. Zonder geheugen of moet ik dat (en nog iets?) er nog bij kopen? Hoeveel dan?
Dat doe ik dan alleen als ik zeker weet dat ik er écht op vooruit ga ten opzichte van de huidige Odroid.

Je kan kijken of de GMKtec G3 nog een beetje goed geprijst is. Ligt er vaak aan of je een nieuw account heb bij Ali en of al eentje gekocht hebt dan is de prijs anders. Ik kocht de 16GB, 256GB opslag voor 212 euro. Kwam van een rbi pi 4b dus zo’n 4 tot 5x sneller. Werkt echt top. Jammere is alleen dat de geheugen prijzen zo hard stijgen dus ik weet niet exact hoe duur hij nu is; Ik heb dit zojuist gevonden op AliExpress: | GMKtec G3 Mini PC Intel Alder Lake N100 Windows 11 Pro Desktop Computer 8/16GB RAM 256/512GB PCIe M.2 SSD WiFi 6 BT5.2 Mini PC

https://a.aliexpress.com/_ExjPelc

[Gramser]

Iets anders… als het mag - wat gebruiken jullie om Home Assistant van buitenshuis te benaderen? Ik zou de boel wel willen monitoren als ik op vakantie ben…

[jannus66]

Gramser schreef op zaterdag 16 mei 2026 @ 17:22:
Iets anders… als het mag - wat gebruiken jullie om Home Assistant van buitenshuis te benaderen? Ik zou de boel wel willen monitoren als ik op vakantie ben…

Nabu Casa.

[hemertje]

Gramser schreef op zaterdag 16 mei 2026 @ 17:22:
Iets anders… als het mag - wat gebruiken jullie om Home Assistant van buitenshuis te benaderen? Ik zou de boel wel willen monitoren als ik op vakantie ben…

Tailscale

[Flexiilex]

Gramser schreef op zaterdag 16 mei 2026 @ 17:22:
Iets anders… als het mag - wat gebruiken jullie om Home Assistant van buitenshuis te benaderen? Ik zou de boel wel willen monitoren als ik op vakantie ben…

Cloudflare

[oeps]

Gramser schreef op zaterdag 16 mei 2026 @ 17:22:
Iets anders… als het mag - wat gebruiken jullie om Home Assistant van buitenshuis te benaderen? Ik zou de boel wel willen monitoren als ik op vakantie ben…

Er zijn eindeloos veel mogelijkheden! Nog een:
Als je al een fritzbox als router heb kun je daar Wireguard op aanzetten. Op iOS, Android, etc dan de Wireguard app als vpn. Configureren op je telefoon gaat eenvoudig met qr code vanaf je fritzbox (of file download).
Ik heb Wireguard 100% van de tijd aan op apparaten en ben dan qua netwerk altijd ‘thuis’.

Nog een: oude router die openwrt aan kan. Binnen openwrt dan weer Wireguard installeren.
Naast bovengenoemde mogelijkheden: kijk ook even wat je huidige router kan (openvpn, wireguard).

[Gramser]

@Flexiilex @jannus66 @hemertje @oeps
Ok, ik heb weer wat om me op te oriënteren… dank!

[Pakhaas]

Gramser schreef op zaterdag 16 mei 2026 @ 17:22:
Iets anders… als het mag - wat gebruiken jullie om Home Assistant van buitenshuis te benaderen? Ik zou de boel wel willen monitoren als ik op vakantie ben…

Tailscale. Ik stond paar maanden terug voor zelfde vraag.

Nabu Casa kost geld, tailscale was erg makkelijk en gratis. Ik zet het steeds aan op de mobiel als ik naar HA wil, anders trekt het je mobiel leeg. Werkt voor mij gemakkelijk.

[Hippe Lip]

Gramser schreef op zaterdag 16 mei 2026 @ 17:22:
Iets anders… als het mag - wat gebruiken jullie om Home Assistant van buitenshuis te benaderen? Ik zou de boel wel willen monitoren als ik op vakantie ben…

Mijn Fritzbox heeft een ingebouwde VPN met gebruik van WireGuard. Erg fijn. Dat heb ik ook op mijn iPhone, iPad en Mac geïnstalleerd zodat ik zonder problemen veilig elk wifipunt kan gebruiken. En mijn HA in de gaten houden uiteraard.

[Hippe Lip]

Pakhaas schreef op zaterdag 16 mei 2026 @ 19:28:
[...]
Nabu Casa kost geld, tailscale was erg makkelijk en gratis. Ik zet het steeds aan op de mobiel als ik naar HA wil, anders trekt het je mobiel leeg. Werkt voor mij gemakkelijk.

Ja, Nabu Casa kost geld. Ondanks dat ik WireGuard gebruik, betaal ik ook voor Nabu Casa. Het gebruik van HA is weliswaar gratis, maar ik wil er toch ook aan bijdragen. Ik gebruik het voor heel wat dingen en het is leuk speelgoed.

We moeten af van de gedachte dat alles zomaar gratis moet kunnen. Een redelijke vergoeding vind ik wel op zijn plaats en zo kostbaar is Nabu Casa nou ook weer niet.

[roawser]

zagreus schreef op donderdag 14 mei 2026 @ 19:47:
[...]ls ik de internet toegang van de zendure blokeer (in de router: drop alle uitgaande verkeer van MAC adres) dan heb ik elke ~10 minuten voor 10-50seconde geen response en dus unavailable.

Zelf had ik dit dus ook, ik heb in mijn roter de Zendure weer internet toegang gegeven maar tevens heb ik in Adguard het domain app.zendure.tech geblokkeerd, waar hij om de paar minuten naar toe wil bellen. Dit werkt, geen 'unavailable' meer om elke haverklap.

[emielbf]

gast777 schreef op zaterdag 16 mei 2026 @ 13:37:
Fix: zou van Zendure moeten komen. Iemand die dit issue heeft en harde data met bewijs voor te laag max aantal connecties voor ZenSDK op de SF 800 Pro, zou het ticket met Zendure kunnen openen.

ik heb het al eerder aangegeven, maar Zendure heeft bij mijn SF800Pro met connectie problemen aangegeven dat het aantal calls beperkt is, max 1 per 3 sec. Bij mij waren de connectie porblemen opgelost toen ik het aantal calls terugdraaide. Wifi (Unifi) was perfect, 3 meter afstand, eigen 2.4 GHz ssid, stabiele verbinding.

[gielz]

emielbf schreef op zondag 17 mei 2026 @ 07:22:
[...]

ik heb het al eerder aangegeven, maar Zendure heeft bij mijn SF800Pro met connectie problemen aangegeven dat het aantal calls beperkt is, max 1 per 3 sec. Bij mij waren de connectie porblemen opgelost toen ik het aantal calls terugdraaide. Wifi (Unifi) was perfect, 3 meter afstand, eigen 2.4 GHz ssid, stabiele verbinding.

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