Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[scruysberghs]

superduper1969 schreef op vrijdag 16 mei 2025 @ 09:29:
Heeft iemand al ervaring met de Day Ahead Optimizer i.p.v. zelf algoritmes maken?
https://gathering.tweakers.net/forum/list_messages/2293338

Heb er wel wat mee gespeeld maar was voor mijn situatie iets te veel gericht op Nederland (weersvoorspellin, prijs integratie enz).

Gebruik nu EMHASS om de Marstek aan te sturen (en curtailment solar, en de laadpaal en het witgoed, warmtepomp, boiler...) met voorspellingen van zon, day ahead prijzen enz. Die heeft ook ingebakken machine learning modellen om je baseload te voorspellen en een MPC optimiser om alles vervolgens in te plannen aan de laagste kost. De output van de planner kan je dan gebruiken om je specifieke toestellen aan te sturen.

EMHASS heeft momenteel nog wel een iets steilere leercurve dan DAO dus als je in Nederland woont zeker eerst eens proberen. EMHASS wat gebruiksvriendelijker maken met documentatie en wat blueprints staat hier op mij todo lijstje, maar nog niet bovenaan. Is hier op Tweakers ook nog wel ergens een topic over te vinden

[scruysberghs]

pascallj schreef op donderdag 15 mei 2025 @ 12:08:
[...]


Dit zou inderdaad mogelijk moeten zijn. Het probleem is alleen dat het lastig om hier een gebruiksvriendelijke manier voor te vinden om dit in stappen uit te leggen. Je moet dan namelijk een specifieke firmware maken die het adres kan veranderen, aansluiten op 1 accu, eenmalig draaien. Nieuwe firmware maken, reflashen en eenmalig aansluiten en draaien op tweede accu etc. Vervolgens moet je weer een nieuwe firmware maken waarin je deze adressen verwerkt voor twee of meer accu's.

Was aan het denken aan een esphome config met alle sensoren voor 2 (of meer) batterijen, met bijvoorbeeld modbus id's 1 en 2. Hier ook het modbus adres zelf als schrijfbare sensor/register toevoegen, eerste batterij koppelen aansluiten, het adres wijzigen van de standaard "1" naar "2", vervolgens de 2de bettarij aansluiten die dan nog op adres 1 zal zitten, .... => resultaat, 2 batterijen aanstuurbaar met hetzelfde bordje
Zelfde recept voor meer dan 2 stuks...

Is inderdaad minder eenvoudig gebruiksvriendelijk uit te leggen dan effectief te doen lijkt me. Maar het is hier toch Tweakers.net

Heb binnenkort een site met meerdere Marsteks (1 per fase) misschien dat ik wel eens probeer

[scruysberghs]

Babavers schreef op vrijdag 16 mei 2025 @ 00:29:
[...]

Ik draai 2 batterijen op 1 Lilygo. Dan moet je inderdaad dat adres aanpassen. Als je dat doet verlies je direct contact met de batterij. Je past de software van de Lilygo dan aan aan de nieuwe adres en klaar is kees. Uiteraard zie je dan wel maar 1 device in HA en moet je de code binnen ESPHome helemaal aanpassen, maar dat is eigenlijk niet meer dan copy/paste en alle benamingen aanpassen. Werkt perfect.
En dat adres valt ook niet zomaar terug op de default waarde. Dat overleeft zelfs een firmware update. Het is enkel bij een reset naar 'factory default' dat de waarde van dat adres gereset wordt naar de standaard waarde 1.

Top, zie je reactie pas na mijn vorig bericht.
Ga idd ook eens zo proberen binnenkort....

[Hometek]

pascallj schreef op maandag 12 mei 2025 @ 15:49:
[...]

• Marstek RS485 Control Mode
  Zet bediening via Modbus aan of uit. Is alleen van toepassing op:
  • Marstek Forcible Charge/Discharge
    Forceer actie: stoppen, laden of ontladen
  • Marstek Forcible Charge Power
    Als bovenstaande actie laden is, limiteer het tot dit ingestelde vermogen (tenzij 'Marstek Max. Charge Power' lager is)
  • Marstek Forcible Discharge Power
    Als bovenstaande actie ontladen is, limiteer het tot dit ingestelde vermogen (tenzij 'Marstek Max. Discharge Power' lager is)
  • Marstek Charge To SOC
    Breng de batterij (laad/ontlaad) eenmalig naar dit ingestelde percentage (met een min/max van de 'Cutoff' percentages) en ga daarna in Standby

Klopt het dat als je de Marstek RS485 Control Mode via de Lilygo op enable zet deze na enige tijd vanzelf weer terug gaat naar disable, tenzij je een charge of discharge commando stuurt?

[Maarten69]

Hometek schreef op vrijdag 16 mei 2025 @ 14:24:
[...]

Klopt het dat als je de Marstek RS485 Control Mode via de Lilygo op enable zet deze na enige tijd vanzelf weer terug gaat naar disable, tenzij je een charge of discharge commando stuurt?

Bij mij heb ik dat nog niet gezien, hij staat vaak 24 uur op enable met stop.

[ Voor 31% gewijzigd door Maarten69 op 16-05-2025 16:01 ]

[Hometek]

Maarten69 schreef op vrijdag 16 mei 2025 @ 16:00:
[...]
Bij mij heb ik dat nog niet gezien, hij staat vaak 24 uur op enable met stop.
[Afbeelding]

Ik zie de disable ook niet terug in de log, maar de controls in HA settings geeft wel disable aan.
Het is ook niet consistent, soms blijft enable wel staan. Waarschijnlijk iets in mijn HA of browser.

Een ander punt: als de mode 'manual' is en ik de Marstek RS485 Control Mode op enable zet verandert de Marstek User Work Mode in HA naar 'anti-feed'. In de app is het vakje voor de mode dan blanco.

[Maarten69]

Dat laatste is hier ook idd.
Ik zal het wat beter monitoren vanaf nu.

[Mirabis]

superduper1969 schreef op vrijdag 16 mei 2025 @ 09:29:
Heeft iemand al ervaring met de Day Ahead Optimizer i.p.v. zelf algoritmes maken?
https://gathering.tweakers.net/forum/list_messages/2293338

Nope, maar was zelf aan het knutselen met HA automations en (niet in combinatie, maar meer aan kijken wat beter/makkelijker werkt):

• https://github.com/ast081...master/battery_manager.py
• https://github.com/TheFes/cheapest-energy-hours
• https://github.com/kotope/aio_energy_management
• https://github.com/davidusb-geek/emhass

Wegens tijdgebrek nog niet af - maar wie weet van het weekend

[scruysberghs]

Mirabis schreef op vrijdag 16 mei 2025 @ 17:38:
[...]


Nope, maar was zelf aan het knutselen met HA automations en (niet in combinatie, maar meer aan kijken wat beter/makkelijker werkt):

• https://github.com/ast081...master/battery_manager.py
• https://github.com/TheFes/cheapest-energy-hours
• https://github.com/kotope/aio_energy_management
• https://github.com/davidusb-geek/emhass

Wegens tijdgebrek nog niet af - maar wie weet van het weekend

Je zal merken dat EMHASS van deze wel het dichtst in de buurt komt van wat een EMS allemaal moet kunnen. Je zal wel in HA aan de slag moeten om je electriciteitsprijzen en je zonvoorspelling vanuit home assistant met de juiste templates door te sturen naar EMHASS via API calls.
Maar is wel bijzonder krachtige tool.
- ML voorspelling van je basisverbruik
- ML aanpassing van de zonvoorspelling aan de echt gemeten waardes om schaduw enz op te vangen
- day ahead prijzen
- optimaal inplannen van verbruikers
- optimelaal aansturen van je batterij
- curtailen van je panelen als het niet anders kan
- voor Belgen in dit forum: limiet bewaken wat je max van het net afneemt om je capaciteitstarief onder controle te houden...

Hieronder alvast een prentje van de planning voor de volgende 24u die uit EMHASS gerold komt...



De 5.12kwh van Marstek (-12% buffer) trekt het net niet tot er weer zon voorzien is morgen.

Zou een linkje zetten naar een live demo maar dat is dacht ik tegen de regels hier...

[Pjotr500]

Ik had de Liligo al een tijdje in huis, maar was er nog niet aan toegekomen om 'm via ESP-Home te flashen.

Vanmorgen ben ik er enthousiast mee begonnen. Inmiddels alle instelling in HomeAssistant aangebracht en de YAML-file vanuit Github gekopieerd. Vanuit de validatie in ESP-Home krijg ik geen foutmeldingen en de Liligo is middels het IP-adres in een browser te benaderen.

Als ik de YAML-file met de nieuwe Github code wil installeren, krijg ik echter toch een soort van JSON foutmelding.
(de packages directory is aangemaakt en voorzien van het yaml-bestand en de verwijzing staat ook de de configuration file)

Wat zou dit kunnen zijn ?

[Maarten69]

@Pjotr500 wel herstart na aanpassing van configuration.yaml?

[pascallj]

Hometek schreef op vrijdag 16 mei 2025 @ 14:24:
[...]

Klopt het dat als je de Marstek RS485 Control Mode via de Lilygo op enable zet deze na enige tijd vanzelf weer terug gaat naar disable, tenzij je een charge of discharge commando stuurt?

Er is wel een klein probleempje met de weergave. De waarde wordt niet meteen veranderd in de weergave, maar pas met de volgende uitvraag van het register.

Heb al een PR uitstaan in ESPHome, maar nog geen reactie gehad.

[superduper1969]

Alle LilyGo files aangepast op Github.
Ik kan voor 2e en 3e accu niets testen maar alle wijzigingen met accu 1 gecontroleerd met KDiff3 https://invent.kde.org/sdk/kdiff3

[ Voor 3% gewijzigd door superduper1969 op 17-05-2025 15:45 ]

[Pjotr500]

Maarten69 schreef op zaterdag 17 mei 2025 @ 12:32:
@Pjotr500 wel herstart na aanpassing van configuration.yaml?

Jawel, een complete herstart doorgevoerd. Eerst alleen een HomeAssistant herstart gedaan. Later een reboot op het complete systeeem (Raspberry 4) uitgevoerd.

Vooralsnog heb ik het voor nu werkend gekregen door de LED-sectie te verwijderen en het framework van Arduino te wijzigen naar esp-idf. Ik vermoed dat het aan mijn ESP-Home configuratie in HA ligt.
Op het HA forum zie ik weinig oplossingen, behalve dan dat er hier en daar geadviseerd wordt om de ESP-Home add-on te verwijderen en opnieuw te installeren.
Daar wacht ik nog heel even mee.

[ Voor 37% gewijzigd door Pjotr500 op 17-05-2025 22:56 ]

[JanAllElectric]

superduper1969 schreef op zaterdag 17 mei 2025 @ 15:40:
Alle LilyGo files aangepast op Github.
Ik kan voor 2e en 3e accu niets testen maar alle wijzigingen met accu 1 gecontroleerd met KDiff3 https://invent.kde.org/sdk/kdiff3

ik gebruik esphome 2025.2.2 in een LXC container van proxmox.

Mijn 2 lilygo's werken goed met type: esp-idf zonder het led gedeelte.

Voor mijn 3e lilygo maar weer eens geprobeerd de led lampjes aan te zetten.

Netjes aangepast en het led gedeelte toegevoegd:

esp32:
board: esp32dev
framework:
type: arduino

Ik krijg dan steeds deze foutmelding aan het eind:

INFO ESPHome 2025.2.2
INFO Reading configuration /root/config/marstek-3.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing marstek-3 (board: esp32dev; framework: arduino; platform: platformio/espressif32@5.4.0)
--------------------------------------------------------------------------------
Library Manager: Installing SPI
INFO Installing SPI
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
- toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5
Dependency Graph
|-- AsyncTCP-esphome @ 2.1.4
|-- WiFi @ 2.0.0
|-- FS @ 2.0.0
|-- Update @ 2.0.0
|-- ESPAsyncWebServer-esphome @ 3.2.2
|-- ESPmDNS @ 2.0.0
|-- noise-c @ 0.1.6
|-- ArduinoJson @ 6.18.5
|-- NeoPixelBus @ 2.7.3
RAM: [= ] 12.5% (used 40908 bytes from 327680 bytes)
Flash: [====== ] 56.0% (used 1027013 bytes from 1835008 bytes)
Building .pioenvs/marstek-3/firmware.bin
Creating esp32 image...
Successfully created esp32 image.
esp32_create_combined_bin([".pioenvs/marstek-3/firmware.bin"], [".pioenvs/marstek-3/firmware.elf"])
usage: esptool merge_bin [-h] --output OUTPUT [--format {raw,uf2,hex}]
[--chunk-size CHUNK_SIZE] [--md5-disable]
[--flash_freq {keep,80m,60m,48m,40m,30m,26m,24m,20m,16m,15m,12m}]
[--flash_mode {keep,qio,qout,dio,dout}]
[--flash_size {keep,256KB,512KB,1MB,2MB,2MB-c1,4MB,4MB-c1,8MB,16MB,32MB,64MB,128MB}]
[--spi-connection SPI_CONNECTION]
[--target-offset TARGET_OFFSET]
[--fill-flash-size {256KB,512KB,1MB,2MB,4MB,8MB,16MB,32MB,64MB,128MB}]
<address> <filename> [<address> <filename> ...]
esptool merge_bin: error: argument <address> <filename>: [Errno 2] No such file or directory: '/root/.platformio/packages/framework-arduinoespressif32/tools/partitions/boot_app0.bin'
*** [.pioenvs/marstek-3/firmware.bin] Explicit exit, status 2
========================= [FAILED] Took 10.61 seconds =========================

[Njord1]

superduper1969 schreef op vrijdag 16 mei 2025 @ 09:29:
Heeft iemand al ervaring met de Day Ahead Optimizer i.p.v. zelf algoritmes maken?
https://gathering.tweakers.net/forum/list_messages/2293338

Ben er wel mee bezig geweest, maar krijg mijn 3 Marsteks niet werkend.

[AUijtdehaag]

@JanAllElectric
‘clean build files’ wil soms wel eens helpen

[pj]

superduper1969 schreef op zaterdag 17 mei 2025 @ 15:40:
Alle LilyGo files aangepast op Github.
Ik kan voor 2e en 3e accu niets testen maar alle wijzigingen met accu 1 gecontroleerd met KDiff3 https://invent.kde.org/sdk/kdiff3

Wat is er aangepast dan? Ik zie geen changelog of release?

[superduper1969]

pj schreef op zondag 18 mei 2025 @ 10:05:
[...]


Wat is er aangepast dan? Ik zie geen changelog of release?

Zijn maar een paar dingen. Zie startpost. En als je Exact het verschil wil weten met jouw variant dan gebruik je kdiff3.

[Gwaihir]

Mijn Jupiter-E is inmiddels aangesloten op de PV-panelen en het stopcontact. Wel zijn er diverse problemen. Daaronder: van de Modbus API taal nog teken.

Is die er bij de Venus simpelweg, of moet je daarvoor nog iets aanzetten / kiezen? (Ik vind er niets over in de startpost, dus ik vermoed het eerste.)

[jbeMR]

@superduper1969 If I see it correctly I should copy/replace from line 34 "web _server" to update the existing file of my installtion to keep the individual settings? Thanks

[PVerga]

Heeft iemand al eens de bitmasks getest van modbus register 36100?
Dit zou een 32 bit register moeten zijn volgens de modbus documentatie.
Ik heb dit eens getest door de stekker van de Marstek uit het stopkontakt te trekken en dan krijg ik waarde 128 DEC of 80 HEX terug als 'grid undervoltage' fout, wat ik helemaal niet kan mappen met de bitmasks zoals vermeld in de documentatie.
Ik lees het register als een 32 bit unsigned, twee16 bit registers high word / low word volgorde.
(net zoals het uilezen van vb. registers 33004, 33006 die ik wel correct binnenkrijg). Andere combinaties van register of byte volgorde leveren nonsens waarden op.
Ik heb nu wel het alarm voor undervoltage in orde, maar vrees voor de waarden van andere alarmen in dit register...

[superduper1969]

jbeMR schreef op maandag 19 mei 2025 @ 08:34:
@superduper1969 If I see it correctly I should copy/replace from line 34 "web _server" to update the existing file of my installtion to keep the individual settings? Thanks

That would be the best option for most updates.

[superduper1969]

PVerga schreef op maandag 19 mei 2025 @ 09:27:
Heeft iemand al eens de bitmasks getest van modbus register 36100?
Dit zou een 32 bit register moeten zijn volgens de modbus documentatie.
Ik heb dit eens getest door de stekker van de Marstek uit het stopkontakt te trekken en dan krijg ik waarde 128 DEC of 80 HEX terug als 'grid undervoltage' fout, wat ik helemaal niet kan mappen met de bitmasks zoals vermeld in de documentatie.
Ik lees het register als een 32 bit unsigned, twee16 bit registers high word / low word volgorde.
(net zoals het uilezen van vb. registers 33004, 33006 die ik wel correct binnenkrijg). Andere combinaties van register of byte volgorde leveren nonsens waarden op.
Ik heb nu wel het alarm voor undervoltage in orde, maar vrees voor de waarden van andere alarmen in dit register...

Ik heb de registers nooit getest, ik heb wel een keer een Pull Request van @pascallj geaccepteerd hierover:
https://github.com/Superd...d6d815f8bc45c97075d6c6355

[jbeMR]

okay, I did for borh batteries. With both I get this messages:

code:

11:07:02][W][[b]component:239]: Component modbus_controller took a long time for an operation (55 ms).
[11:07:02][W][component:240]: Components should block for at most 30 ms.[/b]
[11:07:02][D][modbus_controller.select:014]: New select value 1 from payload
[11:07:02][D][select:015]: 'Marstek Backup Function': Sending state disable (index 1)
[11:07:02][D][modbus_controller.select:014]: New select value 21947 from payload
[11:07:02][D][select:015]: 'Marstek RS485 Control Mode': Sending state disable (index 1)
[11:07:02][D][modbus_controller.select:014]: New select value 0 from payload
[11:07:02][D][select:015]: 'Marstek Forcible Charge/Discharge': Sending state stop (index 0)
[11:07:02][D][modbus.number:023]: Number new state : 0.00
[11:07:02][D][number:012]: 'Marstek Charge To SOC': Sending state 0.000000
[11:07:02][D][modbus.number:023]: Number new state : 0.00
[11:07:02][D][number:012]: 'Marstek Forcible Charge Power': Sending state 0.000000
[11:07:02][D][modbus.number:023]: Number new state : 2400.00
[11:07:02][D][number:012]: 'Marstek Forcible Discharge Power': Sending state 2400.000000
[11:07:02][D][modbus_controller.select:014]: New select value 1 from payload
[11:07:02][D][select:015]: 'Marstek User Work Mode': Sending state anti-feed (index 1)
[11:07:02][D][modbus.number:023]: Number new state : 90.00
[11:07:02][D][number:012]: 'Marstek Charging Cutoff Capacity': Sending state 90.000000
[11:07:02][D][modbus.number:023]: Number new state : 25.00
[11:07:02][D][number:012]: 'Marstek Discharging Cutoff Capacity': Sending state 25.000000
[11:07:02][D][modbus.number:023]: Number new state : 10.00
[11:07:02][D][number:012]: 'Marstek Max. Charge Power': Sending state 10.000000
[11:07:02][D][modbus.number:023]: Number new state : 2037.00
[11:07:02][D][number:012]: 'Marstek Max. Discharge Power': Sending state 2037.000000
[b][11:07:02][W][component:239]: Component modbus_controller took a long time for an operation (54 ms).
[11:07:02][W][component:240]: Components should block for at most 30 ms.[/b]
[11:07:06][D][status:886]: Modbus: 24, WiFi: -18

[jbeMR]

11:07:02][W][[b]component:239]: Component modbus_controller took a long time for an operation (55 ms).
[11:07:02][W][component:240]: Components should block for at most 30 ms.

[superduper1969]

jbeMR schreef op maandag 19 mei 2025 @ 11:10:
okay, I did for borh batteries. With both I get this messages:

code:

11:07:02][W][[b]component:239]: Component modbus_controller took a long time for an operation (55 ms).
[11:07:02][W][component:240]: Components should block for at most 30 ms.[/b]
[11:07:02][D][modbus_controller.select:014]: New select value 1 from payload
[11:07:02][D][select:015]: 'Marstek Backup Function': Sending state disable (index 1)
[11:07:02][D][modbus_controller.select:014]: New select value 21947 from payload
[11:07:02][D][select:015]: 'Marstek RS485 Control Mode': Sending state disable (index 1)
[11:07:02][D][modbus_controller.select:014]: New select value 0 from payload
[11:07:02][D][select:015]: 'Marstek Forcible Charge/Discharge': Sending state stop (index 0)
[11:07:02][D][modbus.number:023]: Number new state : 0.00
[11:07:02][D][number:012]: 'Marstek Charge To SOC': Sending state 0.000000
[11:07:02][D][modbus.number:023]: Number new state : 0.00
[11:07:02][D][number:012]: 'Marstek Forcible Charge Power': Sending state 0.000000
[11:07:02][D][modbus.number:023]: Number new state : 2400.00
[11:07:02][D][number:012]: 'Marstek Forcible Discharge Power': Sending state 2400.000000
[11:07:02][D][modbus_controller.select:014]: New select value 1 from payload
[11:07:02][D][select:015]: 'Marstek User Work Mode': Sending state anti-feed (index 1)
[11:07:02][D][modbus.number:023]: Number new state : 90.00
[11:07:02][D][number:012]: 'Marstek Charging Cutoff Capacity': Sending state 90.000000
[11:07:02][D][modbus.number:023]: Number new state : 25.00
[11:07:02][D][number:012]: 'Marstek Discharging Cutoff Capacity': Sending state 25.000000
[11:07:02][D][modbus.number:023]: Number new state : 10.00
[11:07:02][D][number:012]: 'Marstek Max. Charge Power': Sending state 10.000000
[11:07:02][D][modbus.number:023]: Number new state : 2037.00
[11:07:02][D][number:012]: 'Marstek Max. Discharge Power': Sending state 2037.000000
[b][11:07:02][W][component:239]: Component modbus_controller took a long time for an operation (54 ms).
[11:07:02][W][component:240]: Components should block for at most 30 ms.[/b]
[11:07:06][D][status:886]: Modbus: 24, WiFi: -18

11:07:02][D][number:012]: 'Marstek Max. Discharge Power': Sending state 2037.000000
[11:07:02][W][component:239]: Component modbus_controller took a long time for an operation (54 ms).
[11:07:02][W][component:240]: Components should block for at most 30 ms.

This is correct, the response of the MT Venus is slower than normally in Modbus.
This has no effect on the outcome.

Thats why in Github I marked this sensor as as a "Slow Sensor"

# Slow Sensor
- name: "Marstek Max. Discharge Power"
id: "lilygo_rs485_marstek_max_discharge_power"
icon: mdi:tune-variant
mode: box
platform: modbus_controller
modbus_controller_id: mt
register_type: holding
address: 44003
value_type: U_WORD
unit_of_measurement: "W"
min_value: 0
max_value: 2500
step: 1
skip_updates: 2 # 10 seconds

[Gwaihir]

Gwaihir schreef op zondag 18 mei 2025 @ 20:22:
Mijn Jupiter-E is inmiddels aangesloten op de PV-panelen en het stopcontact. Wel zijn er diverse problemen. Daaronder: van de Modbus API taal nog teken.

Is die er bij de Venus simpelweg, of moet je daarvoor nog iets aanzetten / kiezen? (Ik vind er niets over in de startpost, dus ik vermoed het eerste.)

De BT verbinding vereist (in stilte) GPS! Kon nu firmware updaten en dan gaat hij - als het goed is - ook leveren bij de Nederlandse netvoltages.

Maar ik kom helaas niets verder met de modbus sturing. Hardwarematig / low level lijkt alles goed te zitten, maar op elk modbus request dat ik doe, krijg ik een modbus exception terug. Het 'praat' dus wel rs485 maar antwoord op alles 'geen zin in'.

Dat komt overeen met de reactie van support dat de interface 'niet open staat' en dat daar maar voor onbepaalde tijd op gewacht moet worden. Tja.. twee maand terug zeiden ze in elk geval nog 'binnenkort'..

Dit apparaat lijkt dus verkocht te worden met een modbus koppeling die vaporware is .
@Duramotion wat nu?

[superduper1969]

Gwaihir schreef op dinsdag 20 mei 2025 @ 12:25:
[...]

De BT verbinding vereist (in stilte) GPS! Kon nu firmware updaten en dan gaat hij - als het goed is - ook leveren bij de Nederlandse netvoltages.

Maar ik kom helaas niets verder met de modbus sturing. Hardwarematig / low level lijkt alles goed te zitten, maar op elk modbus request dat ik doe, krijg ik een modbus exception terug. Het 'praat' dus wel rs485 maar antwoord op alles 'geen zin in'.

Dat komt overeen met de reactie van support dat de interface 'niet open staat' en dat daar maar voor onbepaalde tijd op gewacht moet worden. Tja.. twee maand terug zeiden ze in elk geval nog 'binnenkort'..

Dit apparaat lijkt dus verkocht te worden met een modbus koppeling die vaporware is .
@Duramotion wat nu?

Maar, je bent nu bezig met een Waveshare? Als enige...
Terwijl iedereen een Lilygo of een Elfin heeft?
Ik neem aan dat je de waveshare probeert aan te sturen zoals een Elfin en ook op de juiste baudrate gebruikt?
Of is het puur op de Jupiter-E?

[Gwaihir]

superduper1969 schreef op dinsdag 20 mei 2025 @ 15:21:
[...]

Maar, je bent nu bezig met een Waveshare? Als enige...
Terwijl iedereen een Lilygo of een Elfin heeft?
Ik neem aan dat je de waveshare probeert aan te sturen zoals een Elfin en ook op de juiste baudrate gebruikt?
Of is het puur op de Jupiter-E?

Het is puur de Jupiter-E.

Ik gebruik inderdaad een Waveshare, als een van de weinigen in dit topic - maar zeker niet de enige. Maar ik probeer ook niet te verbinden met HA. En ook de kabel, incl. aansluiting aan Marstek zijde, is al anders, geen vijf maar vier polen en voor zover bekend daarbij nimmer voeding voor je converter. (Pin 1 = A+ en Pin 2 = B-, da's alles wat Marstek tot nu toe losgelaten heeft. Ik heb dus geen data gnd geprobeerd aan te sluiten. Wel braaf slotweerstanden gebruikt, hoewel een bus met één device en nog geen meter kabel.)

Het is inderdaad op de ook voor de Venus gebruikte baudrate (e.d.) dat ik een antwoord krijg in de vorm van een modbus exception, wanneer ik bijv. om de device name of SOC vraag.

Deze Waveshare is dual channel - twee stuks in één kastje - waarbij het andere kanaal een elektriciteitsmeter uitleest waarop de Jupiter is aangesloten. Dat gaat prima. Zo weet ik dus wat de Jupiter concreet levert. En ben ik er best wel zeker van dat het niet aan de Waveshare / modbus instellingen ligt. Ik krijg immers ook echt exceptions terug. D.w.z. het gaat niet 'gewoon' mis, maar de Jupiter antwoord met een exception conform de modbus standaard. Communicatie zelf is er dus. Hij wil alleen nergens over praten . Net zoals Marstek zelf dus, wanneer je dit onderwerp aansnijdt .

[Maxwp]

Gwaihir schreef op dinsdag 20 mei 2025 @ 12:25:
[...]

De BT verbinding vereist (in stilte) GPS! Kon nu firmware updaten en dan gaat hij - als het goed is - ook leveren bij de Nederlandse netvoltages.

Maar ik kom helaas niets verder met de modbus sturing. Hardwarematig / low level lijkt alles goed te zitten, maar op elk modbus request dat ik doe, krijg ik een modbus exception terug. Het 'praat' dus wel rs485 maar antwoord op alles 'geen zin in'.

Dat komt overeen met de reactie van support dat de interface 'niet open staat' en dat daar maar voor onbepaalde tijd op gewacht moet worden. Tja.. twee maand terug zeiden ze in elk geval nog 'binnenkort'..

Dit apparaat lijkt dus verkocht te worden met een modbus koppeling die vaporware is .
@Duramotion wat nu?

Het word of werd toch verkocht met modbus ondersteuning?
Willen ze niet datcklanten te veel accu info opslaan in database?
Bedoel bij cell problemen en zo in de toekomst

[PVerga]

superduper1969 schreef op maandag 19 mei 2025 @ 09:34:
[...]

Ik heb de registers nooit getest, ik heb wel een keer een Pull Request van @pascallj geaccepteerd hierover:
https://github.com/Superd...d6d815f8bc45c97075d6c6355

Bedankt voor je reactie en suggestie Superduper1969.
Ik heb die pull request nagelezen. Ik zie geen verschil met wat ik doe. Probleem is dat ik integreer met Loxone home automation en dat is uiteraard geen 100% match met de HA modbus I/F..
Maar ik heb ook nog eens een modbus tool gebruikt om het register uit te lezen en ik kom tot hetzelfde resultaat: Grid undervoltage resulteert in een waarde van DEC 128 op register 36100. (unsigned integer 32 bit). Zie screen shot.
Wanneer de netspanning terug wordt gaat dit keurig terug naar nul.
Maar zoals eerder vermeld klopt de binaire waarde voor geen meter met wat er in de mod bus documetatie staat. Ik vrees dus voor de andere foutcodes in dit register. Tweede probleem is dat de andere foutcodes niet eenvoudig te reproduceren zijn.
Als iemand met een HA integratie ook eens de stekker uit het stopkontakt kan trekken om deze foutcode te reproduceren leren we mss iets meer en kan er evt feedback naar Marstek gestuurd worden.

[Gwaihir]

Maxwp schreef op dinsdag 20 mei 2025 @ 16:26:
[...]
Het word of werd toch verkocht met modbus ondersteuning?

Jazeker! (En zonder enige 'komt t.z.t.' disclaimer.)

Willen ze niet datcklanten te veel accu info opslaan in database?
Bedoel bij cell problemen en zo in de toekomst

De uitleg die Marstek gegeven heeft is dat ze er nog niet aan toe gekomen zijn en dat het weinig prio heeft omdat er weinig vraag naar is. Die uitleg acht ik plausibel, dus ik neem op zich van ze aan dat ze zo denken en te werk gaan. Maar ik kan er weinig mee: het product moet het gewoon doen (en zelfs het leveren tot de in NL gebruikelijke 253V blijft nog een probleem).

Ik zocht dit apparaat specifiek uit om die modbus ondersteuning en sprak er tevoren over met de verkoper; ik wil sowieso alles lokaal en moet 'm in m'n HEMS hebben om netjes samen te werken met andere accu's en schakelbare belastingen. En inmiddels ben ik ook ruim 3k aan gerelateerde kosten verder (panelen met plaatsing, opstellingskast voor de accu). Dus het eindeloze 'je moet maar wachten' schiet me behoorlijk in het verkeerde keelgat, met name zo zonder enige datum hoewel het inmiddels al maanden duurt. Zij moeten onderhand 'ns wat.

(En ik moet maar 'ns met de winkelier overleggen hoe hier nu nog meer om te gaan. Zo werkt dat tenslotte juridisch, al kan die ook moeilijk zelf firmware schrijven natuurlijk. [Edit: Da's vandaag gelukt. Ze gaan (nogmaals) hun best doen erop te leunen en zijn er verder helder over dat ik mijn geld terug zou kunnen krijgen. Ik houd mijn hoop op dat eerste, want ik zie vooralsnog geen concurrent het wel bieden.])

Enig lichtpuntje in dit alles: bij het opvolgende model, de Jupiter-C Plus die modulair van opbouw is, staat het (wederom) expliciet in de datasheet. Van afstel lijkt dus al met al gelukkig (nog) geen sprake.

[ Voor 6% gewijzigd door Gwaihir op 21-05-2025 17:40 ]

[Avenger 2.0]

Dus de Jupiter heeft intern nog geen modbus commando's in de firmware zitten als ik goed begrijp? Dat is nog iets wat ze in een toekomstige firmware upgrade moeten toevoegen? Hoogstwaarschijnlijk als daar van bv een grote importeur vraag naar is voor eigen EMS systeem te gebruiken?

[ Voor 3% gewijzigd door Avenger 2.0 op 20-05-2025 18:02 ]

[Gwaihir]

Dat is mijn indruk op dit moment, ja. Al is dat natuurlijk maar 'n inschatting zo lang er ook geen API (= lijst registers) officieel gecommuniceerd is.

Tja.. als ik de info in het andere topic zo lees over alleen al de tweakers actie van ca. vorige week, dan kocht ik bij een 'grote importeur'. Maar of dat op de schaal die Hame / Marstek kennelijk heeft enige indruk maakt..

Denkend dat zo'n firmware op een gezamenlijke code base draait én veel van de opbouw van de apparaten ook hetzelfde is, kan ik me niet voorstellen dat het zo enorm veel werk is, eigenlijk. Ik snap 't dus niet zo goed. Cultuurverschil?

[lennartb]

Prima stappenplan. 2 Lilygo's met succes geflashed. Kleine side note; met een hidden SSID even "fast connect: true" bij de wifi settings zetten. Anders komt hij slecht/ niet meer op. Eerste keer even flashen via usb ook doet wonderen daarin.

code:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: True

[ Voor 18% gewijzigd door lennartb op 21-05-2025 10:13 ]

[mgiebels]

matrover schreef op zondag 11 mei 2025 @ 14:30:
[...]


zeker kan dat! intressante waardes. dit is via de Hame Relay niet via modbus.

[Afbeelding]

Hoe heb je dit gedaan? ik gebruik ook hamerelay en hm2mqtt maar ik krijg niet alle waardes eruit.
Ik heb een venus en volgens mij moet ik HMG-50 instellen ipv hmg-2

[Scorpio1953]

Beste panelleden,

Weten jullie of de CT003 P1 meter al goed samenwerkt met de Landis +Gyr E360 meter, er staat ook een code 0052 op de meter?

Bedankt.

Dick

[newz]

Scorpio1953 schreef op woensdag 21 mei 2025 @ 11:52:
Beste panelleden,

Weten jullie of de CT003 P1 meter al goed samenwerkt met de Landis +Gyr E360 meter, er staat ook een code 0052 op de meter?

Bedankt.

Dick

Werkt hier prima, maar ik moest wel de HW P1 splitter gebruiken én de CT003 upgraden naar v114

[Utron]

Hallo, ik wil jullie bedanken voor jullie goede werk. Ik vind het nog steeds een beetje moeilijk om Home Assistant te gebruiken, maar het is me gelukt om data uit de Marstek te halen met mijn EW11 en de marstek_venus_battery_control.yaml.
Is er een kant-en-klare YAML om de beschrijfbare registers in te stellen zoals in de afbeelding. Sorry dat was vertaald met Deepl.

[Eveir]

Bedankt aan de topicstarter voor de gedetailleerde info, heeft me aangezet tot integratie 3x Venus E in de Loxone app via een 4-kanaals Waveshare RS485 naar ETH.

Momenteel de 0x03 functies in weergave en berichtgeving doorgevoerd.
0x06 en 0x10 staan op de planning.

De CT002 valt op het eerste zicht niet uit te lezen via modbus om te gaan integreren.

Template en voorbeeld in bijlage.

[ Voor 112% gewijzigd door Eveir op 21-05-2025 18:24 ]

[Gwaihir]

Eveir schreef op woensdag 21 mei 2025 @ 18:11:
Bedankt aan de topicstarter voor de gedetailleerde info, heeft me aangezet tot integratie 3x Venus E in de Loxone app via een 4-kanaals Waveshare RS485 naar ETH.

Voor de samenwerking met Loxone kwam ik ook op zo'n Waveshare uit .

De CT002 valt op het eerste zicht niet uit te lezen via modbus om te gaan integreren.

Ik heb de P1 poort zelf aan Loxone gekoppeld. Dat voelt voor mij ook veel beter / logischer / robuster dan dit gedoe met klemmen en WiFi.

Bij eventuele communicatieproblemen, zou ik trouwens die spoeltjes (opgerolde signaaldraden) in je modbusverbinding nog 'ns heroverwegen.

[ Voor 10% gewijzigd door Gwaihir op 22-05-2025 10:23 ]

[PVerga]

Eveir schreef op woensdag 21 mei 2025 @ 18:11:
Bedankt aan de topicstarter voor de gedetailleerde info, heeft me aangezet tot integratie 3x Venus E in de Loxone app via een 4-kanaals Waveshare RS485 naar ETH.

Momenteel de 0x03 functies in weergave en berichtgeving doorgevoerd.
0x06 en 0x10 staan op de planning.

De CT002 valt op het eerste zicht niet uit te lezen via modbus om te gaan integreren.

Template en voorbeeld in bijlage.

[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Blij dat er nog Loxone gebruikers bezig zijn met de Marstek modbus intergratie.
Ik heb voorlopig èèn batterij en gebruik ook de waveshare interface en verder Shelly Pro 3em voor de meetpunten.
Ik heb eerder in dit forum mijn benadering als eens toegelicht: mijn batterij staat permanent op zelf consumptie en ik heb een Shelly emulator gebouwd in Loxone die toelaat de gemeten waarden te manipuleren om zo het laden en ontladen (bij) te sturen.
Werkt allemaal prima, maar ik heb mijn twijfels bij het uitlezen van het 'fault word' modbus register 36100.
Dit is een register dat o.a. Undervoltage alarm kan genereren. Ik zou dit graag gebruiken om een spanningsuitval te melden.
Maar volgens mij kloppen de bitmasks niet die in de documentatie staan, of ik maak een fout hoe ik dit 32 bit register uitlees.
Wanneer ik de stekker van de Marstek uittrek, krijg code 128 decimaal, dus binair 1000 0000, wat ik niet kan mappen met de documentatie. Daardoor heb ik ook mijn twijfels over de andere foutmeldingen in dit register, en die zijn moeilijker te simuleren....
Zie ook een post van me van enkele dagen geleden en de reactie van Superduper1969, maar ik tast nog steeds in het duister...
Hulp welkom en ik wil best ook verdere details verschaffen over mijn set-up indien gewenst.

[Eveir]

Gwaihir schreef op donderdag 22 mei 2025 @ 10:20:
[...]

Voor de samenwerking met Loxone kwam ik ook op zo'n Waveshare uit .

[...]

Ik heb de P1 poort zelf aan Loxone gekoppeld. Dat voelt voor mij ook veel beter / logischer / robuster dan dit gedoe met klemmen en WiFi.

Bij eventuele communicatieproblemen, zou ik trouwens die spoeltjes (opgerolde signaaldraden) in je modbusverbinding nog 'ns heroverwegen.

Het had leuk geweest dat de CT002 of de CT003 gewoon uitgelezen kon worden, heb het als VOC doorgegeven aan Marstek los van hun mogelijk meer of minder idealistische gedachtengang.

Momenteel heb ik geen signaalproblemen, ik snap zeker je gedachtengang!

[Eveir]

PVerga schreef op donderdag 22 mei 2025 @ 10:48:
[...]


Blij dat er nog Loxone gebruikers bezig zijn met de Marstek modbus intergratie.
Ik heb voorlopig èèn batterij en gebruik ook de waveshare interface en verder Shelly Pro 3em voor de meetpunten.
Ik heb eerder in dit forum mijn benadering als eens toegelicht: mijn batterij staat permanent op zelf consumptie en ik heb een Shelly emulator gebouwd in Loxone die toelaat de gemeten waarden te manipuleren om zo het laden en ontladen (bij) te sturen.
Werkt allemaal prima, maar ik heb mijn twijfels bij het uitlezen van het 'fault word' modbus register 36100.
Dit is een register dat o.a. Undervoltage alarm kan genereren. Ik zou dit graag gebruiken om een spanningsuitval te melden.
Maar volgens mij kloppen de bitmasks niet die in de documentatie staan, of ik maak een fout hoe ik dit 32 bit register uitlees.
Wanneer ik de stekker van de Marstek uittrek, krijg code 128 decimaal, dus binair 1000 0000, wat ik niet kan mappen met de documentatie. Daardoor heb ik ook mijn twijfels over de andere foutmeldingen in dit register, en die zijn moeilijker te simuleren....
Zie ook een post van me van enkele dagen geleden en de reactie van Superduper1969, maar ik tast nog steeds in het duister...
Hulp welkom en ik wil best ook verdere details verschaffen over mijn set-up indien gewenst.

Is het mogelijk de info van de analoge ingang even te posten? Ik lees bit als value type met aantal bytes 4 in de documentatie. Bit 0 tot en met 15 zijn gedefinieerd, waarvan de laatste 9 als reserve.

Er zijn 7 bits beschreven, jij krijgt er 8, wat inderdaad afwijkt van de handleiding.

Momenteel monitor ik de status van het net (lees: Fasespanningen & frequentie) adhv mijn PV-omvormer via TCP/IP. Afhankelijk van de terugkoppeling en/of foutcode die deze geeft, stuur in een melding via Loxone en mail.

De spanning wanneer de omvormer uit dienst gaat zou wel eens anders kunnen zijn dan die van de batterij. In BE zou dat bij 10 minuten 253V voor omvormers moeten zijn.

Het heropstarten of uit beveiliging halen van de batterij zou een mooie integratie zijn

[Gwaihir]

@Eveir Hij leest vier bytes uit. Dus krijgt hij 4x8 bits. Da's logisch.

Wat helaas niet zo strak gestandaardiseerd is, is de volgorde van die vier bytes en de volgorde binnen de byte. Er zijn dus nogal wat combinaties. Maar toch, werken de andere registers en lees je hetzelfde, dan zou het moeten kloppen. Ik zou het dus eerst vergelijken met het binnen hengelen van de device naam; die waarde is immers ook meerdere registers lang die dus op volgorde moeten staan. (Met een getal met vooral veel voorloopnullen zie je het lang niet altijd.)

@PVerga Welke verwacht je te simuleren? Ik kan zo 1-2-3 niet plaatsen waarom hij die (bijv.) wel undervoltage maar niet underfrequency zou bestempelen. Misschien kijk je wel naar een van de ongedocumenteerde 'reserve' bits.

En ik vind dit een slecht stukje api van Marstek. Modbus kent wel degelijk boolean registers, dus dit samenvegen is niet nodig. Daarnaast is - juist ook voor testen - gebruikelijk dat er tenminste één algemeen 'alarm' signaal is dat AAN staat tenzij er iets mis is (waar de andere registers dan details over kunnen geven). Dat is zoveel makkelijker te verwerken dan je af moeten vragen of je een eventuele fout echt gaat zien in het geval deze optreedt..

[Broodro0ster]

Ik deed een update aan mijn modbus package voor de Marstek batterij en herstarte daarna HA. Op dat moment is mijn EW11 er gedisconnected van mijn netwerk en ik krijg geen data meer in HA.
Is mijn EW11 nu gewoon crashed of zou ik perongeluk modbus op de Marstek hebben uitgeschakeld? Kan ik dat laatste terug inschakelen via de Marstek app? Ik vind daar nergens een optie voor.

Zodra ik thuis ben, zal ik mijn dongle ook even opnieuw inpluggen. Die heeft misschien een power cycle nodig.

[superduper1969]

Broodro0ster schreef op donderdag 22 mei 2025 @ 14:41:
Ik deed een update aan mijn modbus package voor de Marstek batterij en herstarte daarna HA. Op dat moment is mijn EW11 er gedisconnected van mijn netwerk en ik krijg geen data meer in HA.
Is mijn EW11 nu gewoon crashed of zou ik perongeluk modbus op de Marstek hebben uitgeschakeld? Kan ik dat laatste terug inschakelen via de Marstek app? Ik vind daar nergens een optie voor.

Zodra ik thuis ben, zal ik mijn dongle ook even opnieuw inpluggen. Die heeft misschien een power cycle nodig.

Modbus functie op de MT is niet uit te schakelen dus je hebt iets anders te onderzoeken.

[Broodro0ster]

superduper1969 schreef op donderdag 22 mei 2025 @ 15:42:
[...]

Modbus functie op de MT is niet uit te schakelen dus je hebt iets anders te onderzoeken.

Thanks, dan maakt het debuggen al iets makkelijker. Straks eens mijn EW11 opnieuw inpluggen en dan gaat het hopelijk werken. Waarschijnlijk is die gecrashed nadat wat aanpassingen in de package file gedaan heb.

[PVerga]

Gwaihir schreef op donderdag 22 mei 2025 @ 13:06:
@Eveir Hij leest vier bytes uit. Dus krijgt hij 4x8 bits. Da's logisch.

Wat helaas niet zo strak gestandaardiseerd is, is de volgorde van die vier bytes en de volgorde binnen de byte. Er zijn dus nogal wat combinaties. Maar toch, werken de andere registers en lees je hetzelfde, dan zou het moeten kloppen. Ik zou het dus eerst vergelijken met het binnen hengelen van de device naam; die waarde is immers ook meerdere registers lang die dus op volgorde moeten staan. (Met een getal met vooral veel voorloopnullen zie je het lang niet altijd.)

@PVerga Welke verwacht je te simuleren? Ik kan zo 1-2-3 niet plaatsen waarom hij die (bijv.) wel undervoltage maar niet underfrequency zou bestempelen. Misschien kijk je wel naar een van de ongedocumenteerde 'reserve' bits.

En ik vind dit een slecht stukje api van Marstek. Modbus kent wel degelijk boolean registers, dus dit samenvegen is niet nodig. Daarnaast is - juist ook voor testen - gebruikelijk dat er tenminste één algemeen 'alarm' signaal is dat AAN staat tenzij er iets mis is (waar de andere registers dan details over kunnen geven). Dat is zoveel makkelijker te verwerken dan je af moeten vragen of je een eventuele fout echt gaat zien in het geval deze optreedt..

@Gwaihir , @Eveir Dank voor jullie reacties. Ik heb zowat alle combinaties van 32bit signed/unsigned, Order of registers en Byte order uitgeprobeerd en het enige wat enigszins steek houdt is de waarde DEC 128 voor undervoltage zoals eerder gemeld. Dit gaat keurig ook terug naar nul wanneer de netspanning terug aanwezig is. Wat ik nu in de Loxone config heb voor dit register vind je in de screenshot hieronder.
Bitwise maakt het geen enkele zin, tenzij undervoltage in de documentatie overvoltage zou zijn en vice versa. Maar wat dan met de andere 'faults'?
Ik ben op dit moment voor een langere periode niet in de buurt van de batterij, dus ik kan het 'stekker uittrekken' voorlopig niet uitvoeren voor ver dere testen. Ik heb wel toegang tot Loxone config.
Nogmaals dank en verdere suggesties zijn zeer welkom.

[Gwaihir]

@PVerga Ik vind de config nogal een nare manier om dingen uit te proberen. Met de modbus extensie heb ik helaas nog niet anders gevonden. Maar waar er zo'n Waveshare tussen zit, heb ik gelijk een ander tooltje gezocht voor het uitproberen. Hier werd ik wel blij van: https://github.com/serhmarch/ModbusTools .

En, zoals ik al eerder zei: kun je met diezelfde wel / niet aangevinkte drie opties de naam goed uitlezen?

[Maarten69]

Ik heb mijn modbus timings van 20ms naar 50ms gezet in de yaml. Iemand die hier meer over weet?

[Chris96]

Edzelf schreef op donderdag 13 maart 2025 @ 11:43:
De print en de software voor mijn Venus-control project is inmiddels gereed:

[Afbeelding]

Venus-control vervangt de Marstek software voor nul op de meter. Tevens is een uitgebreide web-interface beschikbaar. MQTT koppeling volgt nog. Zie de beschrijving hier.

Indien er belangstelling voor is kan ik wel een exemplaar opsturen. Neem even contact op. De prijs van de module (zonder kastje) is 10 euro plus verzendkosten.

Fantastisch deze oplossing om alle data vanuit de batterij in home assistant te krijgen. Nou heb ik alle pagina's gelezen maar kon nergens terug vinden of iemand daadwerkelijk tot het aanbieden ervan over gegaan is. Mocht dat toch niet het geval zijn is er dan misschien iemand die er 1 over heeft?

[Weet niet of deze vraag toegestaan is]

[mgiebels]

Ik wil zelf ook de lily bestellen en die kabels om de Marstek Venus E aan te sluiten echter die kabels zijn uitverkocht is er iemand die een alternatief gevonden heeft?

Die lily bestel ik bij ALi express maar voor de rest ook overal uitverkocht

Heb nu zelf het het in homeassistant via software gedaan maar dat is gewoon niet volledig en mega traag.

[leejoow]

mgiebels schreef op vrijdag 23 mei 2025 @ 07:52:
Ik wil zelf ook de lily bestellen en die kabels om de Marstek Venus E aan te sluiten echter die kabels zijn uitverkocht is er iemand die een alternatief gevonden heeft?

Die lily bestel ik bij ALi express maar voor de rest ook overal uitverkocht

Heb nu zelf het het in homeassistant via software gedaan maar dat is gewoon niet volledig en mega traag.

Welke kabels bedoel je?
Bevestiging voor de lilygo kan ik btw voor je printen mocht je interesse hebben

[mgiebels]

leejoow schreef op vrijdag 23 mei 2025 @ 08:03:
[...]


Welke kabels bedoel je?
Bevestiging voor de lilygo kan ik btw voor je printen mocht je interesse hebben

Heb zelf 3d printer dus ben nog op zoek naar het bestand om zelf te printen.

Maar de kabel van de lilygo naar de Venus adapter die had superdupe netjes erin staan echter zijn die uitverkocht steeds

[superduper1969]

Maarten69 schreef op donderdag 22 mei 2025 @ 21:45:
Ik heb mijn modbus timings van 20ms naar 50ms gezet in de yaml. Iemand die hier meer over weet?

Wat voor probleem denk je hiermee op te lossen?
20ms heb ik getest en werkt prima met de Lillygo.

[leejoow]

mgiebels schreef op vrijdag 23 mei 2025 @ 08:10:
[...]

Heb zelf 3d printer dus ben nog op zoek naar het bestand om zelf te printen.

Maar de kabel van de lilygo naar de Venus adapter die had superdupe netjes erin staan echter zijn die uitverkocht steeds

Bedoel je deze: https://nl.aliexpress.com/item/1005005811950799.html?
Volgens ali wel beschikbaar, maar je zit wel met wat levertijd….

[ Voor 8% gewijzigd door leejoow op 23-05-2025 08:13 ]

[mgiebels]

leejoow schreef op vrijdag 23 mei 2025 @ 08:13:
[...]


Bedoel je deze: https://nl.aliexpress.com/item/1005005811950799.html?
Volgens ali wel beschikbaar, maar je zit wel met wat levertijd….

Ja ik had via iemand anders link van amazon.
En de lilygo is eerder leverbaar dan wil je meteen aan de gangnatuurlijk haha

Maar ik las iets in het hoofdbericht dat per april andere indeling van de kabel is of is dat niet voor de Venus E?
Heb hem net een week de accu namelijk.

Is dit ook wat? https://www.amazon.nl/con...Z2V0TmFtZT1zcF9hdGY&psc=1

[ Voor 39% gewijzigd door mgiebels op 23-05-2025 08:39 ]

[mgiebels]

Misschien stomme vraag maar je kan die 5volt voor de lilygo toch ook uit die rs485 halen? ik zie op andere sites dat ze een losse adapter aansluiten en ook op die van Denie van kleef doet het zo.

Maar ik vraag me af waarom zou je het niet gewoon vanuit die kabel zelf doen of kan dat niet?

[Maarten69]

@mgiebels dat kan ook gewoon, heb 3 MT's en dus 3 lilygo's zo aangesloten.

[mgiebels]

Maarten69 schreef op vrijdag 23 mei 2025 @ 11:31:
@mgiebels dat kan ook gewoon, heb 3 MT's en dus 3 lilygo's zo aangesloten.

Ja leek mij ook toch geeen via 5v en gnd snap niet waarom je nog een adapter erbij zou doen los weer een stekker

[Maarten69]

Dit deden sommige omdat het leek als de v2 geen 5V kon leveren, dit bleek een fout in de kabel (andere pinout)

[Hometek]

Ik ben aan het experimenteren met aansturen van de Marstek Venus vanuit HA in een off-grid setting (zie deze post)

In de off-grid setting wordt de batterij via de backup poort opgeladen door AC stroom van de zonnepanelen. Mijn plan was om de zonnepanelen uit te schakelen zodra SOC 100% bereikt.
Dit bleek in de test niet te werken, de batterij ging in storing zodra deze vol was (geen stroom meer op de backup poort, rode warn led aan).

Voor zover ik het kon nagaan gaat de batterij in storing voordat de SOC waarde '100%' via modbus uitgestuurd wordt. De externe regeling kreeg dus geen informatie om de panelen uit te schakelen.

Om het off-grid systeem te laten werken op basis van de SOC moet ik dus de panelen afschakelen bij 99%.
Maar dan worden de cellen nooit netjes gebalanceerd en zal de SOC drift met de tijd toenemen.
Niet echt een probleem voor een noodoplossing die niet vaak gebruikt zal worden.

Maar uit technische nieuwsgierigheid vraag ik me toch af of er geen andere mogelijkheid is om te detekteren waneer de batterij echt 'vol' is en de panelen af te schakelen voordat de batterij in storing gaat.

[Hometek]

mgiebels schreef op vrijdag 23 mei 2025 @ 08:10:
[...]
Heb zelf 3d printer dus ben nog op zoek naar het bestand om zelf te printen.

Maar de kabel van de lilygo naar de Venus adapter die had superdupe netjes erin staan echter zijn die uitverkocht steeds

3D bestanden kun je hier vinden, en in de TS.

De extra kabel is niet echt nodig, tenzij je de modbus kabel ook nog voor andere doeleinden nodig hebt.
Je kunt de stekkers van de Liligo rechtstreeks aansluiten.

[mgiebels]

@Hometek thanks Ik had zelf ook al anderebehuizing gevonden op makersworld https://makerworld.com/en...=search#profileId-1053950

[ Voor 6% gewijzigd door mgiebels op 23-05-2025 18:07 ]

[pascallj]

PVerga schreef op maandag 19 mei 2025 @ 09:27:
Heeft iemand al eens de bitmasks getest van modbus register 36100?
Dit zou een 32 bit register moeten zijn volgens de modbus documentatie.
Ik heb dit eens getest door de stekker van de Marstek uit het stopkontakt te trekken en dan krijg ik waarde 128 DEC of 80 HEX terug als 'grid undervoltage' fout, wat ik helemaal niet kan mappen met de bitmasks zoals vermeld in de documentatie.
Ik lees het register als een 32 bit unsigned, twee16 bit registers high word / low word volgorde.
(net zoals het uilezen van vb. registers 33004, 33006 die ik wel correct binnenkrijg). Andere combinaties van register of byte volgorde leveren nonsens waarden op.
Ik heb nu wel het alarm voor undervoltage in orde, maar vrees voor de waarden van andere alarmen in dit register...

Krijg jij ook een alarm lampje als je de spanning eraf haalt? Ik heb even snel getest door de stekker eruit te halen maar krijg geen alarm LED. Dus weet niet of het uitblijven van de foutcode nu komt omdat het apparaat niet in alarm schiet, of omdat de bitmasks incorrect zijn in de documentatie en dus ook in de config.

[Marco_64]

Voor de geïnteresseerden, ik heb een andere behuizing gemaakt voor de LilyGo's van mijn batterijen. Deze keer met alle kabel en connectoren mooi in de behuizing. De kabel gaat in de behuizing via een PG7 draadwartel.

Hier vind je het ontwerp terug op Thingiverse en Printables

[PVerga]

pascallj schreef op zaterdag 24 mei 2025 @ 12:32:
[...]


Krijg jij ook een alarm lampje als je de spanning eraf haalt? Ik heb even snel getest door de stekker eruit te halen maar krijg geen alarm LED. Dus weet niet of het uitblijven van de foutcode nu komt omdat het apparaat niet in alarm schiet, of omdat de bitmasks incorrect zijn in de documentatie en dus ook in de config.

Ik ben op dit ogenblik en voor een langere periode en ver verwijderd van mijn batterij, dus ik kan het niet nakijken.
Maar voor alle duidelijkheid: ik krijg wel een ‘fault’ melding via modbus wanneer ik de stekker uittrek, maar de waarde die ik doorkrijg (dec 128) klopt niet met de bits zoals in de modbus documentatie beschreve staat...
Ik zoek verder wanneer ik terug bij de stekker kan.

[Gely]

Maxwp schreef op maandag 12 mei 2025 @ 09:54:
[...]

Zeker
Maar device id en mac van de martsek zelf staan op.die site niet in de app ?
Als die site offline is kan ik die niet terug vnden

Als jarenlang gebruiker van HomeAssistant heb ik mij ook aan de Marstek MQTT setup gewaagd. De server https://eu.hamedata.com/app/AfterSales/index.html is inderdaad onbereikbaar geworden en op de nieuwe https://www.besscenter.com kan je blijkbaar als consument nog niet inloggen.
Echter, die Device_ID, is dat niet de 12 cijferige code van de onderste barcode van het toestel? Kan je dit bevestigen, dus die onder het S/N? Dat begint met dezelfde alfanum. cijfers als het MAC adres maar is langer.

Ik krijg dit uit de log van de Hame-Relay met die code, ben echter niet zeker of dit deel eigenlijk al werkt.

EDIT: Als ik een andere random code ingeef krijg ik in de log te lezen dat de Device_ID tussen 20 en 22 karakters moet zijn OF exact 12 digits. Beetje verwarrend.

[ Voor 6% gewijzigd door Gely op 25-05-2025 09:21 ]

[pascallj]

Gely schreef op zondag 25 mei 2025 @ 09:17:
[...]


Als jarenlang gebruiker van HomeAssistant heb ik mij ook aan de Marstek MQTT setup gewaagd. De server https://eu.hamedata.com/app/AfterSales/index.html is inderdaad onbereikbaar geworden en op de nieuwe https://www.besscenter.com kan je blijkbaar als consument nog niet inloggen.
Echter, die Device_ID, is dat niet de 12 cijferige code van de onderste barcode van het toestel? Kan je dit bevestigen, dus die onder het S/N? Dat begint met dezelfde alfanum. cijfers als het MAC adres maar is langer.

Ik krijg dit uit de log van de Hame-Relay met die code, ben echter niet zeker of dit deel eigenlijk al werkt.

EDIT: Als ik een andere random code ingeef krijg ik in de log te lezen dat de Device_ID tussen 20 en 22 karakters moet zijn OF exact 12 digits. Beetje verwarrend.

[Afbeelding]

Deze al bekeken? Richh in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

[Gely]

pascallj schreef op zondag 25 mei 2025 @ 09:35:
[...]


Deze al bekeken? Richh in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

Neen, die specifieke post nog niet, had wel her en der info gesprokkeld en beide Github pagina’s doorgenomen m.b.t. broker/relay. Mosquito had ik al draaien.

Ik ga deze eens bekijken, bedankt!

[AUijtdehaag]

@Gely
Wel vreemd dat je mac en device id praktisch hetzelfde zijn in je screenshot.
Zie je ook je inlognaam en ww bevestiging voorbij komen in de log?

[Gely]

AUijtdehaag schreef op zondag 25 mei 2025 @ 10:14:
@Gely
Wel vreemd dat je mac en device id praktisch hetzelfde zijn in je screenshot.
Zie je ook je inlognaam en ww bevestiging voorbij komen in de log?

[Afbeelding]

Bedankt voor de reactie. Inderdaad. Dat was ook mijn initiële vraag of dat Device_ID de onderste barcode van het toestel is met een lengte van 12 digits waarvan het eerste deel overeenkomt met het MAC adres van het toestel. Want als je een foutieve code in de Hame-Relay config ingeeft meldt deze dat de code ofwel tussen 20 en 22 ligt (ik lees in verschillende posts zelfs 24) OF dat de code exact 12 digits moet zijn. Ik dacht dus dat die laatste kon worden gebruikt. Nu ik er even over nadenk zal die 12 digit code eerder het Bluetooth MAC adres van het toestel zijn.

Van het probleem blijft dus over: de Hame Server die niet bereikbaar is waarvoor ik dus geen credentials heb en dus ook geen Device_ID met een lengte van >20digits heb. Dus no MQTT

EDIT: Maar als je mijn log bekijkt zou je denken dat het werkt, want geen error meldingen

[ Voor 3% gewijzigd door Gely op 25-05-2025 10:35 ]

[AUijtdehaag]

@Gely
Ik heb eventueel nog wel een nodered flow die de gegevens (device id en mac) opvraagt aan de hand van je inlognaam en ww (in md5 hash)
Graag via DM verder als je interesse daarin hebt

[ Voor 5% gewijzigd door AUijtdehaag op 25-05-2025 10:58 ]

[Gely]

AUijtdehaag schreef op zondag 25 mei 2025 @ 10:14:
@Gely
Wel vreemd dat je mac en device id praktisch hetzelfde zijn in je screenshot.
Zie je ook je inlognaam en ww bevestiging voorbij komen in de log?

[Afbeelding]

OK, dingen beginnen iets duidelijker te worden. Heb in de Hame-Relay mijn Marstek e-mail en paswoord ingegeven en krijg nu onderstaande maar met 2 devices waarvan één Inverse Forwarding op false staat (en kan dit niet wijzigen) en met het 22 digit Device_ID , nu nog een manier vinden om er één van te deleten:

[AUijtdehaag]

@Gely
In de configuratie tab van de add-on hame relay kan je toch inverse forwarding aanvinken en opslaan?
Of even naar de yaml mode
Wellicht hame-relay even opnieuw installeren (bug?)

[ Voor 16% gewijzigd door AUijtdehaag op 25-05-2025 11:30 ]

[Gely]

AUijtdehaag schreef op zondag 25 mei 2025 @ 11:28:
@Gely
In de configuratie tab van de add-on hame relay kan je toch inverse forwarding aanvinken en opslaan?
Of even naar de yaml mode

@AUijtdehaag Jawel, maar wat ik ook doe (ook in YAML Mode), ik krijg een error bij het opslaan.
Zie hieronder:

[ Voor 20% gewijzigd door Gely op 25-05-2025 11:46 ]

[AUijtdehaag]

@Gely
Vreemd
Zo ziet die er bij mij uit (met aanhalingstekens - probeer eens)

[ Voor 3% gewijzigd door AUijtdehaag op 25-05-2025 12:24 ]

[mvanimpe]

Ik krijg de gecreerde sensors niet binnen in mijn home assistant..

Ik kan alle waarden zien via het esp dashboard maar als ik de status opvraag van de gemaakte sensoren staat er 'unavailable'.
Ik heb ook verschillende versies gezien van de marstek_venus_battery_control.yaml dus waarschijnlijk zit ik daar ergens fout.
Kan iemand me helpen waar ik moet zoeken? Al bedankt!

[pascallj]

mvanimpe schreef op zondag 25 mei 2025 @ 12:28:
Ik krijg de gecreerde sensors niet binnen in mijn home assistant..

Ik kan alle waarden zien via het esp dashboard maar als ik de status opvraag van de gemaakte sensoren staat er 'unavailable'.
Ik heb ook verschillende versies gezien van de marstek_venus_battery_control.yaml dus waarschijnlijk zit ik daar ergens fout.
Kan iemand me helpen waar ik moet zoeken? Al bedankt!

[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Wat is je entity_id van bijvoorbeeld 'AC Power'? Sensor aanklikken en dan tandwieltje geloof ik.

[mvanimpe]

[Gely]

AUijtdehaag schreef op zondag 25 mei 2025 @ 12:21:
@Gely
Vreemd
Zo ziet die er bij mij uit (met aanhalingstekens - probeer eens)
[Afbeelding]

@AUijtdehaag And 12 points go to ... you

Bedankt, dat is al een stap vooruit

[pascallj]

mvanimpe schreef op zondag 25 mei 2025 @ 12:35:
[Afbeelding]

Dan zal je sensor.lilygo_rs485_marstek_ac_power in regel 13, 14, 25 en 26 moeten vervangen voor sensor.marstek_thuisbatterij_lilygo_marstek_ac_power. Je hebt waarschijnlijk de naam van het apparaat gewijzigd van "LILYGO RS485" naar "Marstek thuisbattery lilygo".

[mvanimpe]

dank je wel!

[AUijtdehaag]

Waarom gebruiken jullie in de code zulke lange namen?

YAML:

esphome:
  name: marstek_m1
  friendly_name: MT1

en

YAML:

# Sensoren
sensor:
  - name: "AC Power"
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 32202
    value_type: S_DWORD
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    accuracy_decimals: 0
    skip_updates: 2 # 10 seconds

resulteert in
sensor.marstek_m1_ac_power
ipv
sensor.marstek_thuisbatterij_lilygo_marstek_ac_power.

https://github.com/fonske...me/tree/main/MarstekVenus

[ Voor 4% gewijzigd door AUijtdehaag op 25-05-2025 13:13 ]

[ELTUNO]

[
Ik heb de twee Lilygos in HA werkend.

Krijg het niet voor elkaar om ze vanuit HA in Homey te krijgen.

Wie kan mij hier of op een andere manier aub bij helpen?

---------------------------------------------------------------------------------------------------

Ondertussen MQTT toegevoegd aan yaml - nu nog met MQTT werkend krijgen in Homey.

[ Voor 92% gewijzigd door ELTUNO op 25-05-2025 17:56 . Reden: MQTT toegevoegd ]

[JanAllElectric]

Voor de zelfprogrammeurs onder ons heb ik een aantal eigenaardigheden bemerkt bij aansturing van mijn 3 Marsteks:

- (1) Verschil tussen Marstek Forcible Charge Power/Marstek Forcible Discharge Power en Marstek AC Power is meestal rond 10W.
- (2) boven 99% SOC wordt het laadvermogen getrottled tot 1200W.
- (3) onder x% SOC (15%?) wordt het ontlaadvermogen getrottled tot 1500W.
- (4) soms stopt laden bij 99% SOC ipv 100% SOC (Marstek Forcible Charge Power = 2500 && Marstek Forcible Charge/Discharge = 'charge' levert Marstek AC Power = 0 && Marstek Inverter State = 'Standby' ).

Met 1 Marstek heb je er geen last van, maar met 3 Marsteks wordt het vermogen niet goed verdeeld over de Marsteks.

ad (1): laat ik op dit moment zo. NOM beweegt dan rond +- 25W, indien afname huis/teruglevering PV een beetje stabiel is).

edit: gecorrigeerd met delta. NOM beweegt dan tussen +-15W en minder.

ad (2): ik corrigeer het max laadvermogen tot vol
ad (3): ik corrigeer het max ontlaadvermogen tot leeg
ad (4): ik corrigeer de inhoud in dat geval (tijdelijk tot de volgende discharge) met de vulgraad bij 99%. Vaak blijkt dan bij de volgende charge wel 100% te worden gehaald.

Zijn er nog meer "eigenaardigheden" waar in het programma rekening moet worden gehouden?

[ Voor 3% gewijzigd door JanAllElectric op 25-05-2025 21:22 ]

[Hometek]

JanAllElectric schreef op zondag 25 mei 2025 @ 17:42:
Voor de zelfprogrammeurs onder ons heb ik een aantal eigenaardigheden bemerkt bij aansturing van mijn 3 Marsteks:
...
- (2) boven 99% SOC wordt het laadvermogen getrottled tot 1200W.
...
Zijn er nog meer "eigenaardigheden" waar in het programma rekening moet worden gehouden?

Bij mij zie ik het laadvermogen al bij 95% dalen tot ca. 1200W.

Verder zie ik regelmatig dat de SOC plotseling sterk daalt in de lage SOC range, bv van 22% in één keer naar 11% terwijl het verbruik minder dan 200W is.
Ook blijven mijn batterijen vaak erg lang doorladen op 99% voordat de 100% bereikt wordt.
Ik vermoed dat dit veroorzakt wordt door SOC drift. Bij een geforceerde oplaad/ontlaad/oplaad cycle zie ik dit niet.
Het kan zijn dat dit effect niet voor iedereen even sterk aanwezig is, mogelijk afhankelijk van de batterij, en/of de dagelijkse belasting.

Ik ben mijn aansturing nu zo aan het inrichten dat de batterijen geforceerd opgeladen worden tot 100% zodra de SOC boven een (nog te bepalen) drempelwaarde komt.
En eventueel ook een automatisering om minstens 1 keer per week tot 100% te laden.

[Wâldpyk-9]

Ook ik heb de V2 versie, maar wanneer ik de MODbus plug in de Marstek Venus doe dan meet ik geen DC spanning op de 2 zwarte draden. Moet de RS485 misschien ingeschakeld worden?

[pascallj]

Wâldpyk-9 schreef op zondag 25 mei 2025 @ 20:22:
Ook ik heb de V2 versie, maar wanneer ik de MODbus plug in de Marstek Venus doe dan meet ik geen DC spanning op de 2 zwarte draden. Moet de RS485 misschien ingeschakeld worden?

RS485 is standaard ingeschakeld. Er is wat gerommeld met de kleuren van de draden. Ik zou even tussen wat meer paren meten. Zwart1-Rood, of Zwart2-rood misschien.

[Eveir]

PVerga schreef op donderdag 22 mei 2025 @ 20:40:
[...]


@Gwaihir , @Eveir Dank voor jullie reacties. Ik heb zowat alle combinaties van 32bit signed/unsigned, Order of registers en Byte order uitgeprobeerd en het enige wat enigszins steek houdt is de waarde DEC 128 voor undervoltage zoals eerder gemeld. Dit gaat keurig ook terug naar nul wanneer de netspanning terug aanwezig is. Wat ik nu in de Loxone config heb voor dit register vind je in de screenshot hieronder.
Bitwise maakt het geen enkele zin, tenzij undervoltage in de documentatie overvoltage zou zijn en vice versa. Maar wat dan met de andere 'faults'?
Ik ben op dit moment voor een langere periode niet in de buurt van de batterij, dus ik kan het 'stekker uittrekken' voorlopig niet uitvoeren voor ver dere testen. Ik heb wel toegang tot Loxone config.
Nogmaals dank en verdere suggesties zijn zeer welkom.
[Afbeelding]

Ik heb enkele codes weten te activeren, de andere mits extrapolatie owv niet simuleerbaar alsvolgt geconcludeerd.

ID:36100 fault word
Bit 0: 0-64 (normaal-abnormaal)
Bit 1: 0-128 (Hier zag jij de 128 decimaal wanneer undervoltage)
Bit 2: 0-256
Bit 3: 0-512
Bit 4: 0-1024
Bit 5: 0-2048
Bit 6: 0-4096

ID:43100 discharge time1 week zijn we aan volgende decimale nummers aanbeland:
Bit 0: 0-65536 (maandag niet geselecteerd-maandag wel geselecteerd)
Bit 1: 0-131072
Bit 2: 0-262144
Bit 3: 0-524288
Bit 4: 0-1048576
Bit 5: 0-2097152
Bit 6: 0-4194304 (zondag niet geselecteerd-zondag wel geselecteerd)

Gedocumenteerde reservebits zullen naar alle waarschijnlijkheid rekening houdende met deze trend steeds tot de macht van 2 genomen worden tov de vorige gebruikte bit.

[ Voor 22% gewijzigd door Eveir op 25-05-2025 22:28 ]

[pascallj]

Eveir schreef op zondag 25 mei 2025 @ 21:02:
[...]


Ik heb enkele codes weten te activeren, de andere mits extrapolatie owv niet simuleerbaar alsvolgt geconcludeerd.

ID:36000 alarm code
Bit 0 0-1 (normaal-abnormaal)
Bit 2 0-2
Bit 3 0-4
Bit 4 0-8
Bit 5 0-16
Bit 6 0-32

ID:36100 fault word
Bit 0 0-64 (normaal-abnormaal)
Bit 1 0-128 (Hier zag jij de 128 decimaal wanneer undervoltage)
Bit 2 0-256
Bit 3 0-512
Bit 4 0-1024
Bit 5 0-2046
Bit 6 0-4092

Bij een cross-check op ID:43100 discharge time1 week zijn we aan volgende decimale nummers aanbeland:
Bit 1: 0-65536 (maandag niet geselecteerd-maandag wel geselecteerd)
...
Bit 7: 0-4194304 (zondag niet geselecteerd-zondag wel geselecteerd)

Hoe moet ik dit interpreteren? Want er kan op 1 bit niet meer dan 0 of 1 zitten. Heb je het dan gewoon over hele waarde van het hele register ipv 1 bit? En komt dit overeen met de documentatie of juist niet?

Overigens denk ik dat bit 5, 2048 moet zijn.

[Eveir]

pascallj schreef op zondag 25 mei 2025 @ 21:06:
[...]


Hoe moet ik dit interpreteren? Want er kan op 1 bit niet meer dan 0 of 1 zitten. Heb je het dan gewoon over hele waarde van het hele register ipv 1 bit? En komt dit overeen met de documentatie of juist niet?

Overigens denk ik dat bit 5, 2048 moet zijn.

Interpreteren oplopend volgens ID, steeds decimaal verdubbelend.
Reservebits tellen niet mee. (Lees: geen waardes toegekend en dus ook geen verdubbeling in rekening brengen)

Is niet aanwezig in de documentatie.

Bedankt voor je oog voor detail op bit 5, aangepast.

[pascallj]

Eveir schreef op zondag 25 mei 2025 @ 21:12:
[...]


Interpreteren oplopend volgens ID, steeds decimaal verdubbelend.
Reservebits tellen niet mee. (Lees: geen waardes toegekend en dus ook geen verdubbeling in rekening brengen)

Is niet aanwezig in de documentatie.

Bedankt voor je oog voor detail op bit 5, aangepast.

Dus met 'Bit 0' bedoel je Bit 0 zoals beschreven in de documentatie? Want dan is 36000 volgens jouw tabel dus wel correct, alleen 36100 niet (want die begint bij 64 aka bit 7).

Of nee wacht je hebt geen 'Bit 1' in 36000? Waar zou die waarde dan zijn gebleven?

[ Voor 6% gewijzigd door pascallj op 25-05-2025 21:19 ]

[Wâldpyk-9]

Ik heb alle combinaties van draden gemeten, maar meet geen spanning. Vandaar mij twijfel of de RS485 ingeschakeld dient te worden.

[Eveir]

pascallj schreef op zondag 25 mei 2025 @ 21:17:
[...]


Dus met 'Bit 0' bedoel je Bit 0 zoals beschreven in de documentatie? Want dan is 36000 volgens jouw tabel dus wel correct, alleen 36100 niet (want die begint bij 64 aka bit 7).

Of nee wacht je hebt geen 'Bit 1' in 36000? Waar zou die waarde dan zijn gebleven?

Ik heb de nodige aanpassingen doorgevoerd.

Indien er foutcodes (ongewenst) gereproduceerd worden lijkt het mij een idee deze in dit topic te posten met vermelding van de ID, naam en de oorzaak (indien zeker) van de fout.

Het uitlezen of bekijken van de netwaarden die een PV-omvormer opvolgt en het loggen van de batterijwaarden kunnen hiervoor een handige tool zijn.

[ Voor 13% gewijzigd door Eveir op 25-05-2025 23:00 ]

[Hometek]

Toevoeging voor de lilygo-rs485.yaml:
Inverter State case 6: "AC bypass"

Deze state treed op in manual mode met backup enabled.

code:

  - platform: template
    name: "Inverter State"
    lambda: |-
      switch (int(id(inverter_state).state)) {
        case 0: return std::string("Sleep");
        case 1: return std::string("Standby");
        case 2: return std::string("Charge");
        case 3: return std::string("Discharge");
        case 4: return std::string("Fault");
        case 5: return std::string("Idle");
        case 6: return std::string("AC bypass");
        default: return std::string("Unknown");
      };
    update_interval: 5s

[mgiebels]

Even een controle vraag als mijn Marstek aan het opladen is en met 1,5 of 2,5 kw dan hoor je een zoem/licht fluit toon is dit normaal?
Lijkt net een soort ventilator die draait.
Vooral als hij bijna vol is lijkt dit harder te gaan.

En andere vraag mijn moeder heeft een zuurstof apparaat ivm copd en nu vroeg me vader zich af ik heb hem nu zo staan dat hij automatisch alles doet maar hij wilt eigenlijk wel dat hij wat erin houd om ook het zuurstof apparaat als er wat uitvalt nog van stroom te voorzien kan dit met de APP? of moet dat dan ook via Homeassistant (wat hij niet heeft)

[SatScan]

mgiebels schreef op maandag 26 mei 2025 @ 12:11:
Even een controle vraag als mijn Marstek aan het opladen is en met 1,5 of 2,5 kw dan hoor je een zoem/licht fluit toon is dit normaal?
Lijkt net een soort ventilator die draait.
Vooral als hij bijna vol is lijkt dit harder te gaan.

En andere vraag mijn moeder heeft een zuurstof apparaat ivm copd en nu vroeg me vader zich af ik heb hem nu zo staan dat hij automatisch alles doet maar hij wilt eigenlijk wel dat hij wat erin houd om ook het zuurstof apparaat als er wat uitvalt nog van stroom te voorzien kan dit met de APP? of moet dat dan ook via Homeassistant (wat hij niet heeft)

Ga hier eens lezen

Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu
en
Marstek / Duravolt Venus PnP Thuisaccu gebruiken als backup