I’ve sent it off. It’s a shame, as it’s never fun having to roll things back. It is disappointing that there turned out to be such a significant difference between the versions; it had been running like a dream over the past few weeks. One thing I did notice, though, is that while you are reporting a connection error, the device remains available, which makes it look in the GUI as if everything is still working. That might be a deliberate choice on your part, of course, but it did catch my eye.
d329a26a-d006-44b9-b98b-8f8e5a4dbb03
@koahkoah same here (still)
All reports I got where on .13 I just released the .17 that was in test for the last week.
Be aware the V3 will hate me releasing this version again at least for X hours.
So dont panic and hold your breath, I hope its dpeloyed and back alive by the time the sun is producing for your Homeys.
I added some chnges to the code that hopefully helps future updates to not hang the V3 for a couple fo hours after a release or restart. Fingers crossed.
And I really hope this version gets your readings going, its a uphill battle for the V3 UTP based modbus support, I might have to tell you all to just go and get a modbus gateway, they are rock solid for every release, its only the native UTP support that is just very… unstable… for lack of a word I am allowed to tpe 
Hello,
Last night, I automatically received the update to version 1.5.17. Since then, I have been experiencing issues retrieving data from my 2 x Venus E v3 and 1 x Venus D batteries.
After a few hours, 2 out of the 3 batteries recovered automatically. However, after restarting the app, I no longer receive live data from any of the 3 batteries.
I also do not see any indication that the batteries are offline in the device status section in Homey.
Kind regards,
Dave
Like I stayed over and over, the marstek utp modbus support is terrible in losing connection, it holds the connection locked for hours. So every update and restart causes those batteries to lose connection. I have not found a way to handle this.
None of the gateways have this behavior. It is unique for the utp modbus setups.
So restarting will only make it worse.
If they don’t come online all you can do is try to reboot the battery first, restarting the app will hang the other batteries again for hours.
If you want stable modbus use a gateway over the serial port, there the modbus works great.
Now all users have been migrated to the .17 and some time has passed? Who is still experiences dead connections (and did nto try to resolve it by restarting the app regurly)?
looks fine again here
Hi Vincent, … since the last update (approx 3 days ago) all went pear shaped. Before that I could read out the “opgeladen” and “ontladen” kWH from my Venus E 3.0’s and the accu percentage on Homey looked fine. Now it stays on 100% even when the batteries are almost empty and most importantly : the read outs of kWh totals stays the same. Restarted app, restarted batteries… nothing helps
Are you the one that send the report in?
And restarting the app makes it worse, make sure to leave it running for several hours
No, didn’t send in report yet. Switched over 2 out of 3 to Serial Ethernet port, the last one refused to connect to CT over serial so I’m stuck with LAN on that one. Restart CT just now and will wait some hours.
Hi,
I’m still having an issue with one of the three batteries (Venus E v3). I’ve tried turning it off and back on again (holding the button for 10 seconds), but that doesn’t seem to resolve the issue.
Sometimes I notice that after, for example, 8 hours, data suddenly comes through once, updating the battery status to its current state, but after that it goes silent again.
I’ve just held the button for 10 seconds again, so I’ll wait until the end of the day to see if it starts working again.
Weird that serial impacts the CT readings?
Thanks to a very detailed log send it by someone I have a new lead, I am following up on that route.
Similar issue here. Tried both Serial and LAN… nothing will be reported to Homey dashboard as % shown in dashboard does not equal the status on the Venus E 3.0 themselves nor the Marstek android app. Daily readout of he load/unload kWh stats in my Homey reporting flow shows exactly the same data for over 4 days now… it started since the latest update. I read Vincent may have a lead… fingers crossed.
New version on Test, thanks to a user testing each register on his V3 he found more registers that dont exist (anymore?) and cause the freezes if I try to read them.
So people who are stuck please update to the test, the rest might want to wait till we have green light from this poeple. I dont have a v3 so I can not test this.
But it works now by auto detectin bad registers, if I run into one, I remember it as bad.
You connection might still lock the session, restart if it does.
It might find a second bad register and hang again, but I remember this one also, restart
So it might take a manual restart or two/three to find all the bad ones.
Please let me know, it this is the final cause I will consider the auto restart for the non test release later on.
- Versie v1.5.18 geïnstalleerd.
- Verbindingstimeout op 10000 gezet.
- Accu’s spanningsloos gemaakt
- Homey Pro 2026 opnieuw opgestart.
- Na ruim 10 minuten de Marstek E v3.0 weer aangezet
Resultaat:
-
Ik krijg verkeerde waardes uit de Marstek Energy Storage v.w.b.. de accupercentages.
-
Bij het starten van een flow reageren de accu’s niet bv. van Zelfconsumptie naar Handmatig.
Rapport
e66c10f2-42ab-4654-97bf-04401af34f8b
Hi there,
I’m trying to debug the code, I have a venus E V3 and it’s not really working fine.
Logs show issues at each startup because of registry key Read 44000, it does not exists in this version.
Seen this page: GitHub - ViperRNMC/marstek_venus_modbus · GitHub, I suppose it is worth to add a different driver for the venus E V3 so that old registers read are not catch by the single try / catch statement.
Would you like me to send you a report? I can also help by reviewing any PR you wish on github (user: rmangin).
It’s a very promessing app but the result for now is less satisfying than the actual Cloud solution (with refresh frequency about 10/15 minutes).
Would think to separate the two drivers for Venus E 12/3 would be better for dummy users like me!
Please help
Rémi
I am anyway made aware of that register and one more. I made the test version to auto block reading registers that are rejecting from that point on. (was already part of Test version .18)
The test version .19 should already be handling that automatically.
Did you check that one?
It now remembers what registers get rejected and resets the frozen connection.
So it might take two or three cycles for it to skip all rejecting registers, but then it should be stable for ever, until marstek changes registers in future firmwares.
I did not get feedback from people on .18 so I hope this means that it worked for them.
