Thanks for trying. The Binding has the retry interval to address these issues. It is really more the Marstek Firmware / Device capabilities that seem to be the limiting factor here. I initially had issues already with one device.
Keep us posted on results. I am still planning to release the current version officially, just need to find the time…
Hi,
I tried it, but still it does not work, below the AI feedback with suggestions how to resolve it in the binding.
I am currently testing the Marstek binding 0.2.2-rc1 with six Marstek VenusE 3.0 batteries in openHAB.
My Thing configuration uses separate UDP ports and different refresh intervals:
Thing marstek:battery:mtbl11 "MT_B L1-1" [ hostname="192.168.1.249", port=30000, localPort=30000, refreshInterval=90 ]
Thing marstek:battery:mtbl12 "MT_B L1-2" [ hostname="192.168.1.11", port=30001, localPort=30001, refreshInterval=100 ]
Thing marstek:battery:mtbl21 "MT_B L2-1" [ hostname="192.168.1.13", port=30002, localPort=30002, refreshInterval=95 ]
Thing marstek:battery:mtbl22 "MT_B L2-2" [ hostname="192.168.1.14", port=30003, localPort=30003, refreshInterval=110 ]
Thing marstek:battery:mtbl31 "MT_B L3-1" [ hostname="192.168.1.19", port=30004, localPort=30004, refreshInterval=105 ]
Thing marstek:battery:mtbl32 "MT_B L3-2" [ hostname="192.168.1.251", port=29999, localPort=29999, refreshInterval=120 ]
The Things were not initialized all at once. I enabled them manually with random delays between the activations. Unfortunately, the issue still occurs.
Observed behavior
The binding still produces near-simultaneous requests across several Marstek Things.
In the trace, several Marstek.GetDevice calls are sent within only a few milliseconds:
07:04:01.802 Marstek.GetDevice
07:04:01.839 Marstek.GetDevice
07:04:01.843 Marstek.GetDevice
07:04:01.844 Marstek.GetDevice
07:04:01.859 Marstek.GetDevice
Shortly afterwards, several ES.GetStatus requests are sent almost at the same time:
07:04:01.882 ES.GetStatus
07:04:01.905 ES.GetStatus
07:04:01.940 ES.GetStatus
07:04:01.945 ES.GetStatus
07:04:01.946 ES.GetStatus
07:04:01.960 ES.GetStatus
Most of these ES.GetStatus calls then run into retry loops up to retries: 15.
Example pattern:
Send/resend Package ... method ES.GetStatus retries: 0 timeout 250
Send/resend Package ... method ES.GetStatus retries: 1 timeout 500
Send/resend Package ... method ES.GetStatus retries: 2 timeout 1000
...
Send/resend Package ... method ES.GetStatus retries: 15 timeout 1000
No Response for ...
Error querying energy system status: Timeout ...
While those retry chains are still active, the binding already starts new refresh cycles for other Things.
Why I think this is a binding-level concurrency issue
The devices were manually enabled with random delays, so this does not appear to be only a startup synchronization problem.
The trace suggests that the binding still allows:
multiple active Marstek API requests at the same time
multiple parallel ES.GetStatus retry chains
new refresh cycles while previous retries are still active
This can create a request storm, especially with multiple VenusE 3.0 devices.
From the device side, Marstek.GetDevice often still responds successfully, but ES.GetStatus tends to time out. After the timeout, the binding continues with other calls such as ES.GetMode, EM.GetStatus, and Bat.GetStatus.
Suspected effect
The Marstek devices appear to become unstable or unresponsive when this happens. My suspicion is that the binding overloads the devices’ local UDP/API implementation by sending too many parallel requests and retries.
Suggested improvement
I think the binding would need a binding-wide request serialization mechanism, not only per Thing.
Possible approach:
Global FIFO request queue across all Marstek Things
Only one active UDP/API request at a time
Configurable minimum delay between requests, e.g. 1000–2000 ms
Do not start a new refresh while a previous refresh/retry chain is still running
Skip refresh if the previous one is still active
Use retry backoff after consecutive ES.GetStatus timeouts
Optionally pause a device for some minutes after repeated timeouts
In other words, the binding should avoid this pattern:
Thing 1 -> ES.GetStatus retry loop
Thing 2 -> ES.GetStatus retry loop
Thing 3 -> ES.GetStatus retry loop
Thing 4 -> ES.GetStatus retry loop
...
and instead enforce something like:
Thing 1 request
wait
Thing 2 request
wait
Thing 3 request
wait
...
Question
Is there already any hidden/configurable mechanism in 0.2.2-rc1 to enforce global request serialization or a minimum request gap across multiple Things?
If not, would you consider adding a global Marstek API queue / rate limiter to prevent overlapping request and retry chains?
I can provide the full TRACE log if needed.
Hi.
Not sure I follow the reasoning of the AI, it is not explaining why this happens on one device and not all, and why not if there is only one device. A request storm happens between the binding and the device, so unclear why happening with many devices.
The binding did have longer times between requests initially, to actually fix this problem, response from the battery. The PR changed that to be more dynamic and shorter if no issues, but getting longer if responses do not come in. I can have a look if that can be adapted to get slower via a setting.
Hi Achim,
It does not happen to one single device, its random which device will fail first, as more devices fail as longer it takes that the next device will fail.
→ This makes me thinking that the AI’s reasoning might go in the correct direction.
If somehome possible the binding should only request the device status device by device and not in parallel, it should be avoided solving issues with timings.
Alternative i would appreciate if Marstek could deliver a proper firmware for their devices, than all this work arounds would not be required.
I’ve not tried to build a binding on my own, but I would give it a try. No idea how complicate this is…
I’ll try now a workaround.
I’ll only always activate/deactivate 3 of 6 storages every minute. Assuming that the stopps requests when a thing gets deactivated. If that solves my issue it would be proove of the theory.
I’ll update you in two or three days
@Michael_Paier
I asked AI to fix the issues, here an untested version with those fixes. - Release Beta fix mutli devices · acfischer42/openhab-addons · GitHub
Let me know how this works.
Thanks a lot!
I’ll install it tomorrow evening - I don’t want to interrupt the actual test (as descriped above)
Short feedback:
I stoped now the testing with alternating three storages. This was working as expected - 3 days without any issue.
I installed now your beta. - The Basic function seems to be functional as expected. I’ll provide a update in a few days. - Thanks again a lot!
BR
Michael
@Michael_Paier - do you have testing results?
I just discovered there is a api 2.0 released and wanted to know where to start from for integrating that.
thanks
Achim
Hi Achim,
I’ve been testing it, but there is no big change in the behaviour. It seems, that my method and your new version do basically work as expected, but the result is the same - the storages stop working - but a bit later maybe its now 3 to four days…
I’m about to stop working on that, I’ve started the discussion with the distributor to take back the storages as they don’t work as specified.
I’ll search for a different sollution, most likely a third Huawei Inverter with a Luna Storage…
Thanks for your efforts, but the Marstek SW is too buggy for going on with that.
BR
Michael
Hi Achim!
Since yesterday I have a brand new Marstek Venus E v3 and installed it instantly to see, if it works and it does. I use it as an extension to our existing SolarEdge plant with an LG storage.
Then I installed the beta version 0.1 of your binding and it was activated smoothly. I linked items to all channels and got data from several channels:
Some items keep staying empty.
Today I installed the SNAPSHOT version 5.2.0.202601091712 to see, if some more data is coming up and to try if I can update some values. I am especially interested in updating the switches for charging/discharging permitted, but they are still not updating the Venus.
Do you have a list of channels that should work? Are there already update channels provided?
Thank you for your work!
Regards Christoph
Looks good to me. The items that are empty are the pv ones that are not supported by that model,no?
You can set charging mode and power as described in the readme. With this you can turn charging on and off.
The api is limited and recently changed to 2.0. O didn’t have time to check that out yet.
Which firmware version are you on?
Sorry. This is what I meant. There are the command to send in there.
I recently have massive problems when local api is activated. Battery crashes, forgets settings, etc. Also on v148. Just a watch out
Ah, thanks!
Since yesterday I also have suspicious situations in the App.
- Manual mode still active, but without timer settings. This combination should not be allowed by design a.f.a.i.k.
- I enter new timers and apply the changes. At first the Venus does like expected, but later it is inactive and the timers are gone.
- It looks as if the only stable mode is manual (Eigenverbrauch).
I tried to use the manual mode to check settings to set later via openHAB, but now it is unusable.
I think I will try a different approach by manipulating the incoming data from uni-meter in a OH rule. Actually I have the SolarEdge inverter as input device. I started to test MQTT as input instead. If that works, the Venus will stay in auto mode.
Regards Christoph
Sometimes the Local API is unpredictable switched off…
Hi !
Does anybody have the value in batteryPower ? i think this is an important value to have
Ciao Gerd