Marstek OpenAPI

[eddieb]

Marstek released a new version of there App which allows us the enable OpenAPI
in the App there is a link to the documentation,

see https://resource.marstekenergy.com/ems/ ... penApi.pdf

Anyone tested this and was able to get this into domoticz ?

[waltervl]

Someone already has written an HA integration, there is a python test and discover script that can be run to see if it is working. That script could be updated to a Domoticz python plugin....
https://github.com/jaapp/ha-marstek-loc ... aster/test

[eddieb]

I hope someone will create a domoticz plugin for this, I am not a python programmer...
If someone does, I would be happy to test

[willemd]

Someone already developed a MQTT bridge for the Marstek Venus A. You should be able to use that and connect it to the Domoticz MQTT plugin. No need for a dedicated Domoticz plugin.
https://github.com/IvanKablar/marstek-venus-bridge

[willemd]

I did now try to install that MQTT bridge myself for the Marstek Venus A that I bought. It works but it publishes a JSON and the control functions (to change operating mode) are not implemented fully, although the framework is include in the API.

So a mapping from JSON data fields to Domoticz devices still has to be done and also the control functions would need to be implemented.

Therefore I am now starting on the development of a full Domoticz plugin, reusing the API but without the MQTT broker. Should not be too difficult given the API library is already available.

[eddieb]

@willemd I am interested and would like to see if this also works on a Marstek Venus E, as we are able to enable that api port there to ...
I looked at that github page but I dont like the idea of the api poller and the mqtt in one container ...

[willemd]

@willemd I am interested and would like to see if this also works on a Marstek Venus E, as we are able to enable that api port there to ...
I looked at that github page but I dont like the idea of the api poller and the mqtt in one container ...

Should work for the Venus E since it is the same API. I already had a MQTT broker running so I slightly adapted the bridge installation to use the existing broker. But I think the plugin will not use the MQTT broker, it will just use the API functions. I will publish on github once available, should not take too long.

[eddieb]

Should work for the Venus E since it is the same API. I already had a MQTT broker running so I slightly adapted the bridge installation to use the existing broker. But I think the plugin will not use the MQTT broker, it will just use the API functions. I will publish on github once available, should not take too long.

I do have a spare domoticz running in a docker environment on a rpi5 so I should be able to test your code ...

[willemd]

Should work for the Venus E since it is the same API. I already had a MQTT broker running so I slightly adapted the bridge installation to use the existing broker. But I think the plugin will not use the MQTT broker, it will just use the API functions. I will publish on github once available, should not take too long.

I do have a spare domoticz running in a docker environment on a rpi5 so I should be able to test your code ...

Thanks

The first version of the plugin has now been uploaded to github. It has been tested in my environment with one Marstek Venus A.
https://github.com/WillemD61/Marstek-Venus-plugin

It will collect data onto 42 domoticz devices and you can change operating mode using a selector switch. For manual and passive mode it will pick up data from domoticz devices that hold configuration data for these modes.

Additional info described on github.

[eddieb]

Although I enabled local API on port 30000 I get timeouts ....

Timeout waiting for response from 192.168.0.155:30000

Alle devices are created, none is updated ...

[willemd]

And you are sure you filled in the correct IP address of your Marstek?

What if you use the provided test programs to run all the API commands? Note those use the config.json file to pick up the IP address so you need to fill it in there as well. If needed you can turn on extended logging in the venus_api_v2.py file by uncommenting the relevant lines.

No firewall or other security setting getting in the way?

[eddieb]

Yes,
I am pretty sure I entered the corrext IP ...

The test code gives me the same results ...
Timeouts

[willemd]

if you have enabled Open API, it must be a network issue, or the device itself.

Can you ping the IP address? Or from a linux command line, if you use arp -v followed by the IP address, you should get back the mac address. In that way you can verify you have the correct device.

What type of system is it? Firmware version? Does it support Open API?

By the way, a new version is already available for corrected handling of electric/kW/power devices.

[eddieb]

- yes I can ping it ...
Venus E (MST_ACCP_3393)
V153
Local API enabled
I can read it with https://rweijnen.github.io/marstek-venu ... or/latest/

Code: Select all

⚡ Runtime Information [19:53:54]
Backup Power: 0 W
Battery Power: 0 W
Work Mode: 1 (Standby)
Status Flags B/C/D: 1/1/1 (0x01/0x01/0x01)
📡 Connections: None
🔧 System: Idle
⚠️ Error State: Meter Disconnect
Product Code: 0x0099
Power Rating: 1035 W
Daily Charge: 0.07 kWh
Daily Discharge: 0.05 kWh
Monthly Charge: 27.368 kWh
Monthly Discharge: 21.50 kWh
Total Charge: 726.20 kWh
Total Discharge: 579.54 kWh
Firmware Version: v5.1
Build Code: 215
Firmware Build: 2024-09-09 01:59
Cal/Variant Tag 1: 61955
Cal/Variant Tag 2: 356
Reserved/Counter: 3
Parallel Machine: OFF (0)
Generator: OFF (0)
Local API: ENABLED (Port: 30000)
Device Type: 1035W Battery System

[willemd]

That tool communicates over bluetooth low energy, so is not valid comparion/reference.
I cannot use that tool because it requires Venus E or CT002, but I can connect over wifi and use UDP.

Maybe the API for Venus E is different. The specification seems to be generic but does mention at the end that certain devices might respond differently. The chapter detailing that further still has to be written....

My guess is that it is still a network related issue. It would surprise me if all the UPD commands would be different and fail.

[eddieb]

Is it neccesary to reboot the Venus after enabling local api ?
I did enable it a while ago but perhaps it did not reboot after that

[willemd]

Is it neccesary to reboot the Venus after enabling local api ?
I did enable it a while ago but perhaps it did not reboot after that

Normally no, I have switched it on several times when it was reset due to communication overload during development of the plugin.
Then again , probably does not hurt, worth a try.

[eddieb]

Need more time for this.
I tried to disable local api and that gives an error ...
still no ears on 30000/udp

[esflint]

I tried it with a Venus C 2,5kWh and get this error:

2026-02-14 11:13:11.170 Marstek Venus C: es status data receivedNone
2026-02-14 11:13:14.060 Error: Marstek Venus C hardware (7) thread seems to have ended unexpectedly

[willemd]

I tried it with a Venus C 2,5kWh and get this error:

2026-02-14 11:13:11.170 Marstek Venus C: es status data receivedNone
2026-02-14 11:13:14.060 Error: Marstek Venus C hardware (7) thread seems to have ended unexpectedly

Did you enable local Open API in the Marstek app?

Even then, there are frequent timeouts in the UDP communication with Marstek, but the plugin handles that well.

Each data retrieval round there are 6 different data collection statements issued, for different types of data. Each is allowed 3 timeouts and if nothing is received it returns "None". A new cycle is started after the defined heartbeat interval. But Domoticz will raise that "thread seems to have ended unexpectedly" error. It will not crash, it will continue, so consider it a warning.

In the latest version (which I will publish this afternoon, edit: done now): If all 6 statement fail, then a cyclecounter is updated and after 3 cycles it will put an additional error message in the log and you will receive an email (if configured in the startup options). Usually it means that the local Open API has been disabled and you need to enable it in the Marstek app again. Once enabled and once communication is receiving data again, you will get a message that communication has been restored.

So it is quite robust, although those "thread" messages might give another impression. Mine has been running a few days now without interruptions.

But maybe the Venus C Open API behaves differently from the Venus A? It should not, but .....