-
-
Notifications
You must be signed in to change notification settings - Fork 916
Add Marstek Venus battery #21487
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Marstek Venus battery #21487
Conversation
Introduce `MarstekVenus` implementation for battery system monitoring and control, including CurrentPower, SoC, and battery mode management. Also, add a template definition for configuration with Modbus TCP parameters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @Chris8er - I've reviewed your changes and they look great!
Here's what I looked at during the review
- 🟡 General issues: 3 issues found
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Hinweis: ich habe kaum Erfahrungen in GO, wollte aber gerne den Marstek Venus integriert haben. Lokal läuft es. Habe ich noch etwas vergessen? Schaut bitte mal drüber und sagt Bescheid, wenn noch etwas zu tun ist. Die Steuerung des Venus erfordert mehrere Modbus Befehle: Steuerung aktivieren, Modus setzen. Danach Steuerung deaktivieren um wieder in den "normal" mode zu kommen. |
Replaced hardcoded Modbus control values with named constants for better readability and maintainability. Updated associated logic and comments to ensure consistent use of the new constants. Also added `"skiptest"` to the EVCC requirements in the YAML definition.
Replaced WriteMultipleRegisters calls with WriteSingleRegister to simplify register writing logic. This enhances code readability and reduces unnecessary complexity in setting battery modes. Logging improvements were also added to provide clearer status updates.
… holding the battery in place. Explicitly noted the intentional decision not to disable RS485 to prevent the battery from reverting to Normal mode.
Thank you for this PR. Afaikt by a quick look, there‘s nothing special that would require a Go module here. Could this be implemented purely using templates? |
@andig Ich hatte das Ganze schon mal nur über die Config laufen. Allerdings musste ich für die Steuerung dann einen Umweg über IO Broker Script über HTTP Plugin in EVCC gehen. Um genau zu sein: ich wüsste nicht wie ich die Logik in |
Ja, dafür gibts das |
Removed the Go-based Marstek Venus meter implementation, replacing it with an enhanced YAML-based custom configuration template. The new template simplifies configuration, adds battery-mode handling, and improves flexibility with support for additional parameters and mappings.
Ah das kannte ich noch nicht. Habs angepasst und lokal getestet. Noch was zu tun? |
Updated the scale value from 1 to 0.01 in the Marstek Venus YAML template. This correction ensures accurate decoding of the total charging energy value from Modbus data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @Chris8er - I've reviewed your changes - here's some feedback:
- Consider pulling the hard‐coded control codes (e.g. 21930, 21947) and the fixed 2500 W charge power into named parameters or constants to improve readability and configurability.
- The template defines an
energy
measurement at register 33000, but the PR description and code only mention power, SOC, and mode—please confirm the implementation supports energy or remove it from the template. - Factor out the repeated RS485 Enable/Disable sequence into a shared step or helper to reduce duplication across the three battery modes.
Here's what I looked at during the review
- 🟢 General issues: all looks good
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
Introduced `charge_power` and `work_mode_normal` parameters to allow customization of charge power and work mode settings. Updated Modbus write operations to use these parameters dynamically instead of hardcoded values. Improved flexibility for different deployment scenarios.
Co-authored-by: andig <cpuidle@gmail.com>
Co-authored-by: andig <cpuidle@gmail.com>
Corrected an erroneous space in the variable reference `{{ . maxchargepower }}` to `{{ .maxchargepower }}`. This ensures proper rendering and functionality in the template.
Do we need all these timeouts and delays? If not, please remove. Go version didn't have them? |
The `timeout` and `delay` parameters were removed from multiple modbus register definitions in the `marstek-venus.yaml` file. These parameters were either unnecessary or handled elsewhere, simplifying the configuration. This change helps reduce potential configuration errors and improves maintainability.
The LilyGo is connected to the RS485 port on the Marstek Venus E and provides all the necessary data in Home Assistant (i think with MQTT). However, EVCC cannot use it. |
If LilyGo is a Modbus converter you can use it. If not... not. You can still create a "custom" meter to integrate data over MQTT. |
If I read it correct i first need a modbuss that i can use over wifi? The setup in evcc asks for the ipadress, of the marstek or the modbuss? |
The same question do I also have. The first stats that a device called "PUSR USR-DR134 Modbus TCP gateway" shall be used. However, this is not a unique name/brand to order. |
The evcc documentation specifies that the Marstek Venus battery storage connects via RS485, which can be interfaced using various methods like a TCP Ethernet gateway, TCP WiFi gateway, or a USB-to-RS485 adapter, depending on your setup. The PUSR USR-DR134 Modbus TCP gateway is mentioned as an example (got mine from Amazon), but any compatible RS485-to-TCP gateway should work. However, since evcc supports multiple hardware configurations, I think the docs likely avoid being overly prescriptive to allow flexibility. |
Well, I agreed that the docs mentions RS485 and that - if you are familiar with this - it is clear that an additional device is needed. However, all other devices I integrated in my setup worked directly with using their local IP address for the |
@Chris8er I have an Marstek Venus E und just received an "PUSR Din Rail “Lipstick” RS485 zu Ethernet Server für serielle Geräte Modbus Gateway Modbus RTU nach Modbus TCP Rich Protocols USR-DR134". I would assume that matches the Hardware you used. I now recognized, that the ModBus Connector cable delivered by Marstek is not compatible with the connector on the lipstick, so I assume I have to remove the connector from the Marstek cable and insert the cables directly in the connector of the Lipstick. From the number of cables it should work, but I'm unsure about the order, because I did not found any documentation from the Marstek ModBus Connector. There are just 5 cables (from left to right: red, black, black, red, yellow) and I don't know how to connect. |
I'm not part of the evcc team and can't speak for them. Your issue is hardware-specific and beyond evcc's scope, as it only requires RS485 for the Marstek Venus E. The rest is your responsibility. Modbus isn't as straightforward as web APIs, so some technical knowledge is needed, and since it's not plug-and-play, proceed carefully to avoid issues. Having faced the same challenge connecting the PUSR USR-DR134, I can share a tip. Refer to this post for wiring details (the image shows the connector from the back not front). I cut the white connector from the Marstek cable and wired it directly to the PUSR. Since Marstek's cable colors may vary across batches, use a multimeter to verify the pin connections before wiring. In my case it was: Yellow -> A Black -> Data GND Use this information carefully and at your own risk. |
@Chris8er: Your last reply was very helpful! I now managed to include my Marstek Venus E into evcc with this device: https://www.amazon.de/dp/B09PD5ZD56/ |
I have an additional question. I interprete the code in line 60 (https://github.com/evcc-io/evcc/pull/21487/files#diff-061f0ffca5472bbfa10184a4f4fe0c29ce3bf98874a73f77c1e3a8fe25fd96d5R60) such that evcc is able to control the charging value of the Marstek battery. A variable names |
@DanielGlaas I'm pretty confident, that this is only the setting for the work mode, this does not control the charging in a narrow sense, only work mode: Work mode für Normal-Modus. 0 manuell, 1 Eigenverbrauch, 2 AI-Optimierung. This can be set in the configuration of the battery |
the batterymode definitions enable how evcc can use the active battery control on the device: https://docs.evcc.io/en/docs/features/battery#active-battery-control For some you might need to enable experimental mode in the UI config. So it should be possible to grid load the device on cheap prices with by evcc via UI menu for HomeBattery/Grid Charging Tab also. (batterymode 3 / "Charge") |
Well, in the code for case 3, there are three subsequent modbus write commands:
For me, this looks the battery charging is controlled by evcc. |
@beebee Thanks for the link to the docs. But it does not explain the three modes of To be honest, it still is not clear to me what I have to do. |
Clicking "Battery" in the EVCC menu allows you to configure your battery to charge from the grid (scheduled). This disables discharging and charges the battery at the specified power level (config). The code is used for that. The "work_mode_normal" option in the Venus EVCC settings determines the mode that Venus returns to after being locked by EVCC vehicle fast charge. |
@DanielGlaas : How did you setup the Elfin Device? When implementing the Code in the evcc.yaml with the dedicated adresses it computes error message as it seems, that it cannot access the tcp-server:
in the evcc.yaml:
in general the communication is working with modbus in homeassistant... :-? |
@Chris8er Thank you for the additional details. To sum up, the setup of the Marstek with a shelly meter is necessary, such that it can autonomously decide without evcc when to charge/discharge. |
@tjahebro1 Maybe you compare these parameters with those in homeassistant. |
Yes, you need a meter compatible with Venus to effectively manage battery adaptation to your grid consumption. The cycles in EVCC might be too slow for this purpose anyways. Have you installed a meter? If so, you could potentially use it with Unimeter. I'm using it with my SMA Home Manager 2 in combination with the Venus. |
solved:
it did not work with "rs485tcpip" in my config using the elfin modbus to wifi adapter. changed now to "tcpip". now it seems to work. |
This should be an configuration (assignment) issue. Nothing to do with the Venus integration itself. |
Hmm okey… going to look for a fix, not happend to anyone before? |
Hi, first of all, thanks @Chris8er for the initial integration. I'm wondering if it's possible to have dynamic charging values - currently, it's set to a fixed value from the config. I couldn't find any information in the docs, unfortunately, but I would like to be able to control the charging power, just like when charging the car: Charge the battery if there's enough solar power and/or charge at max power if prices are cheap/co2 is low. |
EVCC does not directly support dynamic grid consumption control, as it primarily integrates batteries to adjust EV charging power. As mentioned, EVCC's cycle concept is too slow for real-time grid management. It mainly handles the scenarios "stop charging during fast EV charging," "prevent battery discharge while charging an EV," and "charge at (config setting) power when prices are low." For broader control, use Venus with a compatible meter. |
For anybody who's using the ha integration through lilygo - you can integrate with the HA REST API like this: power: # current power
source: http
uri: http://YOURHOMEASSISTANT/api/states/sensor.esp_akku_marstek_ac_power
auth:
type: bearer
token: YOURLONGLIVEDACCESSTOKEN
jq: '.state | tostring'
soc: # state of charge in % (for battery)
source: http
uri: http://YOURHOMEASSISTANT/api/states/sensor.esp_akku_marstek_battery_state_of_charge
auth:
type: bearer
token: YOURLONGLIVEDACCESSTOKEN
jq: '.state | tostring' I'm going to add controls later... |
@joernbeutel it doesn't work that way round - you either use the lilygo for a modbus tcp interface + create a modbus tcp proxy with evcc or you connect it to homeassistant using esphome (or whatever home automation you're using) and talk to the esphome API (or Homeassistant, as mentioned above) |
@njoerd114 Ah, THANK YOU!! okay. Either - or. I have it in homeassistant using esphome. Now it is clear that some got it working. Prob. not using esphome... |
I treid to find out using chatgpt. Was advised to put it under meters like this
but obviously is wrong. |
This PR adds support for the Marstek Venus battery storage system via Modbus TCP.
Changes:
See: https://duravolt.nl/wp-content/uploads/Duravolt-Plug-in-Battery-Modbus.pdf (Duravolt = Marstek Venus)
Testing: