Zendure producten in Home Assistant integreren deel 2

[gielz]

⛔ Zorg ervoor dat HEMS is uitgeschakeld in de Zendure-app ⛔

Beschik je over basiskennis van Home Assistant? Dan kun je hier direct mee aan de slag. Nieuw in Home Assistant? Wees gewaarschuwd: het is verslavend leuk om alles te automatiseren!
In dit topic bespreken we beide integraties en moedigen we je aan om je creativiteit te gebruiken. Deel je ervaringen — samen maken we het slimmer en beter.

Werkt bij jou alles naar wens? Deel dan even wat jij gebruikt in deze poll: https://strawpoll.com/05ZdzxXvmn6

*24-10-2025

🔋 Aansturing - zenSDK (Gielz) 🔋

Installatie	Github	https://github.com/Gielz1986/Zendure-HA-zenSDK
	Connectie	Lokaal
	Soort	Configuration.yaml + 1 automatisering
Aansturing	Omvormer(s)	Maximaal 1 omvormer ⛔
	Type(s)	Solarflow 2400 AC en Solarflow 800 pro (geen aangesloten zonnepanelen)
	Soort	zenSDK
Releasenotes	Github	https://github.com/Gielz1986/Zendure-HA-zenSDK/releases
Issues	Github	https://github.com/Gielz1986/Zendure-HA-zenSDK/issues

Informatie

Om in twee stappen je batterij lokaal werkend te krijgen in Home Assistant.

Gebaseerd op de zenSDK RESTful API voor Home Assistant. Deze setup maakt lokaal verbinding met één Zendure Solarflow 2400 AC / Zendure Solarflow 800 Pro (geen aangesloten zonnepanelen) zonder gebruik te maken van integraties maar werkt met één automatisering. Voor de gene die graag de batterij 100% lokaal in eigen beheer wilt zonder updates van derden en netjes in Home Assistant.

Modus opties

Standby	Zet volledig in standby en `sensor.zendure_2400_ac_opslagmodus` zal naar Opslaan in Flash gaan. Hierdoor is het ook 0 watt op een KWH MID Meter.
Handmatig	Via `input_number.zendure_2400_ac_handmatig_vermogen` kun je zelf aangeven wat de batterij doet.
Nul op de meter	Constant 0 op de meter behouden (-40 watt bij opladen en -2 watt bij ontladen).
Dynamisch NOM	⚠️ Let op: Alleen te gebruiken met Nordpool sensor. Wanneer `sensor.dynamisch_goedkoopste_periode` op JA staat zal er opgeladen worden indien `sensor.dynamisch_spread_indicatie_nom` hoger is dan `input_number.dynamisch_minimale_spread`. Wanneer `sensor.dynamisch_goedkoopste_periode` erg lang op JA staat zal hij pas weer gaan laden wanneer de batterij ontladen is tot 90%. Hij zal na laden constant 0 op de meter behouden (-40 watt bij opladen en -2 watt bij ontladen).
Alleen slim ontladen	Identiek aan Nul op de meter alleen zonder opladen.
Alleen slim opladen	Identiek aan Nul op de meter alleen zonder ontladen.
Opladen met 2400 watt	Snel opladen op maximaal vermogen.
Ontladen met 2400 watt	Snel ontladen op maximaal vermogen.

Aansturingslogboek

🔋 Aansturing - Zendure (voorheen Fireson) 🔋

Installatie	Github	https://github.com/Zendure/Zendure-HA
	Connectie	Lokaal en Cloud
	Soort	HACS integratie
Aansturing	Omvormer(s)	Geen maximum
	Type(s)	Hyper 2000, Solarflow 2400 AC en Solarflow 800 pro
	Soort	zenSDK en MQTT
Releasenotes	Github	https://github.com/Zendure/Zendure-HA/releases
Issues	Github	https://github.com/Zendure/Zendure-HA/issues

Informatie

Deze Home Assistant-integratie koppelt je Zendure-apparaten aan Home Assistant en maakt alle gerapporteerde parameters beschikbaar als entiteiten. Je kunt het batterijniveau, het energieverbruik en -opbrengst volgen, laadinstellingen beheren en je Zendure-apparaten opnemen in je thuisautomatiseringsroutines.

Daarnaast biedt de integratie een energiemanagerfunctie die kan helpen het energieverbruik te balanceren tussen meerdere apparaten wanneer een P1-meterentiteit wordt gebruikt.

Modus opties

Off	Zet in standby.
Manual Power	Kun je zelf aangeven wat de batterij doet.
Smart Matching	Constant 0 op de meter behouden.
Smart discharge only	Identiek aan Smart Matching alleen zonder opladen.
Smart charge only	Identiek aan Smart Matching alleen zonder ontladen.

Aansturingslogboek

🔋 Aansturing - zenSDK (zelfbouw) 🔋

Installatie	Github	https://github.com/Zendure/zenSDK
	Connectie	Lokaal
	Soort	Zelfbouw
Aansturing	Omvormer(s)	Geen maximum
	Type(s)	Solarflow 2400 AC en Solarflow 800 pro
	Soort	zenSDK

Informatie

Tijdens de ontwikkeling van ons vorige Device Data Report Project hebben we een sterke behoefte vastgesteld aan betere lokale controle. Als reactie hierop heeft het team het IoT-framework ZenSDK ontwikkeld

[ Voor 255% gewijzigd door gielz op 25-10-2025 11:38 ]

[jordyc]

Eventjes een wat meer algemene vraag. Zijn er hier al mensen die hebben nagedacht over de combinatie thuisbatterij en een EV? Wat voor slimmigheden hebben jullie al gebouwd om er voor te zorgen dat ze elkaar niet in de weg zitten?

Op dit moment heb ik in HA het volgende gebouwd met de fireson integratie en een aantal extra sensors van Bikkelreal:
Indien smart discharge actief en auto is aan het laden --> naar off mode
Indien smart mode en EV laden --> dan op smart charge.

Daarnaast laad ik de batterij altijd normaal laden in de goedkoopste uren, idee hierachter is dat de batterij juist voor de komende 24 uur is en duurdere afname moet voorkomen. De EV kan eventueel ook minder vol geladen als door load balancing de EV minder vol wordt geladen en de prijzen te hoog worden.

[JanHenk]

@gielz Mooi werk, is te volgen! Begrijp ik het nu goed dat je als het ware je eigen 'matching' (NOM) script hebt geschreven, dat iedere vier seconden wordt gedraaid om het vermogen van de batterij aan te passen?

Is het niet mogelijk om de NOM aansturing bij Zendure te laten en alleen te overschrijven als je 'iets anders' wil? Of werkt de NOM-aansturing van Zendure niet lokaal?

Werkt dit ook met meerdere batterijen? Of beter gezegd; omvormers?

[gielz]

Klopt het is de mijn eigen NOM met 1 automatisering. Elke 4 seconden gaat hij starten of balanceren in de huidige modus. De NOM aansturing van Zendure was ik niet tevreden over omdat ik het liever in eigen beheer heb en lokaal. Bij het testen van de 3CT als het internet weg was deed hij ook niets meer. De restful API aansturing ziet er dan zo uit vandaag (afgerond is het, maar het is 0,06kwh);



Hij is nu geschreven voor 1 omvormer. Maar hij is in theorie eenvoudig aan te passen naar 2 of meerdere omdat bij iedere optie/uitkomst hij aan de api gaat doorgeven wat nodig is. Stel je hebt dan 2 omvormers dan heb je uiteindelijk 2 acties waarbij je bijvoorbeeld set factor = 1.00 kun aanpassen naar de helft per omvormer.

Ik zal adviseren om ze gewoon alle 3 één voor één te proberen en daarna een eigen keuze te maken; (volgorde van hoeveel werk) Zendure, Fireson en Restful API. Wil je 100% lokaal dan is de keuze beperkter.

JanHenk schreef op dinsdag 17 juni 2025 @ 13:56:
@gielz Mooi werk, is te volgen! Begrijp ik het nu goed dat je als het ware je eigen 'matching' (NOM) script hebt geschreven, dat iedere vier seconden wordt gedraaid om het vermogen van de batterij aan te passen?

Is het niet mogelijk om de NOM aansturing bij Zendure te laten en alleen te overschrijven als je 'iets anders' wil? Of werkt de NOM-aansturing van Zendure niet lokaal?

Werkt dit ook met meerdere batterijen? Of beter gezegd; omvormers?

[Sander]

jordyc schreef op dinsdag 17 juni 2025 @ 07:38:
Eventjes een wat meer algemene vraag. Zijn er hier al mensen die hebben nagedacht over de combinatie thuisbatterij en een EV? Wat voor slimmigheden hebben jullie al gebouwd om er voor te zorgen dat ze elkaar niet in de weg zitten?

Op dit moment heb ik in HA het volgende gebouwd met de fireson integratie en een aantal extra sensors van Bikkelreal:
Indien smart discharge actief en auto is aan het laden --> naar off mode
Indien smart mode en EV laden --> dan op smart charge.

Daarnaast laad ik de batterij altijd normaal laden in de goedkoopste uren, idee hierachter is dat de batterij juist voor de komende 24 uur is en duurdere afname moet voorkomen. De EV kan eventueel ook minder vol geladen als door load balancing de EV minder vol wordt geladen en de prijzen te hoog worden.

Ik heb dit draaien en ik moet eerlijk zeggen dat het vooral zo min mogelijk doen is... kleine crosspost uit eigen werk van uit Sander in "Evcc slim laden met de zon en dynamische tarieven" topic:

EVCC pakt in mijn geval (tesla) alleen maar volle amperes omhoog of omlaag dus regelt niet erg fijnmazig. Dit gebeurd ook nog eens met een redelijke wachtperiode tussen schakelmomenten (omhoog/omlaag en aan/uit). Doordat de batterij sneller en fijnmaziger reageert (in tijd en afname/teruggifte) heeft die eigenlijk altijd al zijn vermogen 'geclaimd' voordat EVCC gaat beginnen en die past zich dan aan.

Gaat er kortstondig een wolk voor de zon dan begint evcc eerst met 'terugtellen' voor hij afschakelt en dan springt de batterij kortstondig bij en voorkomt netafname. Gaat de wolk weer weg, pakt de batterij eerst weer vermogen terug voor EVCC schakelt.

Battery-boost werkt op dezelfde manier automatisch: als er te weinig zon is en ik zet de auto op 'snel' laden dan gaat de energiemeter positieve waarden laten zien en springt de batterij ook weer bij.


In aanvulling hierop heb ik wel een paar slimme modes gedefineerd waarmee ik de batterij manipuleer:
- Alleen laden (= verbruiksmeter geef 0 door bij verbruik)
- Alleen ontladen (= verbruiksmeter geeft 0 door bij overschot).

Maar in de praktijk raak ik het eigenlijk niet aan. De essentie is dat mijn lader trager reageert dan de batterij en daarmee zit het elkaar niet in de weg. Behalve dat de batterij soms dus prioriteit neemt bij het opladen (want dan is hij sneller met beschikbaar overschot oppakken dan de TWC)

[ Voor 5% gewijzigd door Sander op 17-06-2025 17:03 ]

[wautah91]

Mooie startport @gielz! Bij de Fireson integratie zou je nog een link naar mijn blogpost kunnen toevoegen, waar ik uitgebreid in ga op het toevoegen van de Hyper2000 in Home Assistant. Ook heb ik het artikel inmiddels geupdatet met een paragraaf over de lokale MQTT aansturing.
https://www.twoenter.nl/b...ratie-met-home-assistant/

[zeegerd]

Mooi gedaan, goede (her)start zo!

Bij de nieuwere types (+API) is er hierboven al aandacht voor werken met RAM ipv flash, maar hoe zit dit bij de @FireSon-integratie? Daar zullen gebruikers vermoedelijk ook liever kiezen om flashgeheugen niet onnodig te belasten. Dit mis ik nog, lijkt me nuttig om toe te voegen.

Misschien ook al elders te vinden, bijv in een handleiding, dan kan ernaar verwezen worden uiteraard. Kan aan mij liggen maar ik heb het zo snel niet gevonden.

[Taro]

zeegerd schreef op woensdag 18 juni 2025 @ 09:45:
Mooi gedaan, goede (her)start zo!

Bij de nieuwere types (+API) is er hierboven al aandacht voor werken met RAM ipv flash, maar hoe zit dit bij de @FireSon-integratie? Daar zullen gebruikers vermoedelijk ook liever kiezen om flashgeheugen niet onnodig te belasten. Dit mis ik nog, lijkt me nuttig om toe te voegen.

Misschien ook al elders te vinden, bijv in een handleiding, dan kan ernaar verwezen worden uiteraard. Kan aan mij liggen maar ik heb het zo snel niet gevonden.

De Fireson integratie werkt met MQTT, de omvormers lezen de waardes af van een MQTT server en schrijven die waarde dus niet lokaal weg.

[gielz]

Weet je dat heel zeker? Want via postman zie je op de 2400 AC dat er wel data wegschreven word maar uiteraard dan wel in het RAM geheugen als de NOM modus aan staat.

Taro schreef op woensdag 18 juni 2025 @ 17:50:
[...]

De Fireson integratie werkt met MQTT, de omvormers lezen de waardes af van een MQTT server en schrijven die waarde dus niet lokaal weg.

[geert1992]

gielz schreef op woensdag 18 juni 2025 @ 18:49:
Weet je dat heel zeker? Want via postman zie je op de 2400 AC dat er wel data wegschreven word maar uiteraard dan wel in het RAM geheugen als de NOM modus aan staat.


[...]

Misschien moeten we onze @FireSon even taggen, om uitsluitsel te geven.

[Taro]

gielz schreef op woensdag 18 juni 2025 @ 18:49:
Weet je dat heel zeker? Want via postman zie je op de 2400 AC dat er wel data wegschreven word maar uiteraard dan wel in het RAM geheugen als de NOM modus aan staat.


[...]

@FireSon Naar mijn weten worden de waardes naar de Zendure of locale MQTT server gestuurd, waar de Hypers/2400AC/SF800Pro ze van ophalen en uitvoeren, correct? Komen daar Flash/RAM writes bij kijken op bijv. het eenmalig aanpassen van een AC-mode na?

[gielz]

Mooie guide/blog. Ik zal zeker een linkje verwerken in de TS.

wautah91 schreef op woensdag 18 juni 2025 @ 09:26:
Mooie startport @gielz! Bij de Fireson integratie zou je nog een link naar mijn blogpost kunnen toevoegen, waar ik uitgebreid in ga op het toevoegen van de Hyper2000 in Home Assistant. Ook heb ik het artikel inmiddels geupdatet met een paragraaf over de lokale MQTT aansturing.
https://www.twoenter.nl/b...ratie-met-home-assistant/

[geert1992]

Taro schreef op woensdag 18 juni 2025 @ 18:52:
[...]

@FireSon Naar mijn weten worden de waardes naar de Zendure of locale MQTT server gestuurd, waar de Hypers/2400AC/SF800Pro ze van ophalen en uitvoeren, correct? Komen daar Flash/RAM writes bij kijken op bijv. het eenmalig aanpassen van een AC-mode na?

Als ik het goed begrijp is het schrijven naar de flash nodig, zodat het apparaat verder gaat waar het gebleven is bij een onderbreking?
Kan je het dan niet testen? Een commando sturen, de ac2400 van de accu afhalen, en dan van de stroom, terug in het stopcontact en direct terug op de accu, en dan kijken wat hij doet?

[Taro]

geert1992 schreef op woensdag 18 juni 2025 @ 19:05:
[...]


Als ik het goed begrijp is het schrijven naar de flash nodig, zodat het apparaat verder gaat waar het gebleven is bij een onderbreking?

Ja, voor een handmatige AC-Mode instelling wel ja. Maar als hij dat via MQTT ophaalt in een slimme mode kan die dat vanaf de MQTT server halen en daarmee verder gaan, dan is schrijven/lezen uit RAM niet nodig volgens mij.

Kan je het dan niet testen? Een commando sturen, de ac2400 van de accu afhalen, en dan van de stroom, terug in het stopcontact en direct terug op de accu, en dan kijken wat hij doet?

Laat ik graag even aan anderen over

[gielz]

Heb ik getest bij de 2400 AC met smartmode = 1. Hierbij word de ACmode niet meer in het flashgeheugen geschreven zoals Zendure heeft aangegeven. De aansturing is dan exact zoals de 3CT en P1. Fireson Integratie (las ik in deel1) en de Restful API doen dit op dezelfde manier voor NOM. Voor de Restful API heb ik dit getest daarbij werd inderdaad de ACmode niet onthouden bij het uitzetten van de omvormer.

Hoe dit bij de Hyper is heb ik geen idee van maar wat ik uit de tekst van Zendure op maak is dat dit gewoon Flash is voor de ACmode.

For the device, each time the output mode is switched, it will be written to the flash. Why is it written? It is designed to ensure that the device can maintain the last state after power failure. For the new 2025 products, you can find a property called smartMode. Once the value is 1, the ac mode setting will no longer be written to the flash, so the flash life will be much longer.
Therefore, for linkage in ct mode, smartmode will be 1, and acmode can be set repeatedly to achieve a balance in overall household energy input and output.

Met 10 jaar garantie op beide producten moet het wel goed komen verwacht ik.

geert1992 schreef op woensdag 18 juni 2025 @ 19:05:
[...]


Als ik het goed begrijp is het schrijven naar de flash nodig, zodat het apparaat verder gaat waar het gebleven is bij een onderbreking?
Kan je het dan niet testen? Een commando sturen, de ac2400 van de accu afhalen, en dan van de stroom, terug in het stopcontact en direct terug op de accu, en dan kijken wat hij doet?

[ Voor 19% gewijzigd door gielz op 18-06-2025 20:16 ]

[FireSon]

Taro schreef op woensdag 18 juni 2025 @ 18:52:
[...]
@FireSon Naar mijn weten worden de waardes naar de Zendure of locale MQTT server gestuurd, waar de Hypers/2400AC/SF800Pro ze van ophalen en uitvoeren, correct? Komen daar Flash/RAM writes bij kijken op bijv. het eenmalig aanpassen van een AC-mode na?

Dat is correct. Het schrijven van properties zoals AC mode gaan waarschijnlijk wel naar de flash. De NOM commando's van de Smart mode niet. Ik heb het niet voor niets uitgezocht

[gielz]

Thanks, ik neem dit ook even op in de FAQ om te voorkomen dat hier over een tijdje weer vragen over komen.

FireSon schreef op donderdag 19 juni 2025 @ 08:29:
[...]

Dat is correct. Het schrijven van properties zoals AC mode gaan waarschijnlijk wel naar de flash. De NOM commando's van de Smart mode niet. Ik heb het niet voor niets uitgezocht

[Mediacj]

FireSon schreef op donderdag 19 juni 2025 @ 08:29:
[...]

Dat is correct. Het schrijven van properties zoals AC mode gaan waarschijnlijk wel naar de flash. De NOM commando's van de Smart mode niet. Ik heb het niet voor niets uitgezocht

Geldt dit ook als je in de manual-stand waarden invult bij het veld “Zendure Manager handmatig vermogen”?

[ Voor 11% gewijzigd door Mediacj op 19-06-2025 09:46 ]

[zeegerd]

Mediacj schreef op donderdag 19 juni 2025 @ 09:46:
[...]

Geldt dit ook als je in de manual-stand waarden invult bij het veld “Zendure Manager handmatig vermogen”?

Goeie, vroeg het me ook al af. Die lijkt op de native modi voor (ont)laden met vast vermogen, althans door mijn ogen.

[c0mplex1]

Dit is mijn eerste post hier op Tweakers, dus als ik iets niet goed doet alvast mijn excuses hiervoor.

Half juli hoop ik mijn SF2400AC + 2*AB3000X te mogen ontvangen.
Ervaring met een thuisbatterij heb ik nog niet.

Met veel interesse volg ik dan ook dit topic (en deel 1), met name de automatisering van @gielz, waar ik dan ook enkele vragen over heb.
Ik zal dan gelijk maar de koe bij de horens vatten:

Sensoren aanmaken:
Wat is het verschil tussen de rest commando's op regel 196 (zendure_x_laden) en regel 201 (zendure_x_laden_balanceren)
Waarom staat bij het ene commando de property "acMode":1 er bij en bij het andere commando niet?
Dit geldt ook zo bij de regels 206 en 211 ("acMode":2).
Kun je dan gewoon niet de property "acMode":x weg laten?

Waarom definieer je zoveel rest commando's als je er maar enkele(4) gebruikt?

Zendure NOM 1.00:
Regels 81, 199: waar verwijst de sensor.xxxx_2 naar toe?
Deze kom ik niet tegen in de sensoren lijst.
Regels 136-139: zijn deze niet overbodig, omdat je dit al met regels 131-133 onderzocht heb?
Regels 174, 195, 254: hier mis ik de "factor" correctie.
De kreten "enabled: true" die je her en der in de automatisering tegen komt zijn m.i. overbodig omdat je niets meer hoeft te testen.

Als ik de batterijen ontvangen heb en je automatisering gaat gebruiken, zullen er waarschijnlijk nog meer vragen bij mij op poppen.

[gielz]

Goed dat je zo naar de code kijkt. Hier werkt het allemaal prima maar er zal zeker wat spaghetti code in zitten wat beter kan. Ik heb even je punten 1 voor 1 bekeken en de antwoorden erbij gezet.

c0mplex1 schreef op donderdag 19 juni 2025 @ 12:18:
Wat is het verschil tussen de rest commando's op regel 196 (zendure_x_laden) en regel 201 (zendure_x_laden_balanceren)
Waarom staat bij het ene commando de property "acMode":1 er bij en bij het andere commando niet?
Dit geldt ook zo bij de regels 206 en 211 ("acMode":2).
Kun je dan gewoon niet de property "acMode":x weg laten?

Bij het starten zet hij de juiste ACmode, hierna gaat hij dit niet nogmaals via de API versturen. Tijdens het testen zag ik namelijk dat hij anders de ACmode weer opnieuw gaat opslaan wat een beetje overbodig is.

Waarom definieer je zoveel rest commando's als je er maar enkele(4) gebruikt?

Ze worden allemaal gebruikt, buiten de zendure_opslaan_in_flash. De NOM gebruikt er 5, de overige worden gebruikt in de selectielijst.

Zendure NOM 1.00:
Regels 81, 199: waar verwijst de sensor.xxxx_2 naar toe?
Deze kom ik niet tegen in de sensoren lijst.

verwijst naar unique_id: Zendure_2400_AC_Ingesteld_Oplaadvermogen en Zendure_2400_AC_Ingesteld_Ontlaadvermogen. Ik zal vanavond even kijken waarom hij hier _2 van gemaakt heeft want er is er maar 1.

Regels 136-139: zijn deze niet overbodig, omdat je dit al met regels 131-133 onderzocht heb?

Nee dit zijn 2 aparte onderdelen. Buiten het opwekseizoen geen gebruik maken van uitgesteld laden en binnen het opwekseizoen wel. Deze regels kunnen ook verwijderd worden maar dan gaat hij in de ochtend en avond hamsteren bij het opladen wat niet optimaal voor je RTE is.

Regels 174, 195, 254: hier mis ik de "factor" correctie.

Bij ontladen heet deze correctie en bij laden heet deze correctie_export. Dit zal ik even in de FAQ aanpassen.

De kreten "enabled: true" die je her en der in de automatisering tegen komt zijn m.i. overbodig omdat je niets meer hoeft te testen.

Stukje spaghetti code

Hopelijk zijn je batterijen er snel! Echt een mooi product.

[gielz]

Binnen de startpost kun je nu direct bovenaan de aanpassingen zien in de startpost. Dit om te voorkomen dat er iets gemist word wat wel relevant kan zijn voor de werking van de batterij.

Startpost aanpassingen

Algemeen

2025-06-19 - Startpost aanpassingen gesplitst per onderdeel.

Fireson integratie

2025-06-18 - FAQ toegevoegd met website waar meer uitleg gegeven word over over de integratie en leuke extra onderdelen.
2025-06-17 - FAQ toegevoegd met betrekking tot bluetooth proxy.

Restful API zenSDK

‪‪2025-06-19 ❤︎‬ CHANGE - Zendure NOM 1.00 Automatisering Tikfout gevonden in optie 5. Hier werd verwezen naar Zendure_2400_AC_Ingesteld_Oplaadvermogen_2 maar dit moet Zendure_2400_AC_Ingesteld_Oplaadvermogen zijn. De NOM werkwijze is en blijft hetzelfde, hij zal alleen nu geen API bericht meer versturen als het ingestelde vermogen gelijk is aan het gewenste vermogen. Dit komt bij opladen vaak voor als hij op de cap zit van 1200 watt en het is in het opwekseizoen.
2025-06-19 - FAQ update over correctie factor bij laden.

[ Voor 4% gewijzigd door gielz op 19-06-2025 14:43 ]

[c0mplex1]

@gielz Volgens mij zitten we niet helemaal op dezelfde golflengte.
Ik heb jouw rest template en automatisering aangepast en (voor mij) leesbaarder gemaakt.
Ook heb ik links en rechts wat foutjes eruit gehaald.
Het geheel (rest template en automatisering) is 100% ongetest op zijn werking.
Ik krijg (nog) geen foutmeldingen in HA, dus de syntax is goed, denk ik.
Hieronder wat ik nu heb:

code:

rest: #------------------------------------------------------------------------
  # HomeWizard Energy Socket
  - resource: http://192.168.0.xxx/api/v1/data
    scan_interval: 1
    sensor:
      - name: "HomeWizard Active Power"
        unique_id: d546d4e4-8bc5-427e-9c7a-ab894d5f2271
        value_template: "{{ value_json.active_power_w }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

  - resource: http://192.168.0.xxx/properties/report
    sensor:
    # Maximum Battery Temperature
      - name: "AB3000X-1 - Batterij Temperatuur"
        unique_id: 7d35f15c-d7fe-4945-80b6-9d1d4ad20252
        value_template: >
          {% set maxTemp = value_json['packData'][0]['maxTemp'] %}
          {{ ((maxTemp - 2731) / 10) | round(1) }} # Kelvin to Celsius
        unit_of_measurement: "°C"
        device_class: temperature
        icon: mdi:thermometer

    # Maximum Battery temperature
      - name: "AB3000X-2 - Batterij Temperatuur"
        unique_id: 2020e295-324a-4dd0-a640-e99ddb13c107
        value_template: >
          {% set maxTemp = value_json['packData'][1]['maxTemp'] %}
          {{ ((maxTemp - 2731) / 10) | round(1) }}
        unit_of_measurement: "°C"
        device_class: temperature
        icon: mdi:thermometer

    # Enclosure Temperature
      - name: "SolarFlow 2400 AC - Omvormer Temperatuur"
        unique_id: f77762b4-ca34-4732-99ba-cddbd7b18e57
        value_template: >
          {% set maxTemp = value_json['properties']['hyperTmp'] %}
          {{ ((maxTemp - 2731) / 10) | round(1) }}
        unit_of_measurement: "°C"
        device_class: temperature
        state_class: measurement
        icon: mdi:thermometer

    # Remaining Charge Time  (Resterende Oplaadtijd)
      - name: "SolarFlow 2400 AC - Resterende Oplaadtijd"
        unique_id: 49c24f72-d4a7-46f1-9a31-ff0603df2e4d
        value_template: >
          {% set total_minutes = value_json['properties']['remainInputTime'] %}
          {% set hours = (total_minutes // 60) %}
          {% set minutes = (total_minutes % 60) %}
          {{ hours }}u {{ minutes }}m

    # Remaining Discharge Time  (Resterende Ontlaadtijd)
      - name: "SolarFlow 2400 AC - Resterende Ontlaadtijd"
        unique_id: 84ded5b7-d876-41d6-b8bb-999533b156d0
        value_template: >
          {% set total_minutes = value_json['properties']['remainOutTime'] %}
          {% set hours = (total_minutes // 60) %}
          {% set minutes = (total_minutes % 60) %}
          {% if hours == 999 and minutes == 0 %}
            Niet bekend
          {% else %}
            {{ hours }}u {{ minutes }}m
          {% endif %}
        icon: mdi:clock-time-eight-outline

    # Battery Level  (Batterij)
      - name: "SolarFlow 2400 AC - Laadpercentage"
        unique_id: 6909394d-c240-4867-940d-aef46d25d835
        value_template: "{{ value_json['properties']['electricLevel'] }}"
        unit_of_measurement: "%"
        device_class: battery

    # SOC Minimaal
      - name: "SolarFlow 2400 AC - Minimale Laadpercentage"
        unique_id: 12f078b1-efcf-4dd3-83b4-f3b0a2a8426a
        value_template: "{{ value_json['properties']['minSoc'] / 10 }}"
        unit_of_measurement: "%"
        device_class: battery
        icon: mdi:battery-high

    # SOC Maximaal
      - name: "SolarFlow 2400 AC - Maximale Laadpercentage"
        unique_id: 408f88e3-2b74-4a6a-922f-2b4d650274a4
        value_template: "{{ value_json['properties']['socSet'] / 10 }}"
        unit_of_measurement: "%"
        device_class: battery
        icon: mdi:battery-high

    # AC Charging Power Limit  (Limiet Opladen)
      - name: "SolarFlow 2400 AC - Ingesteld Oplaadvermogen"
        unique_id: 5d1747d3-fb00-4995-ba2b-1ebf651b5509
        value_template: "{{ value_json['properties']['inputLimit'] }}"
        unit_of_measurement: "W"
        device_class: power

    # Home Output Power Limit  (Limiet Ontladen)
      - name: "SolarFlow 2400 AC - Ingesteld Ontlaadvermogen"
        unique_id: 3017561d-1262-4997-9848-ee4f791e8e85
        value_template: "{{ value_json['properties']['outputLimit'] }}"
        unit_of_measurement: "W"
        device_class: power

    # Output Power To Battery Pack (charging)  (Batterij Opladen)
      - name: "SolarFlow 2400 AC - Vermogen (opladen)"
        unique_id: a6178d62-24b1-426a-9cb6-8f070d572d79
        value_template: "{{ value_json['properties']['outputPackPower'] }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

    # Battery Pack Input Power (discharging)  (Batterij Ontladen)
      - name: "SolarFlow 2400 AC - Vermogen (ontladen)"
        unique_id: 639a4f52-c6cc-4275-9a51-e87907850fde
        value_template: "{{ - (value_json['properties']['packInputPower']) }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "SolarFlow 2400 AC - Vermogen (gecombineerd)"
        unique_id: 70f1cc7b-c278-4113-a779-26168f76515a
        value_template: >
          {% set opladen = value_json['properties']['outputPackPower'] %}
          {% set ontladen = - (value_json['properties']['packInputPower']) %}
          {% if opladen != 0 %}
            {{ opladen }}
          {% else %}
            {{ ontladen }}
          {% endif %}
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "SolarFlow 2400 AC - SOC Status"
        unique_id: 4274e3f6-dc19-42bc-9c3d-622947026555
        value_template: >
          {% set packState = value_json['properties']['socStatus'] %}
          {% set states = {0: "Goed", 1: "Kalibreren"} %}
          {{ states.get(packState, "Onbekend") }}
        icon: mdi:battery-heart-variant

    # AC Mode, 1: Input, 2: Output
      - name: "SolarFlow 2400 AC - Modes"
        unique_id: 754cf3a8-7983-46ec-b55b-8be6fb327369
        value_template: >
          {% set packState = value_json['properties']['acMode'] %}
          {% set states = {1: "Opladen", 2: "Ontladen"} %}
          {{ states.get(packState, "Onbekend") }}
        icon: mdi:battery-charging-wireless

      - name: "SolarFlow 2400 AC - Restapi Rate"
        unique_id: 43459046-75ef-48f2-a9c2-b6538238217c
        value_template: "{{ value_json['messageId'] }}"
        state_class: measurement
        icon: mdi:api

      - name: "SolarFlow 2400 AC - Opslagmodus"
        unique_id: f2e2066c-e658-4b6d-bb2e-04f2dd8bb128
        value_template: >
          {% set packState = value_json['properties']['smartMode'] %}
          {% set states = {1: "RAM", 0: "Flash"} %}
          {{ states.get(packState, "Onbekend") }}
        icon: mdi:floppy

      - name: "SolarFlow 2400 AC - Error"
        unique_id: a67d790a-87f1-42f3-aa08-b42f1b43311b
        value_template: >
          {% set packState = value_json['properties']['is_error'] %}
          {% set states = {0: "Geen", 1: "Zie Zendure APP"} %}
          {{ states.get(packState, "Onbekend") }}
        icon: mdi:battery-alert

rest_command: #----------------------------------------------------------------

  solarflow_2400_ac_x_opladen:
    url: "http://{{ ip }}/properties/write"
    method: POST
    payload: '{"sn":"{{ sn }}", "properties":{"acMode": 1, "inputLimit": {{inputLimit}} }}'

  solarflow_2400_ac_x_ontladen:
    url: "http://{{ ip }}/properties/write"
    method: POST
    payload: '{"sn":"{{ sn }}", "properties":{"acMode": 2, "outputLimit": {{outputLimit}} }}'

  solarflow_2400_ac_x_opladen_balanceren:
    url: http://{{ ip }}/properties/write
    method: POST
    payload: '{"sn":"{{ sn }}","properties":{"inputLimit": {{inputLimit}} }}'

  solarflow_2400_ac_x_ontladen_balanceren:
    url: http://{{ ip }}/properties/write
    method: POST
    payload: '{"sn":"{{ sn }}","properties":{"outputLimit": {{outputLimit}} }}'

  solarflow_2400_ac_stop_met_alles:
    url: "http://{{ ip }}/properties/write"
    method: POST
    payload: '{"sn":"{{ sn }}", "properties":{"inputLimit": 0, "outputLimit": 0 }}'

  solarflow_2400_ac_opslaan_in_ram:
    url: http://{{ ip }}/properties/write
    method: POST
    payload: '{"sn":"{{ sn }}","properties":{"smartMode": 1 }}'

# Riemann sum integral sensor t.b.v. vertonen in energy display ---------------

sensor:
  # Calculate the Power flowing into the battery in kWh
  - platform: integration
    name: "Energy to SolarFlow 2400 AC (gridInputPower)"
    unique_id: 575c7ded-b92c-4320-8ade-7615f604ea8e
    source: sensor.solarflow_2400_ac_vermogen_opladen
    unit_prefix: k
    round: 2
    max_sub_interval:
      minutes: 5

  # Calculate the Power feeding back to the home/grid in kWh
  - platform: integration
    name: "Energy from SolarFlow 2400 AC (outputHomePower)"
    unique_id: 51b8262f-f060-4bd4-8b07-be7919e7c3ee
    source: sensor.solarflow_2400_ac_vermogen_ontladen
    unit_prefix: k
    round: 2
    max_sub_interval:
      minutes: 5

input_select: #----------------------------------------------------------------

  solarflow_2400_ac_mode_select:
    name: SolarFlow 2400 AC - Mode Select
    options:
      - Nul op de meter
      - Alleen slim opladen
      - Alleen slim ontladen
      - Standby
      - Opladen met 800 Watt
      - Ontladen met 800 Watt
    initial: Nul op de meter
    icon: mdi:battery-charging-wireless

automation: #------------------------------------------------------------------

  - id: a3c54ca0-0b39-4fde-b8de-e3c19df00393
    alias: SolarFlow 2400 AC - NOM v1.01
    description: ""

    triggers:
      - trigger: time_pattern
        seconds: /4

    actions:
      - variables:
          p1mtr: "{{ states('sensor.p1_meter_power') | float(0) }}"
          hwpwr: "{{ states('sensor.homewizard_active_power') | float(0) }}"
          ipadd: 192.168.0.xxx
          serno: 123456789

      - choose:
          - alias: "Wanneer de opslagmodus op Flash of Onbekend staat deze op RAM instellen"
            conditions:
              - "{{ states('sensor.solarflow_2400_ac_opslagmodus') in ['Flash', 'Onbekend'] }}"
            sequence:
              - action: rest_command.solarflow_2400_ac_opslaan_in_ram
                data:
                  ip: "{{ ipadd }}"
                  sn: "{{ serno }}"

          - alias: "Start met ontladen bij +100 Watt (75% van de vraag)"
            conditions:
              - "{{ p1mtr > 100 }}"
              - "{{ -1 < hwpwr < 75 }}"
              - "{{ states('input_select.solarflow_2400_ac_mode_select') in ['Nul op de meter', 'Alleen slim ontladen'] }}"
              - or:
                  - "{{ is_state('sensor.solarflow_2400_ac_modus', 'Ontladen') }}"
                  - condition: state
                    entity_id: sensor.solarflow_2400_ac_modes
                    state: Opladen
                    for:
                      hours: 0
                      minutes: 0
                      seconds: 9
            sequence:
              - action: rest_command.solarflow_2400_ac_x_ontladen
                data:
                  ip: "{{ ipadd }}"
                  sn: "{{ serno }}"
                  outputLimit: >-
                    {% set cap = 800 %}     # Max. vermogen
                    {% set factor = 0.75 %}
                    {% set corr = 0 %}
                    {% set total = (p1mtr - hwpwr - corr) * factor %}
                    {{ ([max([total, 0]), cap] | min) | int }}

          - alias: "Tijdens ontladen balanceren naar 0 Watt (100% van de vraag)"
            conditions:
              - condition: template
                value_template: >-
                  {% set cap = 800 %}
                  {% set factor = 1.00 %}
                  {% set corr = 0 %}
                  {% set total = (p1mtr - hwpwr - corr) * factor %}
                  {% set target = ([max([total, 0]), cap] | min) | int %}
                  {% set current = states('sensor.zendure_2400_ac_ingesteld_ontlaadvermogen') | int(0) %}
                  {{ current != target }}
              - "{{ hwpwr < 0 }}"
              - "{{ states('input_select.solarflow_2400_ac_mode_select') in ['Nul op de meter', 'Alleen slim ontladen'] }}"
            sequence:
              - action: rest_command.solarflow_2400_ac_x_ontladen_balanceren
                data:
                  ip: "{{ ipadd }}"
                  sn: "{{ serno }}"
                  outputLimit: >-
                    {% set cap = 800 %}
                    {% set factor = 1.00 %}
                    {% set corr = 0 %}
                    {% set total = (p1mtr - hwpwr - corr) * factor %}
                    {{ ([max([total, 0]), cap] | min) | int }}

          - alias: "Start met opladen bij -100 Watt (alleen tussen 2u na ☀︎ en 1u voor ☾) (75% van aanbod)"
            conditions:
              - "{{ p1mtr < -100 }}"
              - "{{ -10 < hwpwr < 15 }}"
              - "{{ states('sensor.solarflow_2400_ac_laadpercentage') < 99 }}"
              - "{{ states('input_select.solarflow_2400_ac_mode_select') in ['Nul op de meter', 'Alleen slim opladen'] }}"
              - or:
                  - "{{ not (4 <= now().month <= 9) }}" # niet van april t/m september
                  - condition: sun
                    after: sunrise
                    before: sunset
                    after_offset: "+02:00:00"
                    before_offset: "-01:00:00"
              - not:
                  - condition: state
                    entity_id: sensor.solarflow_2400_ac_modus
                    state: Ontladen
                    for:
                      hours: 0
                      minutes: 0
                      seconds: 15
            sequence:
              - action: rest_command.solarflow_2400_ac_x_opladen
                data:
                  ip: "{{ ipadd }}"
                  sn: "{{ serno }}"
                  inputLimit: >-
                    {% set cap = 800 %}
                    {% set factor = 0.75 %}
                    {% set corr = 80 %}
                    {% set total = hwpwr - p1mtr - corr %}
                    {% set limited = total if total > 0 else 0 %}
                    {{ (limited if limited < cap else cap) | int }}

          - alias: "Tijdens opladen balanceren naar -80 Watt (alleen tussen 2u na ☀︎ en 1u voor ☾) (100% van aanbod)"
            conditions:
              - condition: template
                value_template: >-
                  {% set cap = 800 %}
                  {% set factor = 1.00 %}
                  {% set corr = 80 %}
                  {% set total = hwpwr - p1mtr - corr %}
                  {% set limited = total if total > 0 else 0 %}
                  {% set target = (limited if limited < cap else cap) | int %}
                  {% set current = states('sensor.zendure_2400_ac_ingesteld_oplaadvermogen') | int(0) %}
                  {{ current != target }}
              - "{{ hwpwr > 0 }}"
              - "{{ states('sensor.solarflow_2400_ac_laadpercentage') < 99 }}"
              - "{{ states('input_select.solarflow_2400_ac_mode_select') in ['Nul op de meter', 'Alleen slim opladen'] }}"
              - or:
                  - "{{ not (4 <= now().month <= 9) }}"
                  - condition: sun
                    after: sunrise
                    before: sunset
                    after_offset: "+02:00:00"
                    before_offset: "-01:00:00"
              - not:
                  - condition: state
                    entity_id: sensor.solarflow_2400_ac_modus
                    state: Ontladen
                    for:
                      hours: 0
                      minutes: 0
                      seconds: 15
            sequence:
              - action: rest_command.solarflow_2400_ac_x_opladen_balanceren
                data:
                  ip: "{{ ipadd }}"
                  sn: "{{ serno }}"
                  inputLimit: >-
                    {% set cap = 800 %}
                    {% set factor = 1.00 %}
                    {% set corr = 80 %}
                    {% set total = hwpwr - p1mtr - corr %}
                    {% set limited = total if total > 0 else 0 %}
                    {{ (limited if limited < cap else cap) | int }}

[avdwerf]

Heb de entities aangemaakt via de ZenSDK. Werkt allemaal prima. Iemand die al een leuke fancy kaart heeft gemaakt voor op het dashboard? Ik blijf voorlopig alleen uitlezen, aansturen doe ik nog even in Zendure app zelf.

[gielz]

Geen idee of dit binnen je eigen dashboard past maar hier gebruiken wij deze. De onderste grafiek is gemakkelijk over te nemen maar dan zonder de opkomst en ondergang lijn.

- Apexcharts
- 1 Sensor om P1 en de batterij te combineren.

avdwerf schreef op donderdag 19 juni 2025 @ 16:10:
Heb de entities aangemaakt via de ZenSDK. Werkt allemaal prima. Iemand die al een leuke fancy kaart heeft gemaakt voor op het dashboard? Ik blijf voorlopig alleen uitlezen, aansturen doe ik nog even in Zendure app zelf.

[c0mplex1]

@gielz Zou je de code van de onderste grafiek willen delen?
Dit bespaart om niet opnieuw het wiel te hoeven uitvinden.

[gielz]

Hierbij de grafiek, ik heb het config-template-card gedeelte er even uitgehaald voor de zonsopkomst en ondergang. In de header heb ik 2 dagelijkse nutsmeters die ik ook elders gebruik maar die kan je eventueel ook weghalen.

Voor het P1 vermogen inclusief batterij hanteer ik de onderstaande template sensor;

code:

{{
            (states('sensor.p1_meter_power') | float +
            (states('sensor.zendure_2400_ac_vermogen') | float * -1)) | round(0)
          }}

code:

type: custom:apexcharts-card
cache: true
update_interval: 5min
stacked: true
header:
  show: true
  show_states: true
  title: ""
graph_span: 24h
span:
  start: day
series:
  - entity: sensor.zendure_2400_ac_vermogen
    name: Batterij
    group_by:
      func: avg
      duration: 15min
    type: area
    transform: return -x;
    stroke_width: 0
    opacity: 1
    extend_to: now
    color: "#f1b605"
    float_precision: 0
    yaxis_id: energy
    show:
      in_header: false
  - entity: sensor.p1_vermogen_met_batterij
    name: P1 met batterij
    group_by:
      func: avg
      duration: 15min
    type: area
    stroke_width: 0
    opacity: 1
    extend_to: now
    color: "#46474c"
    float_precision: 0
    yaxis_id: energy
    show:
      in_header: false
  - entity: sensor.zendure_2400_ac_laadpercentage
    name: Laadpercentage
    type: line
    color: "#fff"
    opacity: 0
    stroke_width: 2
    extend_to: now
    curve: straight
    group_by:
      func: min
      duration: 15min
    show:
      in_header: false
  - entity: sensor.zendure_2400_ac_import_dagelijks
    yaxis_id: header_only
    name: Vandaag (geladen)
    show:
      in_header: true
      in_chart: false
  - entity: sensor.zendure_2400_ac_export_dagelijks
    yaxis_id: header_only
    name: Vandaag (ontladen)
    show:
      in_header: true
      in_chart: false
  - entity: sensor.zendure_2400_ac_laadpercentage
    yaxis_id: header_only
    name: SOC
    show:
      in_header: true
      in_chart: false
apex_config:
  tooltip:
    x:
      format: HH:mm
      show: false
  xaxis:
    labels:
      show: false
      style:
        colors: grey
    axisTicks:
      show: false
    axisBorder:
      color: "#616269"
  yaxis:
    - title:
        text: ""
      decimalsInFloat: 0
      labels:
        style:
          colors: "#7b7c83"
  grid:
    strokeDashArray: 0
    borderColor: rgb(52,52,52)
    show: true
  chart:
    height: 270px
  legend:
    show: false
  markers:
    size: 0
    hover:
      size: 0

c0mplex1 schreef op dinsdag 24 juni 2025 @ 13:04:
@gielz Zou je de code van de onderste grafiek willen delen?
Dit bespaart om niet opnieuw het wiel te hoeven uitvinden.

[jordyc]

@Taro ik heb de sensors gefixed en getest. De sensoren doen nu ook wat ik verwacht.

Wat is er anders:
- De wallbox gaf in kWh het vermogen, dit wordt nu maal 1000 gedaan om naar watts om te rekenen
- De input boolean op "off" betekent dat de auto NIET met de batterij opgeladen moet worden. Dit voelt iets intuitiever.

Negatieve sensor

code:

{% set vermogen = states('<sensor.p1_meter_vermogen>') | float(0) %}
{% set ev_vermogen = states('<sensor.EV_laadvermogen>')| float(0) * 1000 %}
{% set batterij_input = states('sensor.battery_input_total') | float(0) %}
{% set include_ev = is_state('<input_boolean.ev_laden_met_batterij_stroom>', 'off') %}

{% set netto_vermogen = vermogen - (ev_vermogen if include_ev else 0) %}

{% if netto_vermogen < 0 %}
  {{ netto_vermogen + 1 }}
{% elif netto_vermogen >0 and batterij_input != 0 %}
  {{ netto_vermogen + 1 }}
{% elif netto_vermogen > 0 and batterij_input == 0 %}
  {{ [netto_vermogen, 0] | max }}
{% else %}
  0
{% endif %}

Positieve sensor

code:

{% set vermogen = states('<sensor.p1_meter_vermogen>') | float(0) %}
{% set ev_vermogen = states('<sensor.EV_laadvermogen>') | float(0) * 1000 %}
{% set batterij_output = states('sensor.battery_output_total') | float(0) %}
{% set include_ev = is_state('<input_boolean.ev_laden_met_batterij_stroom>', 'off') %}

{% set netto_vermogen = vermogen - (ev_vermogen if include_ev else 0) %}

{% if netto_vermogen > 0 %}
  {{ netto_vermogen + 1 }}
{% elif netto_vermogen < 0 and batterij_output != 0 %}
  {{ netto_vermogen + 1 }}
{% elif netto_vermogen < 0 and batterij_output == 0 %}
  {{ [netto_vermogen, 0] | max }}
{% else %}
  0
{% endif %}

negative and positive sensor

code:

{% set vermogen = states('<sensor.p1_meter_vermogen>') | float(0) %}
{% set ev_vermogen = states('<sensor.EV_laadvermogen>') | float(0) * 1000 %}
{% set include_ev = is_state('<input_boolean.ev_laden_met_batterij_stroom>', 'off') %}

{{ (vermogen - (ev_vermogen if include_ev else 0)) + 1 }}

[ Voor 4% gewijzigd door jordyc op 24-06-2025 19:58 ]

[pfwolbers]

Ik wil binnenkort zonnepanelen gaan aansluiten op de hyper. Nu heb ik de hyper via de integratie van @FireSon werkend op home assistant.
Echter hoe krijg ik de zonne opbrengst goed in het energy dashboard zonder dat dit dubbel geteld wordt?
Er is een "totaal zonne energie" maar als ik de energie gebruik welke ik heb opgewekt dan komt deze ook terug bij "totaal geleverd". Of klopt dit niet?

[Taro]

pfwolbers schreef op dinsdag 24 juni 2025 @ 21:25:
Ik wil binnenkort zonnepanelen gaan aansluiten op de hyper. Nu heb ik de hyper via de integratie van @FireSon werkend op home assistant.
Echter hoe krijg ik de zonne opbrengst goed in het energy dashboard zonder dat dit dubbel geteld wordt?
Er is een "totaal zonne energie" maar als ik de energie gebruik welke ik heb opgewekt dan komt deze ook terug bij "totaal geleverd". Of klopt dit niet?

Je kunt hiervoor ook een Riemann helper op de DC/PV ingang waarde zetten en dat optellen. Zo heb ik het volgende overzichtje gemaakt:

[pfwolbers]

Ja, dat kan. Maar in het dashboard gaat dat volgens mij niet goed. De panelen op de hyper worden dan wel goed weergegeven, echter deze energie komt ook nog uit de batterij in het dashboard. Gaat dat dan wel goed met het totaal huis verbruik in het dashboard?
Dat is voor zover ik weet een berekening van zonne opbrengst + batterij uitvoer + net invoer. En dat totaal klopt dan niet meer aangezien de opbrengst van de zonnepanelen dubbel geteld wordt.

[Bra-Jo]

Ik had alles goed aan het draaien, dankzij een BT proxy. Nu heb ik mijn systeem uitgebreidmet een tweede Hyper en accu, en sindsdien heb ik weer freezes en moet ik Ha in zijn geheel herstarten om alles weer op de rit te krijgen. Nog niet echt onderzocht wat en hoe, doe ik binnenkort wanneer leven weer onder de 30 graden geleefd kan worden.

Wat ik me afvraag: hoe kan ik de maximale laadsnelheid begrenzen? Ivm veiligheid en C-waarde wil ik die op 500, maar krijg het niet voor elkaar. Input-limit lijkt niks te doen, maakt niet uit wat ik er instel. Ik kan het type cluster instellen, 800/1200/2400 enz. Dat lijkt ook niets te doen, heb ze nu beiden op 800 maar er wordt geladen op 900-1000. Wat doe ik verkeerd?

[Dolf_Tweakers]

Zijn er hier al Belgen die de Hyper met zonnepanelen i.s.m. HA en NodeRed gebruiken?
Wil er namelijk al wat tijd in steken om het een beetje onder de knie te krijgen.
Uiteraard zoveel als mogelijk zelf opgewekte zonnestroom gebruiken maar ook peak-shaving toepassen om capaciteitstarief net onder 2500W te houden.
Zal ook i.s.m. Marstek 5.12 zijn die via RS485 Modbus zal aangestuurd worden.
Wordt dus een hele uitdaging.

[Taro]

Bra-Jo schreef op zondag 29 juni 2025 @ 12:34:
Ik had alles goed aan het draaien, dankzij een BT proxy. Nu heb ik mijn systeem uitgebreidmet een tweede Hyper en accu, en sindsdien heb ik weer freezes en moet ik Ha in zijn geheel herstarten om alles weer op de rit te krijgen. Nog niet echt onderzocht wat en hoe, doe ik binnenkort wanneer leven weer onder de 30 graden geleefd kan worden.

Wat ik me afvraag: hoe kan ik de maximale laadsnelheid begrenzen? Ivm veiligheid en C-waarde wil ik die op 500, maar krijg het niet voor elkaar. Input-limit lijkt niks te doen, maakt niet uit wat ik er instel. Ik kan het type cluster instellen, 800/1200/2400 enz. Dat lijkt ook niets te doen, heb ze nu beiden op 800 maar er wordt geladen op 900-1000. Wat doe ik verkeerd?

Wat gebruik je, de FireSon integratie of als toevoeging daarop nog de "Fake meter" variant van @Bikkelreal ?

Je kunt zowel manual charging qua limiet instellen, als smart mode begrenzen. Hier werkt het nu al weken stabiel met een combinatie van beide en 3 Hypers via local MQTT en BT.

Dus: FireSon integratie altijd op Smart Mode, een fake P1-meter maken die qua waarde verandert. En daar kan je dan het vermogen voor laden/ontladen mee sturen. Zoals je hieronder ook ziet: Een 2400AC en Hyper op 1 groep samen doen 2800 Watt, terwijl ze samen 3600 Watt zouden kunnen doen.

Hierbij zie je mooi hoe dat werkt, de fake meter is -0.1 Watt, maar er wordt op dit moment wel 7910 Watt ontladen

[ Voor 4% gewijzigd door Taro op 29-06-2025 20:35 ]

[Bra-Jo]

Taro schreef op zondag 29 juni 2025 @ 20:29:
[...]

Wat gebruik je, de FireSon integratie of als toevoeging daarop nog de "Fake meter" variant van @Bikkelreal ?

Je kunt zowel manual charging qua limiet instellen, als smart mode begrenzen. Hier werkt het nu al weken stabiel met een combinatie van beide en 3 Hypers via local MQTT en BT.

Dus: FireSon integratie altijd op Smart Mode, een fake P1-meter maken die qua waarde verandert. En daar kan je dan het vermogen voor laden/ontladen mee sturen. Zoals je hieronder ook ziet: Een 2400AC en Hyper op 1 groep samen doen 2800 Watt, terwijl ze samen 3600 Watt zouden kunnen doen.

Hierbij zie je mooi hoe dat werkt, de fake meter is -0.1 Watt, maar er wordt op dit moment wel 7910 Watt ontladen
[Afbeelding]

Alleen de Fireson-integratie, met de P1-meter van Homewizard als "bron". De meter van Bikkelreal heb ik blijkbaar gemist, ga ik me even over inlezen.
Ik had verwacht dat het zou werken met de limiet instellen, dat heb ik ook in een automation meegenomen (set max input load to 500) maar dat (b)lijkt dus niet zo te zijn. Ik dacht even dat de automations misschien het probleem waren, maar zelfs wanneer die niet getriggerd worden, verliest HA af en toe de verbinding en moet ik heel HA herstarten om weer iets van actie te krijgen.

Misschien maar weer eens helemaal terug naar 0, zorgen dat communicatie blijft werken en da kijken wat er gebeurt met m'n aansturing.

[wautah91]

Bra-Jo schreef op maandag 30 juni 2025 @ 06:46:
[...]
Misschien maar weer eens helemaal terug naar 0, zorgen dat communicatie blijft werken en da kijken wat er gebeurt met m'n aansturing.

Dat denk ik ook. Want op de manier hoe jij aanstuurt doe ik het ook. Gewoon een automation die het output limit op 270W zet 's nachts, ongeveer gelijk aan mijn sluipverbruik.




ik heb scripts aangemaakt die door de automation worden uitgevoerd.

Opladen met 1200 Watt, maar je kunt zelf de waarde kiezen.

code:

sequence:
  - action: select.select_option
    metadata: {}
    data:
      option: input
    target:
      entity_id: select.hyper2000_ac_mode
    alias: AC mode input
  - action: number.set_value
    metadata: {}
    data:
      value: "0"
    target:
      entity_id: number.hyper2000_output_limit
  - action: number.set_value
    metadata: {}
    data:
      value: "1200"
    target:
      entity_id: number.hyper2000_input_limit
  - action: select.select_option
    metadata: {}
    data:
      option: "off"
    target:
      entity_id: select.zendure_manager_operation
  - action: input_text.set_value
    metadata: {}
    data:
      value: Volle snelheid opladen
    target:
      entity_id: input_text.gekozen_accustrategie
  - action: automation.turn_off
    metadata: {}
    data:
      stop_actions: true
    target:
      entity_id: automation.handmatige_nom_2
alias: "Thuisaccu: volle snelheid opladen"
description: ""

[ Voor 60% gewijzigd door wautah91 op 30-06-2025 08:16 . Reden: plaatje toegevoegd ]

[Bra-Jo]

wautah91 schreef op maandag 30 juni 2025 @ 08:12:
[...]


Dat denk ik ook. Want op de manier hoe jij aanstuurt doe ik het ook. Gewoon een automation die het output limit op 270W zet 's nachts, ongeveer gelijk aan mijn sluipverbruik.

[Afbeelding]


ik heb scripts aangemaakt die door de automation worden uitgevoerd.

Opladen met 1200 Watt, maar je kunt zelf de waarde kiezen.

code:

sequence:
  - action: select.select_option
    metadata: {}
    data:
      option: input
    target:
      entity_id: select.hyper2000_ac_mode
    alias: AC mode input
  - action: number.set_value
    metadata: {}
    data:
      value: "0"
    target:
      entity_id: number.hyper2000_output_limit
  - action: number.set_value
    metadata: {}
    data:
      value: "1200"
    target:
      entity_id: number.hyper2000_input_limit
  - action: select.select_option
    metadata: {}
    data:
      option: "off"
    target:
      entity_id: select.zendure_manager_operation
  - action: input_text.set_value
    metadata: {}
    data:
      value: Volle snelheid opladen
    target:
      entity_id: input_text.gekozen_accustrategie
  - action: automation.turn_off
    metadata: {}
    data:
      stop_actions: true
    target:
      entity_id: automation.handmatige_nom_2
alias: "Thuisaccu: volle snelheid opladen"
description: ""

Tnx, dat bevestigt dat mijn gedachtengang in ieder geval niet heel verkeerd was. Vanavond na werk maar weer eens puzzelen.

[Sander]

Bra-Jo schreef op maandag 30 juni 2025 @ 08:39:
[...]

Tnx, dat bevestigt dat mijn gedachtengang in ieder geval niet heel verkeerd was. Vanavond na werk maar weer eens puzzelen.

Zodra je de output limit zet gaat de hyper automatisch over naar die fixed limit output stand en stopt hij dus met smart matching modus van FireSon. Die switches (en dat vaak doen) gaven in eerdere releases vaker freezes etc.

Ik doe het dus ook met een input_select waarin ik de modus kies (of laat kiezen door de dynamische prijzen etc) En dan een template die op basis daarvan de powermeter die FireSon integratie oppakt weer manipuleert:

code:

{% set grid_power = (states("sensor.dsmr_reading_electricity_currently_delivered") | float(0) - states("sensor.dsmr_reading_electricity_currently_returned") | float(0)) * 1000 %}
{% set battery_power = ( states("sensor.hyper_2000_power_flow") | float(0)) %}
{% set charge_mode = states("input_select.thuisbatterij_modus") %}
{% if charge_mode == 'Geforceerd laden' %}
  -1250
{% elif charge_mode == 'Geforceerd ontladen' %}
  1000
{% elif charge_mode == 'Alleen Slim Laden' %}
  {% if grid_power > 0 %}
    {{ -battery_power }}
  {% else %}
    {{ min(0, grid_power) }}
  {% endif %}
{% elif charge_mode == 'Alleen Slim Ontladen' %}
  {% if grid_power < 0 %}
    {{ -battery_power }}
  {% else %}
    {{ max(0, grid_power) }}
  {% endif %}
{% else %} {# Default or any other state #}
  {{ grid_power }}
{% endif %}

Op deze manier zorg je er op een makkelijke manier voor dat je op ieder momnet gewoon de integratie hebt draaien maar zelf kan bijsturen wat er wel en niet mag gebeuren.

[Bra-Jo]

Sander schreef op maandag 30 juni 2025 @ 10:58:
[...]


Zodra je de output limit zet gaat de hyper automatisch over naar die fixed limit output stand en stopt hij dus met smart matching modus van FireSon. Die switches (en dat vaak doen) gaven in eerdere releases vaker freezes etc.

Ah dat zou in mijn geval veel verklaren, tnx!
Ik ben nog niet heel erg thuis in het gebruik van scripts, mijn automatiseringen zijn allemaal vrij simpel op basis van de gui. Tijd om me daar in te gaan verdiepen lijkt me. Bedankt allen!

[wautah91]

Bra-Jo schreef op dinsdag 1 juli 2025 @ 06:54:
[...]

Ah dat zou in mijn geval veel verklaren, tnx!
Ik ben nog niet heel erg thuis in het gebruik van scripts, mijn automatiseringen zijn allemaal vrij simpel op basis van de gui. Tijd om me daar in te gaan verdiepen lijkt me. Bedankt allen!

Je kunt de yaml code van de automatisering kopiëren en plakken in je automatisering door te kiezen voor 'Bewerken in yaml' in het menu. Daarna kun je terugswitchen naar de Visuele editor.

[TiBoD]

Ik heb wat zitten vibe coden en een Home Assistant integration gemaakt die de lokale API gebruikt. (Voor nu alleen reads; writes zijn nog TODO).

https://github.com/TimSoethout/home-assistant-zendure_local

Klik om via HACS te installeren:
https://my.home-assistant...ocal&category=integration

Wat vinden jullie er van? Nog doorontwikkelen? Ik weet niet of @FireSon de lokale API ook nog op de planning had staan, want dan voeg ik het liever samen natuurlijk.

[gielz]

Ik liep er hier vaak tegen aan dat je in de homewizard app niet makkelijk bijvoorbeeld even de laatste 15minuten kunt tonen met 5 seconden interval en daarbij aangeeft wat de import en export is en hoe deze aansluit op het huisvermogen (grijs gekleurd). Ik gebruik daarom nu de onderstaande Home Assistant apexchart.

Zijn hier nog andere tweakers met mooie dashboards om inspiratie op te doen?

[gielz]

Ziet er leuk uit! Maar denk wel dat de gebruikers vooral zoeken naar write opties en gewoon een te selecteren modus. Dit omdat sensoren vrij makkelijk zelf aan te maken zijn. Als dit zo doorgaat heeft iedereen wel een hoop te kiezen voor de aansturing en dat is zeker mooi!

Herkenbare rest_commands staan er al wel in zo te zien.

TiBoD schreef op donderdag 3 juli 2025 @ 15:15:
Ik heb wat zitten vibe coden en een Home Assistant integration gemaakt die de lokale API gebruikt. (Voor nu alleen reads; writes zijn nog TODO).

https://github.com/TimSoethout/home-assistant-zendure_local

Klik om via HACS te installeren:
https://my.home-assistant...ocal&category=integration

Wat vinden jullie er van? Nog doorontwikkelen? Ik weet niet of @FireSon de lokale API ook nog op de planning had staan, want dan voeg ik het liever samen natuurlijk.

[Afbeelding]

[avdwerf]

Iemand dit dit voor me kan verduidelijken. Ik heb 2 (of eigenlijk 4, hetzelfde voor ontladen) waardes waartussen ik het verschil niet weet. Werk met de ZenSDK uit de openingspost.
Uit de json properties
inputLimit -> Zendure_2400_AC_Ingesteld_Oplaadvermogen



En
outputPackPower -> Vermogen (opladen)


Zou verwachten dat die laatste het actuele vermogen toont en die eerst een vaste waarde is, maar beiden veranderen tijdens het opladen zoals te zien in de screenshots.

[gielz]

Bij grafiek 1 geef je aan via de restapi wat je wilt dat hij gaat laden. Vervolgens bij grafiek 2 wat hij daadwerkelijk van dit laden overneemt en met een cap van 2400 watt.

Lijkt mij op zich duidelijk omdat het ingesteld oplaadvermogen variabel is (grafiek 1) gaat de batterij ook variabel opladen (grafiek 2)

avdwerf schreef op vrijdag 4 juli 2025 @ 09:54:
Iemand dit dit voor me kan verduidelijken. Ik heb 2 (of eigenlijk 4, hetzelfde voor ontladen) waardes waartussen ik het verschil niet weet. Werk met de ZenSDK uit de openingspost.
Uit de json properties
inputLimit -> Zendure_2400_AC_Ingesteld_Oplaadvermogen

[Afbeelding]

En
outputPackPower -> Vermogen (opladen)
[Afbeelding]

Zou verwachten dat die laatste het actuele vermogen toont en die eerst een vaste waarde is, maar beiden veranderen tijdens het opladen zoals te zien in de screenshots.

[ Voor 20% gewijzigd door gielz op 04-07-2025 10:17 ]

[avdwerf]

gielz schreef op vrijdag 4 juli 2025 @ 10:13:
Bij grafiek 1 geef je aan via de restapi wat je wilt dat hij gaat laden. Vervolgens bij grafiek 2 wat hij daadwerkelijk van dit laden overneemt en met een cap van 2400 watt.

Lijkt mij op zich duidelijk omdat het ingesteld oplaadvermogen variabel is (grafiek 1) gaat de batterij ook variabel opladen (grafiek 2)

[Afbeelding]

[Afbeelding]


[...]

Aah oke. Ik heb de aansturing volledig in HEMS zelf zitten, gebruik HA alleen om uit te lezen. HEMS past dat dus continu aan op basis van de vraag/aanbod in mijn meterkast?

[gielz]

Ben niet echt bekend met HEMS, maar als het goed is stel je daar in hoe hij met je batterij om gaat. Heb je bijvoorbeeld een Shelly of een Ecotracker dan kun je daar naar kijken. Maar je zou nog even advies kunnen vragen in het algemene topic over HEMS en je huidige instellingen.

avdwerf schreef op vrijdag 4 juli 2025 @ 10:44:
[...]


Aah oke. Ik heb de aansturing volledig in HEMS zelf zitten, gebruik HA alleen om uit te lezen. HEMS past dat dus continu aan op basis van de vraag/aanbod in mijn meterkast?

[TiBoD]

gielz schreef op vrijdag 4 juli 2025 @ 09:14:
Ziet er leuk uit! Maar denk wel dat de gebruikers vooral zoeken naar write opties en gewoon een te selecteren modus. Dit omdat sensoren vrij makkelijk zelf aan te maken zijn. Als dit zo doorgaat heeft iedereen wel een hoop te kiezen voor de aansturing en dat is zeker mooi!

Herkenbare rest_commands staan er al wel in zo te zien.


[...]

Klopt, writes zijn wel echt nodig om het echt nuttig te maken.
Het is inderdaad geïnspireerd op jouw eerdere snippets. Zal je nog ergens credits geven.
Ik heb ook de discussie gevolgd over persistent writes, dus wou dat ook goed toevoegen.

Ik kan me wel voorstellen dat de Cloud/Fireson integratie dit uiteindelijk ook gaat ondersteunen, zeker aangezien hij samen met Zendure (gaat) samenwerken.

[geert1992]

@gielz Zou jij misschien een link in de TS willen delen naar de Homey integratie? Welke nu beschikbaar is gekomen. Of zou er in de toekomst een eigen topic gestart moeten worden bij meer interesse?

https://homey.app/nl-nl/app/com.zendure.flow/Zendure/

Het is natuurlijk een beetje grijs gebied om dit in het Home Assistant-integratietopic te vragen.

[ Voor 16% gewijzigd door geert1992 op 04-07-2025 12:49 ]

[gielz]

Zodra er meer Homey's zich hier melden zal ik een stukje opnemen naar deze nieuwe integratie. Apart topic kan denk ik ook wel maar ook wel fijn om alle aparte aansturingen onder 1 dak te hebben.

geert1992 schreef op vrijdag 4 juli 2025 @ 12:47:
@gielz Zou jij misschien een link in de TS willen delen naar de Homey integratie? Welke nu beschikbaar is gekomen. Of zou er in de toekomst een eigen topic gestart moeten worden bij meer interesse?

https://homey.app/nl-nl/app/com.zendure.flow/Zendure/

Het is natuurlijk een beetje grijs gebied om dit in het Home Assistant-integratietopic te vragen.

[Taro]

gielz schreef op vrijdag 4 juli 2025 @ 20:18:
Zodra er meer Homey's zich hier melden zal ik een stukje opnemen naar deze nieuwe integratie. Apart topic kan denk ik ook wel maar ook wel fijn om alle aparte aansturingen onder 1 dak te hebben.


[...]

Ja, graag allemaal hier. Mochten het nou 30 pagina's per dag worden kunnen we altijd verder kijken naar aparte topics.

[Taro]

Benieuwd: De nieuwe pre-release doet volgens mij iets met 2400 AC's, Bluetooth en local MQTT. Iemand daarmee een 2400 AC lokaal in gebruik?

Ik wil als ik terug ben van vakantie een keer van Zendure account wisselen in HA en 3x 2400AC ipv 3x Hyper gaan inzetten. Als dat namelijk goed werkt kan ik de Hypers verkopen en daarvoor extra AB3000X opslag halen. Van 6 naar 3 devices ruimt hier lekker op...

Of 3x 2400 AC lokaal aansturen, maar volgens mij zijn er nog geen scripts die de load over 2 of meerdere devices lokaal aansturen?

[gielz]

Voor de gene die nu een energy socket gebruiken en naar iets anders willen voor metingen buiten een KWH meter om. Ik ben nu de Shelly PM Mini Gen3 aan het testen;

https://www.bol.com/nl/nl...hAhA.4_13.14.ProductImage

code:

  - resource: http://192.168.0.227/rpc/PM1.GetStatus?id=0   # IP-adres van je Shelly PM Mini Gen3 voor API
    scan_interval: 1
    sensor:
      - name: "Shelly Zendure 2400 AC Vermogen Aansturing API"
        value_template: "{{ value_json.apower | float }}"
        unique_id: Shelly_Zendure_2400_AC_Vermogen_Aansturing_API
        unit_of_measurement: "W"
        device_class: power

[Dolf_Tweakers]

gielz schreef op zaterdag 5 juli 2025 @ 09:46:
Voor de gene die nu een energy socket gebruiken en naar iets anders willen voor metingen buiten een KWH meter om. Ik ben nu de Shelly PM Mini Gen3 aan het testen;

https://www.bol.com/nl/nl...hAhA.4_13.14.ProductImage

[Afbeelding]

code:

  - resource: http://192.168.0.227/rpc/PM1.GetStatus?id=0   # IP-adres van je Shelly PM Mini Gen3 voor API
    scan_interval: 1
    sensor:
      - name: "Shelly Zendure 2400 AC Vermogen Aansturing API"
        value_template: "{{ value_json.apower | float }}"
        unique_id: Shelly_Zendure_2400_AC_Vermogen_Aansturing_API
        unit_of_measurement: "W"
        device_class: power

Meet die bi-directioneel?
*edit* Was domme vraag, de foto was duidelijk

[gielz]

Was ik ook benieuwd naar, en ja dat doet hij. Alleen voor de KWH import data heb je alleen een import+export en export. De import moet je even oplossen met een simpele template sensor.




Heb nu alles omgebouwd en zal deze week het doortesten.

Dolf_Tweakers schreef op zaterdag 5 juli 2025 @ 09:58:
[...]


Meet die bi-directioneel?

[c0mplex1]

@gielz Ik heb wat vragen betreffende de timing van de automatisering en hardware.

Dat je om de 4 seconden de automatisering (Zendure NOM 1.00) start snap ik, want bij een kortere tijd bevriest de 2400AC en bij een langere tijd gaat de automatisering te ver uit de pas lopen.

Maar waarom lees je (met REST) de 2400AC om de 30 seconden uit en niet om de 4 seconden, want als je geen scan_interval definieer is de interval tijd standaard 30 sec.
Moet dit dan ook niet eens in de 4 seconden zijn, dus gelijk aan de automatisering?

Waarom lees je de HWE-P1 en HWE-SKT iedere seconde uit en niet eens in de 4 seconden.
Je gooit 3 samples weg, die gebruik je toch niet, omdat de automatiseering er niets mee doet, want die werkt maar 1x per 4 seconden. Dus ook hier de HWE-P1 en HWE-SKT 1x per 4 seconden uitlezen lijkt mij logischer.

[Taro]

@c0mplex1 Er zal ook een volgordelijkheid én stukje timing in zitten. Je stelt de 2400 AC het liefst in met de laatst bekende waarde van maximaal 1 seconde geleden en niet bijv. de waarde van 3-4 seconden geleden.

[gielz]

Dat was ook eerst hier het idee, waarom niet op een 4 seconden interval. Maar wanneer hij om de 4 seconden gaat kijken wat er moet gebeuren dan kan het zijn dat de P1 net nog zijn data moet verversen en je dus met oude data gaat werken. Hier ziet het er trouwens nu zo uit (laatste 30 minuten), dik tevreden;

*Batterij vermogen is omgedraaid in het dashboard - is laden + ontladen om gelijk te lopen met de P1.


De overige sensoren meer uitlezen doe ik zelf voorlopig niet omdat de batterij dan zal bevriezen. Dit is standaard 15 seconden bij de overige sensoren. Ik heb nog wel een vraag open staan wat de rate limiter is van de API.

Mocht je zelf tot iets komen wat beter werkt in de praktijk deel het vooral hier!

c0mplex1 schreef op zaterdag 5 juli 2025 @ 13:47:
@gielz Ik heb wat vragen betreffende de timing van de automatisering en hardware.

Dat je om de 4 seconden de automatisering (Zendure NOM 1.00) start snap ik, want bij een kortere tijd bevriest de 2400AC en bij een langere tijd gaat de automatisering te ver uit de pas lopen.

Maar waarom lees je (met REST) de 2400AC om de 30 seconden uit en niet om de 4 seconden, want als je geen scan_interval definieer is de interval tijd standaard 30 sec.
Moet dit dan ook niet eens in de 4 seconden zijn, dus gelijk aan de automatisering?

Waarom lees je de HWE-P1 en HWE-SKT iedere seconde uit en niet eens in de 4 seconden.
Je gooit 3 samples weg, die gebruik je toch niet, omdat de automatiseering er niets mee doet, want die werkt maar 1x per 4 seconden. Dus ook hier de HWE-P1 en HWE-SKT 1x per 4 seconden uitlezen lijkt mij logischer.

[c0mplex1]

Snap ik.
Wat ik niet snap is waarom de automatisering maar 1x per 4 seconde, en de aangeleverde data 1x per seconde.
Als alles via HA aangestuurd wordt zijn de start momenten, of het 1x per seconde of 1x per 4 seconden, gelijk.
b.v. om de 4 P1 triggers is gelijk aan elke automatisering trigger. HA gebruikt maar 1 klok, toch?

[c0mplex1]

@gielz We hebben gelijktijdig op de reageer knop gedrukt. Mijn antwoord was aan @Taro gericht.

Begrijp ik je goed dat als je de sensoren met een interval van 4 seconden uitleest, dat de 2400AC dan ook bevriest?
Waar baseer je die 15 seconden uitleestijd op? Die instelling kom ik nergens tegen.

[Taro]

c0mplex1 schreef op zaterdag 5 juli 2025 @ 14:22:
Snap ik.
Wat ik niet snap is waarom de automatisering maar 1x per 4 seconde, en de aangeleverde data 1x per seconde.
Als alles via HA aangestuurd wordt zijn de start momenten, of het 1x per seconde of 1x per 4 seconden, gelijk.
b.v. om de 4 P1 triggers is gelijk aan elke automatisering trigger. HA gebruikt maar 1 klok, toch?

HA zal taken serieel uitvoeren, niet parallel vermoed ik. Dus iedere 4 seconden betekent niet exact in dezelfde milliseconde. En het kan zijn dat het ophalen van de data net wat meer tijd kost dan het schrijven van de data naar een ander device en je dus een oude waarde gebruikt.

[gielz]

Ja de batterij zal dan bevriezen en dan moet je hem loskoppelen en van de batterijen aftillen. Ik zie bij de overige sensoren en eigenlijk alle standaard sensoren in HA altijd 15 seconden.

Maar waar loop je nu exact tegen aan in de praktijk? Gaat er iets niet goed?

c0mplex1 schreef op zaterdag 5 juli 2025 @ 14:32:
@gielz We hebben gelijktijdig op de reageer knop gedrukt. Mijn antwoord was aan @Taro gericht.

Begrijp ik je goed dat als je de sensoren met een interval van 4 seconden uitleest, dat de 2400AC dan ook bevriest?
Waar baseer je die 15 seconden uitleestijd op? Die instelling kom ik nergens tegen.

[c0mplex1]

De standaard (rest) scan_interval tijd heb ik hier vandaan.
Als je die op 15 seconden wilt hebben, zul je die parameter moeten invullen... denk ik.

Ik ben me aan het inleven hoe je de automatisering, met wat alles er bij hoort, tot stand hebt gebracht.
Tegen praktische problemen ben ik nog niet aangelopen, omdat ik nog wacht op de volledige levering van Zendure.

Ik ben wel bezig om jouw automatisering in één yaml bestand onder te brengen (rest, rest_command, input_select, Integral sensoren, etc.), zodat alles bij elkaar zit.
Ook dat deel waarmee je de automatisering uitschakelt ben ik aan het aanpassen.

[gielz]

Leuke hobby!

Hier heel specifiek alles gescheiden. Restful gaat via de configuration.yaml. Al het overige direct via de UI. Omdat het hele huis via HA draait moet herstarten echt tot het minimum beperkt worden.

Laat vooral weten hoe het allemaal draait zodra het binnen is en of je nog verbeteringen hebt doorgevoerd.

c0mplex1 schreef op zaterdag 5 juli 2025 @ 15:21:
De standaard (rest) scan_interval tijd heb ik hier vandaan.
Als je die op 15 seconden wilt hebben, zul je die parameter moeten invullen... denk ik.

Ik ben me aan het inleven hoe je de automatisering, met wat alles er bij hoort, tot stand hebt gebracht.
Tegen praktische problemen ben ik nog niet aangelopen, omdat ik nog wacht op de volledige levering van Zendure.

Ik ben wel bezig om jouw automatisering in één yaml bestand onder te brengen (rest, rest_command, input_select, Integral sensoren, etc.), zodat alles bij elkaar zit.
Ook dat deel waarmee je de automatisering uitschakelt ben ik aan het aanpassen.

[bert pit]

Mag ik hier ook een noob vraag stellen?
Ik heb geen ervaring met HA en wil er naar kijken om mijn twee Hypers ermee aan te sturen. Dus heb ik een oud laptopje voorzien van ubuntu en heb daar HA op gezet HA werkte op zich prima, maar het blijkt dat je daar geen HACS mee kan draaien dus ben ik overgestapt naar Debian. Op Debian loop ik vast in het besturingssysteem en krijg dat waarschijnlijk met veel gepruts/tijd wel voor elkaar. Maar het lijkt een beetje op het trekken aan een dood paard.

Mijn vraag aan de experts hier is wat voor een noob als mezelf de makkelijkste weg is om HA met HACS draaiend te krijgen. Is dat een HA green/yellow? Of loop ik daar tegen dezelfde problemen aan?

[ Voor 4% gewijzigd door bert pit op 05-07-2025 18:41 ]

[DaWizza]

@bert pit je vraag past wss beter in Home Assistant: Open source Python3 home automation - deel 5

Dan zou ik daar wel uitleggen waarom HACS installeren niet lukt, dat moet gewoon werken op een x86/64 systeem.

[jordyc]

bert pit schreef op zaterdag 5 juli 2025 @ 18:39:
Mag ik hier ook een noob vraag stellen?
Ik heb geen ervaring met HA en wil er naar kijken om mijn twee Hypers ermee aan te sturen. Dus heb ik een oud laptopje voorzien van ubuntu en heb daar HA op gezet HA werkte op zich prima, maar het blijkt dat je daar geen HACS mee kan draaien dus ben ik overgestapt naar Debian. Op Debian loop ik vast in het besturingssysteem en krijg dat waarschijnlijk met veel gepruts/tijd wel voor elkaar. Maar het lijkt een beetje op het trekken aan een dood paard.

Mijn vraag aan de experts hier is wat voor een noob als mezelf de makkelijkste weg is om HA met HACS draaiend te krijgen. Is dat een HA green/yellow? Of loop ik daar tegen dezelfde problemen aan?

Ik draai HA op een HA green en dat werkt perfect. Ideaal om laagdrempelig te starten.

[klump4u]

bert pit schreef op zaterdag 5 juli 2025 @ 18:39:
Mag ik hier ook een noob vraag stellen?
Ik heb geen ervaring met HA en wil er naar kijken om mijn twee Hypers ermee aan te sturen. Dus heb ik een oud laptopje voorzien van ubuntu en heb daar HA op gezet HA werkte op zich prima, maar het blijkt dat je daar geen HACS mee kan draaien dus ben ik overgestapt naar Debian. Op Debian loop ik vast in het besturingssysteem en krijg dat waarschijnlijk met veel gepruts/tijd wel voor elkaar. Maar het lijkt een beetje op het trekken aan een dood paard.

Mijn vraag aan de experts hier is wat voor een noob als mezelf de makkelijkste weg is om HA met HACS draaiend te krijgen. Is dat een HA green/yellow? Of loop ik daar tegen dezelfde problemen aan?

Ik heb op MP een Intel NUC gekocht met ssd, hier draait HA OS op en draait als een zonnetje, ook HACS

[c0mplex1]

Raspberry Pi 5 Model B - 8GB
Transcend 128GB microSD UHS-I U3 A2 Ultra performance 160/90 MB/s
Behuizing Argon Neo 5 BRED voor RPi 5 (Zwart/Rood)
Raspberry Pi 27W USB-C Power Supply - Wit

Kiwi Electronics +/- € 150,00

Mijn hele huis draait er op. (incl. EV, zonnepanelen, nog geen PiB)

[ Voor 13% gewijzigd door c0mplex1 op 05-07-2025 19:27 ]

[Taro]

Hier na ooit een RPI4 en daarna RPI5 te hebben gebruikt, inmiddels een Intel NUC i3 met 16 GB RAM en 256 GB SSD in gebruik voor Home Assistant. Via HA OS kan je ook Add-ons gebruiken en heb je dus alle mogelijkheden.

Wil je er veel mee doen en ben je er op een gegeven moment zelfs "afhankelijk" van? Ga dan niet voor een SD-kaart - die levensduur is beperkt en maak dus vooral dagelijks backups - maar ga voor een SSD en echte zuinige PC. De performance is echt stukken beter, helemaal als je in sommige gevallen heel HA regelmatig opnieuw moet opstarten zoals bij het debuggen van sommige nieuwe integraties weleens het geval is

[ Voor 5% gewijzigd door Taro op 05-07-2025 20:37 ]

[gielz]

Kijk ook vooral in huis wat je al hebt als je beginner bent. Heb je bijvoorbeeld een Synology NAS dan kun je daar ook gewoon Home Assistant OS erbij draaien. Hij staat al aan dus win-win.

Een collega die niets van Home Assistant wist heeft laatst een Home Assistant Green gekocht. Volgens hem de beste aankoop voor zijn smarthome hobby ooit.

[Taro]

gielz schreef op zaterdag 5 juli 2025 @ 20:49:
Kijk ook vooral in huis wat je al hebt als je beginner bent. Heb je bijvoorbeeld een Synology NAS dan kun je daar ook gewoon Home Assistant OS erbij draaien. Hij staat al aan dus win-win.

Een collega die niets van Home Assistant wist heeft laatst een Home Assistant Green gekocht. Volgens hem de beste aankoop voor zijn smarthome hobby ooit.

Idd, gewoon gratis beginnen. Ik had hiervoor Domoticz, vond Home Assistant een enorme drempel en achteraf dacht ik: Had ik jaren eerder moeten doen.

[remcoXP]

klopt het overigens dat als je voor de FireSon methode kiest je geen integral helpers hoeft aan te maken zoals in de wiki staat?
ik kon op het energie dashboard kiezen voor total geladen en total geleverd. dat is toch correct?

[gielz]

remcoXP schreef op zondag 6 juli 2025 @ 07:15:
klopt het overigens dat als je voor de FireSon methode kiest je geen integral helpers hoeft aan te maken zoals in de wiki staat?
ik kon op het energie dashboard kiezen voor total geladen en total geleverd. dat is toch correct?

Klopt, Fireson is een integratie waar alles voor je klaar gezet word. Is ook een apart onderdeel in de TS. 😉

[remcoXP]

dat klopt maar zijn github en de https://www.twoenter.nl/ blog schrijven er nog wel over, vandaar mijn verwarring

[Taro]

Ik wil graag NOM gaan draaien met 3x 2400 AC in Home Assistant en dus het verdelen van de load over 3x 2400 AC ipv 3x Hyper en 3x 2400 AC. Daarom zou ik graag het lokale NOM gebeuren van @gielz vertalen van 1 naar 2, 3 of meer devices via REST API of MQTT aansturing.

De FireSon integratie doet dat al netjes, die neemt omvormervermogen, SoC, etc. mee en berekent dan de input/output per device. Nadeel is dat ik dit nog niet stabiel werkend heb gekregen voor meerdere 2400 AC's. Ik zal eerlijk zijn, ik zit er niet op te wachten dit helemaal zelf te gaan scripten.

Heeft iemand al een script of automatisering die op basis van 2 of meer Zendure 2400AC devices icm lokale aansturing NOM bereikt?

[mrme12345]

Taro schreef op zondag 6 juli 2025 @ 18:40:
Ik wil graag NOM gaan draaien met 3x 2400 AC in Home Assistant en dus het verdelen van de load over 3x 2400 AC ipv 3x Hyper en 3x 2400 AC. Daarom zou ik graag het lokale NOM gebeuren van @gielz vertalen van 1 naar 2, 3 of meer devices via REST API of MQTT aansturing.

De FireSon integratie doet dat al netjes, die neemt omvormervermogen, SoC, etc. mee en berekent dan de input/output per device. Nadeel is dat ik dit nog niet stabiel werkend heb gekregen voor meerdere 2400 AC's. Ik zal eerlijk zijn, ik zit er niet op te wachten dit helemaal zelf te gaan scripten.

Heeft iemand al een script of automatisering die op basis van 2 of meer Zendure 2400AC devices icm lokale aansturing NOM bereikt?

Ik gebruik een NOM waarbij ik een 2400 AC en een SF 800 Pro combineer. De NOM is gecodeerd via node red.

Bij SoC werkt die zo dat wanneer 1 van de 2 soc hoger is dan ontlaadt die zoveel als mogelijk met de hoogste soc en restant met soc 2.

Daarnaast ook tot 250w wordt het beperkt tot 1 device (om onnodige kleine loads te krijgen).

Het een en ander is ook makkelijk uit te breiden. En dat ga ik ook nog doen (met 1 hyper fireson erbij), maar dat heb ik nu nog niet nodig. Komt van de winter wel

Als je die wil gebruiken laat maar weten dan dm ik die wel even.

[Aziraphale]

Naar aanleiding van een DM wisseling met @Taro hier verder met mijn zoektocht naar hoe ik de Hyper goed kan laten werken met dynamische prijzen. In het algemene Zendure topic was er al code door Taro gedeeld en ik heb ook een handleiding online gevonden, maar die is nog niet genoeg "voor Dummies" om mij het te laten begrijpen.

Ik heb inmiddels zowel de Cheapest Energy Hours van The Fez als AIO Energy Management en Nord Pool geïnstalleerd, dus daarmee kan ik werken. Vervolgens moet ik templates aanmaken en dat kan ik ook, maar welke sensoren moet ik dan gebruiken? De handleiding die ik heb geeft het volgende:

code:

{% from 'cheapest_energy_hours.jinja' import cheapest_energy_hours %}
{{ cheapest_energy_hours('sensor.nordpool_kwh_nl_eur_4_09_021', attr_today='Today', hours=6, split=true, lowest=True, mode='is_now', value_key='price', time_key='time') }}

Maar de sensor die hierin genoemd wordt heb ik zelf niet. En ook in de gedeelde YAML in het andere topic zal ik zaken aan moeten passen voor mijn apparatuur, maar wat? Er is ook sprake van een visuele IFTT editor en dat zou me al een hoop helpen, want ik kon vroeger in Domoticz wel redelijk overweg met Blockly.

Mijn PV is niet rechtstreeks aangesloten op het Hyper, dus hij zal bij invoeding van PV naar het net moeten laden en als er geen PV overschot is op de goedkope uren vanuit het net. Verder streef ik dan naar NOM en daarna naar ontladen op dure uren. Dat laatste is nu nog niet echt van toepassing omdat ik nu de accu's aardig leeg trek gedurende de avond/nacht. Ik ben echter al aan het nadenken over uitbreiding en dan wordt dat waarschijnlijk wel interessant.

[Taro]

@Aziraphale Welke Nord Pool sensor je hebt hangt af van of je deze bijv. incl. of excl. BTW hebt aangemaakt. Heb je een andere dan kan je die prima gebruiken.

Als je mijn code hergebruikt heb je veel sensoren/entiteiten die inderdaad niet bekend zijn. Maar, als dat aangepast/hersteld is ziet het er in de WYSIWIG editor zo uit (2 bovenste delen, de rest herhaalt dit principe):




Waarbij dan de IF checkt in de 1e stap op:


En voor de 2e stap op:


Hopelijk helpt dat in het begrijpelijk maken?

[robkds]

Voor degenen (zoals ik) die met de restful API een Solarflow 800 Pro gebruiken, met deze code in je configuration.yaml kan je de PV inputs uitlezen:

code:

#begin PV input
      - name: "Zendure 2400 AC solarInputPower"
        value_template: "{{ value_json['properties']['solarInputPower'] }}"
        unique_id: Zendure_2400_AC_solarInputPower
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure 2400 AC PV1"
        value_template: "{{ value_json['properties']['solarPower1'] }}"
        unique_id: Zendure_2400_AC_PV1
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure 2400 AC PV2"
        value_template: "{{ value_json['properties']['solarPower2'] }}"
        unique_id: Zendure_2400_AC_PV2
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure 2400 AC PV3"
        value_template: "{{ value_json['properties']['solarPower3'] }}"
        unique_id: Zendure_2400_AC_PV3
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure 2400 AC PV4"
        value_template: "{{ value_json['properties']['solarPower4'] }}"
        unique_id: Zendure_2400_AC_PV4
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
#einde PV input

Dit moet je dus bij het stuk met de sensors toevoegen.

[Aziraphale]

@Taro Hier kan ik al een stuk meer uit halen, thanks! De Nord Pool integratie heb ik gewoon geïnstalleerd en volgens mij heb ik daar verder niets bij aan kunnen geven qua btw. Niet dat dat veel uit zal maken voor de goedkope en dure uren, lijkt me?

[Taro]

Aziraphale schreef op zondag 6 juli 2025 @ 20:26:
@Taro Hier kan ik al een stuk meer uit halen, thanks! De Nord Pool integratie heb ik gewoon geïnstalleerd en volgens mij heb ik daar verder niets bij aan kunnen geven qua btw. Niet dat dat veel uit zal maken voor de goedkope en dure uren, lijkt me?

Ik heb in de configuration.yaml nog het volgende staan om de Nord Pool tarieven gelijk te krijgen aan de Zonneplan tarieven:

YAML:

  - platform: nordpool
    VAT: False
    currency: "EUR"
    price_in_cents: false
    low_price_cutoff: 0.9
    region: "NL"
    precision: 3
    price_type: kWh
    additional_costs: >
      {% set VAT = 0.21 %}
      {% set tax_kWh = 0.10154 %}
      {% set opslag = 0.0165 %}
      {{ (current_price * VAT ) + (tax_kWh + opslag) * (1 + VAT)|float }}

Als je Nord Pool tarieven nu al correct zijn, dan moet je gewoon de huidige beschikbare sensor gebruiken.

[Aziraphale]

Taro schreef op zondag 6 juli 2025 @ 20:28:
[...]

Ik heb in de configuration.yaml nog het volgende staan om de Nord Pool tarieven gelijk te krijgen aan de Zonneplan tarieven:

YAML:

  - platform: nordpool
    VAT: False
    currency: "EUR"
    price_in_cents: false
    low_price_cutoff: 0.9
    region: "NL"
    precision: 3
    price_type: kWh
    additional_costs: >
      {% set VAT = 0.21 %}
      {% set tax_kWh = 0.10154 %}
      {% set opslag = 0.0165 %}
      {{ (current_price * VAT ) + (tax_kWh + opslag) * (1 + VAT)|float }}

Als je Nord Pool tarieven nu al correct zijn, dan moet je gewoon de huidige beschikbare sensor gebruiken.

Die zijn bij mij absoluut niet correct, dus dit stukje is voor mij zeker interessant. Heb je dit zoals het hier staan in de configuration.yaml staan of onder een bepaald kopje?

[Taro]

Aziraphale schreef op zondag 6 juli 2025 @ 22:45:
[...]


Die zijn bij mij absoluut niet correct, dus dit stukje is voor mij zeker interessant. Heb je dit zoals het hier staan in de configuration.yaml staan of onder een bepaald kopje?

In de configuration.yaml.

Iemand wees hier laatst op de optie om een mapje te maken, met bijv. daarin:

zendure.yaml
nordpool.yaml
ecotracker.yaml
etc.

En dan het mapje te includen via de configuration.yaml, maar daarna werkte er helaas niets meer. Dus heb nu alles wederom in 1 bestand staan.

[Aziraphale]

Taro schreef op zondag 6 juli 2025 @ 22:47:
[...]

In de configuration.yaml.

Iemand wees hier laatst op de optie om een mapje te maken, met bijv. daarin:

zendure.yaml
nordpool.yaml
ecotracker.yaml
etc.

En dan het mapje te includen via de configuration.yaml, maar daarna werkte er helaas niets meer. Dus heb nu alles wederom in 1 bestand staan.

Ik heb ook alles daarin staan, maar dat staat dan gegroepeerd onder kopjes als 'template', 'sensor' etc. Dat hoeft hierbij dus niet?

[Taro]

@Aziraphale De Nord Pool config heb ik inderdaad bij het "sensor" onderdeel staan. Dus:

sensor:
- platform: nordpool

[remcoXP]

vandaag de pre versie uit hacs geinstalleerd omdat ik toch maar lokal MQTT, BLE wilde gebruiken.

ik gebruik: EMQX als broker en daarin heb ik de user aangemaakt met alle rechten die in de debuglog van fireson staat.
Echter ben ik nu bijna alle devices kwijt en blijft de status BLE zijn. Heb ik nu wat gemist of moet ik nog wat proberen?

[mrme12345]

remcoXP schreef op maandag 7 juli 2025 @ 08:47:
vandaag de pre versie uit hacs geinstalleerd omdat ik toch maar lokal MQTT, BLE wilde gebruiken.

ik gebruik: EMQX als broker en daarin heb ik de user aangemaakt met alle rechten die in de debuglog van fireson staat.
Echter ben ik nu bijna alle devices kwijt en blijft de status BLE zijn. Heb ik nu wat gemist of moet ik nog wat proberen?

Dan kun je het beste de mqtt reset proberen en als dat niet werkt HA nog een keer opnieuw opstarten

[remcoXP]

gedaan maar helaas, debugging log geeft ook niets raars aan behalve dat hij een getall doet en dat lijkt te werken. geen connection errors of deny oid.
zou niet aan het feit mogen liggen dat ik een andere broker gebruik.

als ik met de user en pass die in de logs staat probeer in te loggen in mqtt explorer zie en kan ik alles

nu weet mqtt lokal uitgezet en alle devices werken weer

[mrme12345]

remcoXP schreef op maandag 7 juli 2025 @ 09:23:
gedaan maar helaas, debugging log geeft ook niets raars aan behalve dat hij een getall doet en dat lijkt te werken. geen connection errors of deny oid.
zou niet aan het feit mogen liggen dat ik een andere broker gebruik.

als ik met de user en pass die in de logs staat probeer in te loggen in mqtt explorer zie en kan ik alles

nu weet mqtt lokal uitgezet en alle devices werken weer

Ja dat heb ik ook tijdje gehad, dat als ik de mqtt lokal uit zet dat die het dan weer goed deed. Maar sinds laatste versie doet de local het ook prima (wel paar keer oflline enz, maar dat heb ik nu gerepareerd door elke nacht sowieso een reset te doen en bericht als meer dan 30sec geen wijziging.). Waar dit dan precies aan ligt weet ik niet. Paar keer herstarten wordt ook wel eens geadviseerd. Of je mqtt gebruiker verwijderen, integratie verwijderen en weer opnieuw proberen.

Ik moet ook zeggen dat de rest api variant bij mij veel stabieler is dan de fireseon. Maar is ook work in progress en uiteindelijk wel samenwerking met zendure. Dus even afwachten hoe het verder gaat.

[ Voor 9% gewijzigd door mrme12345 op 07-07-2025 09:38 ]

[Aziraphale]

@Taro Ik ben er mee aan het stoeien en begin het wat te doorgronden (en ik zal het aan de gang krijgen, al is het alleen maar om het te snappen ), maar ik vroeg me nog wel af wat het verschil is tussen de manier via HA en de Electricity Price Mode in HEMS. Komt die twee niet eigenlijk op hetzelfde neer?

[mrme12345]

robkds schreef op zondag 6 juli 2025 @ 20:20:
Voor degenen (zoals ik) die met de restful API een Solarflow 800 Pro gebruiken, met deze code in je configuration.yaml kan je de PV inputs uitlezen:

code:

#begin PV input
      - name: "Zendure 2400 AC solarInputPower"
        value_template: "{{ value_json['properties']['solarInputPower'] }}"
        unique_id: Zendure_2400_AC_solarInputPower
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure 2400 AC PV1"
        value_template: "{{ value_json['properties']['solarPower1'] }}"
        unique_id: Zendure_2400_AC_PV1
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure 2400 AC PV2"
        value_template: "{{ value_json['properties']['solarPower2'] }}"
        unique_id: Zendure_2400_AC_PV2
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure 2400 AC PV3"
        value_template: "{{ value_json['properties']['solarPower3'] }}"
        unique_id: Zendure_2400_AC_PV3
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure 2400 AC PV4"
        value_template: "{{ value_json['properties']['solarPower4'] }}"
        unique_id: Zendure_2400_AC_PV4
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
#einde PV input

Dit moet je dus bij het stuk met de sensors toevoegen.

Is er een reden waarom je die 2400 AC noemt ondanks dat het over de 4 pv inputs van de sf 800 pro gaat?

[robkds]

mrme12345 schreef op maandag 7 juli 2025 @ 10:12:
[...]

Is er een reden waarom je die 2400 AC noemt ondanks dat het over de 4 pv inputs van de sf 800 pro gaat?

Ja, zo kon ik het script van @gielz gewoon gebruiken zonder zoek-en-vervang acties. Pure luiheid dus

[mrme12345]

robkds schreef op maandag 7 juli 2025 @ 11:18:
[...]

Ja, zo kon ik het script van @gielz gewoon gebruiken zonder zoek-en-vervang acties. Pure luiheid dus

Ok dan snap ik het weer .

[Taro]

Aziraphale schreef op maandag 7 juli 2025 @ 10:02:
@Taro Ik ben er mee aan het stoeien en begin het wat te doorgronden (en ik zal het aan de gang krijgen, al is het alleen maar om het te snappen ), maar ik vroeg me nog wel af wat het verschil is tussen de manier via HA en de Electricity Price Mode in HEMS. Komt die twee niet eigenlijk op hetzelfde neer?

Mijn automatisering vs HEMS bedoel je?

Heb 5 knoppen (booleans) gemaakt die te combineren zijn:

• Onder de 20 cent laden
• Goedkoopste 5 uren laden (op zondag: 6 ivm 100%)
• Duur ontladen
• EV laden uit de accu's
• NOM

En mijn automatisering houdt daar dan rekening mee. Bijv.:

• 5 duurste uren onder de 35 cent: Gemiddeld ontladen
• 5 duurste uren boven de 35 cent: Maximaal ontladen
• 5 goedkoopste uren: Maximaal laden
• Onder de 20 cent, maar niet de goedkoopste uren: Smart charging
• Boven de 20 cent, maar niet de duurste uren: Smart discharging
• Anders: NOM.

Waarbij 5 duurste uren betekent: 3 duurste in de avond en 2 duurste in de ochtend. Gemiddeld gezien zijn dat de duurste 5 van de dag én je zorgt ervoor dat je accu's de rest van de tijd voldoende kWh's hebben voor NOM én dat ze volledig leeg zijn voordat het laden begint.

Vandaag einde ochtend duur ontladen uitgezet, goedkoop inkopen uit, onder de 20 cent laden aan en draait nu NOM t/m morgen 13:00 als er weer een paar uur geladen gaat worden.


Paar dagen gelezen had ik wel goedkoop inkopen en duur ontladen aan (Y-as begint bij -7000 Watt):


Dus nee, niet (exact) hetzelfde als HEMS. Heb Zendure wel uitgebreide feedback gegeven over HEMS, dus hopelijk is dit spoedig ook native mogelijk

[Aziraphale]

@Taro Ik geloof dat ik eens ga kijken naar de Claude Code addon om me hiermee te helpen. Het ziet er allemaal prachtig uit, maar ik vrees dat me dit niet gaat lukken zonder stapsgewijze handleiding met alle sensoren die ik nodig heb en moet maken. Ik zie namelijk al sensoren voorbij komen die ik bij mij niet kan vinden en dus zal moeten maken. Wat dat betreft is HA toch wel een lastiger systeem dan Homey, wat @geert1992 met net heeft gedemonstreerd.

[geert1992]

Aziraphale schreef op maandag 7 juli 2025 @ 21:21:
@Taro Ik geloof dat ik eens ga kijken naar de Claude Code addon om me hiermee te helpen. Het ziet er allemaal prachtig uit, maar ik vrees dat me dit niet gaat lukken zonder stapsgewijze handleiding met alle sensoren die ik nodig heb en moet maken. Ik zie namelijk al sensoren voorbij komen die ik bij mij niet kan vinden en dus zal moeten maken. Wat dat betreft is HA toch wel een lastiger systeem dan Homey, wat @geert1992 met net heeft gedemonstreerd.

Bedankt voor de koffie! Gezellig om een mede tweaker te ontmoeten!

[Aziraphale]

geert1992 schreef op maandag 7 juli 2025 @ 21:51:
[...]


Bedankt voor de koffie! Gezellig om een mede tweaker te ontmoeten!

Insgelijks!

[Taro]

@geert1992 Welke koffie is lekkerder?

[ Voor 3% gewijzigd door Taro op 07-07-2025 22:47 ]

[Taro]

Aziraphale schreef op maandag 7 juli 2025 @ 21:21:
@Taro Ik geloof dat ik eens ga kijken naar de Claude Code addon om me hiermee te helpen. Het ziet er allemaal prachtig uit, maar ik vrees dat me dit niet gaat lukken zonder stapsgewijze handleiding met alle sensoren die ik nodig heb en moet maken. Ik zie namelijk al sensoren voorbij komen die ik bij mij niet kan vinden en dus zal moeten maken. Wat dat betreft is HA toch wel een lastiger systeem dan Homey, wat @geert1992 met net heeft gedemonstreerd.

Dat is inderdaad wel een ding, als je die code overneemt krijg je allemaal unknown devices en sensoren.

Misschien op te lossen door ze allemaal een fixed ID te geven. Zal er in de toekomst eens naar kijken.

Maar wat je ook kunt doen is gewoon heel simpel beginnen en de automatisering steeds verder uitbouwen. Een Homey Pro is verder ook wel toegankelijk, heb ook een keer met Geert meegekeken en zeker een mooie optie.

Ik zie een Zendure meet-up dag aankomen