Update. So far so good. One time connection issues, turned off API and now using simulated Shelly Pro 3EM from Homey. No errors or time outs from that point on.
Hello,
I have a problemāperhaps someone here has some experience with this.
I am using a Marstek Venus C together with a PUSR DR134.
I am able to read values āā(specifically address 32104: battery charge status) using Modbus Poll, but whenever I try to connect via the app, I consistently get a timeout error.
Could the issue lie with the DR134?
I tested it in Home Assistant, and the communication and integration work there.
Solved: Unfortunately, it only works with the Elfin EW adapterāwith that, the storage is recognized immediately.
So, unfortunately, the DR134 does not work!
DR134 use RTU/ASCII over TCP/IP and elfin use TCP/IP
Hi! Iāve read the entire thread, but it seems like Iām the only one with a Venus D. Unfortunately, I havenāt been able to connect Homey to my Venus D on latest firmware 142. Iāve tried:
-
Connecting via local api, where my Marstek was connected via ethernet on the same LAN. āConnection failed: connect ECONNREFUSED 10.0.0.110:502ā. Also tried Slave ID 1, 2 and 99 (Geminiās suggestions).
-
Connecting via RS485 (yes, on the other connector on the Marstek) with a Waveshare RS485 TO POE ETH (B). The RS485 was fully accessible via the network, but linking to the Marstek was not successful. Iāve connected the orange to 485A, orangewhite to 485B and brown to GND. Tried switching A and B, also with the different Slave IDās, but nothing worked. Only timeouts. The green LINK-light on the photo is dimmed and is exactly in this state when nothing is connected. Also tried different baudrates of 9600 and 115200. And some other stuff Gemini came up with. No luck.
Any help would be greatly appreciated. Thank you!
Edit: also asked Marstek if there is a chance they could push the latest firmware to my battery, although it says it is up-to-date.
Edit2: within 3 minutes after asking support the 147 update appeared. Iām going to try that first 
Canāt wait to hear that result.
Based on my quick research it seems the D has some differences in the modbus registers, so that could be the cause.
I want one myself, but itās low on my prio so far.
Iāll see if I can make it blind.
Okay, first results
Updating to 117.114 went fine, with only bluetooth and wifi connected, and ethernet disconnected.
Updating further to 117.115 didnāt work. It says the update was successful, but after refreshing the same update appears again.
But I thought it was worth to try 117.114 (vs the old 142.x). And yes, it worked!
The flow-card initially didnāt work, but without doing anything else, a little later it did work! So far Iām happy, and this is exactly what I wanted 
thanks Kaoh!
PS. I checked your Homey apps if there was a link to buy you a beer, but there is no linkā¦
Cool very good to hear it is working. Let me know if there are capabilities not working.
And indeed, I dont take gifts other than new devices
I do this for my own fun and entertainment and for devices I buy. And prefer to keep it with no strings attached 
Thanks, appreciate it! It fully works
Hi Kaoh! My āone week reviewā:
The app is stable and all information is updated correctly in Homey. Soon I will connect some solar panels directly and see if that is visible too.
But, there is one thing:
See the graph below. Blue line is target power, purple is the actual readout from modbus (and verified in my P1-meter. The modbus values are correct). The output power regularly drops to 0. I now run a frequent check to set it back to the target power, but I donāt understand why it happens. It isnāt a Homey command (I think) and it occurs most often with charging the battery. Temperatures of the battery are fine. It does happen with discharging too, but only once in a while. Does anyone else recognise this behaviour?
I also tried to set the target power frequently, but with no visible difference.
I noticed that myself today, itās a big I introduced recently, fix itās already on its way. I attempted to reduce the amount of writes to the modbus but now I miss the keep alive timer, so it shuts off.
At 3:37 this morning v1.3.5 was installed, but I havenāt noticed any improvement yet. Still regular drops to 0 when charging. Can I provide you with any logging or diagnostics?
Please do
new version on the way to include missed modes that need the same fix.
Installed! Charging will start at 10:00, so I will get back to you this afternoon
Itās still there, although it seems more regular. Within 10 seconds accurary, the dips occur around 700 seconds after eachother. Maybe that helps tackling the problem.
(FYI: the Marstek-graph is now blue, because the target power graph is stable at 1500, so there are no data points in this timeframe)
please confirm this scenario:
A second control surface polling on its own schedule could explain such a regular 700s heartbeat just as well as a firmware countdown.
So if you have another modbus client that fails to send the hearthbeat it could be that that is what is causeing the remaining dips in your case.
If not, please send me a new log with the latest app.
Thank you again for your help. Your app is the only one that could control the Marstek or any modbus device. I donāt have Home Assistant or anything else running. There is no schedule active on the Marstek. Firmware is 147.114.104.116.
2bb46e8f-96c3-450e-ad63-822d024dc4a5
Can you try the new test version?
Marstek Energy Storage | Homey
Just installed it. Next charging session will start tomorrow at 10. Will get back to you tomorrow
Hello everyone, I had an EW11 running on a Marstek Venus E v2 for months, allowing me to control the battery with the great app on Homey Pro 2019. Now I am trying to get the EW11 working again after installing a new router with a new Wi-Fi name; I have done everything exactly the same as last time. Unfortunately, I canāt get it paired with Homey. Is there anyone who can help me get back on track? Kind regards, AndrĆ©
