Zendure producten in Home Assistant integreren deel 2

[gast777]

Henkoes schreef op woensdag 29 april 2026 @ 11:41:
[...]


Hoe werkt het samenvoegen door Gielz? Alles sommen per batterij "laag" en en delen door het aantal batterijen?

Ok, ik snap wat je bedoelt. Voor de meeste waarden moet je bijvoorbeeld het gemiddelde of de hoogste of de laagste van de verschillende Zendures nemen en doorgeven aan HA als waarde van de Virtuele Zendure. Maar dat geldt niet voor de battery packs. Die worden gewoon op elkaar gestapeld en dan integraal doorgegeven.

[Hippe Lip]

gielz schreef op dinsdag 28 april 2026 @ 09:13:
[...]


Ip kan alleen met homewizard kwh of p1. Je moet even je shelly rest regels onderaan je configuration.yaml plakken en uiteraard het ip in die code invullen.

code:

rest:
  - resource: http://<IP-SHELLY_PRO_3EM-CT>/rpc/EM.GetStatus?id=0
    scan_interval: 1
    sensor:
      - name: "CT Shelly Pro 3EM API"
        value_template: "{{ value_json.total_act_power }}"
        unique_id: CT_Shelly_Pro_3EM_API
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

Dan is je home energy meter sensor;
sensor.CT_Shelly_Pro_3EM_API

Ik gebruik hier ook de Shelly Pro 3EM maar heb die aanvulling niet in mijn configuration.yaml (of elders). Toch lijkt alles goed te werken.

Kan het beter met die aanvulling? Waaraan kan ik het verschil dan zien, wat gaat er anders/ beter?

[Flexiilex]

Flexiilex schreef op dinsdag 28 april 2026 @ 22:51:
[...]


Goedkoopste prijs was tussen 2 en half 7 zegt die, dat lijkt niet echt te kloppen natuurlijk.

Om 22:30 is hij gestopt met ontladen en om 23:00 weer begonnen met ontladen.

Edit: Op de host zelf staat de tijd ook gewoon goed. Ik denk door te snel de dure uren aanpassen dat hij van slag is?

[Afbeelding]

Iemand enig idee waar ik nog kan kijken? goedkoopste uren zijn al begonnen meet de Gielz integratie triggert blijkbaar niet het laden. De sensor; sensor.dynamisch_goedkoopste_periode blijft ook op Nee staan terwijl de grafiek wel toont dat de goedkoopste uren zijn begonnen. waar zit dan de mismatch?

Ik zie dit in de details van de sensor, vermoed dat de "2026-04-29T11:45:00+02:00"" en dan voornamelijk de +02:00 er niet in hoort te staan? Hoe komt dit er in en hoe fix ik dit precies?

[ Voor 21% gewijzigd door Flexiilex op 29-04-2026 12:37 ]

[wautah91]

Flexiilex schreef op woensdag 29 april 2026 @ 12:32:
[...]


Iemand enig idee waar ik nog kan kijken? goedkoopste uren zijn al begonnen meet de Gielz integratie triggert blijkbaar niet het laden. De sensor; sensor.dynamisch_goedkoopste_periode blijft ook op Nee staan terwijl de grafiek wel toont dat de goedkoopste uren zijn begonnen. waar zit dan de mismatch?

Ik zie dit in de details van de sensor, vermoed dat de "2026-04-29T11:45:00+02:00"" en dan voornamelijk de +02:00 er niet in hoort te staan? Hoe komt dit er in en hoe fix ik dit precies?

[Afbeelding]

Die +02:00 heeft te maken met de zomertijd.

Wat je nog kan doen is de Tracering Weergeven van de Gielz automation, die heb je wel? Dus Instellingen -> Automatiseringen -> Gielz -> Tracering weergeven. Hie kan je zien of de automatisering uberhaupt wordt uitgevoerd en waarop het eventueel misloopt

[gielz]

Flexiilex schreef op woensdag 29 april 2026 @ 12:32:
[...]


Iemand enig idee waar ik nog kan kijken? goedkoopste uren zijn al begonnen meet de Gielz integratie triggert blijkbaar niet het laden. De sensor; sensor.dynamisch_goedkoopste_periode blijft ook op Nee staan terwijl de grafiek wel toont dat de goedkoopste uren zijn begonnen. waar zit dan de mismatch?

Ik zie dit in de details van de sensor, vermoed dat de "2026-04-29T11:45:00+02:00"" en dan voornamelijk de +02:00 er niet in hoort te staan? Hoe komt dit er in en hoe fix ik dit precies?

[Afbeelding]

Voeg eens een klok toe aan een dashboard. Je HA server leeft in een andere tijdzone. En controleer dit ook op de server zelf.

[Flexiilex]

gielz schreef op woensdag 29 april 2026 @ 13:15:
[...]


Voeg eens een klok toe aan een dashboard. Je HA server leeft in een andere tijdzone. En controleer dit ook op de server zelf.

Dat is wel raar want middels CLI heb ik de tijd opgehaald en die stond goed. automaten die m'n Tapwater om 13:00 doet werkt ook netjes. Als ik een klok toevoeg op m'n dashboard staat de tijd ook gewoon goed.

@gielz Als ik de goedkoopste periodes verhoog naar bijv 40 dan gaat het wel goed en dan zie je in het dashboard ook "Goedkoop" staan.

Edit; ik heb maar even de backup weer opnieuw terug gezet en kijk even wat dat doet. Ik snap er helemaal niks van iig..

[ Voor 30% gewijzigd door Flexiilex op 29-04-2026 14:34 ]

[drice]

Vraagje voor @gast777 , wellicht overbodig.
Ik heb nu een SF2400AC+ staan met 2 batterijen via Gielz en dat loopt goed. Nu heb ik de intentie om een extra SF2400AC+ erbij te doen, moet die per se 2 batterijen of kun je wegkomen met 1 extra. Ik begrijp dat idealiter je dezelfde hoeveelheid wil.

Tweede vraag, moeten beiden hetzelfde laadvermogen aankunnen. Dus als ik er eentje op een eigen groep heb en 2400/2400 en eentje op gedeelde groep. Is dit mogelijk met de flow of gaat het dan een zooitje worden?

[gast777]

drice schreef op woensdag 29 april 2026 @ 15:09:
Vraagje voor @gast777 , wellicht overbodig.
Ik heb nu een SF2400AC+ staan met 2 batterijen via Gielz en dat loopt goed. Nu heb ik de intentie om een extra SF2400AC+ erbij te doen, moet die per se 2 batterijen of kun je wegkomen met 1 extra. Ik begrijp dat idealiter je dezelfde hoeveelheid wil.

Ja idealiter beide dezelfde hoeveelheid batterijopslag. Het is niet een 100% vereiste, kan ook werken met verschillende, maar dan wordt het lastiger om de SoC % bij elkaar te houden.

Tweede vraag, moeten beiden hetzelfde laadvermogen aankunnen. Dus als ik er eentje op een eigen groep heb en 2400/2400 en eentje op gedeelde groep. Is dit mogelijk met de flow of gaat het dan een zooitje worden?

Ja dat is wel nodig. Je kunt maar 1 waarde invullen voor max ontlaadvermogen en 1 voor max oplaadvermogen (geen verandering tov 1 Zendure). Die wordt dan hetzelfde toegepast op beide Zendures. Dus als je 800 ontladen invult, dan geldt dat voor beide Zendures.

[c0mplex1]

zagreus schreef op dinsdag 28 april 2026 @ 20:10:
[...]


Ik heb dat wel geprobeerd: het werkt grotendeels of eigenlijk best goed. Het enige waar ik last van heb (en nog geen duidelijke oplossing) is dat elke +- 12min de zendure niet bereikbaar lijkt gedurende tientallen seconden: dat is niet handig voor NOM uiteraard. Geen idee waarom: geldt zowel voor mqtt als zensdk. Binnenkort wil ik verder testen maar als iemand ervaring / oplossing heeft, ben ik geinteresserd!

Dit 'probleem' heb (had) ik ook en opgelost door in de router al het uitgaande verkeer te blokkeren m.u.v. het DNS-verkeer wat via UDP poort 53 loopt.