Hi there would it be possible to also configure the local binding port? My Venus 2.0 only seems to be answering to Port 30000 (the one set up as port) therefore i alsways get a “Connection test failed: No response from device at 192.168.x.y:30000” The local binding port is hardcoded to 0. it would be great if i could just set it to 30000 in the config of the thing
Hi, not sure i understand. Port 30000 is the port the binding is using.
I think i have not made myself cleat. Let my try again:
Lets say OpenHAB run on Computer A with IP 192.168.1.1 and the Venus runs on IP 192.168.1.199. Then A open a random Port to recieve the response from Venus. Lets assume it picks 12345 then A sends a Packet from 192.168.1.1:12345 → 192.168.1.199:30000 my Venus seems to either respond to 192.168.1.1:30000 or does not respond at all if the source port ist 30000. I would therefore like to use port 30000 on both sides.
The local Port is a paramater of the function sendRequest in MarstekUdpHelper.java it is called for example openhab-addons/bundles/org.openhab.binding.marstek/src/main/java/org/openhab/binding/marstek/internal/marstekHandler.java at 17397d2e40c11ea1bea82ea48a15dfb64bd382f1 · acfischer42/openhab-addons · GitHub
It would be great if you extend the config by a localPort wich can be 0 by default but can be set to 30000
Ok. Understood. Will put it on the improvement list.
Like @Fdewaele I would like to send commands to the Marstek Venus E Gen 3.0 to charge/discharge a specific amount given the production and electrical voltage I’m reading from my electricity meter.
Does it work correctly ? Or is the device updating erraticaly ?
Thank you
lamaZZe
As far as I know the device is updating. The Battery is sensitive to fast updates, so I would not recommend to go below 10 seconds for sure.
This is not my use case, so all you have is to try it out. Use the beta posted above.
Ive submitted a PR with support for a local binding port and a constant datagram socket instead of creating one for every request. I also added a retry mechanism in case the venus does not update. With this the connection seems much more stable and reliable with my venus 2.0
Thanks. Will try to find the time to include.
Releases · acfischer42/openhab-addons · GitHub - Marstek 0.2.2-rc1 Pre-release
Note: I am NOT getting faster responses with this. Do you? Default port is still “0”, but in thing configuration the port can be set.
Hi, the response is a a little bit faster in my case but the main thing ist that the refresh often failed before with my venus 2 because the fixed 1 second delay sometimes was not enough. In other cases the 1 second delay was not needed. With the new retry mechanism it does not fail anymore.
Request and response are retried until success.
I also removed the in my case unneeded warmup request with the additional 1 second delay.
The default local port is set to 0 but can be set. For the venus 2 it seems, that i need to set it to be the same as the remote port.
Thanks! I could also successfully connect to a Venus 2 with the latest version 0.2.2-rc1 of the binding by setting the local port to 30000.
I also set up the communcation via Modbus and will check now what is more reliable 
Continuing the discussion from [Marstek Energy Battery Binding 5.0.0.0;6.0.0.0):
Dear All,
I started a small projekt and installed 6 Venus E 3.0 (2 per Phase). All storages are reacting on the Passive Power Commands. But just one of the Storages is “ONLINE” according to Openhab, the other ones are reporting a “ERROR: COMM” error - but they are reacting.
At the moment all of them are running on the default Port 30000, but the are of course separated via the (fixed) IP-Adress, all of them are connected to Ethernet.
The problem is - I only get one temperature and not from all 6…
Thanks a lot for any Help!
I have only two Venus devices. one 2.0 and one 3.0 i use different ports for each device but noticed a strange behavior. When both of them are connected to the same network, after about 30 seconds to 60 seconds one device seems to reboot or looses the wifi connecteion. First all three leds went on (ct, wifi, bt) and then all of them turned off. After a while the wifi came on again but the CT stayed off. I then could not reach the device via the API. Maybe your problem is similar ?? I “solved“ it by using an additional router with its own network on one of the devices. That also meant that i could not connect the CT to the second device.
What i am doing now is the to set the first device in auto mode and control the second one via the passive mode every 10 seconds. That is not ideal but the best i could manage so far.
@matzet , so both show online for you?
I only have one device, so it is a bit difficult for me to test.
@Michael_Paier, could you set the log to debug and send logs to me? Log level can right now only be set via command line. Don’t know why the UI does not work at the moment. Marstek (at) fischernet (Punkt) net
Yes both of mine are online, but as i said they are connected to different networks with different ip-adresses. To reach the second one i had to set up a portforwarding on the additional router.
Hi, I changed now all Ports, so each Storage has now it own port number.
One of my storages didn’t remember the settings, but today - after having it switched of over night - everything is working as expected.
BR
Michael
Stupid question (I never did that before).
To update a beta version: Just delete the old jar file in the addons folder and place the newer one there?
To update from beta to regular version: Just delete the jar completely from the addons folder and install the binding via “addons” in OH Main UI?
Is that correct? Something to do additionally? (yes, backup ;-))
Sounds about right. In some cases you will need to recreate the thing as well. If the new version has new channels for example they don’t show in the thing unless recreated (I think)
Currently the Beta is the newest version still. There is no release yet of the latest status.
Thanx for your reply! Does anyone know when a Release could be expected?
Dear All,
My setup with 6 Marstek Venus E 3.0 is basically working well, but after a certain time (24 to 32 hours) one of the storages (always a other one) goes offline.
Im not sure if this a problem of the storages or the binding (V0.2.2 -rc1). There for I attached a snippet of a log, hope that helps…
One mor interssting thing, for the logging settings i had to use
org.openhab.addons.reactor.bundles
I also could provide the whole 20MB file if that helps!
In this trace the storage with the IP 192.168.1.19 is affected
2026-05-16 05:41:54.541 [TRACE] [-36-36c] - received Packet: 259 bytes 259, content: { "id":"e0f1cf4462ab6c4b643ad9d2bc", "src":"VenusE 3.0-a8dd9fd8ced7", "result":{ "id":"e0f1cf4462ab6c4b643ad9d2bc", "soc":18, "charg_flag":true, "dischrg_flag":true, "bat_temp":8.0, "bat_capacity":921.0, "rated_capacity":5120.0 } }
2026-05-16 05:41:54.541 [DEBUG] [-36-36c] - Received response e0f1cf4462ab6c4b643ad9d2bc from /192.168.1.19
2026-05-16 05:41:54.541 [TRACE] [-36-36c] - Battery response (259 bytes): { "id":"e0f1cf4462ab6c4b643ad9d2bc", "src":"VenusE 3.0-a8dd9fd8ced7", "result":{ "id":"e0f1cf4462ab6c4b643ad9d2bc", "soc":18, "charg_flag":true, "dischrg_flag":true, "bat_temp":8.0, "bat_capacity":921.0, "rated_capacity":5120.0 } }
2026-05-16 05:41:54.541 [DEBUG] [-36-36c] - Successfully parsed Bat.GetStatus result
2026-05-16 05:41:54.542 [DEBUG] [-36-36c] - marstekHandler refresh finished
2026-05-16 05:42:09.001 [DEBUG] [-36-36c] - marstekHandler refresh false
2026-05-16 05:42:09.001 [DEBUG] [-36-36c] - Send/resend Package: 38e37f469684a2d7e2957645ca retries: 0 timeout 250
2026-05-16 05:42:09.002 [TRACE] [-36-36c] - Sent Message: {"id":"38e37f469684a2d7e2957645ca","method":"Marstek.GetDevice","params":{"id":"38e37f469684a2d7e2957645ca"}}
2026-05-16 05:42:09.100 [TRACE] [-36-36c] - received Packet: 222 bytes 222, content: { "id":"38e37f469684a2d7e2957645ca", "src":"VenusE 3.0-a8dd9fd8d15c", "result":{ "device":"VenusE 3.0", "ver":148, "ble_mac":"a8dd9fd8d15c", "wifi_mac":"", "wifi_name":"", "ip":"192.168.01.251" } }
2026-05-16 05:42:09.101 [DEBUG] [-36-36c] - Received response 38e37f469684a2d7e2957645ca from /192.168.1.251
2026-05-16 05:42:09.101 [DEBUG] [-36-36c] - Send/resend Package: 83765b47b6995f56e87199ede4 retries: 0 timeout 250
2026-05-16 05:42:09.101 [TRACE] [-36-36c] - Sent Message: {"id":"83765b47b6995f56e87199ede4","method":"ES.GetStatus","params":{"id":"83765b47b6995f56e87199ede4"}}
2026-05-16 05:42:09.351 [DEBUG] [-36-36c] - Send/resend Package: 83765b47b6995f56e87199ede4 retries: 1 timeout 500
2026-05-16 05:42:09.351 [TRACE] [-36-36c] - Sent Message: {"id":"83765b47b6995f56e87199ede4","method":"ES.GetStatus","params":{"id":"83765b47b6995f56e87199ede4"}}
2026-05-16 05:42:09.851 [DEBUG] [-36-36c] - Send/resend Package: 83765b47b6995f56e87199ede4 retries: 2 timeout 1000
2026-05-16 05:42:09.851 [TRACE] [-36-36c] - Sent Message: {"id":"83765b47b6995f56e87199ede4","method":"ES.GetStatus","params":{"id":"83765b47b6995f56e87199ede4"}}
2026-05-16 05:42:10.852 [DEBUG] [-36-36c] - Send/resend Package: 83765b47b6995f56e87199ede4 retries: 3 timeout 1000
2026-05-16 05:42:10.852 [TRACE] [-36-36c] - Sent Message: {"id":"83765b47b6995f56e87199ede4","method":"ES.GetStatus","params":{"id":"83765b47b6995f56e87199ede4"}}
2026-05-16 05:42:11.852 [DEBUG] [-36-36c] - Send/resend Package: 83765b47b6995f56e87199ede4 retries: 4 timeout 1000
2026-05-16 05:42:11.852 [TRACE] [-36-36c] - Sent Message: {"id":"83765b47b6995f56e87199ede4","method":"ES.GetStatus","params":{"id":"83765b47b6995f56e87199ede4"}}
2026-05-16 05:42:12.591 [DEBUG] [-36-36c] - marstekHandler refresh false
2026-05-16 05:42:12.591 [DEBUG] [-36-36c] - Send/resend Package: 14f0dd4ecfad1e2c8857c9b256 retries: 0 timeout 250
2026-05-16 05:42:12.592 [TRACE] [-36-36c] - Sent Message: {"id":"14f0dd4ecfad1e2c8857c9b256","method":"Marstek.GetDevice","params":{"id":"14f0dd4ecfad1e2c8857c9b256"}}
2026-05-16 05:42:12.691 [TRACE] [-36-36c] - received Packet: 221 bytes 221, content: { "id":"14f0dd4ecfad1e2c8857c9b256", "src":"VenusE 3.0-a8dd9fd8e655", "result":{ "device":"VenusE 3.0", "ver":148, "ble_mac":"a8dd9fd8e655", "wifi_mac":"", "wifi_name":"", "ip":"192.168.01.11" } }
2026-05-16 05:42:12.691 [DEBUG] [-36-36c] - Received response 14f0dd4ecfad1e2c8857c9b256 from /192.168.1.11
2026-05-16 05:42:12.692 [DEBUG] [-36-36c] - Send/resend Package: b0e2184ba7b06162f40ee5b4a7 retries: 0 timeout 250
2026-05-16 05:42:12.692 [TRACE] [-36-36c] - Sent Message: {"id":"b0e2184ba7b06162f40ee5b4a7","method":"ES.GetStatus","params":{"id":"b0e2184ba7b06162f40ee5b4a7"}}
2026-05-16 05:42:12.852 [DEBUG] [-36-36c] - Send/resend Package: 83765b47b6995f56e87199ede4 retries: 5 timeout 1000
2026-05-16 05:42:12.852 [TRACE] [-36-36c] - Sent Message: {"id":"83765b47b6995f56e87199ede4","method":"ES.GetStatus","params":{"id":"83765b47b6995f56e87199ede4"}}
2026-05-16 05:42:12.942 [DEBUG] [-36-36c] - Send/resend Package: b0e2184ba7b06162f40ee5b4a7 retries: 1 timeout 500
2026-05-16 05:42:12.942 [TRACE] [-36-36c] - Sent Message: {"id":"b0e2184ba7b06162f40ee5b4a7","method":"ES.GetStatus","params":{"id":"b0e2184ba7b06162f40ee5b4a7"}}
2026-05-16 05:42:13.442 [DEBUG] [-36-36c] - Send/resend Package: b0e2184ba7b06162f40ee5b4a7 retries: 2 timeout 1000
2026-05-16 05:42:13.442 [TRACE] [-36-36c] - Sent Message: {"id":"b0e2184ba7b06162f40ee5b4a7","method":"ES.GetStatus","params":{"id":"b0e2184ba7b06162f40ee5b4a7"}}
2026-05-16 05:42:13.852 [DEBUG] [-36-36c] - Send/resend Package: 83765b47b6995f56e87199ede4 retries: 6 timeout 1000
2026-05-16 05:42:13.853 [TRACE] [-36-36c] - Sent Message: {"id":"83765b47b6995f56e87199ede4","method":"ES.GetStatus","params":{"id":"83765b47b6995f56e87199ede4"}}
2026-05-16 05:42:14.326 [DEBUG] [-36-36c] - marstekHandler refresh false
Thanks a lot for your help
I asked the AI for help too
With multiple VenusE 3.0 devices, ES.GetStatus timeouts create overlapping retry chains.
While retries for one device are still running, the next refresh cycle starts for another device.
This appears to overload or lock up the Marstek device/API.Observed:
- Marstek.GetDevice responds
- ES.GetStatus does not respond
- Binding retries ES.GetStatus repeatedly
- Next marstekHandler refresh starts before previous retry chain is finished
- Multiple devices involved: 192.168.1.251, 192.168.1.11, 192.168.1.19
I will increase the thing refresh intervall, and even try to delay the thing initialisation. Would be greate. If this helps we should know if the AI is right, hope that the binding could be updated to resolve it