I tested 1.5.18, but at the same time the battery, which was already not working, also started behaving strangely. It began charging and discharging erratically, so I reverted to 1.5.17.
I’ve just upgraded directly from 1.5.17 to 1.5.19, and now the Venus D and both Venus E v3 units come online in Homey immediately.
I’ll keep an eye on it for a while to see if it remains stable.
since this night i get the following error message:
Retrieval of static info failed: Modbus exception 2: Illegal data address (register not supported by device)
i’m still on official version (.17), which worked without any issues in the past week
diagnostic report: 831cf9a5-ab81-4221-ac42-ed321c2092f0
kind regards,
Floris
hmm, weirdly the battery came back online after i’ve posted the above message.
So you can ignore it.
Thanks!
I’m still experiencing issues. After starting the app, everything works fine for a while, but eventually some of them go offline. The Venus E v3 running version V150 also starts having problems again relatively quickly. The other Venus E v3 running V148 remains online, as does the Venus D running V147. I’ve also noticed that sometimes the devices come back online by themselves.
After restarting the app, the devices that had connection issues come back online again.
Still using v1.5.19
Before restarting, please create a diagnostic report. I still need your logs to snake subs I do not have these batteries.
Same comment than Dave, in the v19 (with v3 batt in firm150), it works approx. 22 minutes then the battery seem to restart and stop connectivity for 15 minutes offline then works again for 22 minutes.
When the connection is lost, restarting the application (which cannot be automated) restores immediately the connection.
Will try to debug after a pull on friday. Let me know if you want that I send you logs.
May I propose a fork so that we can separate registers of EV12 and EV3 which are not the same for example 32100 is replaced by 30100 and 32101 by 30101? It seems on “my” version of your code running locally (with rights registers number), I also encounter “from time to time” disconnection but I’m not sure the battery is restarting with right numbers.
Report : ecc8f35b-2d4d-45ad-bad3-f1c68572ace5
I only received reports on versions 17 & 18. So it seems your not truly using 19
Send me a new diagnostic then, cause I got none in 19
Report : 21f77900-b51c-4f4a-8686-c15288c9b704
I would love to see the moment where it fails again, dave now send a log that proof it failed but the stale device on 150 is already dead in that log.
Forking cant solve stuff like this, I can make drivers that match firmwares, it is going to be hell to maintain. We need a detection system.
So please I hope you can share me your local test results on that device.
If you can find why the firmware register 31101 doesnt report anything anymore is there a new firmware register? Else I can make the code at least follow firmware thresholds and keep older devices working while new firmwares can be resolved if they contain new breaking changes
It looks like it moved to 30200?
Also please report 32100 en 32101
It is getting clearer and clearer it is not a hardware point they broke it but a firware version break point. So if we can detect pre break firmwares and run the old register mappings and for post firmware breaking change run on new mappings.
Because a V3 driver wont solve this for everyone on older firwares for examples.
Nor if they decide to push the same register mappings to the V2.
I used the Modbus Poll tool to check whether I could retrieve the register values. I am not familiar with this tool or the Modbus protocol, so I hope I retrieved the data correctly.
If there is an easier way for me to provide you with information, using another tool or different data, please let me know.
I tried to read the requested registers from my Venus E v3 units running firmware versions 148 and 150.
Results are stored in a PDF file. What is the best way to send it to you. If you can send me an email to dave@deefje.net I will reply on it with the attachment.
New report :ac7cdb8e-8f92-4604-9925-97fdac197081
Venus E v3 - 150 just stoped working
I shared you my email direct 
Unfortunatly I dont seem to be receiving these reports anymore 
Since your report yesterday no new reports received. I hope they are delayed or something
It never worked for me with 31101 sorry! That’s why I used 30200 but it was not seen in the settings until I used the reread unsupported values option.
I used this table to find similar registers: https://github.com/ViperRNMC/marstek_venus_modbus
The battery still restart from time to time but with the last piece of coding I sent you (when the number of errors is too high) that disconnect the modbus client the reconnection happens in less than 2 minutes and everything is repaired at this time.
To work well, I have reduced the timeout option in the settings to 1000 ms because else the full time out round trip was too long.
Let me know if I can help, I suppose you can take my coding and publish the v19 version with the const = if v3 ? 30200 : 31010. and the disconnect stuff.
Can you still run my code then locally on your v1/2 ? If yes, I think it is worth publishing to collect more feedback.
I’m in the house with local running capabilities until mid of September at the latest. Then I will be remote with no option to run local versions.
Best Regards,
Rémi
thanks for your tests and the additional reports, its great that you have a nice mix of devices.
I just pushed a new test version .20 out. Can you try that one?
It is more aware of the version register switches and uses that as marker for other differences in the register mappings.
So your 150 version battery should show version number again in the device details, the 148 probably not due to its not responding to any known version register.
It also includes an attempt to recover freezes triggered by the battery side.
In my opinion we have two major things happing that is causing the problems for the V3 and D owners:
1: The V3 and D modbus over TCP is very weakly implemented, it freezes on bad register reads and seems to freeze itself from time to time on their side.
2: between 147 and 150 people have been receiving firmwares that messed with the registers locations and meaning, but between 148 and 150 again etc. So it is not a ‘we changed at 150’ but we have bene moving stuf around and we are not final there yet maybe…
Its a battle agains many variations now, V2 with older firmware, V3 on 147, V3 on 148 or beta;s or V3 on 150, D 150 or olders etc
If I would make drivers that work for a version of firmware you would have to readd your devices when they get an update. So that wont work.
So my battle is to have all the checks in the drivers to make the code change its expectations based on the firmware your on, but like Daves 148 V3 already shows, that one rejects all firmware polls, again proof of the weird firmware changes.
For the people that suffer conenction issues:
We have two:
1: If I accidently read a register that is now illigal address, it freezes if your on UTP modbus.
2: It seems the V3+D>147 version hangup their own TCP stacks regurly also, this part is still a bit more uncertain.
So for 1 The above story should improve this, for 2 I now have a detection mechanism that reconnects if I think its needed.
So if your unhappy with the current state, please feel invited to test .20
