Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[Njord1]

Ronald_61 schreef op dinsdag 29 april 2025 @ 12:38:
Ik ben heel blij met de
https://github.com/Superd...enus_battery_control.yaml

van Superduper1969. Zonder die yaml had ik mijn modbus niet draaiend gekregen.

Maar zoals Superduper1969 al een keer heeft aangegeven heeft hij het voor batterij 2 en 3 niet kunnen testen.

Ik krijg straks mijn 2e batterij binnen en heb dus de 2e yaml geïnstalleerd
https://github.com/Superd...nus_battery2_control.yaml

Nu krijg ik de melding dat bij utility_meter een dubbele naam wordt gebruikt.
Dit kan opgelost worden door daily_discharge en daily_charge bij de tweede batterij te hernoemen naar b.v. daily_discharge2 en daily_charge2.

De tweede yaml heb ik voor mijzelf als volgt aangepast:

# --------------
# UTILITY METERS
# --------------

utility_meter:
daily_discharge2:
name: My Battery2 Daily Discharging in kWh
unique_id: my_battery2_daily_discharging_in_kwh
source: sensor.my_battery2_discharging_in_kwh
cycle: daily


daily_charge2:
name: My Battery2 Daily Charging in kWh
unique_id: my_battery2_daily_charging_in_kwh
source: sensor.my_battery2_charging_in_kwh
cycle: daily


Maar nu krijg ik nog de melding:
Modbus MarstekVenus host/port 192.168.68.105 is duplicated,second entry not loaded.
Please update MarstekVenus and/or 192.168.68.105_502 for the entry in your configuration.yaml file and restart Home Assistant to fix this issue.

Zijn er nog restricties voor de waarde van de local port?
Mag dit gewoon 503 worden?
Uiteraard in de yaml en configuratie van de Elfin.

Ik heb namelijk 502 in yaml nr.2 gewijzigd in 503 maar ben nu communicatie met de eerste Elfin ook kwijt.
Zodra ik yaml nr2 verwijder uit de packages directory werkt de eerste weer.

Elke Elfin heeft zijn eigen IP adres, deze opzoeken en in de yaml plaatsen.

[Ronald_61]

Njord1 schreef op dinsdag 29 april 2025 @ 14:56:
[...]

Elke Elfin heeft zijn eigen IP adres, deze opzoeken en in de yaml plaatsen.

Dat weet ik en die staan goed.

Het gaat om het port nummer.
Die kan je instellen en dat probeerde ik.

[Njord1]

Ronald_61 schreef op dinsdag 29 april 2025 @ 15:05:
[...]


Dat weet ik en die staan goed.

Het gaat om het port nummer.
Die kan je instellen en dat probeerde ik.

Die blijven op 502.

[Ronald_61]

Ik heb nog een tweede probleem.

Dit ligt denk ik aan de mijn nieuwe accu.

Ik heb home assistant weer teruggezet zoals het al een tijdje werkt. Dus de tweede accu verwijderd.

Communicatie met de eerste accu werkt goed.

Zet gehele hardware modbus aansluiting over van de eerste accu op de tweede accu. Dus kabels en elfin.
Dan krijg ik geen verbinding met de tweede accu.
Als ik het weer op de eerste accu aansluit heb ik weer verbinding.

Zover ik weet hoef je aan de Marstek kant niks aan te passen en zou het moeten werken.

Ik denk dat ik een hardware probleem in de accu heb. Iemand anders een idee wat het zou kunnen zijn?

Aanvulling:
Of zou ook bij de Elfin een voedigsprobleem kunnen zijn?

[ Voor 5% gewijzigd door Ronald_61 op 29-04-2025 16:10 ]

[Juicie]

Ronald_61 schreef op dinsdag 29 april 2025 @ 15:58:
Ik heb nog een tweede probleem.

Dit ligt denk ik aan de mijn nieuwe accu.

Ik heb home assistant weer teruggezet zoals het al een tijdje werkt. Dus de tweede accu verwijderd.

Communicatie met de eerste accu werkt goed.

Zet gehele hardware modbus aansluiting over van de eerste accu op de tweede accu. Dus kabels en elfin.
Dan krijg ik geen verbinding met de tweede accu.
Als ik het weer op de eerste accu aansluit heb ik weer verbinding.

Zover ik weet hoef je aan de Marstek kant niks aan te passen en zou het moeten werken.

Ik denk dat ik een hardware probleem in de accu heb. Iemand anders een idee wat het zou kunnen zijn?

Dit is een paar posts terug al besproken, de nieuwe heeft maar 2,5v op de output staan in plaats van 5v. je zal dus extern moeten voeden met 5v.

[Ronald_61]

Juicie schreef op dinsdag 29 april 2025 @ 16:09:
[...]


Dit is een paar posts terug al besproken, de nieuwe heeft maar 2,5v op de output staan in plaats van 5v. je zal dus extern moeten voeden met 5v.

Bedankt. Terwijl je het stuurde bedacht ik het mij ook.
Had de link nog even niet gelegd omdat ik de Elfin gebruik.
Nu nog uitzoeken hoe ik bij de elfin de voeding kan verbeten.

[superduper1969]

Ronald_61 schreef op dinsdag 29 april 2025 @ 12:38:
Ik ben heel blij met de
https://github.com/Superd...enus_battery_control.yaml

van Superduper1969. Zonder die yaml had ik mijn modbus niet draaiend gekregen.

Maar zoals Superduper1969 al een keer heeft aangegeven heeft hij het voor batterij 2 en 3 niet kunnen testen.

Ik krijg straks mijn 2e batterij binnen en heb dus de 2e yaml geïnstalleerd
https://github.com/Superd...nus_battery2_control.yaml

Nu krijg ik de melding dat bij utility_meter een dubbele naam wordt gebruikt.
Dit kan opgelost worden door daily_discharge en daily_charge bij de tweede batterij te hernoemen naar b.v. daily_discharge2 en daily_charge2.

De tweede yaml heb ik voor mijzelf als volgt aangepast:

# --------------
# UTILITY METERS
# --------------

utility_meter:
daily_discharge2:
name: My Battery2 Daily Discharging in kWh
unique_id: my_battery2_daily_discharging_in_kwh
source: sensor.my_battery2_discharging_in_kwh
cycle: daily


daily_charge2:
name: My Battery2 Daily Charging in kWh
unique_id: my_battery2_daily_charging_in_kwh
source: sensor.my_battery2_charging_in_kwh
cycle: daily


Maar nu krijg ik nog de melding:
Modbus MarstekVenus host/port 192.168.68.105 is duplicated,second entry not loaded.
Please update MarstekVenus and/or 192.168.68.105_502 for the entry in your configuration.yaml file and restart Home Assistant to fix this issue.

Zijn er nog restricties voor de waarde van de local port?
Mag dit gewoon 503 worden?
Uiteraard in de yaml en configuratie van de Elfin.

Ik heb namelijk 502 in yaml nr.2 gewijzigd in 503 maar ben nu communicatie met de eerste Elfin ook kwijt.
Zodra ik yaml nr2 verwijder uit de packages directory werkt de eerste weer.

Vanaf V151 zou je ook de waardes kunnen gebruiken die uit de accu komen ipv de berekeningen. Daarvoor was het een probleem. Ik ben lekker op Vakantie dus ik hoor later wel wat het allemaal is geworden.

[SatScan]

superduper1969 schreef op maandag 28 april 2025 @ 15:11:
Toevallig gisteren een Review gezien van een leuke Buck Booster!

Deze Buck booster begint op 2V
MT3608 DC-DC Step Up Converter Booster
https://nl.aliexpress.com/item/1005005853733696.html
Of morgen geleverd via: https://www.amazon.nl/AZD...usief/dp/B079H3YD8V/?th=1
Review: https://www.youtube.com/watch?v=2BtXrJRqF8Y

Of de Backup-poort op aan zetten en daar een USB adapter indoen als je niet voldoende aansluitpunten hebt.

Dank!

Heb via Feedback melding gemaakt dat de Modbus bij de nieuwere uitvoering te lage stanning heeft en gevraagd dmv een firmware update te fixen... fingers crossed staat nu op 'the do list' DEV team.

Enjoy vakantie.. ik kom je binnenkort achterna

[Avenger 2.0]

SatScan schreef op dinsdag 29 april 2025 @ 19:01:
[...]
Heb via Feedback melding gemaakt dat de Modbus bij de nieuwere uitvoering te lage stanning heeft en gevraagd dmv een firmware update te fixen... fingers crossed staat nu op 'the do list' DEV team

Benieuwd wat de reactie zal zijn. Lijkt me niet iets wat je met een firmware update kan oplossen.

[ Voor 7% gewijzigd door Avenger 2.0 op 29-04-2025 19:05 ]

[SatScan]

Avenger 2.0 schreef op dinsdag 29 april 2025 @ 19:04:
[...]

Benieuwd wat de reactie zal zijn. Lijkt me niet iets wat je met een firmware update kan oplossen.

Zoals ik schrijf op de Chinese 'to do list'
Voor de fijnproevers onder ons: 待辦事項清單

[Ronald_61]

superduper1969 schreef op dinsdag 29 april 2025 @ 18:18:
[...]

Vanaf V151 zou je ook de waardes kunnen gebruiken die uit de accu komen ipv de berekeningen. Daarvoor was het een probleem. Ik ben lekker op Vakantie dus ik hoor later wel wat het allemaal is geworden.

Lekker genieten van je vakantie.
Ik ga nog wel verder zoeken naar de port instellingen.

[Ronald_61]

SatScan schreef op dinsdag 29 april 2025 @ 19:01:
[...]


Dank!

Heb via Feedback melding gemaakt dat de Modbus bij de nieuwere uitvoering te lage stanning heeft en gevraagd dmv een firmware update te fixen... fingers crossed staat nu op 'the do list' DEV team.

Enjoy vakantie.. ik kom je binnenkort achterna

Ik heb ook een melding gemaakt van een te lage spanning.
Ondertussen wel zo'n booster besteld. Hopelijk lost dat een van de twee problemen op.

[Hometek]

JorisLammar schreef op dinsdag 29 april 2025 @ 08:01:
...
Heeft iemand ervaring met het offgrid gebruik van de zonnepanelen en opladen van de batterijen?

Zie dit topic voor Marstek backup en off-grid

[Avenger 2.0]

Is het mogelijk om met twee RS485 naar ethernet toestelletjes de aansturing van de Marstek over bv glasvezel te laten lopen? Dacht eraan de Marstek in tuinhuis te plaatsen.

Bv twee van deze (eentje in client andere in server mode):
https://www.amazon.nl/gp/product/B09QMNWYLQ/

[pascallj]

Avenger 2.0 schreef op woensdag 30 april 2025 @ 13:18:
Is het mogelijk om met twee RS485 naar ethernet toestelletjes de aansturing van de Marstek over bv glasvezel te laten lopen? Dacht eraan de Marstek in tuinhuis te plaatsen.

Bv twee van deze (eentje in client andere in server mode):
https://www.amazon.nl/gp/product/B09QMNWYLQ/

Wat wil je precies bereiken? Ik ben in de war vanwege het feit dat je er eentje in server en een andere in cliënt wil? Waarom zou je het RS485 signaal weer willen reconstrueren? 1 omzetting zou genoeg moeten zijn.

Heb je al een bepaalde datakabel liggen naar het tuinhuis bijvoorbeeld?

[Avenger 2.0]

pascallj schreef op woensdag 30 april 2025 @ 13:52:
[...]
Wat wil je precies bereiken? Ik ben in de war vanwege het feit dat je er eentje in server en een andere in cliënt wil? Waarom zou je het RS485 signaal weer willen reconstrueren? 1 omzetting zou genoeg moeten zijn.

Heb je al een bepaalde datakabel liggen naar het tuinhuis bijvoorbeeld?

De (Jullix) EMS die ik wil gebruiken moet met RS485 met de marstek verbonden zijn. De EMS moet bij de digitale meter staan. Dus ik dacht met RS485 naar ethernet converters het signaal van bij de EMS RS485 poort over het netwerk naar tuinhuis te sturen (waar ik de Marstek wil plaatsen) en dan van ethernet terug naar RS485 aan de Marstek.

[pascallj]

Avenger 2.0 schreef op woensdag 30 april 2025 @ 13:57:
[...]

De (Jullix) EMS die ik wil gebruiken moet met RS485 met de marstek verbonden zijn. De EMS moet bij de digitale meter staan. Dus ik dacht met RS485 naar ethernet converters het signaal van bij de EMS RS485 poort over het netwerk naar tuinhuis te sturen (waar ik de Marstek wil plaatsen) en dan van ethernet terug naar RS485 aan de Marstek.

Klinkt als een valide punt. Ik durf niet te zeggen of het werkt, ik heb even door de handleiding gescand en er lijkt wel een heleboel mogelijk, maar de server en client termen worden in deze context al snel onduidelijk.

Ik zou er zelf even goed doorheen kijken: https://files.waveshare.c...-user-manual-EN-v1.33.pdf

Als je de netwerkkabel niet voor iets anders gebruikt (of genoeg hebt aan 100 Mb/s), kan je ook 1 paar uit de netwerkkabel gebruiken als RS-485 paar

[DarkSideX]

Zonet de LilyGo aangesloten op de nieuwe versie met te laag voltage tussen RS485 pinnen 4 en 5 dus dan maar een extra kabeltje (blauw) van pin 3 naar de - en pin 4 (oranje) naar de +

[pascallj]

DarkSideX schreef op woensdag 30 april 2025 @ 19:00:
Zonet de LilyGo aangesloten op de nieuwe versie met te laag voltage tussen RS485 pinnen 4 en 5 dus dan maar een extra kabeltje (blauw) van pin 3 naar de - en pin 4 (oranje) naar de +

[Afbeelding]

[Afbeelding]

[Afbeelding]

Dit kan niet goed zijn toch? Werkt het? Je hebt de Data GND verbonden met zowel A of B en dan tevens ook aangesloten op GND van de Lilygo? Of zie ik het nu verkeerd?

[JanAllElectric]

Vandaag mijn 2 Marstek 5 kWh binnengekregen en geïnstalleerd. Ging allemaal "plug en play", ook met de beide lilygo's (met externe USB voeding).

Ik heb echter nog een vraag. Ik zie dat in de modbus output bv 1000W laden wordt aangegeven als -1000W AC. In mijn software ging ik er vanuit dat 1000W laden +1000W AC zou zijn. Voordat ik dat verander dus even de vraag of dat goed staat in de modbus output.

[pascallj]

JanAllElectric schreef op woensdag 30 april 2025 @ 21:55:
Vandaag mijn 2 Marstek 5 kWh binnengekregen en geïnstalleerd. Ging allemaal "plug en play", ook met de beide lilygo's (met externe USB voeding).

Ik heb echter nog een vraag. Ik zie dat in de modbus output bv 1000W laden wordt aangegeven als -1000W AC. In mijn software ging ik er vanuit dat 1000W laden +1000W AC zou zijn. Voordat ik dat verander dus even de vraag of dat goed staat in de modbus output.

Ja dat klopt. Negatief is opladen, positief is ontladen. Nu ik er over nadenk is dit eigenlijk niet heel logisch inderdaad. Maar eenvoudig om te draaien mocht je het willen.

[Maxwp]

pascallj schreef op woensdag 30 april 2025 @ 22:18:
[...]


Ja dat klopt. Negatief is opladen, positief is ontladen. Nu ik er over nadenk is dit eigenlijk niet heel logisch inderdaad. Maar eenvoudig om te draaien mocht je het willen.

Bij mij word bij ontladen dus in het net steken stroom opgewekt vanuit de accu dus is dat 1000watt ac
De dc kant ontlaad de accu dan en is het -1000 want er word aan de dc kant ontladen

Als er stroom in de accu gaat in de dc kant dan in de plus dus 1000 en de ac kant dus dan -1000 omdat niet word opgewekt maar onttrokken aan het net

Opzich logisch .

[DarkSideX]

pascallj schreef op woensdag 30 april 2025 @ 21:41:
[...]


Dit kan niet goed zijn toch? Werkt het? Je hebt de Data GND verbonden met zowel A of B en dan tevens ook aangesloten op GND van de Lilygo? Of zie ik het nu verkeerd?

Werkt perfect, is enkel Data Gnd naar +

RS485 Pin	RS485	Jst Xh2.54 Kleur	LilyGo
1	A	Zwart	RS485 A
2	B	Rood	RS485 B
3	Data Gnd	Wit	RS485 Data Gnd RS485 -
-	-	Geel	-
4	Gnd	Oranje	RS485 +
5	-	Groen	-

[pascallj]

DarkSideX schreef op donderdag 1 mei 2025 @ 08:02:
[...]


Werkt perfect, is enkel Data Gnd naar +

RS485 Pin	RS485	Jst Xh2.54 Kleur	LilyGo
1	A	Zwart	RS485 A
2	B	Rood	RS485 B
3	Data Gnd	Wit	RS485 Data Gnd RS485 -
-	-	Geel	-
4	Gnd	Oranje	RS485 +
5	-	Groen	-

Huh? Dus je voedt de LilyGo van de spanning tussen Data GND en GND?! Hoeveel spanning staat daar tussen? Bij mij is er geen enkel potentiaalverschil tussen Data GND en Plus of GND. Zullen de draadjes dan anders zijn aangesloten bij het nieuwe model?

[DarkSideX]

Lijkt mij inderdaad anders aangesloten, tussen die 2 meet ik ongeveer 5V

[pascallj]

DarkSideX schreef op donderdag 1 mei 2025 @ 17:30:
Lijkt mij inderdaad anders aangesloten, tussen die 2 meet ik ongeveer 5V

@SatScan, @kaasmakert, zou jij ook willen meten welke spanningen je meet tussen alle andere kabels dan het RS485 paar bij je nieuwe accu? Misschien zijn er gewoon wat kabels omgedraaid.

Vind het wel bijzonder. Vraag mij namelijk nog steeds af waar die 2,5 V dan vandaan zou komen.

[SatScan]

pascallj schreef op donderdag 1 mei 2025 @ 17:44:
[...]


@SatScan, @kaasmakert, zou jij ook willen meten welke spanningen je meet tussen alle andere kabels dan het RS485 paar bij je nieuwe accu? Misschien zijn er gewoon wat kabels omgedraaid.

Vind het wel bijzonder. Vraag mij namelijk nog steeds af waar die 2,5 V dan vandaan zou komen.

Goeie vraag vind het ook al zo raar 2.5V geen 4,8 of zoiets... net eronder zodat het niet werkt.
Ik heb de nieuwe bijgeleverde modbus kabel gebruikt.

Zal even checken ik kom er op terug...

[Snuffelke]

Ik heb tussen de rode en de zwarte 0v. Tussen de beide zwarte draden heb ik wel 5v.

Het lijkt erop dat ze dan data GND en GND hebben omgedraaid?

[ Voor 27% gewijzigd door Snuffelke op 01-05-2025 20:51 ]

[kaasmakert]

pascallj schreef op donderdag 1 mei 2025 @ 17:44:
[...]


@SatScan, @kaasmakert, zou jij ook willen meten welke spanningen je meet tussen alle andere kabels dan het RS485 paar bij je nieuwe accu? Misschien zijn er gewoon wat kabels omgedraaid.

Vind het wel bijzonder. Vraag mij namelijk nog steeds af waar die 2,5 V dan vandaan zou komen.

Ik ben van plan om er van het weekend weer naar te gaan kijken!

[Avenger 2.0]

SatScan schreef op donderdag 1 mei 2025 @ 19:40:
[...]
Goeie vraag vind het ook al zo raar 2.5V geen 4,8 of zoiets... net eronder zodat het niet werkt.

Er zijn microcontrollers die op 2,5V werken, misschien hebben ze nu een 2,5V ipv 5V model gebruikt?

[SatScan]

Zojuist mysterie opgelost!

Snuffelke schreef op donderdag 1 mei 2025 @ 20:58:
Misschien dat meerdere mensen dit kunnen testen die de LilyGo gebruiken.
Ik denk dat ze de data GND en de GND hebben omgewisseld.
Ik meet wel 5v tussen beide zwarte draden. (Let op dit is enkel voor de nieuwe units, heb er 2)

Ik heb het juist zo aangesloten, spanning blijft >5V en loopt al even zonder probleem.


Ja hoor dat is de oplossing!!
Goed gevonden! Meten is weten!

Dank voor delen! Zal in MT Venus TS dit vermelden!


Meld jij het ook even in het MT Modbus Topic! Dank

[ Voor 3% gewijzigd door SatScan op 01-05-2025 21:49 ]

[Mr_Big]

Hier extra bevestiging dat de voeding van de lilygo werkt bij mijn nieuwgeleverde venus als je Data Ground gebruikt ipv reguliere Ground.

[Ronald_61]

Het wisselen van de ground en data ground doet ook wonderen bij de Elfin.
Ook al is het logisch wilde het toch even melden.

[newz]

Snuffelke schreef op donderdag 1 mei 2025 @ 20:35:
Ik heb tussen de rode en de zwarte 0v. Tussen de beide zwarte draden heb ik wel 5v.

Het lijkt erop dat ze dan data GND en GND hebben omgedraaid?

Bedankt! Zo heb ik vanmorgen de externe voeding kunnen afkoppelen

[JanAllElectric]

Snuffelke schreef op donderdag 1 mei 2025 @ 20:35:
Ik heb tussen de rode en de zwarte 0v. Tussen de beide zwarte draden heb ik wel 5v.

Het lijkt erop dat ze dan data GND en GND hebben omgedraaid?

Bedankt voor de info. Dat ga ik ook aanpassen voor mijn beide lilygo's (2 * Marstek 5kWh)

Mijn eigen HASS/Node-Red software werkt met 2 Marsteks samen op NOM. Ik moest alleen de polling op 10 seconden zetten om een redelijke NOM te krijgen:
- bij stabiele afname/ teruglevering grid kom ik wel op -10W tot +10W en minder
- bij snelle wisselingen door bv kort een extra elektrisch apparaat aanzetten of een wolk voor de zon kan het in het begin en eind wel schommelen tissen -300W en + 300W en meer voordat het weer stabiliseert.
- altijd een lag van zeker 10 - 20 seconden.

Vraag aan mede-tweakers, die ook zelf NOM programmeren: komt dit overeen met hun ervaringen of zijn er slimme algoritmes om dit nog wat te verbeteren?

Voor de goed orde: ik heb een oudere P1 meter, die slechts 1 * 5/10 seconden waarden doorgeeft. Verder zie ik niet veel vertragende zaken:
- ik lees iedere seconde de P1 uit met Iungo, die de waarden via MQTT door geeft aan HASS
- ik gebruik Node-Red addon in HASS om te programmeren en communiceer direct met de LiLygo's in HASS
- Netwerksterkte lilygo's is ca -40dBm

NB: ik zie ook dat in de YAML van lilygo's een vertraging is ingebouwd (ca 10 seconden dacht ik). Is dat noodzakelijk? Ik verander liever niet zelf wat in de yaml om compatible te blijven met nieuwe versies.

[pascallj]

JanAllElectric schreef op vrijdag 2 mei 2025 @ 13:41:
[...]
NB: ik zie ook dat in de YAML van lilygo's een vertraging is ingebouwd (ca 10 seconden dacht ik). Is dat noodzakelijk? Ik verander liever niet zelf wat in de yaml om compatible te blijven met nieuwe versies.

Nee dat is niet noodzakelijk, die kan je allemaal weglaten als je wil. Ik heb een configuratie die alles (behalve paar basale dingen zoals firmware versie) elke 5 seconde (de standaard) uitleest, en dat werkt prima.

[matrover]

JanAllElectric schreef op vrijdag 2 mei 2025 @ 13:41:
[...]

Bedankt voor de info. Dat ga ik ook aanpassen voor mijn beide lilygo's (2 * Marstek 5kWh)

Mijn eigen HASS/Node-Red software werkt met 2 Marsteks samen op NOM. Ik moest alleen de polling op 10 seconden zetten om een redelijke NOM te krijgen:
- bij stabiele afname/ teruglevering grid kom ik wel op -10W tot +10W en minder
- bij snelle wisselingen door bv kort een extra elektrisch apparaat aanzetten of een wolk voor de zon kan het in het begin en eind wel schommelen tissen -300W en + 300W en meer voordat het weer stabiliseert.
- altijd een lag van zeker 10 - 20 seconden.

Vraag aan mede-tweakers, die ook zelf NOM programmeren: komt dit overeen met hun ervaringen of zijn er slimme algoritmes om dit nog wat te verbeteren?

Voor de goed orde: ik heb een oudere P1 meter, die slechts 1 * 5/10 seconden waarden doorgeeft. Verder zie ik niet veel vertragende zaken:
- ik lees iedere seconde de P1 uit met Iungo, die de waarden via MQTT door geeft aan HASS
- ik gebruik Node-Red addon in HASS om te programmeren en communiceer direct met de LiLygo's in HASS
- Netwerksterkte lilygo's is ca -40dBm

NB: ik zie ook dat in de YAML van lilygo's een vertraging is ingebouwd (ca 10 seconden dacht ik). Is dat noodzakelijk? Ik verander liever niet zelf wat in de yaml om compatible te blijven met nieuwe versies.

Gaaf Jan! ik ben benieuwd naar een vergelijking tussen "eigen NOM" en "Marstek NOM" over een paar dagen

[JorisLammar]

JanAllElectric schreef op vrijdag 2 mei 2025 @ 13:41:
[...]

Vraag aan mede-tweakers, die ook zelf NOM programmeren: komt dit overeen met hun ervaringen of zijn er slimme algoritmes om dit nog wat te verbeteren?

Voor de goed orde: ik heb een oudere P1 meter, die slechts 1 * 5/10 seconden waarden doorgeeft. Verder zie ik niet veel vertragende zaken:
- ik lees iedere seconde de P1 uit met Iungo, die de waarden via MQTT door geeft aan HASS
- ik gebruik Node-Red addon in HASS om te programmeren en communiceer direct met de LiLygo's in HASS
- Netwerksterkte lilygo's is ca -40dBm

NB: ik zie ook dat in de YAML van lilygo's een vertraging is ingebouwd (ca 10 seconden dacht ik). Is dat noodzakelijk? Ik verander liever niet zelf wat in de yaml om compatible te blijven met nieuwe versies.

Ik werk met een cyclus van 6,5s, wat me de beste indruk van stabiliteit gaf. Kortere cycli gaven inderdaad soms overshoots. Als de modus wijzigt (charge naar discharge of omgekeerd) wacht ik 12seconden, want dat is de tijd die nodig is om stabiel om te draaien.
Voor ik de berekening start, doe ik een entiteit update van de p1 meter (staat eerder in deze log) zodat ik met de laatste gegevens werk. Ik pas het verschil met het gemeten verbruik en de reeds ingestelde powers wel lichtjes aan op basis van waarnemingen (4% verschil bij charge en 2,5% bij discharge bij hoge powerstanden). Ik probeer wel alleen het verschil bij te tellen bij actieve batterijen, zodat het verbruik redelijk stabiel blijft. Maar het verbruik swingt bij mij ook als ik bv de koffiemachine aanzet of er een wolk voor de zon verschijnt.
Zie ook https://github.com/JorisL...nus-LilyGo-3-bat-strategy

[jbvo]

Voor degene die ook zochten naar alternatieven voor de Lilygo in verband met levertijden: Tinytronics heeft ze weer op voorraad sinds vandaag: https://www.tinytronics.n...pment-board-can-bus-rs485

Heb er net ook 3 besteld voor m'n 3 accu's...

[ Voor 26% gewijzigd door jbvo op 02-05-2025 15:55 ]

[JanAllElectric]

matrover schreef op vrijdag 2 mei 2025 @ 14:39:
[...]


Gaaf Jan! ik ben benieuwd naar een vergelijking tussen "eigen NOM" en "Marstek NOM" over een paar dagen

Ik doe NOM over 2 accu tegelijkertijd op één 16A groep. "Marstek NOM" kan ik maar met 1 accu tegelijk (V1.48 en Shelly emulatie).

JorisLammar schreef op vrijdag 2 mei 2025 @ 15:38:
[...]


Ik werk met een cyclus van 6,5s, wat me de beste indruk van stabiliteit gaf. Kortere cycli gaven inderdaad soms overshoots. Als de modus wijzigt (charge naar discharge of omgekeerd) wacht ik 12seconden, want dat is de tijd die nodig is om stabiel om te draaien.
Voor ik de berekening start, doe ik een entiteit update van de p1 meter (staat eerder in deze log) zodat ik met de laatste gegevens werk. Ik pas het verschil met het gemeten verbruik en de reeds ingestelde powers wel lichtjes aan op basis van waarnemingen (4% verschil bij charge en 2,5% bij discharge bij hoge powerstanden). Ik probeer wel alleen het verschil bij te tellen bij actieve batterijen, zodat het verbruik redelijk stabiel blijft. Maar het verbruik swingt bij mij ook als ik bv de koffiemachine aanzet of er een wolk voor de zon verschijnt.
Zie ook https://github.com/JorisL...nus-LilyGo-3-bat-strategy

Daar had ik naar gekeken inderdaad. Op dit moment test ik daarom met cycli van 6-10 seconden.

Waarop corrigeer je de 4%/2.5%? Omhoog of naar beneden? Op de volgende charge/discharge naar Lilygo?

NB: in principe probeer ik het wisselen van charge naar decharge zoveel mogelijk te vermijden als de tarieven hoog zijn (alleen ontladen) of juist laag (alleen laden). Verder heb ik een level1 (idle onder 100W) en een level2 (minimaal 350W tussen 100 en 350W) vanwege efficiency. Is meestal niet nodig omdat mijn sluip/ruststroom toch > 500W is.

[ Voor 54% gewijzigd door JanAllElectric op 02-05-2025 16:23 ]

[Maxwp]

Mbt het wisselen van grond voor ee 5 volt.
Is het niet gewoon handig boor wie al stekkers heeft gemaakt en uitwisselen van oa de aangesloten esps
Om niet gewoon de pin even uit de witte stekker te priemen en die 2 om te draaien?

[JanAllElectric]

Maxwp schreef op vrijdag 2 mei 2025 @ 16:02:
Mbt het wisselen van grond voor ee 5 volt.
Is het niet gewoon handig boor wie al stekkers heeft gemaakt en uitwisselen van oa de aangesloten esps
Om niet gewoon de pin even uit de witte stekker te priemen en die 2 om te draaien?

Helaas de 2 (middelste) draden afgeknipt . Gelukkig heb ik nog reserve omdat je deze per bos moest kopen

[JanAllElectric]

pascallj schreef op vrijdag 2 mei 2025 @ 13:59:
[...]


Nee dat is niet noodzakelijk, die kan je allemaal weglaten als je wil. Ik heb een configuratie die alles (behalve paar basale dingen zoals firmware versie) elke 5 seconde (de standaard) uitleest, en dat werkt prima.

Zou je die hier kunnen delen? Dan weet ik wat/hoe ik mijn yaml moet aanpassen.

[pascallj]

JanAllElectric schreef op vrijdag 2 mei 2025 @ 16:38:
[...]


Zou je die hier kunnen delen? Dan weet ik wat/hoe ik mijn yaml moet aanpassen.

Mijn configuratie is erg verschillend en ook gemaakt voor een andere ESP device. Dus die kan je sowieso niet 1 op 1 overnemen. Uiteindelijk wil ik wel wat wijzigingen weer terugstoppen dit project in, maar dan zal ik alles weer in het oorspronkelijke format moeten gieten.

Voor nu kan je alle regels met `skip_updates` verwijderen. Dit zal alles updaten volgens de standaard interval (5 seconde) en niets meer overslaan.

[JanAllElectric]

pascallj schreef op vrijdag 2 mei 2025 @ 16:47:
[...]


Mijn configuratie is erg verschillend en ook gemaakt voor een andere ESP device. Dus die kan je sowieso niet 1 op 1 overnemen. Uiteindelijk wil ik wel wat wijzigingen weer terugstoppen dit project in, maar dan zal ik alles weer in het oorspronkelijke format moeten gieten.

Voor nu kan je alle regels met `skip_updates` verwijderen. Dit zal alles updaten volgens de standaard interval (5 seconde) en niets meer overslaan.

[Headshot_NL]

Ronald_61 schreef op donderdag 1 mei 2025 @ 22:38:
Het wisselen van de ground en data ground doet ook wonderen bij de Elfin.
Ook al is het logisch wilde het toch even melden.

Hier ook getest. Had 10 kabeltjes gekocht, data en data gnd omdraaien en nu is hij actief zonder extern adapter.
Nu dus nog 8 kabeltjes over.

[Maxwp]

Headshot_NL schreef op vrijdag 2 mei 2025 @ 20:14:
[...]

Hier ook getest. Had 10 kabeltjes gekocht, data en data gnd omdraaien en nu is hij actief zonder extern adapter.
Nu dus nog 8 kabeltjes over.

Ok dus dat is een Hint dat je opgaat de 40 kwh wilt ?

[Headshot_NL]

Maxwp schreef op vrijdag 2 mei 2025 @ 20:57:
[...]

Ok dus dat is een Hint dat je opgaat de 40 kwh wilt ?

Wie weet, ik heb nog een energiecontract tot 11-2026 zonder terugleverboete en 11,5 cent terugleververgoeding. Ik win er dus niks mee, draai in principe alleen verlies. Het is puur als test om te zien hoe onafhankelijk we kunnen zijn van het net tussen ongeveer maart en oktober.

[Maxwp]

Headshot_NL schreef op vrijdag 2 mei 2025 @ 22:45:
[...]

Wie weet, ik heb nog een energiecontract tot 11-2026 zonder terugleverboete en 11,5 cent terugleververgoeding. Ik win er dus niks mee, draai in principe alleen verlies. Het is puur als test om te zien hoe onafhankelijk we kunnen zijn van het net tussen ongeveer maart en oktober.

Hier het zelfde maar wel minder dan 11 cent ( ben jaloers ) ik wel nu weten hoe en wat voor 1 Jan 2027 en niet einde volgend jaar er pas aan beginnen.
Want ben bang dat het dan te laat is. Kijk nu maar ben al vanaf Jan bezig en loopt nu pas langzaam een beetje goed.

[leejoow]

Hier zijn de accu's ook binnen en wil ze ook gaan aansturen. Heeft iemand toevallig drie kabeltjes die ik kan overnemen? Persoonlijk vind ik het niet nodig om hier ook weer tien kabels te bestellen waar er vervolgens weer zeven van weg gaan.

Als iemand ze naar mij wil sturen, graag een DM ❤

[Tl0Y]

jbvo schreef op vrijdag 2 mei 2025 @ 15:55:
Voor degene die ook zochten naar alternatieven voor de Lilygo in verband met levertijden: Tinytronics heeft ze weer op voorraad sinds vandaag: https://www.tinytronics.n...pment-board-can-bus-rs485

Heb er net ook 3 besteld voor m'n 3 accu's...

Dank u voor de info, die ik van China in bestelling heb ging pas eind juni aankomen

[Hometek]

Mooi topic, met dank aan iedereen die heeft bijgedragen aan dit project!

Mijn 2 lilygo's zijn gisteren aangekomen. Home Assistant en ESPhome zijn nieuw voor mij. Maar met behulp van de TS en Google is het gelukt om de eerste Marstek in HA te integreren.

Ik begrijp dat meerdere batterijen aansturen nog 'in progress' is?
Er staan wel files op github met de nrs. 2 en 3, ik vermoed dat ik voor de tweede batterij de files met nr. 2 moet gebruiken? Voor de eerste heb ik de ongenummerde files gebruikt.

Vond op printables trouwens een mooie strakke 3D print behuizing voor de lilygo
De led is niet zichtbaar, en de knopjes zijn niet bereikbaar, lijkt mij in deze toepassing geen probleem.

[pascallj]

Hometek schreef op zaterdag 3 mei 2025 @ 14:19:
Ik begrijp dat meerdere batterijen aansturen nog 'in progress' is?
Er staan wel files op github met de nrs. 2 en 3, ik vermoed dat ik voor de tweede batterij de files met nr. 2 moet gebruiken? Voor de eerste heb ik de ongenummerde files gebruikt.

Het aansturen van meerdere apparaten via 1 modbus netwerk aangesloten op 1 LilyGo (zou in theorie moeten kunnen) werkt nog niet. Echter als je voor elke Marstek een aparte LilyGo hebt, dan zou volgens mij configuratie 2 voor de tweede LilyGo en tweede Marstek moeten werken. Het enige verschil is de naam van het apparaat, maar dat zou genoeg moeten zijn.

[Snuffelke]

Hier vind je een "gesloten" case waar de led en de knoppen eventueel nog wel te bedienen zijn.

https://www.printables.co...ygo-esp32-t-can485-module

[SatScan]

Hometek schreef op zaterdag 3 mei 2025 @ 14:19:
Mooi topic, met dank aan iedereen die heeft bijgedragen aan dit project!

Mijn 2 lilygo's zijn gisteren aangekomen. Home Assistant en ESPhome zijn nieuw voor mij. Maar met behulp van de TS en Google is het gelukt om de eerste Marstek in HA te integreren.

Ik begrijp dat meerdere batterijen aansturen nog 'in progress' is?
Er staan wel files op github met de nrs. 2 en 3, ik vermoed dat ik voor de tweede batterij de files met nr. 2 moet gebruiken? Voor de eerste heb ik de ongenummerde files gebruikt.

Vond op printables trouwens een mooie strakke 3D print behuizing voor de lilygo
De led is niet zichtbaar, en de knopjes zijn niet bereikbaar, lijkt mij in deze toepassing geen probleem.

[Afbeelding]

Inderdaad de tweede voor batt 2 etc... werkt hier al een paar dagen zonder een enkel probleem!

[JanAllElectric]

Hometek schreef op zaterdag 3 mei 2025 @ 14:19:
Mooi topic, met dank aan iedereen die heeft bijgedragen aan dit project!

.........

Vond op printables trouwens een mooie strakke 3D print behuizing voor de lilygo
De led is niet zichtbaar, en de knopjes zijn niet bereikbaar, lijkt mij in deze toepassing geen probleem.

[Afbeelding]

Mooi doosje .

Even doorgaan op de resetknopjes waar je niet meer bij kan. Ik kan daar nu ook niet meer bij. Best wel belangrijk omdat voor een goede wifiontvangst eerst het meshpoint aan moet en daarna pas de lilygo's, Dat verbetert voor mij de sterkte van -67dBm naar -40dBm. Nu zijn de lilygo's rechtstreeks met de Marsteks verbonden en dus altijd onder stroom.

Mijn vraag is derhalve hoe kan je de lilygo's softwarematig rebooten?

[Maxwp]

SatScan schreef op zaterdag 3 mei 2025 @ 17:15:
[...]


Inderdaad de tweede voor batt 2 etc... werkt hier al een paar dagen zonder een enkel probleem!

Pascallj erboven post nog niet ?
Kan je via 1 lilygo 2 accu uitlezen en ook gen 1 e door ?
Moet je dan modbus adressen veranderen cq schrijven naar de accu ?

[Hometek]

Maxwp schreef op zaterdag 3 mei 2025 @ 19:26:
[...]
Pascallj erboven post nog niet ?
Kan je via 1 lilygo 2 accu uitlezen en ook gen 1 e door ?
Moet je dan modbus adressen veranderen cq schrijven naar de accu ?

Het gaat hier om 2 batterijen en 2 lilygo's.
Aparte yaml files met andere namen voor elk.

[Maxwp]

Hometek schreef op zaterdag 3 mei 2025 @ 21:17:
[...]

Het gaat hier om 2 batterijen en 2 lilygo's.
Aparte yaml files met andere namen voor elk.

Ow thx
Met 2 apparte lilygos en eigen files had ik niet anders verwacht dat fit zou gaan werken.
Dacht meerdere op 1 met elke eigen id

Xal ook wel werken maar iets meer voor nodig

[pascallj]

Maxwp schreef op zaterdag 3 mei 2025 @ 19:26:
[...]

Pascallj erboven post nog niet ?
Kan je via 1 lilygo 2 accu uitlezen en ook gen 1 e door ?
Moet je dan modbus adressen veranderen cq schrijven naar de accu ?

Ja dit klopt ongeveer. Als de Marsteks op een ander adres gezet zijn, kan je in theorie met 1 LilyGo meerdere modbus adressen uitlezen. Echter zal 1 ESPHome apparaat als 1 device verschijnen in HA, dus echt mooi ziet het er niet uit. Er staat al jaren een issue open in ESPHome om 1 ESPHome apparaat op te splitsen in meerdere apparaten in HA. Echter het krijgt nog weinig tractie.

[leejoow]

JanAllElectric schreef op zaterdag 3 mei 2025 @ 18:02:
[...]
Mijn vraag is derhalve hoe kan je de lilygo's softwarematig rebooten?

Door in de YAML de volgende regels toe te voegen heb je een knop om te restarten (zie ook de docs):

code:

button:
  - platform: restart
    name: "Restart device"

[SatScan]

pascallj schreef op zaterdag 3 mei 2025 @ 22:47:
[...]


Ja dit klopt ongeveer. Als de Marsteks op een ander adres gezet zijn, kan je in theorie met 1 LilyGo meerdere modbus adressen uitlezen. Echter zal 1 ESPHome apparaat als 1 device verschijnen in HA, dus echt mooi ziet het er niet uit. Er staat al jaren een issue open in ESPHome om 1 ESPHome apparaat op te splitsen in meerdere apparaten in HA. Echter het krijgt nog weinig tractie.

Waar en hoe kunnen we vanuit dit topic meer tractie veroorzaken?

[pascallj]

SatScan schreef op zondag 4 mei 2025 @ 11:53:
[...]


Waar en hoe kunnen we vanuit dit topic meer tractie veroorzaken?

ESPHome developer worden en de functie implementeren of het voorgestelde Pull Request goedkeuren 😉

Meer dan reageren dat het je handig lijkt (misschien met wat voor doel) kan je niet doen: https://github.com/esphome/feature-requests/issues/1335

[0000T]

AUijtdehaag schreef op dinsdag 22 april 2025 @ 20:41:
@Maxwp
https://nl.aliexpress.com/item/1005005811950799.html

10 cm / 6P / female uit de TS

Is eigenlijk niet helemaal de goede (zit geen borging lip op) maar hij past prima

Heb er nog wel stuk of 20 liggen eventueel

Would you send me two of those to Germany?
Cheers!

[AUijtdehaag]

@0000T i have send a DM

[SatScan]

pascallj schreef op zondag 4 mei 2025 @ 13:30:
[...]


ESPHome developer worden en de functie implementeren of het voorgestelde Pull Request goedkeuren 😉

Meer dan reageren dat het je handig lijkt (misschien met wat voor doel) kan je niet doen: https://github.com/esphome/feature-requests/issues/1335

Of beide

[JanAllElectric]

leejoow schreef op zondag 4 mei 2025 @ 07:34:
[...]


Door in de YAML de volgende regels toe te voegen heb je een knop om te restarten (zie ook de docs):

code:

button:
  - platform: restart
    name: "Restart device"

. Ik kon het niet vinden daar omdat ik op "reboot" had gezocht

[ Voor 8% gewijzigd door JanAllElectric op 04-05-2025 16:18 ]

[SatScan]

Goedeavond,

Kan iemand mij helpen om dit voor 2 batterijen te laten werken
Ik kom er zelf niet uit.

RTE berekening voor meerdere batterijen
Zie hier https://gathering.tweakers.net/forum/view_message/81700760

[pascallj]

SatScan schreef op zondag 4 mei 2025 @ 19:17:
Goedeavond,

Kan iemand mij helpen om dit voor 2 batterijen te laten werken
Ik kom er zelf niet uit.

RTE berekening voor meerdere batterijen
Zie hier https://gathering.tweakers.net/forum/view_message/81700760

Als je de config 2 uit de GitHub gebruikt zou het volgens mij zo moeten zijn (ongetest):

Sensor Template:

code:

# ----------------
# TEMPLATE SENSORS
# ----------------
  
  template:
    - sensor:
        - name: "My Battery Charging in W"
          unique_id: my_battery_2_charging_in_w
          unit_of_measurement: W
          device_class: power
          state_class: measurement
          state: >
            {% if states('sensor.lilygo_rs485_2_marstek_ac_power') | float < 0 %}
              {{ (states('sensor.lilygo_rs485_2_marstek_ac_power') | float) *-1 }}
            {% else %}
              0
            {% endif %}
          
        - name: "My Battery Discharging in W"
          unique_id: my_battery_2_discharging_in_w
          unit_of_measurement: W
          device_class: power
          state_class: measurement
          state: >
            {% if states('sensor.lilygo_rs485_2_marstek_ac_power') | float > 0 %}
              {{ (states('sensor.lilygo_rs485_2_marstek_ac_power') | float) }}
            {% else %}
              0
            {% endif %}
        - name: "My Battery Efficiency Percentage"
          unique_id: my_battery_2_efficiency_percentage
          unit_of_measurement: "%"
          device_class: power
          state_class: measurement
          state: >
            {% set charging = states('sensor.my_battery_2_daily_charging_in_kwh') | float %}
            {% set discharging = states('sensor.my_battery_2_daily_discharging_in_kwh') | float %}
            {% if charging > 0 %}
              {{ ((discharging / charging) * 100) | int }}
            {% else %}
              0
            {% endif %}

ApexCharts Kaartconfiguratie:

code:

type: custom:apexcharts-card
header:
  title: Thuisbatterij 2 Status - Laatste 7 Dagen
  show: true
graph_span: 7d
yaxis:
  - id: first
    min: 0
    max: 5
    decimals: 0
    apex_config:
      tickAmount: 6
  - id: second
    min: 0
    max: 100
    opposite: true
    decimals: 0
    apex_config:
      tickAmount: 10
span:
  start: day
  offset: "-6d"
series:
  - entity: sensor.my_battery_2_daily_charging_in_kwh
    name: Lading (kWh)
    type: column
    color: "#FF4500"
    group_by:
      func: last
      duration: 1d
    show:
      in_header: true
      legend_value: true
    yaxis_id: first
  - entity: sensor.my_battery_2_daily_discharging_in_kwh
    name: Ontlading (kWh)
    type: column
    color: "#CCD500"
    group_by:
      func: last
      duration: 1d
    show:
      in_header: true
      legend_value: true
    yaxis_id: first
  - entity: sensor.my_battery_2_efficiency_percentage
    name: RTE (percentage)
    type: column
    color: "#FFD700"
    group_by:
      func: last
      duration: 1d
    show:
      in_header: true
      legend_value: true
    yaxis_id: second
apex_config:
  xaxis:
    title:
      text: Datum
    type: datetime
  plotOptions:
    bar:
      horizontal: false
  dataLabels:
    enabled: false
  stroke:
    show: true
    width: 2
  tooltip:
    enabled: true
    shared: true
  grid:
    show: true

Dit is alleen voor batterij 2. Dan kan je die uit het topic gebruiken voor batterij 1. Of bedoel je wat anders?

[Hometek]

*knip*

[ Voor 99% gewijzigd door Hometek op 04-05-2025 22:54 ]

[Hometek]

Beste tools om regeling in HA voor batterijen te maken?

Als HA/yaml newbie zie ik een hoop verschillende mogelijkheden om een regeling te bouwen.
Er zijn mensen die de HA scenes en automations gebruiken, anderen gebruiken ook scripts of node-red.

Ik heb nog geen hele duidelijke strategie voor ogen, maar wel diverse processen die ik zou willen gebruiken:

• NOM regeling voor 2 batterijen, na elkaar opladen, ontladen, niet parallel.
• Opladen batterijen bij laagste day-ahead prijs, SOC limiet op basis van weersverwachting
• PV aan/uit op basis van SOC
• Verschillende regeling voor on-grid en voor off-grid.

HA server is een mini PC, 2 Marstek zijn via LilyGo/ESPhome geintegreerd.

Wat zijn volgens jullie de beste tools om dit aan te pakken?

Hopelijk kunnen jullie mij een beetje wegwijs maken zodat ik niet eerst van alles moet uitproberen om te ontdekken dat het toch net niet kan wat ik wil.
Ik ben bereid om complexe applicaties te leren, en een beetje programmeren lukt ook ook wel als ik goede voorbeelden heb.

[pascallj]

Hometek schreef op zondag 4 mei 2025 @ 22:34:
Als HA/yaml newbie zie ik een hoop verschillende mogelijkheden om de batterij aan te sturen.
Er zijn mensen die de HA scenes en automations gebruiken, anderen gebruiken ook scripts of node-red.

Ik heb nog geen hele duidelijke strategie voor ogen, maar wel diverse processen die ik zou willen gebruiken:
NOM regeling voor 2 batterijen, na elkaar opladen, ontladen, niet parallel.
Opladen batterijen bij laagste day-ahead prijs, SOC limiet op basis van weersverwachting
PV aan/uit op basis van SOC
Verschillende regeling voor normaal en voor off-grid.

Wat is volgens jullie de beste manier om een flexibele regeling te maken?
Mij HA draait op een mini PC

Ik heb voldoende technische achtergrond, ben bereid om ook complexe applicaties te leren, en een beetje programmeren lukt ook ook wel als ik de goede voorbeelden heb.

Ik durf niet te zeggen wat het handigste is om in te programmeren. Meestal is het handiger om te beginnen met wat je kent. Echter wat je wil is al best wel complex. Je zal best wel wat handmatige scripts moeten gaan schrijven. Met alleen HA basis automation ga je het denk ik niet redden.

Ik ben al een week bezig met een perfect algoritme te schrijven om te laden en ontladen op dynamische tarieven, en alleen het algoritme wat de keuzes uitrekent is al erg complex ondertussen. Nu is het vooral de winstmaximalisatie dat het lastig maakt, maar toch.

Wat betekent bijvoorbeeld SOC limiet op basis van weersverwachting? En verschillende regeling op basis van off-grid? En NOM regeling met twee batterijen tegelijk zelf doen, ook niet eenvoudig.

De berekeningen zullen niet zwaar zijn, alleen er zitten heel veel haken en ogen aan om aan al je voorwaarden tegelijk te moeten voldoen. Wat krijgt bijvoorbeeld prioriteit met je voorkeuren?

[JanAllElectric]

Hometek schreef op zondag 4 mei 2025 @ 22:53:
Beste tools om regeling in HA voor batterijen te maken?

Als HA/yaml newbie zie ik een hoop verschillende mogelijkheden om een regeling te bouwen.
Er zijn mensen die de HA scenes en automations gebruiken, anderen gebruiken ook scripts of node-red.

Ik heb nog geen hele duidelijke strategie voor ogen, maar wel diverse processen die ik zou willen gebruiken:

• NOM regeling voor 2 batterijen, na elkaar opladen, ontladen, niet parallel.
• Opladen batterijen bij laagste day-ahead prijs, SOC limiet op basis van weersverwachting
• PV aan/uit op basis van SOC
• Verschillende regeling voor on-grid en voor off-grid.

HA server is een mini PC, 2 Marstek zijn via LilyGo/ESPhome geintegreerd.

Wat zijn volgens jullie de beste tools om dit aan te pakken?

Hopelijk kunnen jullie mij een beetje wegwijs maken zodat ik niet eerst van alles moet uitproberen om te ontdekken dat het toch net niet kan wat ik wil.
Ik ben bereid om complexe applicaties te leren, en een beetje programmeren lukt ook ook wel als ik goede voorbeelden heb.

*** knip *** teveel van het goede

[ Voor 58% gewijzigd door JanAllElectric op 05-05-2025 00:20 ]

[JanAllElectric]

*** knip ***

[ Voor 108% gewijzigd door JanAllElectric op 05-05-2025 00:21 ]

[kurt1977]

Hey allemaal,

Ik overweeg een project op te zetten waarbij ik de volgende componenten wil gebruiken:

• DIN-rail kastje
• Raspberry Pi 4
• Raspberry Pi 4 DIN-rail behuizing
• 2 x LilyGO T-CAN485
• 2 x behuizing voor de LilyGO
• 4-poorts DIN-rail switch
• 2-kanaals RS485 naar RJ45 Ethernet Converter (DIN-rail)
• Kabels, voedingen en andere accessoires

Prijskaartje: +/- €250

Nu mijn vragen:

1. Wat zijn de voordelen van het gebruik van de LilyGO T-CAN485 in combinatie met de Marstek Venus E?
2. Wat is het verschil tussen de LilyGo en de standaard app van Marstek als je gewoon in auto modus draait met 2 batterijen.

Ik zou het gewoon doen omdat ik de realtime power flow zo cool vindt.
En waarom alles in DIN-formaat, omdat ik niet hou vanloshangende draadjes en kabeltjes.

[ Voor 6% gewijzigd door kurt1977 op 04-05-2025 23:25 ]

[pascallj]

kurt1977 schreef op zondag 4 mei 2025 @ 23:23:
Hey allemaal,

Ik overweeg een project op te zetten waarbij ik de volgende componenten wil gebruiken:

• DIN-rail kastje
• Raspberry Pi 4
• Raspberry Pi 4 DIN-rail behuizing
• 2 x LilyGO T-CAN485
• 2 x behuizing voor de LilyGO
• 4-poorts DIN-rail switch
• 2-kanaals RS485 naar RJ45 Ethernet Converter (DIN-rail)
• Kabels, voedingen en andere accessoires

Prijskaartje: +/- €250

Nu mijn vragen:

1. Wat zijn de voordelen van het gebruik van de LilyGO T-CAN485 in combinatie met de Marstek Venus E?
2. Wat is het verschil tussen de LilyGo en de standaard app van Marstek als je gewoon in auto modus draait met 2 batterijen.

Ik zou het gewoon doen omdat ik de realtime power flow zo cool vindt.
En waarom alles in DIN-formaat, omdat ik niet hou vanloshangende draadjes en kabeltjes.

1. De grootste voordelen vind ik het uitlezen en aansturen van de Marstek zonder Cloud afhankelijkheid. Dat wil ik absoluut niet. Plus er zijn dan dingen te automatiseren.
2. Via de LilyGo zal je zelf alles moeten regelen als je dingen wil programmeren/aansturen. Als je in 'Marstek Auto' wil blijven draaien via Marstek CT, dan is het verschil dat je zelf zal moeten zorgen voor de software om het uit te lezen. De sturing zal een wisselwerking tussen de accu's en de CT zijn, dus daar heb je geen hand aan. Maar je bent ook dan niet afhankelijk van de cloud.

Wat wil je met de RS485 naar Ethernet adapters?

[JanAllElectric]

kurt1977 schreef op zondag 4 mei 2025 @ 23:23:
Hey allemaal,

Ik overweeg een project op te zetten waarbij ik de volgende componenten wil gebruiken:

• DIN-rail kastje
• Raspberry Pi 4
• Raspberry Pi 4 DIN-rail behuizing
• 2 x LilyGO T-CAN485
• 2 x behuizing voor de LilyGO
• 4-poorts DIN-rail switch
• 2-kanaals RS485 naar RJ45 Ethernet Converter (DIN-rail)
• Kabels, voedingen en andere accessoires

Prijskaartje: +/- €250

Nu mijn vragen:

1. Wat zijn de voordelen van het gebruik van de LilyGO T-CAN485 in combinatie met de Marstek Venus E?
2. Wat is het verschil tussen de LilyGo en de standaard app van Marstek als je gewoon in auto modus draait met 2 batterijen.

Ik zou het gewoon doen omdat ik de realtime power flow zo cool vindt.
En waarom alles in DIN-formaat, omdat ik niet hou vanloshangende draadjes en kabeltjes.

Voordelen modbus aansturing met lilygo:
- controle over beide accu's tegelijk zonder dat je de app of CT003/ HWP1 nodig hebt
- betere NOM regeling (weet ik niet zeker want ik kan niet 2 accu's tegelijk aansturen via de app in V1.48 zonder CT003)
- combineren van (bij)kopen, verkopen, NOM, NOM+, NOM- etc. op basis PV overschot en/of dynamische tarieven.
- EV opladen erbuiten houden (voor mij erg belangrijk)
- max laadvermogen/ max ontlaadvermogen dynamisch instellen per accu.
- loadbalancing voor 2 accu;s op 1 groep (i heb de accu;s op 1 lege groep van 16A)
-.....

[Hometek]

pascallj schreef op zondag 4 mei 2025 @ 22:56:
[...]
....
Je zal best wel wat handmatige scripts moeten gaan schrijven. Met alleen HA basis automation ga je het denk ik niet redden.
...
Wat betekent bijvoorbeeld SOC limiet op basis van weersverwachting? En verschillende regeling op basis van off-grid? En NOM regeling met twee batterijen tegelijk zelf doen, ook niet eenvoudig.

De berekeningen zullen niet zwaar zijn, alleen er zitten heel veel haken en ogen aan om aan al je voorwaarden tegelijk te moeten voldoen. Wat krijgt bijvoorbeeld prioriteit met je voorkeuren?

Bedankt voor je reactie.
Ik weet dat het geen makkelijke klus zal worden, en het zal zeker niet allemaal in één keer gerealiseerd worden.

De gedachte achter SOC limiet op basis van weersverwachting is dit:
Opladen batterij op goedkoopste moment, als veel zon verwacht wordt dan slechts weinig opladen, bv tot 30%, maar als geen zon verwacht wordt tot 100%

Andere regeling voor off-grid:
Bij off-grid gelden andere randvoorwaarden voor het systeem (zie deze post). Zonder grid moet de PV opwek gestuurd worden en is een hele andere strategie nodig.

Prioriteiten heb ik idd nog niet helemaal helder, NOM zal bovenaan komen, off-grid helemaal onderaan.
Maar ik vermoed dat het zinvol is om wel al vanaf het begin rekening te houden met de wens voor een off-grid regeling, omdat het waarschijnlijk impact heeft op de hele opzet.

[Hometek]

JanAllElectric schreef op zondag 4 mei 2025 @ 23:06:
[...]
DISCLAIMER: alle functies zijn nog in bewerking.

De basis functie "distributePower" gebruik ik om over N accu's het beschikbare vermogen te verdelen (in principe niet parallel naar na elkaar). De functie levert een object als plan op (nu in werking voor mijn 2 accu's):
...

Bedankt voor deze voorbeelden, daar zal ik later beslist in detail naar kijken.
Ik neem aan dat de functies onderdeel zijn van een script in HA? (edit: zie nu dat je in node-red functies in java script kunt schrijven)

Op dit moment ben ik nog met de stap vóór het programmeren bezig; welke opties zijn er?

[ Voor 5% gewijzigd door Hometek op 05-05-2025 10:08 ]

[kurt1977]

Bedankt voor de reactiees heren!

[pascallj]

Hometek schreef op maandag 5 mei 2025 @ 00:28:
[...]
Op dit moment ben ik nog met de stap vóór het programmeren bezig; welke opties zijn er?

Ik heb geen ervaring met Node-Red, dus kan daar niet over spreken.

Waar ik zelf nu mee bezig ben met het algoritme voor handelen, is Pyscript in Home Assistant. Dat lijkt veel belovend. Je kan gewoon een HA service aanmaken bijvoorbeeld, data meesturen, in Python verwerken en eer terugsturen naar je service call. Zo blijf je dicht bij HA maar kan je toch geavanceerdere berekeningen doen.

Maar volgens is er nog veel meer mogelijk en kan je daar ook rechtstreeks states aanspreken etc.

Overigens zie ik nu ook dat er een Python Script integratie in HA zelf is, weet niet hoe geavanceerd deze is.

[JorisLammar]

pascallj schreef op maandag 5 mei 2025 @ 10:01:
[...]


Ik heb geen ervaring met Node-Red, dus kan daar niet over spreken.

Waar ik zelf nu mee bezig ben met het algoritme voor handelen, is Pyscript in Home Assistant. Dat lijkt veel belovend. Je kan gewoon een HA service aanmaken bijvoorbeeld, data meesturen, in Python verwerken en eer terugsturen naar je service call. Zo blijf je dicht bij HA maar kan je toch geavanceerdere berekeningen doen.

Maar volgens is er nog veel meer mogelijk en kan je daar ook rechtstreeks states aanspreken etc.

Overigens zie ik nu ook dat er een Python Script integratie in HA zelf is, weet niet hoe geavanceerd deze is.

Ik heb ook de berekening in pyscript gestoken en de output via een hulpvariabele naar een HA script gestuurd. Het rechtstreeks aanpassen van de batterij-instellingen in pyscript lukt me voor één of andere duistere reden niet (de aangepaste waardes zie je wel in HA, maar zijn niet doorgevoerd, alsof er geen enter is gedrukt na het aanpassen).
Het volledig benutten van Python in HA kan alleen via een aparte container. Dat staat nu ook op mijn TODO om mijn HA naar een NUC te migreren met aparte containers (ik ben begonnen als een nieuwsgierig experiment op een zeer oude laptop, maar ondertussen is HA een noodzakelijk onderdeel geworden).

[pascallj]

JorisLammar schreef op maandag 5 mei 2025 @ 11:12:
[...]

Ik heb ook de berekening in pyscript gestoken en de output via een hulpvariabele naar een HA script gestuurd. Het rechtstreeks aanpassen van de batterij-instellingen in pyscript lukt me voor één of andere duistere reden niet (de aangepaste waardes zie je wel in HA, maar zijn niet doorgevoerd, alsof er geen enter is gedrukt na het aanpassen).

Dit klinkt alsof je de states letterlijk hebt aangepast in plaats van een actie uitgevoerd die de states vervolgens laat wijzigen. Een beetje vergelijkbaar met het direct aanpassen van states in 'Developer Tools'. De state lijkt te zijn gewijzigd, maar in feite wijzig je alleen de weergave. Voor het wijzigen van een number zal je bijvoorbeeld de service moeten aanroepen (ongetest):

Python:

number.set_value(entity_id="number.marstek_venus_discharging_cutoff_capacity", value=5)

Het lijkt mij zelf een voordeel om het op deze manier te doen omdat je script dan volledig op zichzelf blijft. Wijzigingen aan entities etc kan je dan gewoon binnen HA Automation oplossen en het script zal met elke in- en output blijven werken.

JorisLammar schreef op maandag 5 mei 2025 @ 11:12:
[...]
Het volledig benutten van Python in HA kan alleen via een aparte container.
[...]

Wat bedoel je met volledig benutten? Ik zie niet zo snel wat voor problemen binnen Python je met andere vormen van installaties kan hebben.

[Hometek]

Lilygo 3D-print behuizing en kabel beheer

Een compacte 3D-print behuizing voor de lilygo met LED venster en toegang tot boot en reset buttons.
Tevens een houder om de lilygo met kabel aan de Marstek Venus te hangen.
De kabel kan in de houder opgeborgen worden, meerdere lengtes mogelijk (geinspireerd door deze
post).
Beide types kabel passen, de flat-cable en de twisted-pair versie.
Kabel kan links of rechts om naar buiten.
Haak-plaatje met dubbelzijdig tape aan Marstek bevestigen.

Files op printables

[ Voor 7% gewijzigd door Hometek op 05-05-2025 13:47 ]

[JorisLammar]

pascallj schreef op maandag 5 mei 2025 @ 11:28:
[...]

Wat bedoel je met volledig benutten? Ik zie niet zo snel wat voor problemen binnen Python je met andere vormen van installaties kan hebben.

Als je bv OS functies wilt gebruiken (lezen van directories). Dat kan je niet met pyscript of de andere python script integratie. Dan moet je effectief een aparte instantie gaan draaien waar je alle functies van Python kan gebruiken. (Bv voor het afspelen van een CD via HA kan je dit gebruiken door eerst de directory te lezen om alle nummers te kennen).

[JanAllElectric]

Hometek schreef op maandag 5 mei 2025 @ 11:43:
Lilygo 3D-print behuizing en kabel beheer

Een compacte 3D-print behuizing voor de lilygo met LED venster en toegang tot boot en reset buttons.
Tevens een houder om de lilygo met kabel aan de Marstek Venus te hangen.
De kabel kan in de houder opgeborgen worden, meerdere lengtes mogelijk (geinspireerd door iemand in het forum die de kabel om de originele doos had gewikkeld, kon de post niet terug vinden).
Beide types kabel passen, de flat-cable en de twisted-pair versie.
Kabel kan links of rechts om naar buiten.
Haak-plaatje met dubbelzijdig tape aan Marstek bevestigen.

Files op printables

[Afbeelding]

Mooie oplossing. Ik heb zelf geen 3D printer. Zou ik die ook ergens of bij jou kunnen bestellen (2 stuks)?

**************************************************

Verder merk ik vandaag een trottle van maxladen boven 95% SOC. Vraag 2500W reactie 1200W.

Mijn vraag is of anderen dat kunnen bevestigen en is er ook trottle onder x% SOC? Dezelfde vraag over ontladen.

[ Voor 9% gewijzigd door JanAllElectric op 05-05-2025 13:54 ]

[Hometek]

JanAllElectric schreef op maandag 5 mei 2025 @ 13:47:
[...]
Mooie oplossing. Ik heb zelf geen 3d printer. Zou ik die ook ergens of bij jou kunnen bestellen (2 stuks)?

Zelf heb ik geen zin om op bestelling onderdelen te printen.
Maar misschien iemand anders hier?
De files staan op printables

[Hometek]

JanAllElectric schreef op maandag 5 mei 2025 @ 13:47:
[...]
...
Verder merk ik vandaag een trottle van maxladen boven 95% SOC. Vraag 2500W reactie 1200W.

Mijn vraag is of anderen dat kunnen bevestigen en is er ook trottle onder x% SOC? Dezelfde vraag over ontladen.

Dat is normaal, bij 95% schakeld de BMS terug naar ca. 1200W
Ik weet niet of dat ook voor ontladen geldt.

Hier grafiek bij manueel laden met 1800W

[JanAllElectric]

Hometek schreef op maandag 5 mei 2025 @ 13:59:
[...]

Dat is normaal, bij 95% schakeld de BMS terug naar ca. 1200W
Ik weet niet of dat ook voor ontladen geldt.

......

Zal ik in mijn software inbouwen. Als de 1e accu >95% SOC en mag de 2e accu de vraag compenseren (zolang dat gaat).

[leejoow]

JanAllElectric schreef op maandag 5 mei 2025 @ 13:47:
[...]
Mooie oplossing. Ik heb zelf geen 3D printer. Zou ik die ook ergens of bij jou kunnen bestellen (2 stuks)?

Ik wil wel printen, stuur maar een DM

[newz]

Sinds dit weekend ben ik ook bezig om in Node-RED een automatisering te maken voor mijn Venus batterij. Ik heb zelf een dynamisch energiecontract (Tibber), maar wellicht denk ik te simpel wat betreft winstmaximalisatie…

Als je oplaadt op de twee goedkoopste uren en ontlaadt op de twee duurste uren ongeacht zonopbrengst, dan is dat toch het maximale wat je eruit kan halen? De batterij (ont)laadt dan redelijk efficiënt.

Het enige wat ik me voor kan stellen is dat als je eerst onder de 2500kWh teug leverde in een jaar dat je wil zorgen dat je daar onder blijft met betrekking tot het salderen, maar zijn er nog andere redenen?

[Ronald_61]

Volgens mij zijn er weinig mensen die met behulp van de Elfin meerdere accu's aansturen.
Immers ik zie weinig vragen hierover terwijl ik .het wel voor 1 accu werkend had maar niet voor 2.

Zelf heb ik per accu een Elfin maar er werkte er maar 1 in home assistant
Vandaag gekeken wat er aan de hand is.

Het probleem is volgens dat je geen twee modbussen via een package directory kan laten werken. Ten minste niet als je voor iedere modbus een aparte yaml heb.

Ik heb een modbus_configs directory aangemaakt.
De file marstek_venus_battery_control.yaml in 2 stukken verdeeld.
Het eerste gedeelte tot "INPUT NUMBER" in een file en die geplaatst in de modbus_configs directory geplaatst. De rest van de file in packages gelaten.

Het begin van de file is enigszins aangepast.
De eerste regels zijn nu:
- name: MarstekVenus
type: tcp
Let op het inspringen in de file is dus ook aangepast.want " Modbus ": is verwijderd

Hetzelfde gedaan voor de tweede batterij.

Dit in combinatie met eerder genoemde wijzigingen (zie mijn bericht van dinsdag 29 april 2025 12:38 ) werkt het perfect.

[pascallj]

newz schreef op maandag 5 mei 2025 @ 18:06:
Sinds dit weekend ben ik ook bezig om in Node-RED een automatisering te maken voor mijn Venus batterij. Ik heb zelf een dynamisch energiecontract (Tibber), maar wellicht denk ik te simpel wat betreft winstmaximalisatie…

Als je oplaadt op de twee goedkoopste uren en ontlaadt op de twee duurste uren ongeacht zonopbrengst, dan is dat toch het maximale wat je eruit kan halen? De batterij (ont)laadt dan redelijk efficiënt.

Het enige wat ik me voor kan stellen is dat als je eerst onder de 2500kWh teug leverde in een jaar dat je wil zorgen dat je daar onder blijft met betrekking tot het salderen, maar zijn er nog andere redenen?

Aangezien ik zelf bezig ben met een algoritme hiervoor heb ik hier wel wat ideeën over.

Om te beginnen moet je rekening houden met de afschrijving van je accu. Elke cyclus heeft z'n prijs, en als het verschil te klein is, heb je netto eigenlijk alleen maar verloren. Hier komt ook de RTE bij kijken. Je verliest met een 5kWh batterij ongeveer 1 kWh aan warmte. Die heb je wel geladen, dus ook deze warmte zal je terug moeten verdienen in de dure uren. Dat is een simpele formule maar komt bij een RTE van 80 procent neer op 25% van de laadprijs wat je ook nog moet terugverdienen.

Er kunnen meerdere perioden zijn op een dag waarover een cyclus zinvol is. Als je dit optimaal wil berekenen zal je dus periodes moeten zoeken die meerdere combinaties pakken van laden en ontladen die de meeste winst opleveren. Dit kan ook gedurende de dag veranderen en de cyclussen kunnen ook over de dag heen gaan zelfs. Of zelfs halve cyclussen (1 uur laden, 1 uur ontladen, 1 uur laden etc.)

Er zit bijvoorbeeld vannacht geen rendabele cyclus in tot morgenochtend. Maar de prijs morgenochtend is hoger dan vanavond. Dus het plan was eerst om te laden vanmiddag en te ontladen vanavond. Daarvan is nu 1 uur ontladen opgeschoven naar morgenochtend en 1 uur vanavond blijven staan.

Komt dit laatste in de praktijk weinig voor: waarschijnlijk wel. Maar als je hebt over winstmaximalisatie, zal je deze dingen moeten meenemen.

[WitteVerf]

pascallj schreef op maandag 5 mei 2025 @ 21:43:
[...]


Aangezien ik zelf bezig ben met een algoritme hiervoor heb ik hier wel wat ideeën over.

Om te beginnen moet je rekening houden met de afschrijving van je accu. Elke cyclus heeft z'n prijs, en als het verschil te klein is, heb je netto eigenlijk alleen maar verloren. Hier komt ook de RTE bij kijken. Je verliest met een 5kWh batterij ongeveer 1 kWh aan warmte. Die heb je wel geladen, dus ook deze warmte zal je terug moeten verdienen in de dure uren. Dat is een simpele formule maar komt bij een RTE van 80 procent neer op 25% van de laadprijs wat je ook nog moet terugverdienen.

Er kunnen meerdere perioden zijn op een dag waarover een cyclus zinvol is. Als je dit optimaal wil berekenen zal je dus periodes moeten zoeken die meerdere combinaties pakken van laden en ontladen die de meeste winst opleveren. Dit kan ook gedurende de dag veranderen en de cyclussen kunnen ook over de dag heen gaan zelfs. Of zelfs halve cyclussen (1 uur laden, 1 uur ontladen, 1 uur laden etc.)

Er zit bijvoorbeeld vannacht geen rendabele cyclus in tot morgenochtend. Maar de prijs morgenochtend is hoger dan vanavond. Dus het plan was eerst om te laden vanmiddag en te ontladen vanavond. Daarvan is nu 1 uur ontladen opgeschoven naar morgenochtend en 1 uur vanavond blijven staan.

Komt dit laatste in de praktijk weinig voor: waarschijnlijk wel. Maar als je hebt over winstmaximalisatie, zal je deze dingen moeten meenemen.

Als ik jullie een tip mag geven met betrekking tot de ontwikkeling van een EMS (wat jullie eigenlijk aan het doen zijn): ik gebruik PowerSaver in NodeRed om de optimale laad en ontlaadvensters te berekenen. In combinatie met een aantal NodeRed functies die bv kijken of de prijsverschillen groot genoeg zijn om economisch te kunnen laden uit het net kom ik tot een vrij optimaal gebruik van mijn accu op basis van voorspelde zonopbrengst en dynamische prijzen. Ik heb dit toegepast voor mijn (niet Marstek) thuisaccu maar nog niet voor mijn Marstek (omdat die ondertussen in Frankrijk staat)...

[pascallj]

WitteVerf schreef op maandag 5 mei 2025 @ 21:52:
[...]

Als ik jullie een tip mag geven met betrekking tot de ontwikkeling van een EMS (wat jullie eigenlijk aan het doen zijn): ik gebruik PowerSaver in NodeRed om de optimale laad en ontlaadvensters te berekenen. In combinatie met een aantal NodeRed functies die bv kijken of de prijsverschillen groot genoeg zijn om economisch te kunnen laden uit het net kom ik tot een vrij optimaal gebruik van mijn accu op basis van voorspelde zonopbrengst en dynamische prijzen. Ik heb dit toegepast voor mijn (niet Marstek) thuisaccu maar nog niet voor mijn Marstek (omdat die ondertussen in Frankrijk staat)...

Ik heb even snel de documentaire gescand, maar tenzij die incompleet is, zijn de schema's niet zo heel ingewikkeld. Laden op goedkoopste uren en verbruikers sturen naar goedkope uren vind ik toch wel anders dan winst maximaliseren (alhoewel je er voor 90 procent wel komt).

Overigens zie ik het natuurlijk ook als een leermoment (blijkbaar was het vak Algoritmiek wel heel nuttig, achteraf). Want die momenten die ik zoek gaan mij nooit mijn tijd terug verdienen.

Maar bedankt voor de tip, altijd welkom!

[Arjen S]

Ik heb nog even gekeken naar het genoemde bedradings probleem en de lage spanning van 2,5V die ik vermeld zag staan.
Mijn oorspronkelijke accu was van het eerste type. Deze is defect geraakt en omgeruild voor het tweede type waarbij de powerstekker aan de andere kant van het stekker paneel geplaatst is.
De bedrading had ik dus conform wat je op de eerste pagina van dit topic vermeld ziet staan,met vier draden, aangesloten. A+B en +en- gemeten voltage 5V A+B heb ik niet gemeten destijds.
Ik heb na de omruil de RS485 kabel van accu 1 laten zitten.
Hij deed het wel maar niet erg stabiel viel mij op, zo nu en dan was hij van zijn padje en kwam data niet goed door.
Toen jullie het hadden over Ground Data leek het mij wel slim om eens te kijken wat voor een spanning ik krijg tussen DATA ground, die ik gelukkig niet had afgeknipt, en A/B. Daartussen zit 2,5V wat prima is voor RS485 die een minimale uitgangsspaning moet hebben van 1,5V. ik heb dus nu de DATA ground aangesloten op de ground tussen A en B op de LilyGo dus de vijfde draad in gebruik genomen. Tot nu toe heb ik NOG geen verstoringen meer voorbij zien komen.

Overigens, deze Marstek Venus versie 2 is ook niet in orde want hij laad en ontlaad maar voor de helft en staat op de wachtlijst om ook weer vervangen te worden. Dit natuurlijk nadat China op afstand,..... neem ik aan,.....even een kijkje had genomen in mijn batterij.
Ach, beter even halve kracht dan totaal geen kracht zeg ik dan maar, en geduld en vertrouwen houden maar weer.

[Hometek]

Ik ben een beetje aan het experimenteren met een HA dashboard.
Daarbij viel mij op dat deze 2 sensors voor de tweede batterij niet werkten:
My Battery2 Charging in W
My Battery2 Discharging in W

De oorzaak blijkt een foute naam in de marstek_venus_battery2_control.yaml:
sensor.lilygo_rs485-2_marstek_ac_power
moet zijn
sensor.lilygo_rs485_2_marstek_ac_power
(naam wordt 4x gebruikt)

Dan werkt het goed

[JanAllElectric]

Voor de mensen die tegen ingewikkelde berekeningen aan hikken, heb ik een vrij eenvoudig algoritme gevonden op basis afwijking prijs_nu tov gemiddelde prijs van vandaag.

Op dit moment gebruik ik dit algoritme voor beide Marsteks met een vergelijkbaar resultaat tov (ingewikkelde) berekeningen op basis allerlei marges in € in mijn virtuele accu.

function prijsLevel(prijsNu, prijsGemiddeld){

// Prijslevel bepalen volgens cFOS-methode
//-6 =very cheap, -5 = cheap, -4 = normal, -3 = expensive, -2 = very expensive
let prijsLevel = '';
let prijsLeveltekst = '';
let prijsRatio = 100 * prijsNu / prijsGemiddeld;
if (prijsRatio >= 140) {prijsLevel = -2; prijsLeveltekst = 'Tarief is erg duur'}
else if (prijsRatio >= 115) {prijsLevel = -3; prijsLeveltekst ='Tarief is duur'}
else if (prijsRatio >= 90) {prijsLevel = -4; prijsLeveltekst = 'Tarief is gemiddeld'}
else if (prijsRatio >= 60) {prijsLevel = -5; prijsLeveltekst = 'Tarief is goedkoop'}
else {prijsLevel = -6; prijsLeveltekst = 'Tarief is erg goedkoop'} ;

return {prijsLevel, prijsLeveltekst}

}

Ik gebruik het voor:
- (bij)kopen als prijsLevel <= -5
- verkopen als prijsLevel >= -3
- NOM als prijsLevel = -4

Bij een gemiddelde prijs van € 0,24 is dan de marge >= € 0,06 (ongeveer voldoende om afschrijving + verlies te compenseren). Je kan het strakker stellen door (bij)kopen <= -6 en verkopen >= -2 te gebruiken

PrijsGemiddeld bepaal je altijd met de prijzen incl energiebelasting en opslag provider
Prijs_nu is ook inclusief energiebelasting en opslag provider zolang je kan salderen. Anders zonder energiebelasting en eventueel zonder opslag provider (hangt van de provider af).

Voordeel is ook dat dit algoritme robuust is voor de komende kwartierprijzen, zolang je uit de gebruikte integratie maar het juiste gemiddelde en juiste kwartierprijs krijgt.

NB: ik heb het iets strakker gemaakt door het gemiddelde te berekenen van 'nu tot einde dag' of van 'nu tot einde morgen'.

[pascallj]

JanAllElectric schreef op dinsdag 6 mei 2025 @ 18:28:
Voor de mensen die tegen ingewikkelde berekeningen aan hikken, heb ik een vrij eenvoudig algoritme gevonden op basis afwijking prijs_nu tov gemiddelde prijs van vandaag.

Op dit moment gebruik ik dit algoritme voor beide Marsteks met een vergelijkbaar resultaat tov (ingewikkelde) berekeningen op basis allerlei marges in € in mijn virtuele accu.

function prijsLevel(prijsNu, prijsGemiddeld){

// Prijslevel bepalen volgens cFOS-methode
//-6 =very cheap, -5 = cheap, -4 = normal, -3 = expensive, -2 = very expensive
let prijsLevel = '';
let prijsLeveltekst = '';
let prijsRatio = 100 * prijsNu / prijsGemiddeld;
if (prijsRatio >= 140) {prijsLevel = -2; prijsLeveltekst = 'Tarief is erg duur'}
else if (prijsRatio >= 115) {prijsLevel = -3; prijsLeveltekst ='Tarief is duur'}
else if (prijsRatio >= 90) {prijsLevel = -4; prijsLeveltekst = 'Tarief is gemiddeld'}
else if (prijsRatio >= 60) {prijsLevel = -5; prijsLeveltekst = 'Tarief is goedkoop'}
else {prijsLevel = -6; prijsLeveltekst = 'Tarief is erg goedkoop'} ;

return {prijsLevel, prijsLeveltekst}

}

Ik gebruik het voor:
- (bij)kopen als prijsLevel <= -5
- verkopen als prijsLevel >= -3
- NOM als prijsLevel = -4

Bij een gemiddelde prijs van € 0,24 is dan de marge >= € 0,06 (ongeveer voldoende om afschrijving + verlies te compenseren). Je kan het strakker stellen door (bij)kopen <= -6 en verkopen >= -2 te gebruiken

PrijsGemiddeld bepaal je altijd met de prijzen incl energiebelasting en opslag provider
Prijs_nu is ook inclusief energiebelasting en opslag provider zolang je kan salderen. Anders zonder energiebelasting en eventueel zonder opslag provider (hangt van de provider af).

Voordeel is ook dat dit algoritme robuust is voor de komende kwartierprijzen, zolang je uit de gebruikte integratie maar het juiste gemiddelde en juiste kwartierprijs krijgt.

NB: ik heb het iets strakker gemaakt door het gemiddelde te berekenen van 'nu tot einde dag' of van 'nu tot einde morgen'.

Er kunnen dagen zijn dat dit goed werkt, maar alleen als de curve vloeiend is. Bij een paar stevige pieken en dalen zal dit al niet zo goed meer werken. Dan zou je denk ik nog beter af zijn met gewoon de twee goedkoopste en twee duurste uren pakken.

Ik betwijfel of 6 cent genoeg is. Mijn accu (niet de Tweakers actie, maar wel flinke korting) heeft al een marge van 6 cent nodig en dan moet je ook nog je RTE verlies meerekenen. Bij een prijs van 10 cent, is dat al 2,5 cent boven op de marge.

Woon je in Belgie? Zo nee, waarom wil je dan NOM draaien?

Overigens zijn de kwartierprijzen ook nog geen zekerheid. Eind deze maand wordt er gestemd. EPEX heeft al aangegeven dat ze zelf tegen gaan stemmen.

[JanAllElectric]

Wanneer je gaat werken met een fysieke accu zoals de Marstek loop je iedere keer tegen onverwachte grenzen, waar je in de software rekening moet houden.

- boven 95% SOC is maximale laadcapaciteit maar 1200W (ipv 2500W)

ik loop nu bij een van beide Marsteks tegen het feit aan dat het laden stopt bij 99% omdat deze meent dat hij vol is. Maar de software rekent op 100% en blijft proberen te laden.

Ik gebruik nu de SOC data uit de lilygo. Ik kan natuurlijk in de software een lagere limiet vol instellen, maar ik heb begrepen dat je periodiek moet proberen te laden naar 100% om "SOC drift" te voorkomen.

Vraag: is er ook een dynamische manier om op basis data uit de lilygo te bepalen of de accu vol is?

[ Voor 56% gewijzigd door JanAllElectric op 06-05-2025 21:09 ]