Zendure producten in Home Assistant integreren deel 2

[mrme12345]

xobdorp schreef op maandag 18 augustus 2025 @ 10:16:
Hey!
Mogelijk een ietwat stomme vraag, maar krijg het zo 1-2-3 niet gevonden. Ik bestuur de Zendure AC2400 bij voorkeur via de app, maar heb wel graag ook alle toeters en bellen in HA. Kan ik de Zendure HA plugin gewoon gebruiken, naast de Zendure app?

Ja hoor kun je beiden gebruiken, je moet de api token in de zendure HA integratie invullen en dan kun je alles lezen qua statussen wat je wil in HA en daarnaast gewoon je zendure app gebruiken

[xobdorp]

mrme12345 schreef op maandag 18 augustus 2025 @ 10:35:
[...]

Ja hoor kun je beiden gebruiken, je moet de api token in de zendure HA integratie invullen en dan kun je alles lezen qua statussen wat je wil in HA en daarnaast gewoon je zendure app gebruiken

Dank! We gaan het meemaken.

[wosp]

xobdorp schreef op maandag 18 augustus 2025 @ 10:16:
Hey!
Mogelijk een ietwat stomme vraag, maar krijg het zo 1-2-3 niet gevonden. Ik bestuur de Zendure AC2400 bij voorkeur via de app, maar heb wel graag ook alle toeters en bellen in HA. Kan ik de Zendure HA plugin gewoon gebruiken, naast de Zendure app?

Ja, met de FireSon integratie dmv de API key blijft de app gewoon werken en met de integratie van @gielz ook en heb je ook geen API key nodig. Je moet uiteraard wel zorgen dat ze niet beide tegelijk gaan aansturen, dus aansturing regel je dan bv dmv de Zendure App en HA gebruik je alleen om uit te lezen.

Edit: sorry, te laat

[zeegerd]

zeegerd schreef op maandag 18 augustus 2025 @ 08:37:
Zat al een tijd tegen de upgrade van FireSon aan te hikken, denkende: er kan best iets misgaan terwijl de boel heel aardig draait, inclusief een fake P1-script.

Uiteindelijk gedaan, ook de officiële app + firmware allemaal naar de hoogste versie.
Voor de zekerheid, heb een Hyper + accu's, aansturing via internet/FireSon in HA.

Resultaat: alle entiteiten laden/actualiseren, maar de Manager, die nu inderdaad 5 modi bevat, werkt niet meer.

Intussen las ik dat de Fuse Group wel moet zijn ingesteld om Smart Matching te laten werken. Die ingesteld.
Hielp nog niet. Daarna nog enkele herstarts van de Zendure Manager/gehele integratie + wisselen tussen modi in de Manager - en hij lijkt het nu weer te doen. De reden blijft mij wat onduidelijk.

[Sander]

zeegerd schreef op maandag 18 augustus 2025 @ 10:42:
[...]


Intussen las ik dat de Fuse Group wel moet zijn ingesteld om Smart Matching te laten werken. Die ingesteld.
Hielp nog niet. Daarna nog enkele herstarts van de Zendure Manager/gehele integratie + wisselen tussen modi in de Manager - en hij lijkt het nu weer te doen. De reden blijft mij wat onduidelijk.

Ik heb hier ook wel eens last van maar het is denk ik vooral (in mijn geval) eigen ongeduld omdat de integratie soms echt een paar minuten nodig heeft om te switch tussen verschillende modi, om configuratie wisselingen (zoals fuse-group) op te pakken etc. Dit soort dingen wat beter documenteren (is een restart of reload integratie wel/niet nodig) zou misschien helpen bij het debuggen en snappen van de zaken.

Ik zelf zag bijv bij het hele debug stappenplan van @FireSon op Github pas hoe bepaalde settings pas na X minuten worden opgepakt en dat ik dus in sommige gevallen geduldiger moest zijn, maar ook dat wijzigingen zoals naar Local MQTT vertraagd worden opgepakt en daardoor in mijn geval leek alsof het 5 mins werkte en daara niet meer, terwijl het eigenlijk niet werkte vanaf het moment dat het opgepakt werd.

[Taro]

TheAnT schreef op maandag 18 augustus 2025 @ 10:23:
kan ik eigenlijk via een rest command "hems" uitschakelen?

Naar mijn weten niet.

[Taro]

Henkoes schreef op maandag 18 augustus 2025 @ 08:59:
Hallo allen.

Zijn er mensen met ervaring met de combinatie van Zendure en Enphase?

Ik wil kijken of export beperking in combi met negatieve energie prijzen en zendure batterij een optie is.

Je wil dat je Enphase systeem blijft terugleveren, maar de Zendure accu's sneller gaan laden? Of wil je Enphase uitschakelen en met Zendure maximaal van het net laden?

Want dan zijn het 2 losstaande zaken: Enphase uitschakelen bij negatieve tarieven moet via de Enphase manier, dat kan vast wel, maar hoort in een ander topic. En de Zendure's kan je inderdaad laten laden bij negatieve tarieven, zit in de App ingebakken (wel per dag handmatig bijsturen), of je doet dit automatisch via HA icm bijv. Cheapest Hours integratie.

[TheAnT]

Taro schreef op maandag 18 augustus 2025 @ 14:12:
[...]

Naar mijn weten niet.

en zou je via api call kunnen switchen tussen energy plans? bvb van smart meter mode naar base load mode?

[Taro]

TheAnT schreef op maandag 18 augustus 2025 @ 14:28:
[...]


en zou je via api call kunnen switchen tussen energy plans? bvb van smart meter mode naar base load mode?

Nee, maar je kunt via HA wel zelf die modes gebruiken/simuleren, zonder HEMS of energy plans uit de Zendure app te gebruiken.

[Devke]

Dashboard Celspanning Batterijen

Wil jij per batterij onder je Zendure omvormer een aantal dingen bij houden waarbij de kerntaak ligt op balanceren/celspanning? Misschien helpt onderstaande je daarbij.



Stap 1:
Maak een sensor aan die de attributen van je batterij bevat. Ik heb onderstaande sensor in configuration.yaml opgenomen. Zet dit wel onder je rest sectie.

YAML:

name: "Zendure Batterij Packs Status"
        value_template: "{{ value_json.properties.electricLevel }}"
        unit_of_measurement: "%"
        device_class: battery
        unique_id: Zendure_Batterij_Packs_Status
        json_attributes:
          - packData

Herstart HA en kijk of de sensor met attributen zichtbaar is.

Stap 2:
Neem ook de volgende code (sensoren) op in je configuration.yaml

YAML:

# Zendure 1 Pack 1
      - name: "Zendure 1 Pack 1 Min Volt"
        value_template: >
          {% set packdata = state_attr('sensor.zendure_batterij_packs_status', 'packData') %}
          {% if packdata and packdata|length > 0 %}
            {{ packdata[0]['minVol'] / 100 }}
          {% else %}
            0
          {% endif %}
        unit_of_measurement: "V"
        device_class: voltage
        unique_id: zendure1_pack1_min_volt

      - name: "Zendure 1 Pack 1 Max Volt"
        value_template: "{{ state_attr('sensor.zendure_batterij_packs_status', 'packData')[0].maxVol / 100 }}"
        unit_of_measurement: "V"
        device_class: voltage
        unique_id: zendure1_pack1_max_volt

      - name: "Zendure 1 Pack 1 Spread"
        value_template: "{{ (state_attr('sensor.zendure_batterij_packs_status', 'packData')[0].maxVol - state_attr('sensor.zendure_batterij_packs_status', 'packData')[0].minVol) / 100 }}"
        unit_of_measurement: "V"
        device_class: voltage
        unique_id: zendure1_pack1_spread

      - name: "Zendure 1 Pack 1 SoC"
        value_template: "{{ state_attr('sensor.zendure_batterij_packs_status', 'packData')[0]['socLevel'] }}"
        unit_of_measurement: "%"
        device_class: battery
        unique_id: zendure1_pack1_soc
      

Herstart wederom HA en kijk of je de sensoren hebt. Herhaal de code voor iedere batterij die je hebt.

Stap 3:
Maak een Kop Kaart aan met de volgende yaml. De laatste mdi symbolen geven de SoC en temperatuur van de betreffende batterij aan. De Fan die je als laatste ziet is voor mij een herkenning dat de fan de omvormer extra koelt. Een eigen gemaakte entiteit. Niet opgenomen in eerder genoemde code.

YAML:

type: heading
heading: Zendure 1 Batterij 1
heading_style: title
badges:
  - type: entity
    show_state: true
    show_icon: true
    entity: sensor.zendure_1_pack_1_soc
    color: amber
    icon: mdi:battery
    tap_action:
      action: more-info
  - type: entity
    show_state: true
    show_icon: true
    entity: sensor.zendure_2400_ac_batterij_1_temperatuur
    color: amber
    icon: mdi:battery
    tap_action:
      action: more-info
  - type: entity
    show_state: true
    show_icon: true
    entity: sensor.zendure_ventilator_power_3
    color: amber
    icon: mdi:fan
    tap_action:
      action: more-info

Stap 4:
Nu zal je voor iedere batterij de MinVolt, MaxVolt en Spread moeten opnemen in een Modern Circular Gauge Kaartconfiguratie. Deze stap herhaal je voor iedere batterij die je hebt. Let op dat je PackData[0] dan veranderd in PackData[1} voor je 2e batterij etc.

Voor MinVolt

YAML:

type: custom:modern-circular-gauge
entity: sensor.zendure_1_pack_1_min_volt
name: Batterij 1 Min V
min: 2
max: 3.8
needle: true
smooth_segments: false
adaptive_icon_color: true
header_position: bottom
grid_options:
  columns: 8
  rows: 3
segments:
  - from: 2
    to: 2.5
    color:
      - 200
      - 0
      - 0
  - from: 2.5
    to: 3.6
    color:
      - 159
      - 222
      - 23
  - from: 3.6
    to: 3.8
    color:
      - 200
      - 0
      - 0
secondary: {}
tertiary: {}

Voor MaxVolt

YAML:

type: custom:modern-circular-gauge
entity: sensor.zendure_1_pack_1_max_volt
name: Batterij 1 Max V
min: 2
max: 3.8
needle: true
smooth_segments: false
adaptive_icon_color: true
header_position: bottom
grid_options:
  columns: 8
  rows: 3
segments:
  - from: 2
    to: 2.5
    color:
      - 200
      - 0
      - 0
  - from: 2.5
    to: 3.6
    color:
      - 159
      - 222
      - 23
  - from: 3.6
    to: 3.8
    color:
      - 200
      - 0
      - 0
secondary: {}
tertiary: {}

En voor de spread

YAML:

type: custom:modern-circular-gauge
entity: sensor.zendure_1_pack_1_spread
min: 0
max: 0.25
needle: true
smooth_segments: false
adaptive_icon_color: true
header_position: bottom
grid_options:
  columns: 8
  rows: 3
segments:
  - from: 0
    to: 0.1
    color:
      - 0
      - 200
      - 0
  - from: 0.1
    to: 0.15
    color:
      - 255
      - 120
      - 0
  - from: 0.15
    to: 0.25
    color:
      - 200
      - 0
      - 0
secondary: {}
tertiary: {}
name: Batterij 1 Spread

[martinvdm]

wosp schreef op woensdag 30 juli 2025 @ 01:48:
Vanavond voor de grap eens zitten testen met de nieuwe integratie van @FireSon met ZenSDK ondersteuning. Daar zit nu ook standaard slimme ontlading en slim opladen in en er is geen extra kWh meter nodig (gebruikt waarschijnlijk de wat onnauwkeurige meters van de batterij zelf?). Verder valt op dat de NOM nu inderdaad door draait als internet wegvalt, maar als je dan een reboot van HA doet heb je wel een probleem, want voor het starten heeft ie blijkbaar wel internet nodig?!? Ook was er in zijn oude integratie een sensor om te zien hoe je verbinding had, die is verdwenen, net zoals een paar anderen (zoals heatstate van elke individuele batterij). Maar verder geen gekke dingen tot nu toe. Ik blijf er nog even op draaien als test, misschien blijf ik er wel op (hij lijkt iets stabielere NOM te hebben, bij mijn zeer wisselvallige stroomverbruik met veel pieken), al zou dat wel een beetje zonde zijn van al m’n werk, haha.

Mooi werk! Die zensdk van fireson, is daar nou Bluetooth voor nodig of alleen voor de Mqtt variant?

[Henkoes]

Taro schreef op maandag 18 augustus 2025 @ 14:15:
[...]

Je wil dat je Enphase systeem blijft terugleveren, maar de Zendure accu's sneller gaan laden? Of wil je Enphase uitschakelen en met Zendure maximaal van het net laden?

Want dan zijn het 2 losstaande zaken: Enphase uitschakelen bij negatieve tarieven moet via de Enphase manier, dat kan vast wel, maar hoort in een ander topic. En de Zendure's kan je inderdaad laten laden bij negatieve tarieven, zit in de App ingebakken (wel per dag handmatig bijsturen), of je doet dit automatisch via HA icm bijv. Cheapest Hours integratie.

Ik wil dat zendure laad op zonnestroom MAAR als de batterij vol zit en er zijn negatieve tarieven dan moet enphase alleen opwekken wat er gebruikt wordt.

[wosp]

martinvdm schreef op maandag 18 augustus 2025 @ 19:04:
[...]

Mooi werk! Die zensdk van fireson, is daar nou Bluetooth voor nodig of alleen voor de Mqtt variant?

ZenSDK spreekt de API aan via WiFi. Geen Bluetooth nodig of überhaupt mogelijk.

[Sander]

Henkoes schreef op maandag 18 augustus 2025 @ 22:04:
[...]


Ik wil dat zendure laad op zonnestroom MAAR als de batterij vol zit en er zijn negatieve tarieven dan moet enphase alleen opwekken wat er gebruikt wordt.

Dit zijn 2 losse systemen en eigenlijk waar een Home Energy Management System (HEMS) (maar dan niet vendor-specific zoals HEMS nu in Zendure) normaal de hoofdrol speelt in het afstemmen en coordineren. Ik doe het dat zelf met Home Assistant nu, en heb tot op heden (het komt niet zo vaak voor) gewoon de panelen zelfs helemaal uit laten schakelen op momenten met negatieve prijzen. Ik wek meer op dan ik verbruik dus voor mij is dat gunstig om mijn energiebelasting die ik niet kan terugvragen weer wat te drukken. Wanneer salderen eraf gaat zal ik ook een regeling gaan maken om de panelen terug te regelen.

[martinvdm]

wosp schreef op dinsdag 19 augustus 2025 @ 01:23:
[...]


ZenSDK spreekt de API aan via WiFi. Geen Bluetooth nodig of überhaupt mogelijk.

Dat dacht ik ook idd. Docs zijn soms niet helemaal helder hierin. Hopenlijk verbeterd men eea nog hierin. Slim ontladen en slim opladen lijken nog niet lekker te werken en nog wat oneffenheden.

[avdwerf]

Henkoes schreef op maandag 18 augustus 2025 @ 22:04:
[...]


Ik wil dat zendure laad op zonnestroom MAAR als de batterij vol zit en er zijn negatieve tarieven dan moet enphase alleen opwekken wat er gebruikt wordt.

Als de tarieven negatief zijn wil je toch helemaal niets meer hebben van je zonnepanelen hebben, ook niet wat je vebruikt? Je krijgt geld om stroom af te nemen, ongeacht wat je gebruikt wil je dan alles van het net af halen toch?

[Henkoes]

Sander schreef op dinsdag 19 augustus 2025 @ 07:24:
[...]


Dit zijn 2 losse systemen en eigenlijk waar een Home Energy Management System (HEMS) (maar dan niet vendor-specific zoals HEMS nu in Zendure) normaal de hoofdrol speelt in het afstemmen en coordineren. Ik doe het dat zelf met Home Assistant nu, en heb tot op heden (het komt niet zo vaak voor) gewoon de panelen zelfs helemaal uit laten schakelen op momenten met negatieve prijzen. Ik wek meer op dan ik verbruik dus voor mij is dat gunstig om mijn energiebelasting die ik niet kan terugvragen weer wat te drukken. Wanneer salderen eraf gaat zal ik ook een regeling gaan maken om de panelen terug te regelen.

Kan je vanuit homeassistant de panelen dimmen en of uitzetten? Dus kan ie export beperkingn vanuit homeassistant bij enphase besturen?

[Sander]

Henkoes schreef op dinsdag 19 augustus 2025 @ 14:09:
[...]


Kan je vanuit homeassistant de panelen dimmen en of uitzetten? Dus kan ie export beperkingn vanuit homeassistant bij enphase besturen?

Ik heb geen enphase maar goodwe en daar kan dat. Enphase is wat geslotener dus je zou zelf even moeten onderzoeken of dit kan in Home Assistant of via andere (zoals bijv Modbus) mogelijkheden. ik wilde alleen maar aangeven dat de 2 zaken (batterij en panelen) los van elkaar staan als het aankomt op de aansturing.

[avdwerf]

Devke schreef op maandag 18 augustus 2025 @ 19:00:

Wil jij per batterij onder je Zendure omvormer een aantal dingen bij houden waarbij de kerntaak ligt op balanceren/celspanning? Misschien helpt onderstaande je daarbij.

Nice! Ga ze erin maken. Is er een bepaalde reden dat je de minVolt wel in een if statement hebt staan om te checken of hij bestaat en de overige zaken niet?

[Devke]

avdwerf schreef op dinsdag 19 augustus 2025 @ 20:03:
[...]


Nice! Ga ze erin maken. Is er een bepaalde reden dat je de minVolt wel in een if statement hebt staan om te checken of hij bestaat en de overige zaken niet?

Nee. Even uit mn hoofd kan die eruit. Er zat een foutje rondom naamgeving in waardoor er standaard al unknown als sensor waarde uitkwam. Bij stap 1 kreeg de sensor de attributen van de batterij niet binnen. Testje geweest. Ik denk dat je ze bij anderen niet ziet toch? Heb HA even niet ter beschikking om te checken.

[ Voor 7% gewijzigd door Devke op 19-08-2025 20:24 ]

[avdwerf]

Devke schreef op dinsdag 19 augustus 2025 @ 20:22:
[...]

Nee. Even uit mn hoofd kan die eruit. Er zat een foutje rondom naamgeving in waardoor er standaard al unknown als sensor waarde uitkwam. Testje geweest. Ik denk dat je ze bij anderen niet ziet toch? Heb HA even niet ter beschikking om te checken.

Nee klopt stond alleen bij de minVolt. Had hem er al uitgehaald, werkt prima verder.

[zeegerd]

avdwerf schreef op dinsdag 19 augustus 2025 @ 13:10:
[...]
Als de tarieven negatief zijn wil je toch helemaal niets meer hebben van je zonnepanelen hebben, ook niet wat je vebruikt? Je krijgt geld om stroom af te nemen, ongeacht wat je gebruikt wil je dan alles van het net af halen toch?

Nou.... Kun je nog salderen? Dan heb je wat meer ruimte, maar ik kan dat de rest van het jaar niet meer. En over enige tijd niemand überhaupt meer, dus nuttig om dit eens te bekijken.

In het laatste geval: bij inkopen betaal je kaal tarief + marge/belastingen. Bij verkopen ontvang je kaal tarief + soms marge (bijv bij Tibber).

Bijv: kaal tarief = 0. De prijs incl marge/bel is ca 14 ct/kWh. Als ik een kWh verkoop krijg ik dus (bij Tibber) 0 + marge (ca 2,5 ct). Echt verdienen door te kopen is er dus pas bij vanaf lager dan ca -15 ct/kWh kaal tarief; dit is redelijk zeldzaam.

Is het kale tarief ergens tussen ca -2,5 en -15 ct/kWh, dan hangt het af van de situatie wat het handigste is. Het klinkt dan goed om de Zendure zodanig aan te sturen dat deze het huis voorziet van stroom voor zover mogelijk, de accu (eventueel) oplaadt en niet teruglevert. Dat klinkt haalbaar met bijv HA-aansturing van een Hyper + DC-gekoppelde PV.

Heb je een Zendure zonder DC-input, en een losse PV-(string)omvormer, dan hangt het ook van de aansturingsmogelijkheden af van die omvormer. Veel typen kun je volgens mij alleen maar aan- of uitzetten, wat eigenlijk redelijk beperkt is. Liefst de mogelijkheid om het huis te voorzien van wat nodig is zonder verder terug te leveren (indien dit geld kost).

[avdwerf]

Devke schreef op maandag 18 augustus 2025 @ 19:00:
.........
Stap 2:
Neem ook de volgende code (sensoren) op in je configuration.yaml
....

Bij mij rondde hij de spread niet lekker af, die klopte vaak niet. Ik denk ook dat je de sensoren op deze manier onder de rest sectie hebt staan? Als ik ze onder de template sectie zet in de config krijg ik namelijk de melding dat verplicht attribuut "state" ontbreekt. Ze zouden ook niet onder rest moeten staan denk ik aangezien je 1 rest sensor hebt waar alle batterijinfo staat, dit zijn verder losse sensoren. Ik heb de code iets aangepast, dit zou dan onder je template sensoren sectie moeten komen in de config:

YAML:

# Zendure - AB3000X 1
      - name: "Zendure AB3000X 1 Min Volt"
        unit_of_measurement: "V"
        device_class: voltage
        unique_id: zendure_ab3000x_1_min_volt
        state_class: measurement
        state: "{{ (state_attr('sensor.zendure_batterij_packs_status','packData')[0]['minVol'] | float(0)) / 100 | round(2) }}"
      - name: "Zendure AB3000X 1 Max Volt"
        unit_of_measurement: "V"
        device_class: voltage
        unique_id: zendure_ab3000x_1_max_volt
        state_class: measurement
        state: "{{ (state_attr('sensor.zendure_batterij_packs_status','packData')[0]['maxVol'] | float(0)) / 100 | round(2) }}"
      - name: "Zendure AB3000X 1 SoC"
        unit_of_measurement: "%"
        device_class: battery
        unique_id: zendure_ab3000x_1_soc
        state_class: measurement
        state: "{{ (state_attr('sensor.zendure_batterij_packs_status','packData')[0]['socLevel'] | float(0)) }}"
      - name: "Zendure AB3000X 1 Spread"
        unique_id: zendure_ab3000x_1_spread
        unit_of_measurement: "V"
        device_class: voltage
        state_class: measurement
        state: >
          {% set p = state_attr('sensor.zendure_batterij_packs_status','packData')[0] %}
          {{ ((p['maxVol']|float(0)) - (p['minVol']|float(0))) / 100 | round(3) }}

[Devke]

avdwerf schreef op woensdag 20 augustus 2025 @ 09:15:
[...]


Bij mij rondde hij de spread niet lekker af, die klopte vaak niet. Ik denk ook dat je de sensoren op deze manier onder de rest sectie hebt staan? Als ik ze onder de template sectie zet in de config krijg ik namelijk de melding dat verplicht attribuut "state" ontbreekt. Ze zouden ook niet onder rest moeten staan denk ik aangezien je 1 rest sensor hebt waar alle batterijinfo staat, dit zijn verder losse sensoren. Ik heb de code iets aangepast, dit zou dan onder je template sensoren sectie moeten komen in de config:

YAML:

# Zendure - AB3000X 1
      - name: "Zendure AB3000X 1 Min Volt"
        unit_of_measurement: "V"
        device_class: voltage
        unique_id: zendure_ab3000x_1_min_volt
        state_class: measurement
        state: "{{ (state_attr('sensor.zendure_batterij_packs_status','packData')[0]['minVol'] | float(0)) / 100 | round(2) }}"
      - name: "Zendure AB3000X 1 Max Volt"
        unit_of_measurement: "V"
        device_class: voltage
        unique_id: zendure_ab3000x_1_max_volt
        state_class: measurement
        state: "{{ (state_attr('sensor.zendure_batterij_packs_status','packData')[0]['maxVol'] | float(0)) / 100 | round(2) }}"
      - name: "Zendure AB3000X 1 SoC"
        unit_of_measurement: "%"
        device_class: battery
        unique_id: zendure_ab3000x_1_soc
        state_class: measurement
        state: "{{ (state_attr('sensor.zendure_batterij_packs_status','packData')[0]['socLevel'] | float(0)) / 100 | round(2) }}"
      - name: "Zendure AB3000X 1 Spread"
        unique_id: zendure_ab3000x_1_spread
        unit_of_measurement: "V"
        device_class: voltage
        state_class: measurement
        state: >
          {% set p = state_attr('sensor.zendure_batterij_packs_status','packData')[0] %}
          {{ ((p['maxVol']|float(0)) - (p['minVol']|float(0))) / 100 | round(3) }}

Afronding is op 0.01 V steeds. Hier gaat het goed, apart. Heb je het naar mV gezet?

[avdwerf]

Devke schreef op woensdag 20 augustus 2025 @ 09:17:
[...]

Afronding is op 0.01 V steeds. Hier gaat het goed, apart. Heb je het naar mV gezet?

Nee had verder niks aangepast. Hij werkt nu goed maar dit toonde hij gister nadat ik alles had aangemaakt.

[Devke]

avdwerf schreef op woensdag 20 augustus 2025 @ 09:23:
[...]


Nee had verder niks aangepast. Hij werkt nu goed maar dit toonde hij gister nadat ik alles had aangemaakt.
[Afbeelding]

Apart. Ik heb hier het idee dat je de verkeerde sensoren bij de verkeerde batterij had staan? Kijk maar eens naar het patroon. Hier staat alles goed. Zal je straks even een screen sturen. Dasboard is niet lekker phoneproof nog.

[avdwerf]

Devke schreef op woensdag 20 augustus 2025 @ 09:30:
[...]

Apart. Ik heb hier het idee dat je de verkeerde sensoren bij de verkeerde batterij had staan? Kijk maar eens naar het patroon. Hier staat alles goed. Zal je straks even een screen sturen. Dasboard is niet lekker phoneproof nog.

Dat dacht ik ook maar heb het echt 2x goed gecheckt en alles klopte. Maar goed, nu dus iets aangepast voor mezelf en hier is alles nu netjes.

[zeegerd]

Momenteel draai ik HA/FireSon (nieuwste versie), icm een fake P1-meter. De manager staat altijd op Slimme Matching.

Wat de P1 o.a. doet 's avonds tijdens relatief hoge tarieven: geeft bijv 1200W aan, zodat hopelijk de Hyper 1200W gaat ontladen. Er lijkt dan niets te gebeuren; bij de vorige versie van FireSon ging het soms goed, soms ook niet.

Dus de (fake) P1 blijft dan op 1200W staan. Meestal helpt het om de manager-modus wat heen en weer te schakelen, dan weer naar Slimme Matching, en dan begint ie alsnog met ontladen, de P1 gaat netjes naar 0W.

Iemand een idee? Zou het beter werken door de managermodus naar Manual te zetten zodat bijbehorende vaste waarde (output) wordt gekozen? Zelf nog niet geprobeerd.

Ontladen (zonder opladen) 's ochtends met fake P1 + slimme matching gaat trouwens wel goed. Dit is dus geen geforceerd ontladen, maar matchen met wat nodig is in de woning (NOM).

[ Voor 5% gewijzigd door zeegerd op 20-08-2025 12:37 ]

[pulsarz]

Ik gebruik al een hele tijd smart matching icm fake p1 meter dmv node-red en heb 1.1.3 al dagen stabiel, geen issues.

Gebruik dit vooral om EV laden te negeren in NOM.

Vgm mag je niet zomaar een fixed waarde returnen. Die van mij is altijd obv de echte p1 waarde.
Is nodig om updates te triggeren dacht ik, want een vaste waarde "update niet".

Dus doe gewoon huidige p1 waarde + 1200W in je fake P1.

Afhankelijk van wat je gebruikt kun je ook gewoon een random waarde na de komma plaatsen telkens, dus bv 1200.123 en dan 1200.456.

[ Voor 73% gewijzigd door pulsarz op 20-08-2025 10:39 ]

[avdwerf]

Als ik via ZenSDK kijk wat voor data er beschikbaar is, heeft ook elke batterij een attribuut "batcur". Iemand een idee wat dat precies is?

[zeegerd]

pulsarz schreef op woensdag 20 augustus 2025 @ 10:35:
Ik gebruik al een hele tijd smart matching icm fake p1 meter dmv node-red en heb 1.1.3 al dagen stabiel, geen issues.

Gebruik dit vooral om EV laden te negeren in NOM.

Vgm mag je niet zomaar een fixed waarde returnen. Die van mij is altijd obv de echte p1 waarde.
Is nodig om updates te triggeren dacht ik, want een vaste waarde "update niet".

Dus doe gewoon huidige p1 waarde + 1200W in je fake P1.

Afhankelijk van wat je gebruikt kun je ook gewoon een random waarde na de komma plaatsen telkens, dus bv 1200.123 en dan 1200.456.

Bedankt; die p1+1200 werkt niet omdat er ook zonnestroom in het spel is; maar inderdaad, met een rekenkundige bewerking is daar wel wat mee te doen, PV is bekend. Idee met decimalen is ook te proberen.

Ik doe nu eenvoudig hiervoor: fake P1 = fixed waarde - huidige Hyper-ontlading. Dus als ie het goed doet is dan: 1200-1200 = 0 (NOM). Stel dat ie net op dat eerste moment al aan het ontladen was, bijv 800W, dan bemerkt hij P1 = 1200-800, hij zal 400W extra ontladen, zoals gewenst.

Wellicht iets met een kringverwijzingsprobleem, om het zo te noemen? Dus ontlading wordt bepaald door (huidige) ontlading. Maar zoals gezegd, soms doet ie het gewoon prima en na wat handmatig switchen in de Manager altijd wel.

[ Voor 5% gewijzigd door zeegerd op 20-08-2025 13:45 ]

[Sander]

zeegerd schreef op woensdag 20 augustus 2025 @ 12:47:
[...]


Bedankt; die p1+1200 werkt niet omdat er ook zonnestroom in het spel is; maar inderdaad, met een rekenkundige bewerking is daar wel wat mee te doen, PV is bekend. Idee met decimalen is ook te proberen.

Ik doe nu eenvoudig hiervoor: fake P1 = fixed waarde - huidige Hyper-ontlading. Dus als ie het goed doet is dan: 1200-1200 = 0 (NOM). Stel dat ie net op dat eerste moment al aan het ontladen was, bijv 800W, dan bemerkt hij P1 = 1200-800, hij zal 400W extra ontladen, zoals gewenst.

Wellicht iets met een kringverwijzingsprobleem, om het zo te noemen? Dus ontlading wordt bepaald door (huidige) ontlading. Maar zoals gezegd, soms doet ie het gewoon prima en na wat handmatig switchen in de Manager altijd wel.

Heb exact hetelfde issue en het komt volgens mij door het niet bijwerken van de waarde. Wat je eens kunt testen is de waarde die je doorgeeft variabel maken (handmatig) door gewoon een paar keer je template te updaten van 1200 naar 1202 naar 1201, dat triggert bij mij juiste gedrag en dan werkt het. Ik wilde eigenlijk zelf kijken of ik iets kon doen met randomizen, maar toen dacht ik: Is het nog nodig?

Fireson integratie kan zelf inmiddels ook Smart Discharge + Smart Charge only, fixed waarde (wat we hier doen) en NOM modus. Dus in principe kan ik ook besluiten om gewoon mijn eigen logic terug te brengen tot aansturen van die waarden in de integratie. Of zie ik daar wat over het hoofd?

[zeegerd]

Sander schreef op woensdag 20 augustus 2025 @ 15:21:
[...]
Heb exact hetelfde issue en het komt volgens mij door het niet bijwerken van de waarde. Wat je eens kunt testen is de waarde die je doorgeeft variabel maken (handmatig) door gewoon een paar keer je template te updaten van 1200 naar 1202 naar 1201, dat triggert bij mij juiste gedrag en dan werkt het. Ik wilde eigenlijk zelf kijken of ik iets kon doen met randomizen, maar toen dacht ik: Is het nog nodig?

Bedankt, ik heb 'm nu met een kleine min of meer random variatie per minuut gemaakt, eens kijken of dat helpt.

Fireson integratie kan zelf inmiddels ook Smart Discharge + Smart Charge only, fixed waarde (wat we hier doen) en NOM modus. Dus in principe kan ik ook besluiten om gewoon mijn eigen logic terug te brengen tot aansturen van die waarden in de integratie. Of zie ik daar wat over het hoofd?

Ik had die conclusie inderdaad ook getrokken, maar nog niet geprobeerd.

[Sander]

zeegerd schreef op donderdag 21 augustus 2025 @ 10:24:
[...]


Bedankt, ik heb 'm nu met een kleine min of meer random variatie per minuut gemaakt, eens kijken of dat helpt.


[...]


Ik had die conclusie inderdaad ook getrokken, maar nog niet geprobeerd.

Mooi, zou je willen laten weten of het helpt? ik heb er niet verder naar gekeken omdat 90% vd tijd NOM prima is en de automations om alleen slim te laden of slim ontladen wel prima werken (wss omdat de template ge-evalueerd blijft worden door HA). Het is bij mij puur geforceerd laden en ontladen wat niet werkt, de andere modi werken via deze methode prima en gebruik ik dagelijks in automations.

[mrme12345]

Sander schreef op woensdag 20 augustus 2025 @ 15:21:
[...]

Fireson integratie kan zelf inmiddels ook Smart Discharge + Smart Charge only, fixed waarde (wat we hier doen) en NOM modus. Dus in principe kan ik ook besluiten om gewoon mijn eigen logic terug te brengen tot aansturen van die waarden in de integratie. Of zie ik daar wat over het hoofd?

Dat is ook precies hoe ik de integratie gebruik. Ik heb mijn eigen logica in node red (nom, pv overschot laden enz) en stuur dat aan met aansturen van laden en ontlaad hoogte via fireson integratie. En dan heb je elke flexibiliteit die je je maar kunt wensen.

[ Voor 4% gewijzigd door mrme12345 op 21-08-2025 11:43 ]

[Taro]

avdwerf schreef op woensdag 20 augustus 2025 @ 11:02:
Als ik via ZenSDK kijk wat voor data er beschikbaar is, heeft ook elke batterij een attribuut "batcur". Iemand een idee wat dat precies is?

De current, kan je zien hoeveel Ampère de accu in of uit gaat.

[gielz]

De TS is wat opgeschoond. Nu ook de correcte link naar Zendure HA (voorheen Fireson).

Binnen de zenSDK ook een vervelende bug opgelost waar @Devke inmiddels al wat tijd aan kwijt is richting Zendure. En die ik nu ook voorbij zie komen bij de Zendure HA op github: https://github.com/Zendure/Zendure-HA/issues/683

Startpost aanpassingen

ZenSDK gielz (lokaal)

‪‪2025-08-21 🔴‬ CHANGE - Batterij modus automatisering is aangepast. Wanneer je de batterij in standby zet tijdens ontladen en de batterij was niet leeg maar ook niet 100% geladen dan ging hij alsnog ontladen (ook bekend bij Zendure). Dit limbo ontladen is nu opgelost. Wil je dit gaan gebruiken voer dan stap 4 opnieuw uit.

[ Voor 3% gewijzigd door gielz op 22-08-2025 08:13 ]

[Dolf_Tweakers]

Ben er even uit geweest maar het is zover.
De Hyper met 2 bats en de Shelly staan in de kelder te wachten.
Zijn gehomologeerd in België, dus daar moet ik het mee doen.
Wil er zo snel als mogelijk mee aan de slag, dit weekend dus.

Zou ik willen weten of er nog landgenoten zijn die de Fireson lokaal gebruiken, aansturing met HA, aangepast met piekvermogen enz.

Anders zie ik geen andere optie dan met een grote Belgische biermand bij @Taro aan de deur te gaan staan .

[klump4u]

gielz schreef op donderdag 21 augustus 2025 @ 23:14:
De TS is wat opgeschoond. Nu ook de correcte link naar Zendure HA (voorheen Fireson).

Binnen de zenSDK ook een vervelende bug opgelost waar @Devke inmiddels al wat tijd aan kwijt is richting Zendure. En die ik nu ook voorbij zie komen bij de Zendure HA op github: https://github.com/Zendure/Zendure-HA/issues/683

Startpost aanpassingen

ZenSDK gielz (lokaal)

‪‪2025-08-21 🔴‬ CHANGE - Batterij modus automatisering is aangepast. Wanneer je de batterij in standby zet tijdens ontladen en de batterij was niet leeg maar ook niet 100% geladen dan ging hij alsnog ontladen (ook bekend bij Zendure). Dit limbo ontladen is nu opgelost.

Ik kan dus stap 4 opnieuw doen met de code (die is aangepast) wil ik dit weg hebben?

[gielz]

klump4u schreef op vrijdag 22 augustus 2025 @ 07:36:
[...]

Ik kan dus stap 4 opnieuw doen met de code (die is aangepast) wil ik dit weg hebben?

Klopt, even de automatisering van stap 4 vervangen. Dit kun je doen door de huidige stap 4 automatisering te openen en opnieuw te plakken.

Alleen het standby onderdeel is aangepast van stop met alles naar stop met laden > wachten > stop met ontladen.

[g00gle]

Ik heb een issue met homeassistant en snap niet waardoor dit komt. Veel gegevens blijven bij mij op unkown staan, maar een deel werkt wel. Ik weet niet goed waar ik het moet zoeken. Iemand een suggestie?

[dennisdew16]

g00gle schreef op zaterdag 23 augustus 2025 @ 12:23:
Ik heb een issue met homeassistant en snap niet waardoor dit komt. Veel gegevens blijven bij mij op unkown staan, maar een deel werkt wel. Ik weet niet goed waar ik het moet zoeken. Iemand een suggestie?

[Afbeelding]

Welke integratie gebruik je om de data van je batterij uit te lezen, Fireson?

[g00gle]

Laatste versie van fireson, deze:
https://github.com/Zendure/Zendure-HA

[geert1992]

g00gle schreef op zaterdag 23 augustus 2025 @ 12:23:
Ik heb een issue met homeassistant en snap niet waardoor dit komt. Veel gegevens blijven bij mij op unkown staan, maar een deel werkt wel. Ik weet niet goed waar ik het moet zoeken. Iemand een suggestie?

[Afbeelding]

Gebruik je de lokale mqtt?

[g00gle]

Ja als het goed is wel, ik vermoed dat het daar ook fout gaat. Maar ik snap niet heel goed hoe HA werkt. Dus het is ongetwijfeld een config dingetje. Alleen ik weet niet goed waar.

Wat ik heb gedaan is dit installeren:


En de Zendure plugin. En tijdens de installatie lokale mqtt gekozen. En mijn HA credentials ingevuld. Zover kwam ik, kon ook verder niet echt een duidelijke how to vinden. Beetje gebrek aan HA ervaring denk ik.

[geert1992]

g00gle schreef op zaterdag 23 augustus 2025 @ 12:52:
Ja als het goed is wel, ik vermoed dat het daar ook fout gaat. Maar ik snap niet heel goed hoe HA werkt. Dus het is ongetwijfeld een config dingetje. Alleen ik weet niet goed waar.

Wat ik heb gedaan is dit installeren:
[Afbeelding]

En de Zendure plugin. En tijdens de installatie lokale mqtt gekozen. En mijn HA credentials ingevuld. Zover kwam ik, kon ook verder niet echt een duidelijke how to vinden. Beetje gebrek aan HA ervaring denk ik.

Heb je ook de add-on mosquito broker geïnstalleerd?

[g00gle]

Nee zeker niet, dat ga ik is doen! Thanks @geert1992

Edit: die stond er blijkbaar al op en draait ook, dus daar zit het issue niet denk ik.

Zit er ergens een mogelijkheid om wat meer logging aan te zetten? Zodat ik kan zien waar het fout gaat. Had al aangezet dat die MQTT communicatie moet loggen.

Edit2: Heb HA helemaal herstart, nu werkt alles ineens. Weet zeker dat ik dat al eerder had gedaan. Het werkt in iedergeval nu. Dank voor het meedenken!

[ Voor 179% gewijzigd door g00gle op 23-08-2025 13:16 ]

[martinvdm]

g00gle schreef op zaterdag 23 augustus 2025 @ 12:52:
Ja als het goed is wel, ik vermoed dat het daar ook fout gaat. Maar ik snap niet heel goed hoe HA werkt. Dus het is ongetwijfeld een config dingetje. Alleen ik weet niet goed waar.

Wat ik heb gedaan is dit installeren:
[Afbeelding]

En de Zendure plugin. En tijdens de installatie lokale mqtt gekozen. En mijn HA credentials ingevuld. Zover kwam ik, kon ook verder niet echt een duidelijke how to vinden. Beetje gebrek aan HA ervaring denk ik.

Zet anders heel de mqtt local eens uit. Het werkt ook zonder en met de local mqtt heb je ook Bluetooth nodig.

[bert pit]

g00gle schreef op zaterdag 23 augustus 2025 @ 12:23:
Ik heb een issue met homeassistant en snap niet waardoor dit komt. Veel gegevens blijven bij mij op unkown staan, maar een deel werkt wel. Ik weet niet goed waar ik het moet zoeken. Iemand een suggestie?

[Afbeelding]

Ik had dat een aantal weken geleden ook met een van de hypers dan weliswaar. Voorafgaand had ik een communicatiestoring waardoor de hyper opnieuw gekoppeld moest worden aan de wifi. Daarna vond ik in HA ineens drie hypers ipv de geïnstalleerde twee. En slechts eentje communiceerde correct. Daarna heb ik de integratie eruit gegooid en ben opnieuw begonnen.

[pfwolbers]

Hebben meer mensen problemen met v1.1.3? Hyper loopt om de paar uur vast, terwijl dit eerder 1x in de paar weken wel eens wilde gebeuren.
Ik heb geen lokale mqtt ingesteld (ook eerder niet)

[mrme12345]

pfwolbers schreef op zondag 24 augustus 2025 @ 10:22:
Hebben meer mensen problemen met v1.1.3? Hyper loopt om de paar uur vast, terwijl dit eerder 1x in de paar weken wel eens wilde gebeuren.
Ik heb geen lokale mqtt ingesteld (ook eerder niet)

Ja had ik ook last van, nu bij 1.1.4 minder. Dus die zou ik installeren als ik jou was en op de github van zendure/fireson kun je een stappenplan terugvinden hoe je het beste de integratie kunt installeren specifiek voor de hyper en de freeze problemen. Overigens is het wel zo dat in versie 1.1.4 de automatische reset (na 5 min geloof ik) er uit is gehaald om meer zicht te krijgen op de problematiek met de hypers.

[geert1992]

mrme12345 schreef op zondag 24 augustus 2025 @ 10:25:
[...]

Ja had ik ook last van, nu bij 1.1.4 minder. Dus die zou ik installeren als ik jou was en op de github van zendure/fireson kun je een stappenplan terugvinden hoe je het beste de integratie kunt installeren specifiek voor de hyper en de freeze problemen. Overigens is het wel zo dat in versie 1.1.4 de automatische reset (na 5 min geloof ik) er uit is gehaald om meer zicht te krijgen op de problematiek met de hypers.

Ik las bij 1 ticket op GitHub, dat de integratie heelveel zat te pingen naar iemand zijn hyper, daar werd geadviseerd om eens opnieuw te installeren. Blijkbaar bleef iets op de achtergrond door lopen.

Maar dat was voor dat specifieke geval, maar proberen kan altijd. Er zijn ook zoveel test versies geweest.

[pfwolbers]

Ok, heb 1.1.4 pre2 geïnstalleerd.
Koste veel moeite om de hyper weer met de zendure app te laten communiceren (batterijen los moeten halen).
Nu afwachten of dit helpt.

[zeegerd]

Sander schreef op donderdag 21 augustus 2025 @ 11:17:
[...]
Mooi, zou je willen laten weten of het helpt? ik heb er niet verder naar gekeken omdat 90% vd tijd NOM prima is en de automations om alleen slim te laden of slim ontladen wel prima werken (wss omdat de template ge-evalueerd blijft worden door HA). Het is bij mij puur geforceerd laden en ontladen wat niet werkt, de andere modi werken via deze methode prima en gebruik ik dagelijks in automations.

Het lijkt inderdaad te werken, hij ontlaadt nu al dagen bijv in de dure avonduren zonder probleem.

[gielz]

De poll heb ik in de TS even een update gegeven. Draai je inmiddels via Home Assistant maar heb je dit nog niet aangegeven zou het fijn zijn als je dit even in de poll kunt aangeven. Dan is goed te zien waar iedereen nu op draait, lekker divers clubje!

https://strawpoll.com/05ZdzxXvmn6



Homey kan niet meer gekozen worden die hebben inmiddels een eigen topic
Zendure Batterijen Slim aansturen met Athom Homey

[tweetyvogel]

gielz schreef op maandag 25 augustus 2025 @ 12:17:
De poll heb ik in de TS even een update gegeven. Draai je inmiddels via Home Assistant maar heb je dit nog niet aangegeven zou het fijn zijn als je dit even in de poll kunt aangeven. Dan is goed te zien waar iedereen nu op draait, lekker divers clubje!

https://strawpoll.com/05ZdzxXvmn6

[Afbeelding]

Homey kan niet meer gekozen worden die hebben inmiddels een eigen topic
Zendure Batterijen Slim aansturen met Athom Homey

Wil eigenlijk wijzigen maar dat kan nog niet.

[gielz]

Ik ben begonnen met een aantal wijzigingen door te testen. Wellicht heeft iemand hier al negatieve of positieve ervaringen mee?

Volgorde van te testen;
- Vermogensaansturing via API ipv Energysocket of Shelly door 1 seconden polling van de zenSDK API
- Aansturing van 1-3 seconden ipv de huidige 1-4 seconden. (Homewizard hanteert 2-4 seconden)
- Optimale RTE oplaadvermogen uitzoeken

[Devke]

gielz schreef op maandag 25 augustus 2025 @ 14:07:
Ik ben begonnen met een aantal wijzigingen door te testen. Wellicht heeft iemand hier al negatieve of positieve ervaringen mee?

Volgorde van te testen;
- Vermogensaansturing via API ipv Energysocket of Shelly door 1 seconden polling van de zenSDK API
- Aansturing van 1-3 seconden ipv de huidige 1-4 seconden. (Homewizard hanteert 2-4 seconden)
- Optimale RTE oplaadvermogen uitzoeken

Gisteren heb ik eens een tijdje geladen op 1000-1600 Watt. Volledig ontladen weer op 2400 W. RTE 86.34%. Vandaag volle snelheid laden. Straks vol ontladen. Gaat lager uitkomen. Ik wil dat wel testen. Het liefst in de goedkoopste uren. Als ik nu bv 3 uur laad tegen 1000 Watt en daarna weer ontlaad op diezelfde 1000 Watt. Dat heb ik geen volledige SoC rit steeds. Stel ik doe die test 3x. Dan het gemiddelde nemen. Heeft het dan enige waarde de RTE die daaruit komt?

Edit : Gemeten met energy socket.

[martinvdm]

Ik probeer eigenlijk op een fatsoenlijke manier de dagelijkse RTE vast te leggen.
Ik heb dus een template sensor aangemaakt die de last_period vastlegt van beide utility_meter sensoren, zowel de import als de export van de batterij en de RTE berekent.

YAML:

sensor:
      - name: "Zendure 2400 Battery RTE Yesterday"
        device_class: energy
        state_class: measurement
        unit_of_measurement: "%"
        state: >
          {% set imp = state_attr('sensor.zendure_2400_ac_import_daily', 'last_period') | float(0) %}
          {% set exp = state_attr('sensor.zendure_2400_ac_export_daily', 'last_period') | float(0) %}
          {% if imp > 0 %}
            {{ (exp / imp * 100) | round(1) }}
          {% else %}
            0
          {% endif %}

Datgeen weer in een apexchart gezet.


Werkt op zich aardig, maar op een of andere manier lijkt de RTE, zeker wanneer er weinig input en weinig output geweest is af te wijken. Nog ff sleutelen dus, maar begin is er.

[Taro]

martinvdm schreef op maandag 25 augustus 2025 @ 18:24:
Werkt op zich aardig, maar op een of andere manier lijkt de RTE, zeker wanneer er weinig input en weinig output geweest is af te wijken. Nog ff sleutelen dus, maar begin is er.

Komt vermoedelijk ook omdat je niet alles op dezelfde dag laadt en ontlaadt? En als een accu naar 10% ontlaadt, kan dat een andere 10% zijn dan de vorige keer, dus daarom pak ik hier ook de optelsom over bijv. een hele maand en nooit over een enkele dag omdat dat heel vaak niet betrouwbaar is.

[martinvdm]

Taro schreef op maandag 25 augustus 2025 @ 18:33:
[...]

Komt vermoedelijk ook omdat je niet alles op dezelfde dag laadt en ontlaadt? En als een accu naar 10% ontlaadt, kan dat een andere 10% zijn dan de vorige keer, dus daarom pak ik hier ook de optelsom over bijv. een hele maand en nooit over een enkele dag omdat dat heel vaak niet betrouwbaar is.

Goeie. Accu is nu nog klein dus wel volledig ontlaad, niet volledig geladen in enkele gevallen. Hoe bewaar jij de data langere tijd en berekent dan de RTE? Of doe je dat niet in HA?

[Devke]

martinvdm schreef op maandag 25 augustus 2025 @ 18:36:
[...]

Goeie. Accu is nu nog klein dus wel volledig ontlaad, niet volledig geladen in enkele gevallen. Hoe bewaar jij de data langere tijd en berekent dan de RTE? Of doe je dat niet in HA?

Heb je er een socket tussen zitten? Dan daar de import en export van pakken. Krijg je wel een RTE lifetime.


Dit is met een volle batterij, zal rond de 85% uitkomen vanavond na legen.

[ Voor 23% gewijzigd door Devke op 25-08-2025 18:41 ]

[Taro]

martinvdm schreef op maandag 25 augustus 2025 @ 18:36:
[...]

Goeie. Accu is nu nog klein dus wel volledig ontlaad, niet volledig geladen in enkele gevallen. Hoe bewaar jij de data langere tijd en berekent dan de RTE? Of doe je dat niet in HA?

Ik heb zowel een 3-fase kWh meter van HomeWizard over alle accu's heen, als een invididuele HW Energy Socket per accu. En dan zet ik die op week of maandweergave om de RTE handmatig te berekenen. Ik vind een dag RTE niet zo interessant.

[martinvdm]

Nee heb er geen socket tussen zitten, dus puur de berekening vanuit ha zelf obv input en output.

Ik zal eens kijken of ik er een statistics sensor aan kan toevoegen die en gemiddelde pakt over een langere tijd.

[ Voor 37% gewijzigd door martinvdm op 25-08-2025 19:29 ]

[gielz]

Devke schreef op maandag 25 augustus 2025 @ 17:05:
[...]

Gisteren heb ik eens een tijdje geladen op 1000-1600 Watt. Volledig ontladen weer op 2400 W. RTE 86.34%. Vandaag volle snelheid laden. Straks vol ontladen. Gaat lager uitkomen. Ik wil dat wel testen. Het liefst in de goedkoopste uren. Als ik nu bv 3 uur laad tegen 1000 Watt en daarna weer ontlaad op diezelfde 1000 Watt. Dat heb ik geen volledige SoC rit steeds. Stel ik doe die test 3x. Dan het gemiddelde nemen. Heeft het dan enige waarde de RTE die daaruit komt?

Edit : Gemeten met energy socket.

Wat ik wil meten is wat het meest optimale vermogen is voor het opladen zodat je aan die kan zo efficiënt mogelijk kan opladen. Het ontladen is dan NOM waarbij je weinig aan de RTE kunt doen.

Zelf ga ik in de donkere maanden testen wat de verschillende oplaadvermogens doen en dan op een vast vermogen van bijvoorbeeld 2000 watt ontladen. Dan kan ik exact uitzoeken wat het oplaadvermogen is.

Eigenlijk een beetje offtopic hier.

[gielz]

ZenSDK (Gielz) 2.0

In het kader van less is more ben ik op dit moment aan het testen met een 2.0 variant van de directe koppeling met de zenSDK zonder tussenkomst van een integratie. Na 3 maanden op de 1.0 variant zonder problemen gedraaid te hebben (geen freezes, perfect NOM) is dit een mooie nieuwe stap. De insteek is om het nog makkelijker te maken. Wat is er dan veranderd?
- Geen externe meter (bijv Homewizard Energysocket) meer nodig bij de batterij
- Nog maar 1 automatisering in plaats van 3 automatiseringen

Hierdoor zijn het straks nog maar 2 configuratie stappen: configuration.yaml + automatisering.

[martinvdm]

gielz schreef op dinsdag 26 augustus 2025 @ 22:06:

ZenSDK (Gielz) 2.0

In het kader van less is more ben ik op dit moment aan het testen met een 2.0 variant van de directe koppeling met de zenSDK zonder tussenkomst van een integratie. Na 3 maanden op de 1.0 variant zonder problemen gedraaid te hebben (geen freezes, perfect NOM) is dit een mooie nieuwe stap. De insteek is om het nog makkelijker te maken. Wat is er dan veranderd?
- Geen externe meter (bijv Homewizard Energysocket) meer nodig bij de batterij
- Nog maar 1 automatisering in plaats van 3 automatiseringen

Hierdoor zijn het straks nog maar 2 configuratie stappen: configuration.yaml + automatisering.

[Afbeelding]

[Afbeelding]

Kleine suggestie, zou leuk zijn als je kunt uitbreiden naar laden icm zonnestroom en ook dynamische energie in je automation of een combinatie ervan. Er zijn voorbeelden icm CheapestHours en Nordpool. En zelfs met solar forecast. Goed werk.

[jordyc]

@gielz mooi werk. Ik kan eventueel wel helpen met testen mocht dat nodig zijn. Heb een vrij gemakkelijke setup met 1 2400AC en 2 batterijen. Verder wel full electric huis en EV waar ik wat dingen voor in HA heb gebouwd.

Waar kan ik de nieuwe configuration en automation vinden?

[ Voor 12% gewijzigd door jordyc op 27-08-2025 07:38 ]

[gielz]

martinvdm schreef op woensdag 27 augustus 2025 @ 07:35:
[...]

Kleine suggestie, zou leuk zijn als je kunt uitbreiden naar laden icm zonnestroom en ook dynamische energie in je automation of een combinatie ervan. Er zijn voorbeelden icm CheapestHours en Nordpool. En zelfs met solar forecast. Goed werk.

Zeker mooie aanvulling maar ik wil de basis simpel houden voor nu mede omdat 2.0 toch weer anders in elkaar zit dan de huidige versie. Ik heb hier Solcast en Nordpool draaien, die laatste zal je nu ook kunnen gebruiken door de modus op Handmatig te zetten op vaste tijdstippen en dan terug naar een andere modus na x uren. @Devke doet het geloof ik op die manier.

jordyc schreef op woensdag 27 augustus 2025 @ 07:37:
@gielz mooi werk. Ik kan eventueel wel helpen met testen mocht dat nodig zijn. Heb een vrij gemakkelijke setup met 1 2400AC en 2 batterijen. Verder wel full electric huis en EV waar ik wat dingen voor in HA heb gebouwd.

Waar kan ik de nieuwe configuration en automation vinden?

Stuur mij even een DM met wat je nu hebt draaien (is dit de standaard 1.0 variant of een variatie daar op). De nieuwe variant heb je waarschijnlijk binnen 5 minuten draaien. Maar ik ben hier en daar nog wel wat dingen aan het aanpassen.

[Devke]

gielz schreef op woensdag 27 augustus 2025 @ 19:44:
[...]


Zeker mooie aanvulling maar ik wil de basis simpel houden voor nu mede omdat 2.0 toch weer anders in elkaar zit dan de huidige versie. Ik heb hier Solcast en Nordpool draaien, die laatste zal je nu ook kunnen gebruiken door de modus op Handmatig te zetten op vaste tijdstippen en dan terug naar een andere modus na x uren. @Devke doet het geloof ik op die manier.


[...]


Stuur mij even een DM met wat je nu hebt draaien (is dit de standaard 1.0 variant of een variatie daar op). De nieuwe variant heb je waarschijnlijk binnen 5 minuten draaien. Maar ik ben hier en daar nog wel wat dingen aan het aanpassen.

En @martinvdm hier draaien de batterijen naar dynamische inzichten met een licht andere insteek. Ik maak gebruik van de cheapest hour integratie om Zendure en HW op de goedkoopste momenten te laden. Daarna gaan ze allebei in stand-by. Op de duurste uren gaat Zendure ontladen. HW moet handmatig en kan deels ontladen. Zendure doet alles volledig middels een automatisering. Als op de dure uren Zendure volledig is ontladen dan geeft de automatisering een seintje naar HW om te gaan Nommen. Dat doet hij tot een uurtje of 8 in de ochtend om vervolgens weer standby te gaan.

Een weersvoorspeller (zon) heb je dynamisch niet zoveel aan. Daar wil je imo zo goedkoop mogelijk laden en op de dure uren ontladen (verkoop stroom) of Nommen. Vaak schijnt de zon op de goedkope uren ook wel.

[gielz]

De afgelopen dagen heb ik de laatste onderdelen getest en gekeken naar de afgelopen 4 nachten. Hier ook eigenlijk niet iets geks gevonden in de standaard aansturing.

Wijzigingen tov 1.0;

- Nog maar één enkele automatisering.
- Aansturing via Zendure vermogen zelf zonder tussenkomst externe meting (bijv. Energysocket).
- Beter opladen om goed in de bufferzone te blijven. (instelbare correctie, staat op 50 watt - FAQ)
- Minder import door standaard naar -5 watt te balanceren. (instelbare correctie, staat op -5 watt - FAQ)
- Iets eerder starten met laden in de ochtend, was 2 uur na zonsopgang. Dit is nu 1 uur. (uiteraard zelf aan te passen - FAQ)
- Standby is nu echt 100% standby door Smartmode uit te zetten en alles op 0 watt te zetten (overgenomen van Zendure HA)

ZenSDK (Gielz) 2.0

De volledige TS is herzien om het allemaal weer een stuk makkelijker en vooral om een betere aansturing te krijgen van de NOM. De grootste aanpassing is eigenlijk het niet meer nodig hebben van een externe meting (bijv Homewizard Energysocket). Ook een aantal kleine aanpassingen zoals nog maar één automatisering en een strakkere NOM lijn.

Conversie

Wil je over van 1.0 (versie augustus) dan kan dat als volgt; Zet de batterij eerst in standby. Zet vervolgens je huidige automatiseringen uit (NOM, Modus en indien aangemaakt ook de Handmatige. Voeg de extra 2 rest onderdelen toe en controleer even goed hoe ze in stap 1 staan (aan het begin en einde);

code:

  - resource: http://<IP-BATTERIJ>/properties/report
    scan_interval: 1
    sensor:
      - name: "Zendure 2400 AC Vermogen Aansturing"
        value_template: >
          {% set opladen = value_json['properties']['outputPackPower'] | int %}
          {% set ontladen = - (value_json['properties']['packInputPower'] | int) %}
          {% if opladen != 0 %}
            {{ opladen }}
          {% else %}
            {{ ontladen }}
          {% endif %}
        unique_id: Zendure_2400_AC_Vermogen_Aansturing
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

code:

zendure_standby:
    url: http://<IP-BATTERIJ>/properties/write
    method: POST
    payload: '{"sn":"<SERIAL-2400AC>","properties":{"smartMode": 0, "outputLimit": 0, "inputLimit": 0 }}'

Herstart vervolgens Home Assistant en voer stap 2 (aanmaken automatisering) uit. Controleer je sensoren als je zaken hebt aangepast. Is bijvoorbeeld je P1 sensor juist (veel gemaakte fout). Zelf zou ik alle stappen doorlopen maar een conversie is wel degelijk mogelijk.

Wanneer je de oude automatiseringen uitschakelt maar niet verwijderd kun je altijd weer terug naar 1.0. Vragen? DM mag altijd.

[TheAnT]

setup
zendure ac2400
shelly pro3em
aansturing in hA -> Fireson

Is dit normaal dat als ik nom draai en hoger verbruik heb dat er steeds wel een piek is, weliswaar duurt dit niet lang maar wss toch niet normaal?

Zoals hier op afbeelding te zien, deze ochtend vanaf 06.00

[ Voor 29% gewijzigd door TheAnT op 28-08-2025 09:56 ]

[c0mplex1]

gielz schreef op donderdag 28 augustus 2025 @ 08:25:

code:

zendure_standby:
    url: http://<IP-BATTERIJ>/properties/write
    method: POST
    payload: '{"sn":"<SERIAL-2400AC>","properties":{"smartMode": 0, "outputLimit": 0, "inputLimit": 0 }}'

Bij mij werkt dit nog niet betrouwbaar. Ik zie met de HW plug nog steeds "lek" stromen van/naar de batterij als die op Standby staat.
Moet ik nog verder onderzoeken.

[gielz]

c0mplex1 schreef op donderdag 28 augustus 2025 @ 11:23:
[...]

Bij mij werkt dit nog niet betrouwbaar. Ik zie met de HW plug nog steeds "lek" stromen van/naar de batterij als die op Standby staat.
Moet ik nog verder onderzoeken.

Hoeveel wattage zie jij dan voorbij komen? Ik heb hier een shelly meting en een energysocket meting. Beide staan op 0 (shelly ziet wel de energysocket van +/- 1 watt). Zodra de smartmode naar 1 gaat maar alles staat op 0 watt ingesteld dan gaat hij weer limbo stroom het net opdrukken.

De oplossing die ik nu gebruik komt hier vandaan;
https://github.com/Zendure/Zendure-HA/issues/683

[c0mplex1]

Ik gebruik de regel zoals staat in device.py

code:

if power == 0:
command = {"properties": {"smartMode": 0, "inputLimit": 0, "outputLimit": 0, "acMode": 1}}

De HW plug geeft ongeveer 15 - 20 watt.
Maar nogmaals ik moet dit nog verder onderzoeken.

[avdwerf]

gielz schreef op donderdag 28 augustus 2025 @ 08:25:
De afgelopen dagen heb ik de laatste onderdelen getest en gekeken naar de afgelopen 4 nachten. Hier ook eigenlijk niet iets geks gevonden in de standaard aansturing.

Nog even wachten tot mijn AC 2400 weer werkt, maar ziet er netjes uit verder. Overzichtelijker ook met maar 1 automatisering. Klein vraagje, Zendure 2400 AC Modus laat bij mij altijd Opladen of Ontladen zien, ook als de AC 2400 in standby staat. Enig idee of dat ook nog netjes te krijgen is (of is dit alleen bij mij) dat hij dan daar ook standby laat zien?

[gielz]

avdwerf schreef op donderdag 28 augustus 2025 @ 13:47:
[...]


Nog even wachten tot mijn AC 2400 weer werkt, maar ziet er netjes uit verder. Overzichtelijker ook met maar 1 automatisering. Klein vraagje, Zendure 2400 AC Modus laat bij mij altijd Opladen of Ontladen zien, ook als de AC 2400 in standby staat. Enig idee of dat ook nog netjes te krijgen is (of is dit alleen bij mij) dat hij dan daar ook standby laat zien?

De AC modus is binnen de properties 1 of 2 en geeft aan hoe de relais staat in laden of ontladen. Die sensor zou eventueel nog verbeterd kunnen worden maar gebruik je hem ergens voor?

Zelf gebruik ik de modus selectie (dropdown) en op basis van het vermogen zie ik wat hij aan het doen is op dat moment. Nu zie ik bijvoorbeeld Laden 2u 23m staan.

[Devke]

c0mplex1 schreef op donderdag 28 augustus 2025 @ 11:47:
Ik gebruik de regel zoals staat in device.py

code:

if power == 0:
command = {"properties": {"smartMode": 0, "inputLimit": 0, "outputLimit": 0, "acMode": 1}}

De HW plug geeft ongeveer 15 - 20 watt.
Maar nogmaals ik moet dit nog verder onderzoeken.

Eerst een laad commando sturen met 0W daarna een ontlaad commando sturen met 0W. Zo heb ik het gefixed. Wel een korte delay tussen beide opdrachten.

[dennisdew16]

@gielz Je bent weer lekker bezig geweest Na het weekend wil ik over op NOM 2.0. Ik neem aan dat ik nog steeds mijn HW kwh meter kan gebruiken voor de aansturing ipv de extra rest sensor?

[gielz]

dennisdew16 schreef op donderdag 28 augustus 2025 @ 15:48:
@gielz Je bent weer lekker bezig geweest Na het weekend wil ik over op NOM 2.0. Ik neem aan dat ik nog steeds mijn HW kwh meter kan gebruiken voor de aansturing ipv de extra rest sensor?

Ik zou persoonlijk over gaan op de directe sturing. Met wolkje, zon, wolkje zie je duidelijk verbetering. Je kunt dan vervolgens wel de KWH standen van je KWH meter gebruiken om de RTE te bepalen.

*wolkje zon wolkje met 50 watt buffer;

[dennisdew16]

gielz schreef op donderdag 28 augustus 2025 @ 15:56:
[...]


Ik zou persoonlijk over gaan op de directe sturing. Met wolkje, zon, wolkje zie je duidelijk verbetering. Je kunt dan vervolgens wel de KWH standen van je KWH meter gebruiken om de RTE te bepalen.

*wolkje zon wolkje met 50 watt buffer;
[Afbeelding]

Maar komt de verbetering door de energysocket niet meer te gebruiken of door optimalisatie van je automatisering? En elke seconde de data opvragen uit de omvormer is dan dus toch geen probleem? Misschien heb ik er overheen gelezen maar dan had je kans op freeze toch.

[gielz]

dennisdew16 schreef op donderdag 28 augustus 2025 @ 18:06:
[...]

Maar komt de verbetering door de energysocket niet meer te gebruiken of door optimalisatie van je automatisering? En elke seconde de data opvragen uit de omvormer is dan dus toch geen probleem? Misschien heb ik er overheen gelezen maar dan had je kans op freeze toch.

De verbetering komt doordat alles nu afkomstig is uit de zenSDK dat heeft dus toevallig het neveneffect gehad dat de NOM strakker loopt gek genoeg. In Mei was het zo met firmware 1.03 dat de omvormer inderdaad plat ging binnen een uur. Sindsdien is 1.04 en 1.06 uitgekomen en zie ik geen freeze meer.

En nog een heel groot voordeel de zenSDK word nu ook 100% ondersteund door Zendure en is niet meer een API die ik toevallig in Mei ergens op Reddit vond; https://github.com/Zendure/zenSDK/discussions/15

[klump4u]

NOM 2.0 geinstalleerd nu met Homewizard P1 (had eerst DSMR reader) en heb nog een Shelly mini g3 op de 2400AC, is nog leuk om te zien dat de accu levert of opslaat. Mooi werk @gielz

[tweetyvogel]

@gielz

Nom 2.0 geïnstalleerd en de koppeling van Zendure verwijderd, werkt prima.

Vraagje bij de Zendure/ Fireson integratie werd op basis van de aanwezige accu's de te verwachte kWH's berekent van de accu's.
Bestaat deze mogelijkheid ook via SDK en zo ja hoe dan ??

[gielz]

tweetyvogel schreef op donderdag 28 augustus 2025 @ 19:01:
@gielz

Nom 2.0 geïnstalleerd en de koppeling van Zendure verwijderd, werkt prima.

Vraagje bij de Zendure/ Fireson integratie werd op basis van de aanwezige accu's de te verwachte kWH's berekent van de accu's.
Bestaat deze mogelijkheid ook via SDK en zo ja hoe dan ??

Zou kunnen maar ik denk dat je dit dan wel met een korreltje zout moet nemen. Hier wanneer de batterij van 15 naar 10% gaat ontladen duurt eeuwen er zit dan veel meer in dan je zou berekenen.

Binnen de Zendure HA zie ik deze code onderdelen voorbij komen. Zo te zien word er op basis van de SOC een berekening gedaan hoeveel KWH dit waard zou moeten zijn waarbij de minimale soc niet meegenomen word (10% vaak). Via een helper zou je dit eenvoudig kunnen bouwen.

code:

self.availableKwh.update_value((self.electricLevel.asNumber - self.minSoc.asNumber) / 100 * self.kWh)

        self.kWh = 0.0
        model = "???"
        match sn[0]:
            case "A":
                if sn[3] == "3":
                    model = "AIO2400"
                    self.kWh = 2.4
                else:
                    model = "AB1000"
                    self.kWh = 0.96
            case "B":
                model = "AB1000S"
                self.kWh = 0.96
            case "C":
                model = "AB2000" + ("S" if sn[3] == "F" else "")
                self.kWh = 1.92
            case "F":
                model = "AB3000"
                self.kWh = 2.88

[Devke]

Cycli Batterij Pack

Ik heb eens een beetje zitten prutsen. Ik heb chatgpt er eens bij gepakt. Zendure biedt op dit moment geen teller om het aantal cycli dat je batterij heeft doorlopen bij te houden. Als je systeem bestaat uit 1 batterij dan is het makkelijker te benaderen dan als je systeem bijvoorbeeld uit 3 batterijen bestaat. Batterij 1 kan veel verder en vaker leeg getrokken worden dan batterij 2 en 3 etc. Om een beetje een houvast te geven die ongetwijfeld niet waterdicht is heb ik eens een teller gebouwd (waarbij chatgpt soms mijn inzichten moest corrigeren) die het aantal cycli telt. Let op: Je batterijen worden dan gezien als 1 grote batterij.

Maak een template sensor aan met onderstaande yaml:

YAML:

{% set C = 8.64 %}  {# totale bruikbare capaciteit kWh (3x2880 Wh) #}
{% set dod = 0.90 %} {# depth of discharge van 100% naar 10% #}

{% set imp = states('sensor.energy_socket_energy_import_8')|float(0) %}
{% set exp_raw = states('sensor.energy_socket_energie_export')|float(0) %}
{% set rte_raw = states('sensor.rte_lifetime_zendure_socket')|float(0) %}
{% set rte = (rte_raw / 100) if rte_raw > 1 else rte_raw %}
{% set s = (rte if rte > 0 else 1) ** 0.5 %}

{# Als export onbekend of 0 is, bereken hem uit import * RTE #}
{% set exp = exp_raw if exp_raw > 0 else imp * rte %}

{# Bereken Equivalent Full Cycles #}
{% set efc = ((imp * s) + (exp / s)) / (2 * C) %}

{{ (efc / dod) | round(0) }}

Vul wel even goed jouw capaciteit in en je DoD. Nogmaals hij zal niet waterdicht zijn maar wellicht een leuke gadget (aantal cycli bij benadering).

Edit : ik heb een energysocket tussen de batterij en de WCD zitten. Die entiteiten gebruik ik in de yaml.

[ Voor 3% gewijzigd door Devke op 28-08-2025 19:55 ]

[gielz]

@tweetyvogel Zoiets zoek je waarschijnlijk zoals het in de Zendure HA Integratie zit. Alleen even de juiste capaciteit invullen van x*2,88kwh.

Onderstaande kun je toevoegen als Helper > Template > Sensor

code:

{% set laad = states('sensor.zendure_2400_ac_laadpercentage') | float(0) %}
          {% set min_laad = states('sensor.zendure_2400_ac_minimale_laadpercentage') | float(0) %}
          {% set capaciteit = 14.4 %}
          {% set bruikbaar_percentage = laad - min_laad %}
          {% if bruikbaar_percentage < 0 %}
            0
          {% else %}
            {{ (bruikbaar_percentage / 100 * capaciteit) | round(2) }}
          {% endif %}

[gielz]

Devke schreef op donderdag 28 augustus 2025 @ 19:20:

Cycli Batterij Pack

Ik heb eens een beetje zitten prutsen. Ik heb chatgpt er eens bij gepakt. Zendure biedt op dit moment geen teller om het aantal cycli dat je batterij heeft doorlopen bij te houden. Als je systeem bestaat uit 1 batterij dan is het makkelijker te benaderen dan als je systeem bijvoorbeeld uit 3 batterijen bestaat. Batterij 1 kan veel verder en vaker leeg getrokken worden dan batterij 2 en 3 etc. Om een beetje een houvast te geven die ongetwijfeld niet waterdicht is heb ik eens een teller gebouwd (waarbij chatgpt soms mijn inzichten moest corrigeren) die het aantal cycli telt. Let op: Je batterijen worden dan gezien als 1 grote batterij.

Maak een template sensor aan met onderstaande yaml:

YAML:

{% set C = 8.64 %}  {# totale bruikbare capaciteit kWh (3x2880 Wh) #}
{% set dod = 0.90 %} {# depth of discharge van 100% naar 10% #}

{% set imp = states('sensor.energy_socket_energy_import_8')|float(0) %}
{% set exp_raw = states('sensor.energy_socket_energie_export')|float(0) %}
{% set rte_raw = states('sensor.rte_lifetime_zendure_socket')|float(0) %}
{% set rte = (rte_raw / 100) if rte_raw > 1 else rte_raw %}
{% set s = (rte if rte > 0 else 1) ** 0.5 %}

{# Als export onbekend of 0 is, bereken hem uit import * RTE #}
{% set exp = exp_raw if exp_raw > 0 else imp * rte %}

{# Bereken Equivalent Full Cycles #}
{% set efc = ((imp * s) + (exp / s)) / (2 * C) %}

{{ (efc / dod) | round(0) }}

Vul wel even goed jouw capaciteit in en je DoD. Nogmaals hij zal niet waterdicht zijn maar wellicht een leuke gadget (aantal cycli bij benadering).

Edit : ik heb een energysocket tussen de batterij en de WCD zitten. Die entiteiten gebruik ik in de yaml.

Mooie aanvulling, ook al word het als 1 batterij gezien.

[tweetyvogel]

gielz schreef op donderdag 28 augustus 2025 @ 20:01:
@tweetyvogel Zoiets zoek je waarschijnlijk zoals het in de Zendure HA Integratie zit. Alleen even de juiste capaciteit invullen van x*2,88kwh.

Onderstaande kun je toevoegen als Helper > Template > Sensor

[Afbeelding]

code:

{% set laad = states('sensor.zendure_2400_ac_laadpercentage') | float(0) %}
          {% set min_laad = states('sensor.zendure_2400_ac_minimale_laadpercentage') | float(0) %}
          {% set capaciteit = 14.4 %}
          {% set bruikbaar_percentage = laad - min_laad %}
          {% if bruikbaar_percentage < 0 %}
            0
          {% else %}
            {{ (bruikbaar_percentage / 100 * capaciteit) | round(2) }}
          {% endif %}

Top, beide “werken” 👍

[Taro]

Zojuist Zendure 1.1.4 pre 2 geïnstalleerd, zie nu overigens dat je ook de totale beschikbare kWh's en totaal vermogen over alle omvormers heen kunt zien, was misschien al aanwezig, maar altijd handig:


En "Verbonden" geeft nu ook ZenSDK aan, stond er eerder volgens mij niet:

[ Voor 25% gewijzigd door Taro op 28-08-2025 21:13 ]

[avdwerf]

gielz schreef op donderdag 28 augustus 2025 @ 14:05:
[...]
De AC modus is binnen de properties 1 of 2 en geeft aan hoe de relais staat in laden of ontladen. Die sensor zou eventueel nog verbeterd kunnen worden maar gebruik je hem ergens voor?

Zelf gebruik ik de modus selectie (dropdown) en op basis van het vermogen zie ik wat hij aan het doen is op dat moment. Nu zie ik bijvoorbeeld Laden 2u 23m staan.

Aah oke, standby heeft dus geen apart status die je kunt lezen. Ik gebruik het verder niet, alleen weergave op mn dashboard

[VicSmurf]

Vraagje, misschien is dit al voorbij gekomen maar kon het niet zo snel vinden.

Ik heb de Zendure app met de Zendure P1 meter (die verkeerde data terug geeft zodra een van de fases positief is) en de Fireson/Zendure integratie in HA waar ik mijn andere P1 meter heb opgegeven.

Wat gebeurd er nu? Wordt de P1 data van de Zendure P1 gebruikt omdat ik dat in de app geconfigureerd heb OF wordt de P1 meter vanuit HA gebruikt? In de app zit de SolarFlow nog in de HEMS.

[ Voor 4% gewijzigd door VicSmurf op 29-08-2025 12:17 ]

[Mediacj]

VicSmurf schreef op vrijdag 29 augustus 2025 @ 12:04:
Vraagje, misschien is dit al voorbij gekomen maar kon het niet zo snel vinden.

Ik heb de Zendure app met de Zendure P1 meter (die verkeerde data terug geeft zodra een van de fases positief is) en de Fireson/Zendure integratie in HA waar ik mijn andere P1 meter heb opgegeven.

Wat gebeurd er nu? Wordt de P1 data van de Zendure P1 gebruikt omdat ik dat in de app geconfigureerd heb OF wordt de P1 meter vanuit HA gebruikt? In de app zit de SolarFlow nog in de HEMS.

In de app de p1 meter van Zendure en in Home Assistant de entiteit die jezelf opgegeven hebt bij de installatie van de integratie en dat kan iedere p1 meter/waarde zijn.

Dus alle NOM functies etc in de app maken gebruik van de daar gekoppelde p1 meter, en in HA de entiteit die je opgegeven hebt.

[ Voor 7% gewijzigd door Mediacj op 29-08-2025 12:40 ]

[VicSmurf]

Mediacj schreef op vrijdag 29 augustus 2025 @ 12:39:
[...]

In de app de p1 meter van Zendure en in Home Assistant de entiteit die jezelf opgegeven hebt bij de installatie van de integratie en dat kan iedere p1 meter/waarde zijn.

Dus alle NOM functies etc in de app maken gebruik van de daar gekoppelde p1 meter, en in HA de entiteit die je opgegeven hebt.

Ja, snap ik maar wat gebeurd er dan precies want beide staan "aan". Zowel de HA integratie is actief als de app.

[Mediacj]

VicSmurf schreef op vrijdag 29 augustus 2025 @ 13:08:
[...]


Ja, snap ik maar wat gebeurd er dan precies want beide staan "aan". Zowel de HA integratie is actief als de app.

Dat is niet logisch of je zet HEMS etc aan of je gebruikt de integratie. Je kunt het uiteraard wel afwisselen dan de app met HEMS en daarna weer de integratie als ze maar niet tegelijk aansturen.

[VicSmurf]

Mediacj schreef op vrijdag 29 augustus 2025 @ 13:10:
[...]

Dat is niet logisch of je zet HEMS etc aan of je gebruikt de integratie. Je kunt het uiteraard wel afwisselen dan de app met HEMS en daarna weer de integratie als ze maar niet tegelijk aansturen.

Is inderdaad niet logisch maar vroeg me af of iets "prioriteit" had boven de ander. Bedankt voor je reacties.

[g00gle]

Volgens mij werkt HA niet als die HEMS integratie actief is. Met andere woorden, HA kan die accu niet sturen wanneer die in HEMS staat.

[jordyc]

@gielz ik heb nu aan het spelen met jou aansturing en loop tegen het volgende aan waarvan ik denk dat het nog een mooie toevoeging zou kunnen zijn.

1. De mogelijkheid om de SOC min en max aan te passen in de automatisering. Dan kan je bijvoorbeeld het zo bouwen dat er alleen op zondag naar 100% wordt geladen.

2. De input en output splitsen in de restAPI zodat je daar dan een integral sensor van kan maken en zien hoeveel er is geladen en ontladen. Deze data is dan weer bruikbaar in het energy dashboard en eventueel in de bovenstaande cyclus counter.

[avdwerf]

jordyc schreef op vrijdag 29 augustus 2025 @ 16:00:
@gielz ik heb nu aan het spelen met jou aansturing en loop tegen het volgende aan waarvan ik denk dat het nog een mooie toevoeging zou kunnen zijn.

1. De mogelijkheid om de SOC min en max aan te passen in de automatisering. Dan kan je bijvoorbeeld het zo bouwen dat er alleen op zondag naar 100% wordt geladen.

2. De input en output splitsen in de restAPI zodat je daar dan een integral sensor van kan maken en zien hoeveel er is geladen en ontladen. Deze data is dan weer bruikbaar in het energy dashboard en eventueel in de bovenstaande cyclus counter.

Die eerste zou wel moeten kunnen denk ik met een nieuw restcommand.
Nummer 2 zat in versie 1.00 van de NOM en heb ik om dezelfde reden bewaard:

YAML:

- name: "Zendure 2400 AC Vermogen (ontladen)"
        value_template: "{{ - (value_json['properties']['packInputPower'] | int) }}"
        unique_id: Zendure_2400_AC_Vermogen_Ontladen
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

      - name: "Zendure 2400 AC Vermogen (opladen)"
        value_template: "{{ value_json['properties']['outputPackPower'] }}"
        unique_id: Zendure_2400_AC_Vermogen_Opladen
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

[gielz]

KNIP, niet gebruiken geeft foutieve data.

[ Voor 98% gewijzigd door gielz op 30-08-2025 17:35 ]