I just tried on my Venus A.

Disabling Open API also in my app results in a device config error, after about 5 seconds (I tried a few times). Enabling is no problem though.

I trust you know what you are doing, but just to be sure..... when you state tested on UDP/30000 I assume you mean IP/3000, so you tested on your Marstek IP address and port 30000 ?

Especially the fact that you get configuration errors when using the App I find strange. Are the other app function ...

Did you run the scan for other ports than 30000?

Your two screenprints still show an active notification. Did you select the notifcation and then press delete? Or did you press clear in the bottom right corner?

They both work on that port. I also checked the connection with Postman but get no response from the battery.


As an alternative, you could also try this
https://github.com/tomquist/hame-relay
This basically communicates with the cloud (so not using local API) in the same way the Marstek App ...

No, these battery systems use UDP for the local API (unfortunately)

Configuration for telegram is in the settings.

notifications can then be sent from many places, for example
1) from a device directly
2) from a plugin
3) from dzvents
4) using a json command

And does the plugin and API work on that port?

You can try to run

sudo nmap -sUV IPaddress -p 30000

or, to scan a range of ports:

sudo nmap -sUV IPaddress -p 28000-30000

(filling in your IPaddress of course)

and see whether it report the port open/filtered or closed.

On my system it comes back with the port open and reports the MAC ...

Meanwhile I updated my plugin to 1.0.4

I tried to power down my Venus E v2 but after holding the powerbutton for about 10sec it powersdown and immediatly powers up again ...

Still no luck

And after that, re-enabled the API I assume?

I am sorry, I cannot help any further. If it is not a ...

waltervl wrote: Saturday 14 February 2026 16:34 As stated on the section above the device table python device update commands follow in general the API update rules.
No idea what nvalue does for P1, I think it is ignored but needs a valid numeric value eg 0.

Yes, tested, nValue 0 or actual power does not make a difference.

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

I see that a line has been added to explanation of type 250 as follows:

250 P1 Smart Meter 1 Energy nValue=0, sValue="USAGE1;USAGE2;RETURN1;RETURN2;CONS;PROD" see for more info Domoticz API/JSON URL's#Electricity P1 smart meter

That should do it, since that is the normal and working update ...

Did you check and test ?

The wiki is still incorrect.

The wiki still mentions
Devices[Unit].Update(nValue=nValue, sValue="USAGE1;USAGE2;RETURN1;RETURN2;CONS;PROD;DATE") and
DATE = date with %Y-%m-%d format (for instance 2019-09-24) to put data in last week/month/year history log, or "%Y-%m-%d %H ...

So the actual counter values are both correct.

I know I am not answering your question (you can easily find out the answer by making some changes), but I would personally put the old house values on a separate device and keep that for history.

And start building up new data for the new house on a ...

I created an issue on github to get the wiki corrected. Gizmocuz has already seen it.

The second field is the daily usage, the third field is the counter. In order to keep the dbase consistent those values should normally match from day to day. But I know even a domoticz error in the daily closing routine makes those values inconsistent (last 5 minutes is missing in the second field ...

Well, after a full afternoon trying to get this to work, it turns out that you should NOT include a date in the sValue.

So the wiki is wrong. If you include a date the values shows "Invalid!".

As the error message originates from Domoticz itself and not from the plugin, I wonder whether I could receive a recommendation from the Domoticz community.
What can happen when Domoticz forks a thread ?
What can cause "Error: xxx hardware (x) thread seems to have ended unexpectedly " ?

I know ...

Sorry, I have to leave further investigation to the developer of the plugin.