Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[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.

[SatScan]

TDSgame schreef op zaterdag 12 juli 2025 @ 15:07:

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.

Dit zou ik in de feedback van de app melden en vragen of ze hier een oplossing voor kunnen bedenken.
Zou zo maar kunnen dat ze een test/beta versie voor je maken die dit probleem verhelpt.
Dat komt geregeld voor als gebruikers een probleem melden in hun specifieke situatie.

Of toch met de wifi settings van je netwerk aan de slag. Afhankelijk van de AP hardware/firmware kun je dit zelf instellen.

[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.

Zou dat te maken kunnen hebben dat ze met UDP werken en niet met TCP. Ik heb zelf al gezien dat de CT003 soms een broadcast doen op het LAN. Dan zou het wel eens kunnen dat de verkeerde Venus het op vangt.

In dit soort situaties help maar 1 ding, gescheiden netwerken, dit kan je door VLANs afdwingen.

[SatScan]

WargamingPlayer schreef op zaterdag 12 juli 2025 @ 18:23:
[...]

Zou dat te maken kunnen hebben dat ze met UDP werken en niet met TCP. Ik heb zelf al gezien dat de CT003 soms een broadcast doen op het LAN. Dan zou het wel eens kunnen dat de verkeerde Venus het op vangt.

In dit soort situaties help maar 1 ding, gescheiden netwerken, dit kan je door VLANs afdwingen.

Misschien dat deze nieuwe versie ook helpt.

Nieuwste update voor CT003 V117

"Hello, the latest version has optimised the following: 1. Optimised UDP reception and restart optimisation. 2. Added Bluetooth upgrade command for Remote modules. 3. Fixed the 7E1 configuration bug in CT3, optimised SML protocol parsing, and added SML protocol printing functionality. We recommend that you upgrade to the latest version for smoother device operation. If you have any questions, please feel free to contact us."

[TDSgame]

Bedankt voor jullie feedback allemaal, ik heb deze middag dus nogmaals geprobeerd om de 2de accu van meter 1 op de CT003 aan te sluiten maar deze blijft kijken naar de verkeerde CT003 (meter 2) zelf al zit deze niet in de app, ook zie ik dat de laatste beschikbare versie van de CT003 bij mij momenteel V116 bedraagt.

Een andere AP of VLAN zou waarschijnlijk helpen maar dit is momenteel niet mogelijk doordat ik gebruik maak van een standaard router van de provider. batterijen staan op V153

[JorisLammar]

TDSgame schreef op zaterdag 12 juli 2025 @ 20:39:
Bedankt voor jullie feedback allemaal, ik heb deze middag dus nogmaals geprobeerd om de 2de accu van meter 1 op de CT003 aan te sluiten maar deze blijft kijken naar de verkeerde CT003 (meter 2) zelf al zit deze niet in de app, ook zie ik dat de laatste beschikbare versie van de CT003 bij mij momenteel V116 bedraagt.

Een andere AP of VLAN zou waarschijnlijk helpen maar dit is momenteel niet mogelijk doordat ik gebruik maak van een standaard router van de provider. batterijen staan op V153

Ik heb daar gisteren ook last mee gehad (3de batterij dan). Na enkele pogingen de CT proberen te veranderen en eens in manuele mode te zetten is het me gelukt.
Eerste dag was het verloop niet goed, vandaag al een beetje beter. Wat het eigenlijk doet is met een tact-tijd van 15 seconden werken per batterij waarbij elke batterij asynchroon is tov de andere. Dus de ene batterij pakt het verschil op wat de andere maken (ism verbruik). Dus in sommige gevallen is de ene aan het laden terwijl de andere aan het ontladen is.

[Metsubsidie]

Voor Domoticz gebruikers

Zie https://forum.domoticz.com/viewtopic.php?f=65&t=43761

Ik heb op relatief eenvoudige wijze de Marstek Venus via PUSR-DR134 en de MqttMapper plugin van Domoticz de modbus uitlezing/integratie in Domoticz kunnen realiseren.

Geen aparte API of dedicated plugin nodig!

Met dank aan @superduper1969 en anderen voor de hier gepubliceerde startinformatie.

[Gh0st]

Hoi!

Ik heb gezocht in de TS maar kon het antwoord helaas niet vinden.

Marstek heeft een update voor me accu klaar gezet maar werkt de Lilygo code voor uitlezen voor Home Assistant op elke firmware versie van de thuis batterij?

Bvbd!

[Hometek]

Gh0st schreef op zondag 13 juli 2025 @ 16:07:
Hoi!

Ik heb gezocht in de TS maar kon het antwoord helaas niet vinden.

Marstek heeft een update voor me accu klaar gezet maar werkt de Lilygo code voor uitlezen voor Home Assistant op elke firmware versie van de thuis batterij?

Bvbd!

Voor zover mij bekend werkt de modbus/lilygo setup in ieder geval tm FW V153.
Er is wel een post over max/min cell temperatuur die anders wordt weergegeven in V153. Maar modbus functioneert.
Alleen MQTT lijkt niet te werken bij V153.

[superduper1969]

Gh0st schreef op zondag 13 juli 2025 @ 16:07:
Hoi!

Ik heb gezocht in de TS maar kon het antwoord helaas niet vinden.

Marstek heeft een update voor me accu klaar gezet maar werkt de Lilygo code voor uitlezen voor Home Assistant op elke firmware versie van de thuis batterij?

Bvbd!

Ja, anders zou er voor iedere release weer een andere versie van de Lilygo code zijn gereleased, en dat is dus niet nodig.

[pascallj]

Hometek schreef op zondag 13 juli 2025 @ 16:57:
[...]

Voor zover mij bekend werkt de modbus/lilygo setup in ieder geval tm FW V153.
Er is wel een post over max/min cell temperatuur die anders wordt weergegeven in V153. Maar modbus functioneert.
Alleen MQTT lijkt niet te werken bij V153.

Deze verandering komt eigenlijk door BMS 213 en niet door firmware v153. Stond namelijk vermeld in de changelog.

MQTT werkt inmiddels ook weer via een update van de developer. Nog wel in bèta.

[SatScan]

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.

Oke, prima, maar je gaat dan minder verbruiken dan die 0,4kwh p/d?

Het laden en gelijktijdig ontladen herken ik niet als ik via de modbus kijk.
Kan wel voorkomen als je via de app kijkt omdat die vaak met een flinke vertraging de gegevens weergeeft.
Maw feitelijk werken ze elkaar niet tegen.

[TDSgame]

@SatScan Ik zie het voornamelijk door op leds op het toestel zelf te zien dat ze tegen elkaar werken.

Mijn verbruiken met 1 marstek manueel en 1 auto varieren tussen 0.1kwh p/d en 0.9 met een gemiddelde van 0.5kwh ongeveer

[SatScan]

TDSgame schreef op zondag 13 juli 2025 @ 19:47:
@SatScan Ik zie het voornamelijk door op leds op het toestel zelf te zien dat ze tegen elkaar werken.

Mijn verbruiken met 1 marstek manueel en 1 auto varieren tussen 0.1kwh p/d en 0.9 met een gemiddelde van 0.5kwh ongeveer

Daar zit ik ook op met 2batt op NOM en de CT003.
Dus het maakt allemaal niet zoveel uit, ben benieuwd als we meer bewolkte dagen gaan krijgen hoe het zich dan gaat verhouden.

[JorisLammar]

SatScan schreef op zondag 13 juli 2025 @ 19:09:
[...]


Oke, prima, maar je gaat dan minder verbruiken dan die 0,4kwh p/d?

Het laden en gelijktijdig ontladen herken ik niet als ik via de modbus kijk.
Kan wel voorkomen als je via de app kijkt omdat die vaak met een flinke vertraging de gegevens weergeeft.
Maw feitelijk werken ze elkaar niet tegen.

Verbruik gisteren was 0,45 kWh / p.d.
Ik meet het vermogen van de batterijen via een HW plug. Die refreshen om de 5 seconden. Ik heb gisteren ook V116 geinstalleerd op de CT003 (iemand sprak van V117, maar die heb ik niet). De tact-tijd nu per batterij is 10 seconden (ipv 15).

[SatScan]

Goedemorgen,

Heb ondertussen de v117 in de CT3 zitten en na 24u kan ik zeggen dat deze een stuk soepeler werkt dan de v116.

Minder grid verbruik, hoewel dit tienden van een KWh is, nu even afwachten en bekijken hoe bij bewolkt weer deze combinatie de NOM regelt.

m2c

[thepixel]

Ben benieuwd, met name of de snelheid van het regelen verbeterd is.

Welke BMS versie heb je nu?

[SatScan]

thepixel schreef op dinsdag 15 juli 2025 @ 11:15:
Ben benieuwd, met name of de snelheid van het regelen verbeterd is.

Welke BMS versie heb je nu?

Hoi, de snelheid weet ik niet.. heb een 1sec DM. Volgens mijn eerste indruk is er veel minder overshoot + en - in de sturing om NOM te handhaven. Moet nog wel even langer testen of dit ook vandaag met de bewolking zo blijft.

Helaas kan ik de BMS (nog) niet uitlezen, de Add-ons in HA zijn een tijd terug gestopt met werken. Moet dat nog eens uitvogelen wat er niet goed gaat.

[corsat]

Ik heb inmiddels HA OS op mijn NAS onder VMM en heb esphome builder en ben opnieuw begonnen met mijn lilygo te programmeren en bij install heb ik 4 opties, bij wireless krijg ik het eerste plaatje te zien en bij optie 4 manual download krijg ik het 2e plaatje te zien. Wat ik overigen ook probeer de lilygo blijft offline dus ergens doe ik iets niet goed maar wat gaat hier nu verkeerd?

[Horla]

geef je in je yaml configuratie mee op welk draadloos netwerk (en welk wachtwoord) de lilygo moet connecteren?

[pascallj]

Horla schreef op dinsdag 15 juli 2025 @ 14:38:
geef je in je yaml configuratie mee op welk draadloos netwerk (en welk wachtwoord) de lilygo moet connecteren?

En, heb je de eerste keer wel geflasht via USB? Weet niet hoe dat met de builder en alles werkt, ik gebruik altijd de terminal.

[blackcom]

corsat schreef op dinsdag 15 juli 2025 @ 14:20:
[Afbeelding][Afbeelding]
Ik heb inmiddels HA OS op mijn NAS onder VMM en heb esphome builder en ben opnieuw begonnen met mijn lilygo te programmeren en bij install heb ik 4 opties, bij wireless krijg ik het eerste plaatje te zien en bij optie 4 manual download krijg ik het 2e plaatje te zien. Wat ik overigen ook probeer de lilygo blijft offline dus ergens doe ik iets niet goed maar wat gaat hier nu verkeerd?

Bij optie 4 moet je de firmware downloaden van de builder website en op een andere manier installeren op de LilyGO. Ben zelf niet zo bekend met de LilyGO maar met andere esp32 bordjes kan dit vrij eenvoudig via web.esphome.io.

Voor optie 1 ken je het IP address van je LilyGO en kan je er naar pingen? Waarschijnlijk zit die wel op het netwerk maar vindt Home assistant hem niet.

[corsat]

Horla schreef op dinsdag 15 juli 2025 @ 14:38:
geef je in je yaml configuratie mee op welk draadloos netwerk (en welk wachtwoord) de lilygo moet connecteren?

yep

[corsat]

pascallj schreef op dinsdag 15 juli 2025 @ 14:40:
[...]


En, heb je de eerste keer wel geflasht via USB? Weet niet hoe dat met de builder en alles werkt, ik gebruik altijd de terminal.

yep, eerste keer via usb geflashed.

[corsat]

blackcom schreef op dinsdag 15 juli 2025 @ 16:46:
[...]


Bij optie 4 moet je de firmware downloaden van de builder website en op een andere manier installeren op de LilyGO. Ben zelf niet zo bekend met de LilyGO maar met andere esp32 bordjes kan dit vrij eenvoudig via web.esphome.io.

Voor optie 1 ken je het IP address van je LilyGO en kan je er naar pingen? Waarschijnlijk zit die wel op het netwerk maar vindt Home assistant hem niet.

esphome web kon ik eerst niet openen maar dat blijkt op een mac een probleem te zijn, heb nu via google chrome esphome web kunnen openen en in HA zie ik esphome web nu ook staan en ik zie inmiddels een roe lamp op mijn lilygo. Ik verwacht eigenlijk wel dat ik hem terug kan vinden in mijn netwerk maar ik zie hem dus niet. In de log geeft hij steeds aan dat hij netwerk zoekt maar niet vind. Ik denk dat ik hem moet nu moet aansluiten op mijn marstek en dat hij dan zou moeten werken en ook connecten met mijn wifi of mis ik nog iets.
Wellicht een ander punt, mijn wifi naam heeft een liggend streepje en mijn ww eindigd met een ! kan dit een probleem geven?

[ Voor 5% gewijzigd door corsat op 15-07-2025 17:19 ]

[Animal]

Vandaag de Marstek ontvangen. Ingesteld. Modbus kabel gemaakt. Alles werkt perfect (nu nog met 2500 emulatie add-on die een shelly emuleert. De p1 meter die erbij zit krijg ik niet verbonden)

De updates komen nu per 15 seconden binnen. Super. Wordt dit sneller zodra je wat sensoren uitschakeld of is dit het snelste dat kan?

Dank voor al het werk!

[JSTAL]

superduper1969 schreef op vrijdag 27 juni 2025 @ 18:52:
[...]

Ja, daarom heeft MT met Modbus ook een hoger energie gebruik omdat je de interne computer wakker houdt. Ik denk eraan als de accu vol is en er voldoende opwek om het uitvragen van info te pauzeren.

en hoe zou dat pauzeren dan moeten gebeuren? de 5V van de liliygo ondebreken?

[SatScan]

*knip*

[ Voor 99% gewijzigd door SatScan op 15-07-2025 21:01 ]

[AUijtdehaag]

Mensen met een M5stack Atom S3 lite, willen jullie zelf eens deze versie uitproberen
Heb gepoogd de wifi te verbeteren met verbeterde code van @xoror (ecodan)

[xoror]

@AUijtdehaag de wifi.yaml is ook nodig, maar bemoedigend dat je al resultaat ziet.

[mgiebels]

SatScan schreef op dinsdag 15 juli 2025 @ 10:44:
Goedemorgen,

Heb ondertussen de v117 in de CT3 zitten en na 24u kan ik zeggen dat deze een stuk soepeler werkt dan de v116.

Minder grid verbruik, hoewel dit tienden van een KWh is, nu even afwachten en bekijken hoe bij bewolkt weer deze combinatie de NOM regelt.

m2c

merkte ik ook op maar ik houd het voorlopig bij mij P1 van homewizard die is sneller.

[Flesym]

AUijtdehaag schreef op dinsdag 15 juli 2025 @ 21:13:
Mensen met een M5stack Atom S3 lite, willen jullie zelf eens deze versie uitproberen
Heb gepoogd de wifi te verbeteren met verbeterde code van @xoror (ecodan)

[Afbeelding]

Levert een flinke verbetering hoewel mijn signaal al goed was.

[WargamingPlayer]

Vandaag kwam ik er achter dat bij Powerflow Card Plus er maar 1 batterij opgegeven kan worden. Dus ben ik weer even wat aan het "coden" geweest. Tevens een uitgebreidere beschrijving voor de Elfin 11B.

https://github.com/Wargam...-Venus-E-Modbus/tree/main

[tdolder]

WargamingPlayer schreef op woensdag 16 juli 2025 @ 00:02:
Vandaag kwam ik er achter dat bij Powerflow Card Plus er maar 1 batterij opgegeven kan worden. Dus ben ik weer even wat aan het "coden" geweest. Tevens een uitgebreidere beschrijving voor de Elfin 11B.

https://github.com/Wargam...-Venus-E-Modbus/tree/main

Mooi werk, dank! Ik heb de Elfin besteld.
Marstek Venus E nu een weekje in gebruik en leuke accu. Had nog een usb to rs485 converter liggen maar kreeg daarmee niet voor elkaar.

[blackcom]

corsat schreef op dinsdag 15 juli 2025 @ 17:13:
[...]

esphome web kon ik eerst niet openen maar dat blijkt op een mac een probleem te zijn, heb nu via google chrome esphome web kunnen openen en in HA zie ik esphome web nu ook staan en ik zie inmiddels een roe lamp op mijn lilygo. Ik verwacht eigenlijk wel dat ik hem terug kan vinden in mijn netwerk maar ik zie hem dus niet. In de log geeft hij steeds aan dat hij netwerk zoekt maar niet vind. Ik denk dat ik hem moet nu moet aansluiten op mijn marstek en dat hij dan zou moeten werken en ook connecten met mijn wifi of mis ik nog iets.
Wellicht een ander punt, mijn wifi naam heeft een liggend streepje en mijn ww eindigd met een ! kan dit een probleem geven?

Ik weet niet hoe jouw nas netwerk regelt voor jou vm maar kans bestaat dat er iets mis gaat met de broadcasts waardoor mdns niet werkt. Komt er op neer dat HA op het netwerk roept naar welk apparaat er luistert naar de naam lilygo-rs485.local maar de lilygo dit niet hoort en dus ook niet antwoord. Een mogelijke oplossing is de lilygo een statisch ip adres te geven in esphome en het terug een keer via usb te flashen. Daarna zou het terug OTA moeten lukken.

[Weldie]

Kan iemand mij uitleggen waar ik de api en ota kan vinden war hieronder beschreven is?

6. Selecteer Edit en kopieer het deel met de api en ota encryption key en plak deze tijdelijk in Kladblok/Notepad++

Ben bezig een esp maar is voor mij de eerste keer.

Alvast bedankt

[dannyro]

AUijtdehaag schreef op dinsdag 15 juli 2025 @ 21:13:
Mensen met een M5stack Atom S3 lite, willen jullie zelf eens deze versie uitproberen
Heb gepoogd de wifi te verbeteren met verbeterde code van @xoror (ecodan)

[Afbeelding]

Heb het ook aangepast, zie geen verschil, was al perfect.

[Kr3Kr]

Bedankt allemaal, ik heb mijne ook werkend met de uitleg van TS.

8. Maak een map packages als submap van config.

Ik had geen map "config", dus dit was even verwarrend. Ging er vanuit dat dit in de HA-hoofdmap zou zijn, klopt dat?

De map "config" heet in de HA File Editor "homeassistant"

[ Voor 11% gewijzigd door Kr3Kr op 16-07-2025 14:55 ]

[antonboonstra]

Vanwege de onduidelijkheid over volatile / nonvolatile geheugencellen in de Marstek, heb ik een grotere 'dode zone' geprogrammeerd. Dit betekent dat ik de modbus sturing van (ont)laadvermogen niet wijzig bij kleine afwijkingen, maar alleen bij grotere afwijkingen.

Zo laad ik bijvoorbeeld alleen midden overdag (vanaf 12:00 uur) op zonnestroom, waarbij ik regel op 400 W teruglevering. Oftewel ik 'schaaf' alleen de pieken van de PV opbrengst weg. Het was zo dat als ik via de P1 410W teruglevering meet, dat ik het laadvermogen gelijk met 10W verhoog. Daarmee krijg je veel schrijfwaarden naar de Marstek, waarbij misschien het flashgeheugen sneller slijt en in het ergste geval defect raakt. Nu stuur ik pas bij als er meer dan 25% afwijking is, dus pas als de teruglevering >500W is (is >100W afwijking) stuur ik de laadsnelheid van de Marstek bij.

[pascallj]

pascallj schreef op vrijdag 11 juli 2025 @ 23:09:
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.

Bij deze een vervolg m.b.t. onbekende Modbus registers.

Heb nu een aantal dagen de onbekende registers gemonitord en wat tests gedraaid en voor een hoop is nu duidelijk waar het voor dient. Helaas zijn veel registers dubbel uitgevoerd, dus aan die data hebben we niet zoveel. Heb alles gedocumenteerd in de datasheet.

Hier een overzicht van wat we tot nu toe extra weten ten opzichte van het Duravolt document, maar voor de details verwijs ik je naar de datasheet:

• Battery voltage average (dubbel)
• Battery current (average) (dubbel)
• AC voltage (dubbel)
• AC current (dubbel)
• AC offgrid voltage (dubbel)
• Internal MOS1 temperature (dubbel)
• Internal MOS2 temperature (dubbel)
• Internal temperature (dubbel)
• WiFi status (nieuw!)
• BT status (nieuw!)
• Cloud status (nieuw!)
• WiFi Signal Strength (nieuw!)
• BMS version (HEX) (dubbel)
• Software version (HEX) (dubbel)
• Firmware version (HEX) (dubbel)
• Device MAC address
• Communication module firmware version
• Firmware version
• BMS version
• AC power (dubbel)
• Battery SOC (dubbel)
• Cell temperature (dubbel)
• Maximum cell voltage
• Minimum cell voltage
• Power restriction (nieuw!)
• WiFi SSID

Er zijn nog een paar registers onbekend die wel regelmatig van waarde veranderen, maar die ik nog niet kan thuisbrengen. De rest van de registers blijft leeg, of bevat waarschijnlijk een instelling/status die ik niet heb kunnen zien veranderen.

Zoals ook al gemeld door @rtlvandeven is het ook mogelijk om 'Grid loss' uit te lezen in de error registers (op meerdere plekken), maar verder is het lastig om andere errors te simuleren.

[superduper1969]

pascallj schreef op woensdag 16 juli 2025 @ 14:36:
[...]


Bij deze een vervolg m.b.t. onbekende Modbus registers.

Heb nu een aantal dagen de onbekende registers gemonitord en wat tests gedraaid en voor een hoop is nu duidelijk waar het voor dient. Helaas zijn veel registers dubbel uitgevoerd, dus aan die data hebben we niet zoveel. Heb alles gedocumenteerd in de datasheet.

Hier een overzicht van wat we tot nu toe extra weten ten opzichte van het Duravolt document, maar voor de details verwijs ik je naar de datasheet:

• Battery voltage average (dubbel)
• Battery current (average) (dubbel)
• AC voltage (dubbel)
• AC current (dubbel)
• AC offgrid voltage (dubbel)
• Internal MOS1 temperature (dubbel)
• Internal MOS2 temperature (dubbel)
• Internal temperature (dubbel)
• WiFi status (nieuw!)
• BT status (nieuw!)
• Cloud status (nieuw!)
• WiFi Signal Strength (nieuw!)
• BMS version (HEX) (dubbel)
• Software version (HEX) (dubbel)
• Firmware version (HEX) (dubbel)
• Device MAC address
• Communication module firmware version
• Firmware version
• BMS version
• AC power (dubbel)
• Battery SOC (dubbel)
• Cell temperature (dubbel)
• Maximum cell voltage
• Minimum cell voltage
• Power restriction (nieuw!)
• WiFi SSID

Er zijn nog een paar registers onbekend die wel regelmatig van waarde veranderen, maar die ik nog niet kan thuisbrengen. De rest van de registers blijft leeg, of bevat waarschijnlijk een instelling/status die ik niet heb kunnen zien veranderen.

Zoals ook al gemeld door @rtlvandeven is het ook mogelijk om 'Grid loss' uit te lezen in de error registers (op meerdere plekken), maar verder is het lastig om andere errors te simuleren.

Hi @pascallj

Ik heb zelf weinig tijd om te testen maar als je zover bent om weer een pull request op github te doen dan hoor ik het wel.