Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[wrak]

spattex schreef op vrijdag 4 juli 2025 @ 14:35:
[...]


Ik weet niet of het een container is, HA draait op een Thinclient met ssd. HA is gewoon bereikbaar op mijn netwerk met zijn eigen IP en via openvpn kan ik HA bekijken onderweg op de Android app.

Hmm HA zit op LAN en de Venus met de CT003 op een eigen router, maar wel in het zelfde netwerk 192.168.176.xxx

Waar zou ik dan moeten kijken waar het probleem zit, ik had in het begin de sensor gelinkt van de Victron modbus als p1 in het B2500 script, maar dat pakte hij niet.

Dit is de opstart log van het B2500 emu script.
[Afbeelding]

Het lijkt erop dat je meerdere devices tegelijkertijd emuleerd? Hoe ziet je yaml configuratie eruit?
Dit werkt bij mij. Letop dat je verbruik en productie sensoren in W zijn, niet in kW

code:

power_input_alias: >-
  sensor.energieverbruik_fase_l1,sensor.energieverbruik_fase_l2,sensor.energieverbruik_fase_l3
power_output_alias: >-
  sensor.energieproductie_fase_l1,sensor.energieproductie_fase_l2,sensor.energieproductie_fase_l3
poll_interval: 1
disable_absolute_values: false
device_types: shellypro3em
throttle_interval: 0
log_level: info

[LodeBo]

spattex schreef op vrijdag 4 juli 2025 @ 12:47:
Beste mede tweakers, ik heb mijn Venus E vorige week gekocht met af fabriek firmware V1.52.
Tijdens het meten op de 485 kabel die bijgeleverd was, is de 5Volt lijn op de getwiste geel en rode draad?
Waarbij geel plus is, blijven ze nu dit wijzigen of is dit een fout.
[Afbeelding]

[Afbeelding]

[Afbeelding]

RS485 is een differentieel signaal dus op rood en geel meet je altijd spanning maar dit is geen voeding.
Het zijn de twee zwarte draden waar de spanning op zit. Even doormeten voor de plus en min.

[Soundstorm]

Heb hier heel wat elektronica materiaal liggen, maar natuurlijk niks dat gelijk is aan hetgeen hier in de startpost staat. Mij dus even bezig gehouden met wat ik wel heb liggen.

- ESP32 C3 SuperMini module
- RS-485 naar RS-232 omvormer

Dat met wat draadjes aan elkaar gekoppeld en in een 3D print behuizing gestoken. De SP17 connector die bij de batterij zit heb ik hergebruikt. Je kan die uit elkaar draaien en mijn behuizing draait er ook gewoon op.
Het geheel is kleiner dat de connector van de netspanning, dus ik moet normaal geen schrik hebben dat er iets aan blijft haken en het af breekt.









3D FIles:
https://www.printables.co...nus-e-v2-modbus-connector

[gmj2]

Even een klein vraagje tussendoor; Schijnbaar zit in Homeassistant 2025.7.1 een nieuwe modbus versie (3.9.x) en nu lees ik her en der dat modbus hierdoor nogal wat problemen geeft, of kan geven. Dus de vraag voordat ik op de upgrade knop druk: Heeft iemand al de laatste versie HA en werkt het met modbus (i.c.m. Elfin EW11) nog steeds stabiel?

[Flesym]

Ik gebruik de M5stack voor Marstek op 2025.7.1 en deze is stabiel.

[Aroha]

De sensoren van mijn Lilygo zijn dikwijls niet beschikbaar in HA.
Ik gebruik de standaardoplossing uit de TS, nog iemand last van?

De wifi is een apart 2,4ghz iot netwerk op een unify dreammachine, dus dat zou alvast in orde moeten zijn.

[tinamar]

Aroha schreef op zondag 6 juli 2025 @ 10:32:
De sensoren van mijn Lilygo zijn dikwijls niet beschikbaar in HA.
Ik gebruik de standaardoplossing uit de TS, nog iemand last van?

De wifi is een apart 2,4ghz iot netwerk op een unify dreammachine, dus dat zou alvast in orde moeten zijn.

Hier ook af en toe niet beschikbaar, hoeveel Db staat de wifi in de Lilygo? Schomelt bij mij tussen -60 en -75 Db wifi ontvangt Lilygo is niet goed, ik ga eens kijken of ik wifi antenne uit oude laptop kan monteren.
Maar eens ingesteld kijk ik er eigenlijk niet veel meer naar

[tinamar]

gmj2 schreef op zaterdag 5 juli 2025 @ 22:25:
Even een klein vraagje tussendoor; Schijnbaar zit in Homeassistant 2025.7.1 een nieuwe modbus versie (3.9.x) en nu lees ik her en der dat modbus hierdoor nogal wat problemen geeft, of kan geven. Dus de vraag voordat ik op de upgrade knop druk: Heeft iemand al de laatste versie HA en werkt het met modbus (i.c.m. Elfin EW11) nog steeds stabiel?

Weet niet of het iets met elkaar te maken heeft maar sinds ESPHome update 2025.6.3 is de wifi ontvangst van de Lilygo bij mij slechter geworden.

[Hometek]

Aroha schreef op zondag 6 juli 2025 @ 10:32:
De sensoren van mijn Lilygo zijn dikwijls niet beschikbaar in HA.
Ik gebruik de standaardoplossing uit de TS, nog iemand last van?

De wifi is een apart 2,4ghz iot netwerk op een unify dreammachine, dus dat zou alvast in orde moeten zijn.

Dat Lilygo sensoren niet beschikbaar zijn in HA is niet normaal.
Mogelijke oorzaken kunnen zijn:
- zwakke wifi verbinding met router
- problemen met dynamische IP adressen
- onderbrekingen in HA zelf door andere integraties
- zwakke 5V voeding Lilygo
- hardware issues
-...?

[Aroha]

Hometek schreef op zondag 6 juli 2025 @ 13:00:
[...]

Dat Lilygo sensoren niet beschikbaar zijn in HA is niet normaal.
Mogelijke oorzaken kunnen zijn:
- zwakke wifi verbinding met router
- problemen met dynamische IP adressen
- onderbrekingen in HA zelf door andere integraties
- zwakke 5V voeding Lilygo
- hardware issues
-...?

ik heb ook de indruk dat het issue zich voordoet sinds een esphome update

[Hometek]

tinamar schreef op zondag 6 juli 2025 @ 10:59:
[...]
Hier ook af en toe niet beschikbaar, hoeveel Db staat de wifi in de Lilygo? Schomelt bij mij tussen -60 en -75 Db wifi ontvangt Lilygo is niet goed, ik ga eens kijken of ik wifi antenne uit oude laptop kan monteren.
Maar eens ingesteld kijk ik er eigenlijk niet veel meer naar

Ik zie bij mij ook een invloed van de batterijen zelf op het wifi signaal.

Hieronder het wifi signaal van batterij 1 en 2.
21:30 Batterij 1 gaat van auto naat manual, Batterij 2 gaat van manual naar auto
08:15 Batterij 1 gaat van manual naar auto, Batterij 2 gaat van auto naat manual
Batterij 2 staat direct bij de schakelkast en stopcontacten.
Het soms zwakke signaal van batterij 2 geeft tot nog toe geen problemen

[tinamar]

Hier altijd NOM
Update ESPHome rond 13h en wifi verslechterd met +/- 10 dBm
.

[mgiebels]

die van mij zit altijd rond de -47

[AUijtdehaag]

Je kan oudere esphome versies installeren om iets terug opnieuw te compilen en te vergelijken.
https://github.com/khenderick/esphome-legacy-addons

[ Voor 6% gewijzigd door AUijtdehaag op 06-07-2025 14:25 ]

[Aroha]

Update: "lock to access point" UIT gezet op de unifi controller

Lilygo is geconnecteerd met hetzelfde AP, maar de verbinding is stabiel nu.

[zeef]

PisPix schreef op vrijdag 4 juli 2025 @ 13:09:
Ik heb de modbus integratie van @superduper1969 geinstalleerd (Dank!) maar loop nu even vast in het aansturen (HA) hiervan. Als ik het volgende wil configureren:

code:

          - action: input_number.set_value
            metadata: {}
            data:
              value: -800
            target:
              entity_id: input_number.my_battery_discharging_charging_power

Dan kan dit niet omdat ik een negatieve waarde opgeef (ontladen). De input_number.set_value accepteert alleen een getal > 0. Moet er een aparte entity gemaakt worden voor charge en discharge wellicht?

PS Mocht iemand nog zo'n AliExpress modbus kabeltje nodig hebben, ik heb er 9 over. DM me maar.

offtopic:
dankjewel!!!

[djrein86]

Super bedankt voor dit mooie project! Inmiddels heb ik alles up & running.

Ik vroeg me alleen af: laat iedereen de aansturing (bijvoorbeeld NOM) nu via HA lopen? Zo ja, zijn daar voorbeelden van waarop verder gebouwd kan worden? Ik kon op het forum of in de GitHub-repo niet echt iets bruikbaars vinden (of ik heb er overheen gekeken, sorry!).

Ik begrijp natuurlijk dat iedereen een andere situatie heeft. Zelf dacht ik bijvoorbeeld aan: overdag laden met overschot en ’s nachts naar NOM.

Kortom, is er iets van een NOM-automation of een voorbeeld dat als startpunt kan dienen?

[bruneelm]

Is overdag (evident) laden op overtollige zonnestroom soms niet NOM?

[AUijtdehaag]

@djrein86
Ik gebruik node red daarvoor.

[pascallj]

Ik heb hier over na zitten denken, maar zou toch niet de NOM regeling via Modbus willen. Ik denk dat al die wijzigingen in parameters elke zoveel seconde wel een aanslag zijn op het flash geheugen. Kwam vandaag via de hame relay pagina op een MQTT API document van Marstek (voor de B2500), waarbij van alle opties die via MQTT worden gewijzigd, bij stond welke wel, en welke niet in het flash worden opgeslagen. Oftewel, er is daar dus wel over nagedacht.

Nu is dat via Modbus dus wel een beetje anders, maar totdat we weten welke parameters veilig zijn om vaak te wijzigen, zou ik dat niet doen. Mocht je zelf NOM willen regelen, ben je denk ik beter uit de B2500 emulator te gebruiken en de input waardes te manipuleren.

[gmj2]

@djrein86 , Ik zou gewoon de NOM van de Marstek gebruiken. Ik heb 2 simpele triggers in HA gezet die 's ochtends de teruglever vermogen op 0 zet (maar dus wel gewoon NOM blijft doen voor het laden van de batterij) en dan rond 17:00 uur het vermogen weer op de oude waarde zet. Dus overdag alleen laden met overtollige stroom van zonnepanelen, en alleen NOM ontladen in de avond en nacht.

[mgiebels]

gmj2 schreef op zondag 6 juli 2025 @ 22:54:
@djrein86 , Ik zou gewoon de NOM van de Marstek gebruiken. Ik heb 2 simpele triggers in HA gezet die 's ochtends de teruglever vermogen op 0 zet (maar dus wel gewoon NOM blijft doen voor het laden van de batterij) en dan rond 17:00 uur het vermogen weer op de oude waarde zet. Dus overdag alleen laden met overtollige stroom van zonnepanelen, en alleen NOM ontladen in de avond en nacht.

Kan je die delen? Ben wel benieuwd

[gmj2]

mgiebels schreef op zondag 6 juli 2025 @ 23:15:
[...]

Kan je die delen? Ben wel benieuwd

Jazeker. Als eerste, ik gebruik de Elfin EW11 modbus oplossing. Voor de power control in de martstek.yaml file zie mijn vorige post:
gmj2 in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"

Voor de triggers is er nog een scriptje nodig in de .yaml file onder de "SCRIPTS" sectie:

code:

    mtbat1_disable_discharge_nom:
      alias: MTbat1 set discharge power to 0
      description: Set the discharge power to 0
      icon: mdi:battery-charging-20
      sequence:
        - choose:
            - conditions:
                - condition: numeric_state
                  entity_id: input_number.mtbat1_setmax_discharging_power
                  above: -1
                  below: 801
              sequence:
                - action: modbus.write_register
                  data:
                    hub: MarstekVenus
                    address: 44003
                    slave: 1
                    value: "0"

En dan 2 automatiseringen toevoegen in HA:


De eerste: power op 0 in de ochtend:


En dan savonds weer instellen op de oude waarde:


NB: Mijn batterij zit op gedeelde groep, dus ik heb ontalden op max. 800W staan,

[WargamingPlayer]

gmj2 schreef op zaterdag 5 juli 2025 @ 22:25:
Even een klein vraagje tussendoor; Schijnbaar zit in Homeassistant 2025.7.1 een nieuwe modbus versie (3.9.x) en nu lees ik her en der dat modbus hierdoor nogal wat problemen geeft, of kan geven. Dus de vraag voordat ik op de upgrade knop druk: Heeft iemand al de laatste versie HA en werkt het met modbus (i.c.m. Elfin EW11) nog steeds stabiel?

Werkt hier zonder issues met Elfin EW11B.

[tinamar]

Aroha schreef op zondag 6 juli 2025 @ 16:44:
Update: "lock to access point" UIT gezet op de unifi controller

Lilygo is geconnecteerd met hetzelfde AP, maar de verbinding is stabiel nu.

Raar maar hier ook hetzelfde gedaan op asus zenwifi xd6 en lilygo terug 10 dBm betere ontvangst

[JorisLammar]

pascallj schreef op zondag 6 juli 2025 @ 22:36:
Ik heb hier over na zitten denken, maar zou toch niet de NOM regeling via Modbus willen. Ik denk dat al die wijzigingen in parameters elke zoveel seconde wel een aanslag zijn op het flash geheugen. Kwam vandaag via de hame relay pagina op een MQTT API document van Marstek (voor de B2500), waarbij van alle opties die via MQTT worden gewijzigd, bij stond welke wel, en welke niet in het flash worden opgeslagen. Oftewel, er is daar dus wel over nagedacht.

Nu is dat via Modbus dus wel een beetje anders, maar totdat we weten welke parameters veilig zijn om vaak te wijzigen, zou ik dat niet doen. Mocht je zelf NOM willen regelen, ben je denk ik beter uit de B2500 emulator te gebruiken en de input waardes te manipuleren.

Oei? Kan je dat document delen in dit forum? Ik dacht dat jij ook NOM via de Modbus regelde? Ik werk al enkele maanden met een routine (pyscript/Home Assistant) die om de 6 seconden de gegevens wijzigt en dat werkt prima. Ik ben trouwens bezig de routine te verfijnen en sneller updates uit te voeren (rekening houdende met het verwacht ingesteld vermogen en werkelijk vermogen, sneller in te spelen in wijzigingen in het totaal vermogen). Al een paar keer proef gedraaid voor 15 minuten en dat ging toch redelijk OK.

[pascallj]

JorisLammar schreef op maandag 7 juli 2025 @ 09:39:
[...]


Oei? Kan je dat document delen in dit forum? Ik dacht dat jij ook NOM via de Modbus regelde? Ik werk al enkele maanden met een routine (pyscript/Home Assistant) die om de 6 seconden de gegevens wijzigt en dat werkt prima. Ik ben trouwens bezig de routine te verfijnen en sneller updates uit te voeren (rekening houdende met het verwacht ingesteld vermogen en werkelijk vermogen, sneller in te spelen in wijzigingen in het totaal vermogen). Al een paar keer proef gedraaid voor 15 minuten en dat ging toch redelijk OK.

Nee ik handel op dynamische contracten via Modbus. Daarvoor hoef ik alleen de 'Forcible' acties te gebruiken en die zijn hoogstwaarschijnlijk volatile, dus daarbij wordt niets opgeslagen.

Dit is de link die ik via hame-relay heb ontdekt: https://eu.hamedata.com/e...ex.html?version=2#topic11

[JanAllElectric]

pascallj schreef op zondag 6 juli 2025 @ 22:36:
Ik heb hier over na zitten denken, maar zou toch niet de NOM regeling via Modbus willen. Ik denk dat al die wijzigingen in parameters elke zoveel seconde wel een aanslag zijn op het flash geheugen. Kwam vandaag via de hame relay pagina op een MQTT API document van Marstek (voor de B2500), waarbij van alle opties die via MQTT worden gewijzigd, bij stond welke wel, en welke niet in het flash worden opgeslagen. Oftewel, er is daar dus wel over nagedacht.

Nu is dat via Modbus dus wel een beetje anders, maar totdat we weten welke parameters veilig zijn om vaak te wijzigen, zou ik dat niet doen. Mocht je zelf NOM willen regelen, ben je denk ik beter uit de B2500 emulator te gebruiken en de input waardes te manipuleren.

Beetje overbodig voorzichtig.

Ik stuur via modbus alles aan (NOM, bijkopen, kopen/verkopen) en heb -zoals je zelf beschrijft- alleen de "forcibles" nodig en die zullen volatile zijn (dus niet in het flash geheugen worden opgeslagen). Anders zou HAMAS met zijn eigen NOM-besturing hetzelfde probleem hebben

[ Voor 5% gewijzigd door JanAllElectric op 07-07-2025 10:48 ]

[pascallj]

JanAllElectric schreef op maandag 7 juli 2025 @ 10:44:
[...]


Beetje overbodig voorzichtig.

Ik stuur via modbus alles aan (NOM, bijkopen, kopen/verkopen) en heb -zoals je zelf beschrijft- alleen de "forcibles" nodig en die zullen volatile zijn (dus niet in het flash geheugen worden opgeslagen). Anders zou HAMAS met zijn eigen NOM-besturing hetzelfde probleem hebben

Waar baseer je dat op? Heb je data over hoe het geschreven wordt naar het flash geheugen? Zo niet, kan je niet zeggen dat het 'overbodig' voorzichtig is. Fijn dat het bij jou na een klein half jaar nog werkt, maar dat zegt natuurlijk niets.

Je weet ook niet hoe andere NOM besturingen werken, wij hebben geen officiële Modbus datasheet. Misschien zijn er zowel volatile als non-volatile registers (dit is dus wel zo bij de B2500 beschreven in het document wat ik linkte). De Forcible acties zijn volatile, maar de 'Power' waardes volgens mij niet. Die heb je nodig met NOM om het aan te passen.

[ Voor 3% gewijzigd door pascallj op 07-07-2025 10:56 ]

[pascallj]

En omdat bovenstaande relatief eenvoudig te testen is, heb ik Forcible Charge op 300 W gezet, Modbus losgetrokken, de Maestro uitgezet, de stekker eruit getrokken en gewacht tot hij helemaal uit was (geen Bluetooth verbinding meer).

Toen ik hem weer aanzette en Modbus weer had aangesloten, waren de Forcible instellingen gewoon nog aanwezig. Dus of de Marstek was toch niet helemaal afgesloten, of de instellingen worden gewoon opgeslagen. RS485 control was wel automatisch uitgeschakeld.

[spattex]

Nou als het goed is, werkt hier nu alles na behoren.
Ik wil alvast iedereen bedanken die al dit moois mogelijk gemaakt hebben!

Mijn situatie nog even in het kort, ik heb reeds een Victron systeem met 15kWh. Deze regelt geheel de stroom voorziening in mijn huis en zorgt op dit moment voor 0 op de meter. Aangezien de ruimte te klein is om nog meer te plaatsen heb ik voor de Marstek gekozen omdat deze voor mij overal te plaatsen is.

Er moest een koppeling komen met de Victron, zodat ze elkaar niet in de weg zitten. Volgens mij heb ik het nu voor elkaar. De Marstek wordt d.m.v. de Lilygo en modbus aangestuurd via HA. De NOM regel ik nu via de B2500 emu (werkt nu volledig) en als input gebruik ik de sensor van de Victron met de kritische belasting.

Dit omdat de Victron deze taak op zich neemt en de Marstek hier een beetje van slag raakt. Met een aantal condities in HA regel ik dat als de SOC van het Victron systeem boven de 95% en de zon opbrengst 2500W is, schakel dan de Marstek in op laden SOC met een voorlopig maximale waarde van 1500W.

Voor het ontladen van de Marstek gebruik ik de B2500 als P1 meter, maar de input sensor is die van Victron kritische belasting op L1. De condities zijn dan als volgt, als het 17 uur is geweest en de zon opbrengst is lager dan 400W en het Victron systeem heeft nog steeds 95% SOC. Dan schakel de Marstek vrij op bediening via RS485 en zet mode op anti-feed.

Er zal best nog het 1 en ander gefine tuned moeten worden, maar voor dit moment even gaan testen om te kijken of het allemaal gaat werken zoals ik het bedoeld heb.

[ Voor 25% gewijzigd door spattex op 07-07-2025 11:20 ]

[spattex]

Ik had de Lilygo wat hoger geplaatst op de Marstek zodat deze net een beter en stabiel WIFI heeft. Voorheen viel de verbinding nog wel eens weg en branden het ledje rood.

Ik moet zeggen wel een mooie toevoeging zodat je op afstand kan zien dat de verbinding intact is.

[JanAllElectric]

pascallj schreef op maandag 7 juli 2025 @ 10:56:
[...]


Waar baseer je dat op? Heb je data over hoe het geschreven wordt naar het flash geheugen? Zo niet, kan je niet zeggen dat het 'overbodig' voorzichtig is. Fijn dat het bij jou na een klein half jaar nog werkt, maar dat zegt natuurlijk niets.

Je weet ook niet hoe andere NOM besturingen werken, wij hebben geen officiële Modbus datasheet. Misschien zijn er zowel volatile als non-volatile registers (dit is dus wel zo bij de B2500 beschreven in het document wat ik linkte). De Forcible acties zijn volatile, maar de 'Power' waardes volgens mij niet. Die heb je nodig met NOM om het aan te passen.

Je hebt bij Modbus aansturing alleen de "forcibles" nodig. Power wordt alleen uitgelezen.

[pascallj]

JanAllElectric schreef op maandag 7 juli 2025 @ 11:55:
[...]


Je hebt bij Modbus aansturing alleen de "forcibles" nodig. Power wordt alleen uitgelezen.

Ik had het over de 'Forcible (Dis)charge power' waardes. Die blijven gewoon bewaard na een reboot.

[JanAllElectric]

pascallj schreef op maandag 7 juli 2025 @ 12:01:
[...]


Ik had het over de 'Forcible (Dis)charge power' waardes. Die blijven gewoon bewaard na een reboot.

Welke volatile "forcibles" blijven dan over? Dan heb je alleen nog "forcible Charge/Discharge". Daar heb je voor NOM niet voldoende aan. Maar ok. rest my case.

chatGPT:

code:

In een thuisaccu is de frequentie en hoeveelheid van schrijfacties meestal beperkt, bijvoorbeeld:

Gegevens    Schrijffrequentie   Omschrijving
Firmware/config Zelden  Alleen bij update of reset
Event logs (fouten, storingen)  Bij gebeurtenis Meestal paar keer per dag of week
SOC logging / metingen  Elke paar seconden – minuten    Vaak in RAM of FRAM, soms flash

📌 Goed ontworpen systemen loggen tijdelijk in RAM en schrijven pas na aggregatie of bij afsluiten naar flash.

Dan maar hopen dat de Marsteks goed ontworpen zijn

[ Voor 47% gewijzigd door JanAllElectric op 07-07-2025 12:35 ]

[pascallj]

JanAllElectric schreef op maandag 7 juli 2025 @ 12:09:
[...]


Je spreekt je zelf tegen in jouw eigen chats. Welke volatile "forcibles" blijven dan over? Dan heb je alleen nog "forcible Charge/Discharge". Daar heb je voor NOM niet voldoende aan. Maar ok. rest my case.

Nee niet helemaal, ben hooguit niet volledig geweest. Mijn assumptie was dat alleen Forcible Acties (Charge, Discharge, Stop) volatile was en de Forcible Power waardes niet. Maar na testen blijkt dat niets bewezen volatile is. Alles blijft bewaard na een reboot.

[MsXgAmEs]

Ik had nog een M5stack Core2 met een IoTBase CatM extension board liggen. De RS485 pinnen kan ik niet vinden, alhoewel de handleiding zegt RX=G13 (GPIO13) en TX=G15 (GPIO15) . Heb een signal analyser aangesloten op de RX en TX met Saleae software, maar ik zie slechts ruis. Als ik het programma upload krijg ik de melding GPIO15 is een strapping pin. Heeft iemand ervaring met deze configuratie en weet wat de pinouts voor de RS485 zijn?

[pascallj]

MsXgAmEs schreef op dinsdag 8 juli 2025 @ 00:24:
Ik had nog een M5stack Core2 met een IoTBase CatM extension board liggen. De RS485 pinnen kan ik niet vinden, alhoewel de handleiding zegt RX=G13 (GPIO13) en TX=G15 (GPIO15) . Heb een signal analyser aangesloten op de RX en TX met Saleae software, maar ik zie slechts ruis. Als ik het programma upload krijg ik de melding GPIO15 is een strapping pin. Heeft iemand ervaring met deze configuratie en weet wat de pinouts voor de RS485 zijn?

Als ik de website goed lees is het G19 en G2. Staat onderaan op de pagina van het extension board een tabel waarmee je het kan pairen met de Core2.

[MsXgAmEs]

Ja, ook al geprobeerd. G2 geeft ook de error dat het een strapping pin is. Hier is ook meer te vinden.

[Metsubsidie]

superduper1969 schreef op donderdag 26 juni 2025 @ 12:35:
[...]

In de startpost staat ook een PoE-Ethernet variant van de Lilygo.
Dit lijkt me handiger tenzij je van een uitdaging houdt.

@superduper1969 Bedankt voor de uitgebreide en leerzame beschrijving.
Vooral dat bijgeleverde "standaard" modbus kabeltje van de Marstek V2 zou al een uitdaging geweest zijn.
Zal wel door een kleurenblinde in elkaar gezet zijn...

Installatie van de Pusr-DR134 was eigenlijk echt een peuleschil en in notime worden de Marstek registerwaarden geleverd in MQTT/Mosquito.

Ik gebruik echter Domoticz dus vandaar ook de eigen weg.

[corsat]

Hometek schreef op woensdag 2 juli 2025 @ 16:25:
[...]

Let er vooral goed op dat het aantal spaties aan het begin van elke regel precies klopt, yaml is daar erg gevoelig voor.

Inmiddels een weekje verder en wijzer geworden. Ik heb HA op de nas via vmm en zonder supervisor dus moet via een omweg met esphome aan de slag maar dat lukt mij linksom of rechtsom niet. Of het wordt een raspberry pi of alles gaat naar de opslag

[leejoow]

En esphome gewoon op je machine installeren lokaal en via deze weg de esp programmeren? ESPHome hoeft niet op je HA te staan om het apparaat toe te voegen aan Home Assistant.

[ Voor 54% gewijzigd door leejoow op 08-07-2025 17:26 ]

[JSTAL]

Ik heb enkele vragen ivb met het aansluiten van de Liligo.

- Moet ik de batterij uitschakelen alvorens de modbus connector in de batterij te steken.
- Dien ik de Liliigo nog van externe voeding te voorzien via de onboard USB-C connector?
- De batterij zit op een aparte AP, moet de Liliygo met diezelfde AP verbonden worden of met de standaard router in huis?

[pascallj]

JSTAL schreef op dinsdag 8 juli 2025 @ 20:39:
Ik heb enkele vragen ivb met het aansluiten van de Liligo.

- Moet ik de batterij uitschakelen alvorens de modbus connector in de batterij te steken.
- Dien ik de Liliigo nog van externe voeding te voorzien via de onboard USB-C connector?
- De batterij zit op een aparte AP, moet de Liliygo met diezelfde AP verbonden worden of met de standaard router in huis?

1) Nee maakt niet uit. Je kan het inpluggen wanneer je wilt.
2) Er wordt 5V geleverd op een paar draden (tussen zwart en zwart bij V2, even meten voor de zekerheid) dat uit de Modbus aansluiting komt (zie TS). Je kan deze aansluiten op de DC ingang van de LilyGo en daar je stroom vandaan halen. Voeden via de USB-C kan ook.
3) Probeer te begrijpen hoe de LilyGo werkt. Deze communiceert met de Marstek via Modbus. Hierna kan je hem gebruiken om bijvoorbeeld via Home Assistant aan te sturen. Hij zal dus op het netwerk moeten zitten waarop je het wil gebruiken. Hoe hoeft niet per se op hetzelfde AP als de Marstek, want hij hoeft niet draadloos te communiceren met de Marstek: daar is de Modbus voor.

[JSTAL]

pascallj schreef op dinsdag 8 juli 2025 @ 20:46:
[...]


1) Nee maakt niet uit. Je kan het inpluggen wanneer je wilt.
2) Er wordt 5V geleverd op een paar draden (tussen zwart en zwart bij V2, even meten voor de zekerheid) dat uit de Modbus aansluiting komt (zie TS). Je kan deze aansluiten op de DC ingang van de LilyGo en daar je stroom vandaan halen. Voeden via de USB-C kan ook.
3) Probeer te begrijpen hoe de LilyGo werkt. Deze communiceert met de Marstek via Modbus. Hierna kan je hem gebruiken om bijvoorbeeld via Home Assistant aan te sturen. Hij zal dus op het netwerk moeten zitten waarop je het wil gebruiken. Hoe hoeft niet per se op hetzelfde AP als de Marstek, want hij hoeft niet draadloos te communiceren met de Marstek: daar is de Modbus voor.

Dank u voor de feedback, heb nu meer duidelijkheid hoe te gebruiken.

[WargamingPlayer]

Inmiddels redelijk wat aanpassingen gemaakt op de yaml van Superduper.
https://github.com/Wargam.../main/ElfinEW11B/packages

Zo heb ik nu code waarmee je:

• Percentage Minimale SOC
• Percentage Maximale SOC
• Maximale laad vermogen
• Maximale ontlaad vermogen

kan instellen. Deze zullen ook direct in de Marstek worden aangepast. Waarde uit de Marstek zullen worden overgenomen.

Volgende zaken toegevoegd:

YAML:

modbus:
    sensors:
      - name: "Marstek 1 Name"
      - name: "Marstek 1 Battery Charge Limits"
      - name: "Marstek 1 Capacity and Power registers"
      - name: "Marstek 1 Alarm State"
      - name: "Marstek 1 Fault State"

input_number:
  marstek_1_set_max_discharging_power:
    name: "Marstek 1 Set Maximum discharging power"
  marstek_1_set_max_charging_power:
    name: "Marstek 1 Set Maximum charging power"
  marstek_1_set_battery_min_soc:
    name: "Marstek 1 Set Battery minimum SOC (Discharge)"
  marstek_1_set_battery_max_soc:
    name: "Marstek 1 Set Battery maximum SOC (Charge)"

# Lichtelijk aangepast
automation:
  - id: marstek_1_sync_modbus_and_input_select
    alias: "Marstek 1 Sync Modbus and Input Select"
# nieuw
  - id: marstek_1_sync_modbus_and_max_charge
    alias: "Marstek 1 Sync Modbus and Maximum Charge"
  - id: marstek_1_sync_modbus_and_max_discharge
    alias: "Marstek 1 Sync Modbus and Maximum Discharge"
  - id: marstek_1_sync_modbus_and_battery_min_soc
    alias: "Marstek 1 Sync Modbus and Min SOC"
  - id: marstek_1_sync_modbus_and_battery_max_soc
    alias: "Marstek 1 Sync Modbus and Max SOC"

template:
  - sensor:
      - name: "Marstek 1 State"
        unique_id: marstek_1_state
      - name: "Marstek 1 Alarm PLL Abnormal Restart"
        unique_id: marstek_1_alarm_PLL_abnormal_restart
      - name: "Marstek 1 Alarm Overtemperature Limit"
        unique_id: marstek_1_alarm_overtemperature_limit
      - name: "Marstek 1 Alarm Low Temperature Limit"
        unique_id: marstek_1_alarm_low_temperature_limit
      - name: "Marstek 1 Alarm Fan Abnormal Warning"
        unique_id: marstek_1_alarm_fan_abnormal_warning
      - name: "Marstek 1 Alarm Low Battery SOC Warning"
        unique_id: marstek_1_alarm_low_battery_SOC_warning
      - name: "Marstek 1 Alarm Output Overcurrent Warning"
        unique_id: marstek_1_alarm_output_overcurrent_warning
      - name: "Marstek 1 Alarm Abnormal Line Sequence Detection"
        unique_id: marstek_1_alarm_abnormal_line_sequence_detection
      - name: "Marstek 1 Alarm WIFI abnormal"
        unique_id: marstek_1_alarm_wifi_abnormal
      - name: "Marstek 1 Alarm Blutooth abnormal"
        unique_id: marstek_1_alarm_blutooth_abnormal
      - name: "Marstek 1 Alarm Network abnormal"
        unique_id: marstek_1_alarm_network_abnormal
      - name: "Marstek 1 Alarm CT connection abnormal"
        unique_id: marstek_1_alarm_ct_connection_abnormal
      - name: "Marstek 1 Battery maximum SOC (Charge)"
        unique_id: marstek_1_battery_maximum_soc
      - name: "Marstek 1 Battery minimum SOC (Discharge)"
        unique_id: marstek_1_battery_minimum_soc
      - name: "Marstek 1 Maximum Charge Power"
        unique_id: marstek_1_max_charge_power
      - name: "Marstek 1 Maximum Discharge Power"
        unique_id: marstek_1_max_discharge_power

# Fixed:
utility_meter:
  daily_discharge_1:
  daily_charge_1:

[Hometek]

WargamingPlayer schreef op dinsdag 8 juli 2025 @ 21:39:
Inmiddels redelijk wat aanpassingen gemaakt op de yaml van Superduper.
https://github.com/Wargam.../main/ElfinEW11B/packages
...

Bedankt voor het delen.
Ik zie dat er nog een 'Trade mode' in staat als input voor 'user work mode', moet dat niet 'AI' zijn?

[mb0erman]

Hallo lui,

Ik heb dit topic uitgepluisd met relevante zoektermen maar nog niet verder gekomen. Excuus als ik iets stoms over het hoofd zie.

Heb de guide van Denie van Kleef gevolgd om een Lilygo te configureren. (Ik weet dat de instructies in de TS hier enigszins verschillen maar voor mij als ESPhome n00b was de video beter te volgen.)

Probleem is nu dat de lilygo alleen "no response received" meldingen geeft. Dit verandert niet als ik 'm van de batterij afkoppel. Er is dus geen communicatie met de batterij.

Kans is niet nul de fout bij mij ligt. Maar ik las ook ergens dat de RS485 poort op de batterij tegenwoordig standaard uit staat. Kan iemand dat bevestigen? Of zijn er andere voor de hand liggende zaken die ik kan controleren?


Marstek Venus-E v2
Device: V152
Lilygo: v1.1

[pascallj]

mb0erman schreef op dinsdag 8 juli 2025 @ 22:58:
Hallo lui,

Ik heb dit topic uitgepluisd met relevante zoektermen maar nog niet verder gekomen. Excuus als ik iets stoms over het hoofd zie.

Heb de guide van Denie van Kleef gevolgd om een Lilygo te configureren. (Ik weet dat de instructies in de TS hier enigszins verschillen maar voor mij als ESPhome n00b was de video beter te volgen.)

Probleem is nu dat de lilygo alleen "no response received" meldingen geeft. Dit verandert niet als ik 'm van de batterij afkoppel. Er is dus geen communicatie met de batterij.

Kans is niet nul de fout bij mij ligt. Maar ik las ook ergens dat de RS485 poort op de batterij tegenwoordig standaard uit staat. Kan iemand dat bevestigen? Of zijn er andere voor de hand liggende zaken die ik kan controleren?


Marstek Venus-E v2
Device: V152
Lilygo: v1.1

De Modbus heeft nooit standaard uitgestaan op de Venus. Ik geloof wel op de B2500 en daarom dachten mensen dat dit voor de Venus ook zo was, maar het probleem was elke keer wat anders.

Ik weet niet hoe het zit met die video, maar zorg dat je de juiste versie van de configuratie geflashed hebt voor welk apparaat jij hebt. Daarna kan je proberen om je RS485 A en B draden om te draaien en kijken of dat verschil maakt. En even de voeding via USB-C gebruiken om te kijken of het geen vermogensprobleem is voor als je voeding uit de Modbus aansluiting pakt.

[WargamingPlayer]

Hometek schreef op dinsdag 8 juli 2025 @ 22:39:
[...]

Bedankt voor het delen.
Ik zie dat er nog een 'Trade mode' in staat als input voor 'user work mode', moet dat niet 'AI' zijn?

Ik heb net een nieuwe gepushed. Daar heet het Trade.

Ik zit echter met een issue. Wanneer ik register 43000 uitlees dan krijg ik de volgende waarden:
0: Manual
1: NOM en AI

Het wordt nooit 2 wat volgens de documentatie wel zou moeten.

[Hert]

Mijn domotica systeem (Wiser for Knx) heeft 3 fysieke klemmen voor ModBus: D1/+, D0/- en 0V, maar de Marstek heeft 5 kabels voor ModBus. Hoe zou dit dan aangesloten moeten worden?

[pascallj]

Hert schreef op woensdag 9 juli 2025 @ 08:22:
Mijn domotica systeem (Wiser for Knx) heeft 3 fysieke klemmen voor ModBus: D1/+, D0/- en 0V, maar de Marstek heeft 5 kabels voor ModBus. Hoe zou dit dan aangesloten moeten worden?

Dat is standaard RS485: A(-), B(+) en GND. De Marstek biedt op het laatste paar nog een 5V voeding aan.

Voor deze kleine afstanden is GND niet nodig, je hoeft dus alleen het A en B paar aan te sluiten.

[mb0erman]

pascallj schreef op dinsdag 8 juli 2025 @ 23:03:
[...]


De Modbus heeft nooit standaard uitgestaan op de Venus. Ik geloof wel op de B2500 en daarom dachten mensen dat dit voor de Venus ook zo was, maar het probleem was elke keer wat anders.

Ik weet niet hoe het zit met die video, maar zorg dat je de juiste versie van de configuratie geflashed hebt voor welk apparaat jij hebt. Daarna kan je proberen om je RS485 A en B draden om te draaien en kijken of dat verschil maakt. En even de voeding via USB-C gebruiken om te kijken of het geen vermogensprobleem is voor als je voeding uit de Modbus aansluiting pakt.

Dank! Ik heb het inmiddels aan de praat. Denk dat er de vorige keer iets mis is gegaan met flashen. De led op de lilygo ging ook niet branden eerder, nu wel.

[WargamingPlayer]

pascallj schreef op woensdag 9 juli 2025 @ 08:41:
[...]


Dat is standaard RS485: A(-), B(+) en GND. De Marstek biedt op het laatste paar nog een 5V voeding aan.

Voor deze kleine afstanden is GND niet nodig, je hoeft dus alleen het A en B paar aan te sluiten.

In principe komen de volgende signalen voor de V2 model met handvatten. Deze zijn volgende:

code:

ROOD: A (Data-)
GEEL: B (Data+)
ZWART: VCC- (0)
Leeg:
ZWART: VCC+ (4.5-5.5V)
ROOD: COM.

Voor RS485 zijn alleen A en B nodig. Dit kan makkelijk over 1200 m (4,000 foot). Dus je hoeft de andere signalen niet te gebruiken. Data Ground is leuk, maar veroorzaakt meer problemen dan het oplost en hoeft allen gebruikt te worden op grote afstanden waarbij deze aan een COMMON GROUND aangesloten worden.

Op deze afstanden moet je namelijk ook een terminator gebruiken tussen VCC+ -[720OH] -B-[130OHM]-A-[720OHM]-COM.

Voor onze oplossingen is eigenlijk alleen A en B, VCC- en VCC+ interessant omdat je het als volgt aan sluit:

code:

ROOD: A - Device A (of Data -)
GEEL: B - Device B (of Data +)
ZWART: Naar Power - van Device (of VCC- of 0)
LEEG: Niet aangesloten
ZWART: Naar Power + van Device (of VCC+ of +5V)
ROOD: NIET GEBRUIKEN!

Overigens zijn de officiële kleuren:

code:

A = GROEN
B = ROOD

Wil je een goede aansluiting maken en maak je je zorgen over het signaal dan kan je 2 x 60Ohm weerstand nemen, 1 x een 22uF 10V condensator en maak je de volgende schakeling:

code:

Marstek----- A Kabel -----o--[60 Ohm]--+
Marstek----- B Kabel -----o--[60 Ohm]--+---[220 pF]--- Gnd/VCC-/0

o= Je device.

Meer feiten:
https://www.ti.com/lit/an...252Fen.wikipedia.org%252F

[blackcom]

Nu ben ik toch ook benieuwd naar de die vraag of het nul op de meter houden via modbus potentieel schadelijk zou zijn of niet. Ik doe het zelf ook en verwacht niet dat dit problemen gaat geven. Ik heb de vraag in elk geval gesteld aan de support van Marstek, maar daar heb ik tot hiertoe nog geen degelijk antwoord van gekregen.

Zijn hier nog mensen die nom doen via modbus of mensen die dit expliciet niet doen wegens schrik voor het vele schrijven?

[Robin2133]

blackcom schreef op woensdag 9 juli 2025 @ 18:20:
Nu ben ik toch ook benieuwd naar de die vraag of het nul op de meter houden via modbus potentieel schadelijk zou zijn of niet. Ik doe het zelf ook en verwacht niet dat dit problemen gaat geven. Ik heb de vraag in elk geval gesteld aan de support van Marstek, maar daar heb ik tot hiertoe nog geen degelijk antwoord van gekregen.

Zijn hier nog mensen die nom doen via modbus of mensen die dit expliciet niet doen wegens schrik voor het vele schrijven?

wat is het verschil tussen nom in de marstek app en nom via modbus ? nom is nom lijkt mij

[pascallj]

Robin2133 schreef op woensdag 9 juli 2025 @ 19:12:
[...]


wat is het verschil tussen nom in de marstek app en nom via modbus ? nom is nom lijkt mij

Kortgezegd: NOM via Marstek is gewoon een waarde die wordt doorgestuurd en meteen verwerkt en niet opgeslagen. Als je zelf een NOM algoritme gaat maken en sturen via Modbus stuur je een commando en wordt deze ook opgeslagen. Dus voor elke wijziging, wordt er een schrijf actie gedaan.

Zoals je hierboven ziet, kan je discussie hebben of dit ernstig is of niet, maar flash geheugen in dit soort producten heeft een veel kortere levensduur dan bijvoorbeeld een SSD in je PC. Dus meestal probeer je veel schrijf acties te voorkomen.

[Hometek]

blackcom schreef op woensdag 9 juli 2025 @ 18:20:
Nu ben ik toch ook benieuwd naar de die vraag of het nul op de meter houden via modbus potentieel schadelijk zou zijn of niet. Ik doe het zelf ook en verwacht niet dat dit problemen gaat geven. Ik heb de vraag in elk geval gesteld aan de support van Marstek, maar daar heb ik tot hiertoe nog geen degelijk antwoord van gekregen.

Zijn hier nog mensen die nom doen via modbus of mensen die dit expliciet niet doen wegens schrik voor het vele schrijven?

Ik doe NOM niet via modbus, maar via de auto-mode in de batterij zelf. Ik heb hier hoofdzakelijk voor gekozen omdat ik de ingebouwde regeling goed genoeg vond en geen reden zag om daar zelf iets voor te maken. De onduidelijkheid of de apparaten geschikt zijn voor intensieve aansturing via modbus heeft die keuze wel makkelijker gemaakt.

[blackcom]

Hometek schreef op woensdag 9 juli 2025 @ 19:31:
[...]

Ik doe NOM niet via modbus, maar via de auto-mode in de batterij zelf. Ik heb hier hoofdzakelijk voor gekozen omdat ik de ingebouwde regeling goed genoeg vond en geen reden zag om daar zelf iets voor te maken. De onduidelijkheid of de apparaten geschikt zijn voor intensieve aansturing via modbus heeft die keuze wel makkelijker gemaakt.

Als ik het goed lees heb jij 2 venus batterijen en gebruik jij een shelly om die aan te sturen? Werken de batterijen dan goed samen? De reden dat ik het vraag omdat de ct003 bij mij niet wil werken.

[WargamingPlayer]

pascallj schreef op woensdag 9 juli 2025 @ 19:19:
[...]


Kortgezegd: NOM via Marstek is gewoon een waarde die wordt doorgestuurd en meteen verwerkt en niet opgeslagen. Als je zelf een NOM algoritme gaat maken en sturen via Modbus stuur je een commando en wordt deze ook opgeslagen. Dus voor elke wijziging, wordt er een schrijf actie gedaan.

Zoals je hierboven ziet, kan je discussie hebben of dit ernstig is of niet, maar flash geheugen in dit soort producten heeft een veel kortere levensduur dan bijvoorbeeld een SSD in je PC. Dus meestal probeer je veel schrijf acties te voorkomen.

Misschien verklaard dit ook het verschil met wat register 43000 doet. Je kan hem op 0, 1, 2 zetten. Maar uiteindelijk zal hij allen de waarde 1 rapporteren voor zowel NOM als AI. In de Marstek is dus NOM en AI het zelfde.

De vraag is dus, wat bepaald nu of de Marstek AI of NOM doet zijn. Ik heb gemerkt dat AI modus best wel goed werkt met 2 Marsteks, alleen is de vraag waarom er soms keuzes gemaakt worden welke ik zelf iets anders zou doen.

Ik heb zelf eens een NOM sturing gekeken voor HA. Maar wanneer ik zie hoe veel register writes dit zijn, dan is de flash (als het flash is) eerder kapot dan de Accu’s van de Marsteks.

Dus rest de vraag, zijn de registers in RAM of in Flash. Ik verwacht voor de counters gewoon in RAM met een batterij om deze persistent te houden, maar verwachting is altijd een bron voor teleurstelling.

[pascallj]

WargamingPlayer schreef op woensdag 9 juli 2025 @ 21:18:
[...]

Misschien verklaard dit ook het verschil met wat register 43000 doet. Je kan hem op 0, 1, 2 zetten. Maar uiteindelijk zal hij allen de waarde 1 rapporteren voor zowel NOM als AI. In de Marstek is dus NOM en AI het zelfde.

De vraag is dus, wat bepaald nu of de Marstek AI of NOM doet zijn. Ik heb gemerkt dat AI modus best wel goed werkt met 2 Marsteks, alleen is de vraag waarom er soms keuzes gemaakt worden welke ik zelf iets anders zou doen.

Ik heb zelf eens een NOM sturing gekeken voor HA. Maar wanneer ik zie hoe veel register writes dit zijn, dan is de flash (als het flash is) eerder kapot dan de Accu’s van de Marsteks.

Dus rest de vraag, zijn de registers in RAM of in Flash. Ik verwacht voor de counters gewoon in RAM met een batterij om deze persistent te houden, maar verwachting is altijd een bron voor teleurstelling.

Dat eerste heb ik zojuist getest en klopt idd. Je kunt wel AI als modus instellen, en dit werkt ook, maar het zal uit te lezen zijn als NOM hierna. Vreemd.

Dat laatste heb ik van de week getest: pascallj in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"

Plan is om ooit een scan te doen op alle registers en kijken of er nog ongedocumenteerde registers een antwoord geven.

[WargamingPlayer]

pascallj schreef op maandag 7 juli 2025 @ 11:16:
En omdat bovenstaande relatief eenvoudig te testen is, heb ik Forcible Charge op 300 W gezet, Modbus losgetrokken, de Maestro uitgezet, de stekker eruit getrokken en gewacht tot hij helemaal uit was (geen Bluetooth verbinding meer).

Toen ik hem weer aanzette en Modbus weer had aangesloten, waren de Forcible instellingen gewoon nog aanwezig. Dus of de Marstek was toch niet helemaal afgesloten, of de instellingen worden gewoon opgeslagen. RS485 control was wel automatisch uitgeschakeld.

Dat zegt nog niet alles. Het kan ook gewoon RAM zijn met een batterij. Daarom moet Marstek daar een uitspraak over doen.

[WargamingPlayer]

pascallj schreef op woensdag 9 juli 2025 @ 21:24:
[...]


Dat eerste heb ik zojuist getest en klopt idd. Je kunt wel AI als modus instellen, en dit werkt ook, maar het zal uit te lezen zijn als NOM hierna. Vreemd.

Dat laatste heb ik van de week getest: pascallj in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"

Plan is om ooit een scan te doen op alle registers en kijken of er nog ongedocumenteerde registers een antwoord geven.

Een scan is goed, maar je zou eigenlijk een volledige map moeten maken van alle actieve registers. Dan in de App de waarde op AI zetten, zien wat er veranderd, dus weer alle registers uitlezen en dan weer naar andere mode. En dat een paar keer. Dan pas weet je wat er aan de hand is en of de informatie goed is. De App moet het tenslotte ook uit de Marstek halen.

[pascallj]

WargamingPlayer schreef op woensdag 9 juli 2025 @ 21:36:
[...]

Een scan is goed, maar je zou eigenlijk een volledige map moeten maken van alle actieve registers. Dan in de App de waarde op AI zetten, zien wat er veranderd, dus weer alle registers uitlezen en dan weer naar andere mode. En dat een paar keer. Dan pas weet je wat er aan de hand is en of de informatie goed is. De App moet het tenslotte ook uit de Marstek halen.

Haha ja dat zou kunnen... Echter communiceert de app niet via Modbus dus niet alles hoeft via Modbus beschikbaar te zijn. De Marstek reageert met een foutcode op registers die niet actief zijn, dus met een scan zou je in elk geval al weten welke registers wel actief zijn maar niet gedocumenteerd.

[Hometek]

blackcom schreef op woensdag 9 juli 2025 @ 19:47:
[...]
Als ik het goed lees heb jij 2 venus batterijen en gebruik jij een shelly om die aan te sturen? Werken de batterijen dan goed samen? De reden dat ik het vraag omdat de ct003 bij mij niet wil werken.

Ik heb steeds maar 1 van de 2 batterijen op auto, de andere staat dan stand-by in manual. Automatisch wisselen wordt gestuurd vanuit HA.

[MaGy]

Hoi allemaal

Na het vinden van dit topic ben ik ook overtuigd geraakt om een marstek venus te bestellen, als deze goed werkt en geïntegreerd raakt in mijn loxone systeem komen er misschien nog 2 bij.

De batterij is nog in bestelling, als ook een waveshare 4ch rs485 naar eth omvormer zoals hier gelezen bij enkele van de loxone gebruikers in dit topic aanwezig.

Nu zit ik echter wel al direct met enkele vragen, aangezien mijn kennis over netwerk/modbus toestanden redelijk beperkt is (om niet te zeggen momenteel nog onbestaand).

Momenteel is mijn energiemanagement beperkt tot het aansturen van mijn boiler, bij voldoende vermogen export, met een digitale uitgang. Een elektrisch kacheltje in de badkamer, dit via een homewizard socket met lokale api, en het aan/uit zetten van de airco via infrarood.

Is er hier een vriendelijke techneut aanwezig die mij hiermee op weg kan helpen en eventueel een loxone template of programmatje wil delen? Voor het uitlezen (en aansturen) van de marstek? Die shelly emulator om de net gegevens te manipuleren lijkt me ook wel leuk, aangezien ik verwarm met een warmtepomp en ik in de winter weinig zonneopbrengst heb zou ik een piekshaving willen maken.

Doorverwijzingen naar andere topics waar dit al uitgelegd zijn natuurlijk ook welkom.

Ook nog een vraag aan de bezitters van meerdere Venus batterijen, werken deze goed samen in nul op de meter?

Alvast bedankt

[CoNsPiRaCyBE]

MaGy schreef op woensdag 9 juli 2025 @ 21:45:
Hoi allemaal

Na het vinden van dit topic ben ik ook overtuigd geraakt om een marstek venus te bestellen, als deze goed werkt en geïntegreerd raakt in mijn loxone systeem komen er misschien nog 2 bij.

De batterij is nog in bestelling, als ook een waveshare 4ch rs485 naar eth omvormer zoals hier gelezen bij enkele van de loxone gebruikers in dit topic aanwezig.

Nu zit ik echter wel al direct met enkele vragen, aangezien mijn kennis over netwerk/modbus toestanden redelijk beperkt is (om niet te zeggen momenteel nog onbestaand).

Momenteel is mijn energiemanagement beperkt tot het aansturen van mijn boiler, bij voldoende vermogen export, met een digitale uitgang. Een elektrisch kacheltje in de badkamer, dit via een homewizard socket met lokale api, en het aan/uit zetten van de airco via infrarood.

Is er hier een vriendelijke techneut aanwezig die mij hiermee op weg kan helpen en eventueel een loxone template of programmatje wil delen? Voor het uitlezen (en aansturen) van de marstek? Die shelly emulator om de net gegevens te manipuleren lijkt me ook wel leuk, aangezien ik verwarm met een warmtepomp en ik in de winter weinig zonneopbrengst heb zou ik een piekshaving willen maken.

Doorverwijzingen naar andere topics waar dit al uitgelegd zijn natuurlijk ook welkom.

Ook nog een vraag aan de bezitters van meerdere Venus batterijen, werken deze goed samen in nul op de meter?

Alvast bedankt

Ik heb ook Loxone. Wat is de meerwaarde van integratie met de batterij? Ik gebruik zelf Loxone misschien niet optimaal. Ik werk liever met Home Assistant (waar zowel Loxone als de batterijen ook aan gekoppeld zijn)

[JorisLammar]

Hometek schreef op woensdag 9 juli 2025 @ 19:31:
[...]

Ik doe NOM niet via modbus, maar via de auto-mode in de batterij zelf. Ik heb hier hoofdzakelijk voor gekozen omdat ik de ingebouwde regeling goed genoeg vond en geen reden zag om daar zelf iets voor te maken. De onduidelijkheid of de apparaten geschikt zijn voor intensieve aansturing via modbus heeft die keuze wel makkelijker gemaakt.

Ik heb 3 batterijen en als ik de software van Marstek laat sturen, is het verbruik veel volatieler dan dat ik het stuur. De software is wel fel verbeterd sinds v151, maar het punt is dat hun software geen rekening houdt met andere batterijen en daardoor dit gedrag vertoont (elk batterij probeert voor zichzelf ergens een punt van nulverbruik te bereiken). Daarom stuur ik het zelf aan.

[CoNsPiRaCyBE]

JorisLammar schreef op donderdag 10 juli 2025 @ 09:34:
Ik heb 3 batterijen en als ik de software van Marstek laat sturen, is het verbruik veel volatieler dan dat ik het stuur. De software is wel fel verbeterd sinds v151, maar het punt is dat hun software geen rekening houdt met andere batterijen en daardoor dit gedrag vertoont (elk batterij probeert voor zichzelf ergens een punt van nulverbruik te bereiken). Daarom stuur ik het zelf aan.

Heb je meer info over de implementatie hiervan? Zijn hier kant en klare oplossingen voor in HA?

[JorisLammar]

CoNsPiRaCyBE schreef op donderdag 10 juli 2025 @ 09:40:
[...]


Heb je meer info over de implementatie hiervan? Zijn hier kant en klare oplossingen voor in HA?

https://github.com/JorisL...nus-LilyGo-3-bat-strategy

[SatScan]

JorisLammar schreef op donderdag 10 juli 2025 @ 09:34:
[...]


Ik heb 3 batterijen en als ik de software van Marstek laat sturen, is het verbruik veel volatieler dan dat ik het stuur. De software is wel fel verbeterd sinds v151, maar het punt is dat hun software geen rekening houdt met andere batterijen en daardoor dit gedrag vertoont (elk batterij probeert voor zichzelf ergens een punt van nulverbruik te bereiken). Daarom stuur ik het zelf aan.

Bij mij werkt het prima met de MT software en meerdere batterijen.
Sinds v151 en CT003 v114 werkt het bijna perfect (er is altijd ruimte voor verbetering).
Kom de avond/nacht door met een grid verbruik van kleiner dan 0,2KWhh en de gehele dag met 0,4KWh.

Welke andere regeling doet dit beter?

[ Voor 16% gewijzigd door SatScan op 10-07-2025 10:23 ]

[JorisLammar]

Gezien de opmerkingen rond het nadeel van veelvuldig gebruik van het flashgeheugen, zal ik ook eens enkele dagen laten draaien op de MT software. Het is inderdaad mogelijk een discussie in de marge (als de het meerverbruik 0,5 kWh per dag is, is die kost minimaal versus het risico jouw investering van de batterijen naar de filistijnen te helpen). Keep ya posted.

[rtlvandeven]

Ik heb nog een scan gemaakt van de registers (Venus-E/v153) en kwam tot deze 2 lijsten:

Scanned 30000-39999:
Range [30000-30010]
Range [30100-30103]
Range [30200-30203]
Range [30300-30303]
Range [30399-30407]
Range [30500-30500]
Range [30600-30600]
Range [30700-30700]
Range [30800-30805]
Range [31000-31009]
Range [31100-31102]
Range [31200-31209]
Range [32100-32105]
Range [32200-32204]
Range [32300-32303]
Range [33000-33011]
Range [35000-35002]
Range [35010-35011]
Range [35100-35100]
Range [35110-35112]
Range [36000-36001]
Range [36100-36103]
Range [37000-37016]

Scanned 40000-49999:
Range [41000-41001]
Range [41010-41010]
Range [41100-41100]
Range [41200-41200]
Range [41500-41516]
Range [41600-41632]
Range [42000-42000]
Range [42010-42011]
Range [42020-42021]
Range [43000-43000]
Range [43100-43129]
Range [44000-44003]
Range [44100-44100]
Range [45603-45604]

Hierin staan ranges die niet in het duravolt pdf-document voorkomen.

Ik denk dat onderstaande registers misschien nog wel interessant kunnen zijn:

30402[6]: mac address
30800[6]: communication module firmware version
37006[1]: current cell temperature ?
37007[1]: current voltage of highest cell ? (x0.001)
37008[1]: current voltage of lowest cell ? (x0.001)
41500[16]: ssid

[pascallj]

rtlvandeven schreef op donderdag 10 juli 2025 @ 14:53:
Ik heb nog een scan gemaakt van de registers (Venus-E/v153) en kwam tot deze 2 lijsten:

Scanned 30000-39999:
Range [30000-30010]
Range [30100-30103]
Range [30200-30203]
Range [30300-30303]
Range [30399-30407]
Range [30500-30500]
Range [30600-30600]
Range [30700-30700]
Range [30800-30805]
Range [31000-31009]
Range [31100-31102]
Range [31200-31209]
Range [32100-32105]
Range [32200-32204]
Range [32300-32303]
Range [33000-33011]
Range [35000-35002]
Range [35010-35011]
Range [35100-35100]
Range [35110-35112]
Range [36000-36001]
Range [36100-36103]
Range [37000-37016]

Scanned 40000-49999:
Range [41000-41001]
Range [41010-41010]
Range [41100-41100]
Range [41200-41200]
Range [41500-41516]
Range [41600-41632]
Range [42000-42000]
Range [42010-42011]
Range [42020-42021]
Range [43000-43000]
Range [43100-43129]
Range [44000-44003]
Range [44100-44100]
Range [45603-45604]

Hierin staan ranges die niet in het duravolt pdf-document voorkomen.

Ik denk dat onderstaande registers misschien nog wel interessant kunnen zijn:

30402[6]: mac address
30800[6]: communication module firmware version
37006[1]: current cell temperature ?
37007[1]: current voltage of highest cell ? (x0.001)
37008[1]: current voltage of lowest cell ? (x0.001)
41500[16]: ssid

Hiervoor zit ik op Tweakers

[MaGy]

CoNsPiRaCyBE schreef op donderdag 10 juli 2025 @ 05:09:
[...]


Ik heb ook Loxone. Wat is de meerwaarde van integratie met de batterij? Ik gebruik zelf Loxone misschien niet optimaal. Ik werk liever met Home Assistant (waar zowel Loxone als de batterijen ook aan gekoppeld zijn)

Dan weet je hoeveel vermogen er in of uit de batterij gaat, en hoeveel er in zit. Daar kan de rest van je energie manager dan rekening houden.
bvb er gaat meer dan 2000W naar de batterij, dan kan ook de boiler opgezet worden, 1500W boiler 500W nog naar de batterij. of omgekeerd, als er niet meer voldoende productie is gaat de boiler de batterij niet leeg trekken. Airco kan je bvb als extra start voorwaarde geven dat er 90% in de batterij moet zitten, en uitgezet als de soc onder de 70% zakt, dan wordt die minder aan en uitgezet, wat beter is voor zulk toestel

Met home assistant heb ik geen ervaring, maar ik zou het liever met 1 systeem houden. Ik veranderstel dat je vermelde voorbeelden dan via HA doet ipv Loxone

[SatScan]

rtlvandeven schreef op donderdag 10 juli 2025 @ 14:53:
Ik heb nog een scan gemaakt van de registers (Venus-E/v153) en kwam tot deze 2 lijsten:

Scanned 30000-39999:
Range [30000-30010]
Range [30100-30103]
Range [30200-30203]
Range [30300-30303]
Range [30399-30407]
Range [30500-30500]
Range [30600-30600]
Range [30700-30700]
Range [30800-30805]
Range [31000-31009]
Range [31100-31102]
Range [31200-31209]
Range [32100-32105]
Range [32200-32204]
Range [32300-32303]
Range [33000-33011]
Range [35000-35002]
Range [35010-35011]
Range [35100-35100]
Range [35110-35112]
Range [36000-36001]
Range [36100-36103]
Range [37000-37016]

Scanned 40000-49999:
Range [41000-41001]
Range [41010-41010]
Range [41100-41100]
Range [41200-41200]
Range [41500-41516]
Range [41600-41632]
Range [42000-42000]
Range [42010-42011]
Range [42020-42021]
Range [43000-43000]
Range [43100-43129]
Range [44000-44003]
Range [44100-44100]
Range [45603-45604]

Hierin staan ranges die niet in het duravolt pdf-document voorkomen.

Ik denk dat onderstaande registers misschien nog wel interessant kunnen zijn:

30402[6]: mac address
30800[6]: communication module firmware version
37006[1]: current cell temperature ?
37007[1]: current voltage of highest cell ? (x0.001)
37008[1]: current voltage of lowest cell ? (x0.001)
41500[16]: ssid

TOP!

Dank je wel 👍

[WargamingPlayer]

rtlvandeven schreef op donderdag 10 juli 2025 @ 14:53:
Ik heb nog een scan gemaakt van de registers (Venus-E/v153) en kwam tot deze 2 lijsten:

Scanned 30000-39999:
Range [30000-30010]
Range [30100-30103]
Range [30200-30203]
Range [30300-30303]
Range [30399-30407]
Range [30500-30500]
Range [30600-30600]
Range [30700-30700]
Range [30800-30805]
Range [31000-31009]
Range [31100-31102]
Range [31200-31209]
Range [32100-32105]
Range [32200-32204]
Range [32300-32303]
Range [33000-33011]
Range [35000-35002]
Range [35010-35011]
Range [35100-35100]
Range [35110-35112]
Range [36000-36001]
Range [36100-36103]
Range [37000-37016]

Scanned 40000-49999:
Range [41000-41001]
Range [41010-41010]
Range [41100-41100]
Range [41200-41200]
Range [41500-41516]
Range [41600-41632]
Range [42000-42000]
Range [42010-42011]
Range [42020-42021]
Range [43000-43000]
Range [43100-43129]
Range [44000-44003]
Range [44100-44100]
Range [45603-45604]

Hierin staan ranges die niet in het duravolt pdf-document voorkomen.

Ik denk dat onderstaande registers misschien nog wel interessant kunnen zijn:

30402[6]: mac address
30800[6]: communication module firmware version
37006[1]: current cell temperature ?
37007[1]: current voltage of highest cell ? (x0.001)
37008[1]: current voltage of lowest cell ? (x0.001)
41500[16]: ssid

Perfect dat is al meer dan ik gehoopt had.

[antonboonstra]

blackcom schreef op woensdag 9 juli 2025 @ 18:20:
Nu ben ik toch ook benieuwd naar de die vraag of het nul op de meter houden via modbus potentieel schadelijk zou zijn of niet. Ik doe het zelf ook en verwacht niet dat dit problemen gaat geven. Ik heb de vraag in elk geval gesteld aan de support van Marstek, maar daar heb ik tot hiertoe nog geen degelijk antwoord van gekregen.

Zijn hier nog mensen die nom doen via modbus of mensen die dit expliciet niet doen wegens schrik voor het vele schrijven?

Ik stuur ook bijna continu via modbus op NOM. Tot nu toe (ca 3 maanden lang) nog zonder problemen.

Een aantal dagen geleden via de website van Marstek support gevraagd of de modbusregisters in volatile of nonvolatile geheugen staan. 'k Heb zojuist antwoord ontvangen.

Hi, we don't provide modbus functionality at the moment, we apologise for the inconvenience, if your problem is still not solved, please contact us via "Settings" -> "User Feedback".Thanks again for your great support of the product, best regards!

From MARSTEK Support Team

Daar heb je dus ook niks aan

[pascallj]

antonboonstra schreef op donderdag 10 juli 2025 @ 20:47:
[...]

Ik stuur ook bijna continu via modbus op NOM. Tot nu toe (ca 3 maanden lang) nog zonder problemen.

Een aantal dagen geleden via de website van Marstek support gevraagd of de modbusregisters in volatile of nonvolatile geheugen staan. 'k Heb zojuist antwoord ontvangen.

[...]

Daar heb je dus ook niks aan

Klopt, er is al meerdere malen via support om Modbus informatie gevraagd, maar ze willen dat niet geven. Is alleen beschikbaar voor de grote partijen.

[blackcom]

antonboonstra schreef op donderdag 10 juli 2025 @ 20:47:
[...]

Ik stuur ook bijna continu via modbus op NOM. Tot nu toe (ca 3 maanden lang) nog zonder problemen.

Een aantal dagen geleden via de website van Marstek support gevraagd of de modbusregisters in volatile of nonvolatile geheugen staan. 'k Heb zojuist antwoord ontvangen.

[...]

Daar heb je dus ook niks aan

Ik heb ook soortgelijk bericht gekregen. Ik ben nu aan het proberen om mijn controller een shelly te doen faken en zo per batterij de ingebouwde regeling te beïnvloeden. (gebaseerd op het b2500-meter project) Het ziet er zeer belovend uit maar nog wel wat werk aan. Modbus blijft de betere keuze al is het maar vanwege de flaky wifi van de batterijen dus hopelijk kan iemand te weten komen of het veilig kan.

[_ferry_]

Hometek schreef op woensdag 9 juli 2025 @ 19:31:
[...]

Ik doe NOM niet via modbus, maar via de auto-mode in de batterij zelf. Ik heb hier hoofdzakelijk voor gekozen omdat ik de ingebouwde regeling goed genoeg vond en geen reden zag om daar zelf iets voor te maken. De onduidelijkheid of de apparaten geschikt zijn voor intensieve aansturing via modbus heeft die keuze wel makkelijker gemaakt.

Ik moet tzt ook beide gaan aansturen, nu doe ik het via een vast vermogen (prima in de nacht, 180w sluipverbruik opvangen. Ik wissel ze dan af)
Maar voor het najaar wordt het opeens een stuk complexer verwacht ik.

Hele nacht NOM, prima, wat verbruik van standby en de warmtepomp.
Tot het zonnetje misschien doorkomt, dan gaat hij laden, maar soms is dat vroeg in de ochtend, wanneer de prijs nog erg hoog is, en wil je pas later gaan laden. Dat soort invloeden.
En dan ook nog beide accus benutten. Misschien een soort serieschakeling maken, dat als de ene leeg is, de ander gebruikt gaat worden. En dat dan elke week/maand wisselen oid, zodat ze een beetje hetzelfde aantal cycli maken.

Aan de andere kant, in de echte winterperiode is de opwekking zo laag, dat je niet naar de prijs kijkt, maar gewoon elke watt aan opwek in je accu wil stoppen

[Hometek]

_ferry_ schreef op vrijdag 11 juli 2025 @ 08:35:
[...]
Ik moet tzt ook beide gaan aansturen, nu doe ik het via een vast vermogen (prima in de nacht, 180w sluipverbruik opvangen. Ik wissel ze dan af)
Maar voor het najaar wordt het opeens een stuk complexer verwacht ik.

Hele nacht NOM, prima, wat verbruik van standby en de warmtepomp.
Tot het zonnetje misschien doorkomt, dan gaat hij laden, maar soms is dat vroeg in de ochtend, wanneer de prijs nog erg hoog is, en wil je pas later gaan laden. Dat soort invloeden.
En dan ook nog beide accus benutten. Misschien een soort serieschakeling maken, dat als de ene leeg is, de ander gebruikt gaat worden. En dat dan elke week/maand wisselen oid, zodat ze een beetje hetzelfde aantal cycli maken.

Aan de andere kant, in de echte winterperiode is de opwekking zo laag, dat je niet naar de prijs kijkt, maar gewoon elke watt aan opwek in je accu wil stoppen

Als je een bepaalde strategie wilt volgen op basis van kosten kun je het opladen/ontladen afhankelijk maken van de stroomprijs op dat moment door de cheapest hours integratie in HA te gebruiken.

Ik gebruik de batterijen ook in een soort serieschakeling, met extra wisselmomenten 's ochtend en 's avonds op basis van SOC en opwek om het gebruik een beetje gelijkmatig te verdelen.
Ik heb hier mijn aanpak verder toegelicht (mijn strategie is echter niet gebaseerd op kosten, maar op maximaal eigen gebruik)

[TDSgame]

Hallo allemaal,

Dit is mijn eerste post op het forum, dus hallo iedereen!

Ik heb er thuis drie marstek venusen in gebruik, maar de bijgeleverde software werkt helaas verre van optimaal. Vooral het gedrag wanneer je twee batterijen op één energiemeter aansluit, is echt problematisch, dit werkt gewoonweg niet goed. (combo van V1 en V2)

Na heel wat frustratie heb ik daarom besloten om zelf de volledige aansturing via Modbus te schrijven. Het is nog een work in progress, maar ik wilde dit alvast even met jullie delen.

Om dit goed aan te pakken, heb ik ook een nieuwe module besteld: de LilyGO T-Connect
👉 https://github.com/Xinyuan-LilyGO/T-Connect
Deze gebruik ik als basis om beide batterijen via één teller betrouwbaar uit te lezen en aan te sturen.

Ik verwacht binnen ongeveer een maand een eerste versie van mijn software publiek beschikbaar te maken. Als er interesse is, hou ik jullie hier graag op de hoogte van de voortgang!

Groeten,
Thomas

[TDSgame]

Ik heb ook recent een 3D-printbaar haaks verloopstuk ontworpen voor de Betteri BC01-connector, specifiek met het oog op gebruik bij Marstek- of Duravolt-thuisbatterijen. Het idee ontstond omdat ik de batterijen graag dichter bij elkaar wilde plaatsen, bijvoorbeeld in een flightcase voor kleine events of mobiele toepassingen. De originele connector steekt recht naar buiten en dat maakt het soms lastig in krappe ruimtes.

Een paar details:

Niet waterdicht (gebruik op eigen risico)

Bestaat uit 2 printbare delen: de behuizing (staand printen) en het deksel (vlak printen) — beide met support

Ontworpen voor 3G2.5-kabel met een beetje trekontlasting

Nodig: 2x M3x16mm schroeven en een extra BC01-connector (ik wilde de originele behouden voor garantie)

Misschien heeft iemand hier ook iets aan, zeker als je met vergelijkbare batterijen werkt of zelf een compacte opstelling wilt maken. STL’s zijn beschikbaar via Printables, laat gerust weten als je interesse hebt!

https://www.printables.co...etteri-bc01-connector-mar

Groeten,
Thomas

[Hometek]

TDSgame schreef op vrijdag 11 juli 2025 @ 14:14:
Ik heb ook recent een 3D-printbaar haaks verloopstuk ontworpen voor de Betteri BC01-connector, specifiek met het oog op gebruik bij Marstek- of Duravolt-thuisbatterijen. Het idee ontstond omdat ik de batterijen graag dichter bij elkaar wilde plaatsen, bijvoorbeeld in een flightcase voor kleine events of mobiele toepassingen. De originele connector steekt recht naar buiten en dat maakt het soms lastig in krappe ruimtes.

Een paar details:

Niet waterdicht (gebruik op eigen risico)

Bestaat uit 2 printbare delen: de behuizing (staand printen) en het deksel (vlak printen) — beide met support

Ontworpen voor 3G2.5-kabel met een beetje trekontlasting

Nodig: 2x M3x16mm schroeven en een extra BC01-connector (ik wilde de originele behouden voor garantie)

Misschien heeft iemand hier ook iets aan, zeker als je met vergelijkbare batterijen werkt of zelf een compacte opstelling wilt maken. STL’s zijn beschikbaar via Printables, laat gerust weten als je interesse hebt!

https://www.printables.co...etteri-bc01-connector-mar

Groeten,
Thomas

Hier is een 3D geprinte haakse stekker uit 1 stuk. Deze is echter iets minder compact.
Ik gebruik deze ook buiten.

[JorisLammar]

JorisLammar schreef op donderdag 10 juli 2025 @ 10:31:
Gezien de opmerkingen rond het nadeel van veelvuldig gebruik van het flashgeheugen, zal ik ook eens enkele dagen laten draaien op de MT software. Het is inderdaad mogelijk een discussie in de marge (als de het meerverbruik 0,5 kWh per dag is, is die kost minimaal versus het risico jouw investering van de batterijen naar de filistijnen te helpen). Keep ya posted.

Na een dagje draaien: eerste bevindingen. Op het eerste zicht komt het laden dicht bij NOM (0,4 kWh / dag injectie). Maar ... terwijl de ene batterij aan de het laden is, is de andere batterij aan het ontladen. Niet echt bevordelijk voor de efficientie. Ik ga dus terug mijn eigen routines laten draaien.

[pascallj]

JorisLammar schreef op vrijdag 11 juli 2025 @ 19:35:
[...]


Na een dagje draaien: eerste bevindingen. Op het eerste zicht komt het laden dicht bij NOM (0,4 kWh / dag injectie). Maar ... terwijl de ene batterij aan de het laden is, is de andere batterij aan het ontladen. Niet echt bevordelijk voor de efficientie. Ik ga dus terug mijn eigen routines laten draaien.

Maar als jij de HW P1 uit je signatuur ook gebruikt voor NOM, dan is dat uiteraard te verwachten. Alleen de meters van Marstek ondersteunen meerdere batterijen voor NOM. Dat staat ook duidelijk beschreven in het andere topic: 'Ondersteuning meerdere batterijen' in Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu

[JorisLammar]

pascallj schreef op vrijdag 11 juli 2025 @ 20:09:
[...]


Maar als jij de HW P1 uit je signatuur ook gebruikt voor NOM, dan is dat uiteraard te verwachten. Alleen de meters van Marstek ondersteunen meerdere batterijen voor NOM. Dat staat ook duidelijk beschreven in het andere topic: 'Ondersteuning meerdere batterijen' in Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu

Dat had ik niet gelezen dat dit vanaf v151 wel zou werken. Ik had eerst gewerkt met de CT003 maar daar was het ook niet OK (de ene batterij was gekoppeld aan L1, de andere aan L2, de derde nam het totaal in het oog - zonnepanelen op L1 en L2). Bijkomend probleem is dat de HW p1 instabiel is als die samen met de CT003 in de splitter zat. Maar, ik ga dit alleszins opnieuw testen.

[pascallj]

JorisLammar schreef op vrijdag 11 juli 2025 @ 20:46:
[...]


Dat had ik niet gelezen dat dit vanaf v151 wel zou werken. Ik had eerst gewerkt met de CT003 maar daar was het ook niet OK (de ene batterij was gekoppeld aan L1, de andere aan L2, de derde nam het totaal in het oog - zonnepanelen op L1 en L2). Bijkomend probleem is dat de HW p1 instabiel is als die samen met de CT003 in de splitter zat. Maar, ik ga dit alleszins opnieuw testen.

Je zou alles op totaal-som moeten kunnen zetten vanaf firmware 114 op de CT003 en firmware 151 van de batterij. Sowieso ook beide meters van een voeding voorzien tijdens het testen. Jij hebt weer een projectje erbij .

[pascallj]

Naar aanleiding van mijn geniale idee om een Modbus scan te doen en de opzet van @rtlvandeven, kon ik het niet laten om dit ook uit te voeren. Ik heb wat hardware in elkaar geknutseld en een scan uitgevoerd op alle adressen (wist niet of rtlvandeven dat ook al had gedaan, of alleen tussen 30000-49999). Ik heb de gegevens kunnen verifiëren en verder geen nieuwe ranges gevonden.

Van veel ranges is het nog niet bekend wat er op zit. Dan zou ik ze even moeten gaan loggen tijdens gebruik van de batterij, maar zover ben ik nog niet gekomen. Het lastige is dat een range kan bestaan uit meerdere adressen, of 1 adres met veel data.

Technisch paragraafje (mag je overslaan):

Normaal bevat een Modbus adres 2 bytes. Je kunt natuurlijk meer dan 2 bytes aan data willen, normaal gebruik je dan meerdere adressen. Je kunt echter wel meerdere adressen tegelijk uitvragen waardoor je data netjes achter elkaar krijgt. Het gekke bij de Venus, is dat als een adres meer dan 2 bytes bevat (en dus eigenlijk meer adressen nodig heeft om dit op te slaan) je deze uit moet vragen met 1 uitvraag. De data is niet correct wanneer je het doet met twee opeenvolgende uitvragen. Voorbeeld: het apparaatnaam is altijd: "BI_2.5_2.5". Normaal bevat adres 1 'BI', adres 2 '_2', adres 3 '.5' etc. Als je het allemaal uitvraagt vanaf adres 1 met een lengte die groot genoeg is, krijg je netjes achtereenvolgend de naam terug. Echter als je met de hand adres 2 zou opvragen, antwoordt de Venus in dit geval 'I_' etc. Er gaat dus wat mis met uitvragen en als je handmatig adres 1,2,3 etc. achter elkaar zou plakken, krijg je niet het goede resultaat. Maar, vanwege deze gekkigheid, is het dus wel mogelijk om te bepalen wanneer een range bestaat uit losse registers, of uit 1 register met meer data of een combinatie daarvan zolang er maar iets van data aanwezig is. Als de registers leeg zijn (nullen bevatten) kan je natuurlijk niet zien wanneer de data opschuift en dus incorrect is.

Met bovenstaande gekkigheid heb ik afgeleid wanneer ranges eigenlijk losse registers zijn. Er is 1 geval waar zich dit niet voordoet en dat is de WiFi SSID. Hoe dat komt zou ik niet weten. Misschien klopt bovenstaande niet altijd? Het klopte echter wel voor alle registers waarvan we de waardes al wisten.

Maar goed, dat terzijde, nu we steeds meer wijzigingen gaan maken aan de bekende Modbus specificatie heb ik deze overgenomen in een Sheet zodat we makkelijker wijzigingen kunnen doorvoeren. Deze vind je hier:

https://docs.google.com/s...gid=319238506&single=true

Wat dingen die we nu al extra kunnen uitlezen via Modbus:

* Device MAC address (rtlvandeven)
* Communication module firmware version (rtlvandeven)
* WiFi SSID (misschien ook wijzigen?) (rtlvandeven)
* Mogelijk Current cell temperature?? (rtlvandeven)
* Mogelijk Current voltage of highest cell?? (x0.001) (rtlvandeven)
* Mogelijk Current voltage of lowest cell?? (x0.001) (rtlvandeven)
* BMS version (dus 213 o.i.d)
* Firmware version (dus 153 o.i.d)
* Eerste twee karakters van het WiFi password (ja echt hoe dat werkt zou ik niet weten, misschien ook wijzigen?)

Mocht iemand hier mee aan de slag gaan en nog suggesties hebben voor onbekende adressen, laat maar weten dan pas ik het aan! Ook als er dingen zijn die we opgemerkt hebben op het bestaande document wat incorrect was, maar nog niet aangepast zijn, hoor ik het graag! Ook handig om het naast de MQTT te leggen als je dat gebruikt!

De error codes zijn daar 1 van, misschien dat bovenstaande theorie wat licht kan schijnen op dat probleem.

Het slechte nieuws: individuele cell voltages zitten er gegarandeerd niet in. Dat patroon had wel opgevallen voor 16 cellen.

[AUijtdehaag]

@pascallj
Met een api call staan de cell voltages allemaal echter elkaar gescheiden door een komma.
Misschien in modbus ook?
AUijtdehaag in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

[Maarten69]

@pascallj held! Dit waardeer ik enorm.

[WargamingPlayer]

AUijtdehaag schreef op zaterdag 12 juli 2025 @ 06:31:
@pascallj
Met een api call staan de cell voltages allemaal echter elkaar gescheiden door een komma.
Misschien in modbus ook?
AUijtdehaag in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

Het is mij nog niet gelukt om via Modbus de cel voltages uit te lezen omdat ik niet weet welk register ze zijn. Wanneer ik dat zou weten dan was het heel eenvoudig want dan lees ik met 1 opdracht alle registers uit, stop ik deze in een sensor en ga ik met states(‘sensor.name’).split(‘,’)[batnum] | float

Maar tja, welk serie aan registers zijn het?

Waar we achter zijn door een aantal slimme mensen zoals @pascallj en @superduper1969 in het Modbus forum dat sommige Modbus registers alleen te lezen zijn wanneer je ze in 1 grote batch uit leest (count x).

[pascallj]

AUijtdehaag schreef op zaterdag 12 juli 2025 @ 06:31:
@pascallj
Met een api call staan de cell voltages allemaal echter elkaar gescheiden door een komma.
Misschien in modbus ook?
AUijtdehaag in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

Zo'n berg data had wel opgevallen. Het meeste wat nu nog onbekend is zijn kleine lage getallen of ranges die helemaal leeg zijn. Ik acht de kans klein dat het aanwezig is.

[TDSgame]

@SatScan gebruik jij meerder batterijen (3, 1 op elke fase)? zoja staat je MT instelling dan per fase?

@JorisLammar ik heb hetzelfde probleem dat de ene op laad en ontlaad maar mijn instelling staat op de som van het net en niet per fase, ik denk dat het per fase beter werkt (kan ik niet testen aangezien ik een 3x230 net heb, ook maar 2 accu's niet 3),

wat betreft de levensduur vanwege het schrijven dit zou geen probleem mogen zijn aangezien modbus daar voor gemaakt is.

[ Voor 4% gewijzigd door TDSgame op 12-07-2025 11:45 ]

[Hometek]

TDSgame schreef op zaterdag 12 juli 2025 @ 11:42:
...
wat betreft de levensduur vanwege het schrijven dit zou geen probleem mogen zijn aangezien modbus daar voor gemaakt is.

Modbus is slechts een data protocol, dat staat los van het type geheugens dat een producent gebruikt in zijn hardware. En in mijn ervaring is het met name bij Chinese producten niet ongebruikelijk dat componenten gebruikt worden met minimale veiligheidsmarges.
Bij een plug-and-play apparaat als de Venus lijkt mij de seriele poort vooral bedoelt als service interface om bv nieuwe firmware te kunnen installeren na een software crash. Volledige ansturing door externe controllers was mogelijk geen beoogd doel tijdens het ontwerp.

[Animal]

Gekozen om de Elfin EW11 en de JST connector te kopen. Accu komt komende week binnen denk ik.
Enorm bedankt voor alle informatie!

[SatScan]

TDSgame schreef op zaterdag 12 juli 2025 @ 11:42:
@SatScan gebruik jij meerder batterijen (3, 1 op elke fase)? zoja staat je MT instelling dan per fase?

@JorisLammar ik heb hetzelfde probleem dat de ene op laad en ontlaad maar mijn instelling staat op de som van het net en niet per fase, ik denk dat het per fase beter werkt (kan ik niet testen aangezien ik een 3x230 net heb, ook maar 2 accu's niet 3),

wat betreft de levensduur vanwege het schrijven dit zou geen probleem mogen zijn aangezien modbus daar voor gemaakt is.

Heb er 2 op dit moment en ze staan op NOM 3fase-som en dat werkt (bijna) perfect!
Je hebt wel de juiste versie FW nodig voor je Batt en CT003
Lees hier en Hier

Het veelvuldig data schrijven van info in de modbus kan een probleem vormen.
We weten het gewoon niet, meestal wordt de data eerst in vluchtig geheugen gezet en later pas weggeschreven in permanent geheugen.

[ Voor 11% gewijzigd door SatScan op 12-07-2025 14:02 ]

[TDSgame]

@SatScan ik zal nog eens bekijken of het met de CT003 werkt maar ik heb het een eindje getest en het werkte echt gigantisch slecht, voornamelijk dan het op en ontladen van elkaar, (ik heb van wel een beetje een speciale situatie die nog wat andere problemen veroorzaakte)

Meter 1 heb ik een V1 en V2 batterij met een CT003 dit werkte echt slecht ene batterij was 500W aan het laden de andere 700W aan het geven en het wisselde constant af welke er leverde en welke opladen

Meter 2 heb ik een V1 met CT003 (dit werkt wel)

hierdoor heb ik ook nog problemen dat de batterijen soms aan de verkeerde CT003 gekoppeld geraken (nochtans zitten ze in een verschillend marstek account) ze zitten namelijk op het zelfde wifi netwerk.

[WargamingPlayer]

TDSgame schreef op zaterdag 12 juli 2025 @ 15:07:
@SatScan ik zal nog eens bekijken of het met de CT003 werkt maar ik heb het een eindje getest en het werkte echt gigantisch slecht, voornamelijk dan het op en ontladen van elkaar, (ik heb van wel een beetje een speciale situatie die nog wat andere problemen veroorzaakte)

Meter 1 heb ik een V1 en V2 batterij met een CT003 dit werkte echt slecht ene batterij was 500W aan het laden de andere 700W aan het geven en het wisselde constant af welke er leverde en welke opladen

Meter 2 heb ik een V1 met CT003 (dit werkt wel)

hierdoor heb ik ook nog problemen dat de batterijen soms aan de verkeerde CT003 gekoppeld geraken (nochtans zitten ze in een verschillend marstek account) ze zitten namelijk op het zelfde wifi netwerk.

Vergeet niet dat er al een paar firmware updates zijn geweest. En nu gaat het wel goed, alleen heb ik alleen ervaring met twee keer V2 + CT003.