Open s-allius opened 4 months ago
I see the same gaps with my MS600 (using dev-0.8.0, 10 sec interval. I switched off cloud. The gap is very regularly: every ~13 min, 55-58 request (or similar). Looks like your gaps have the same frequency - interval 1 min, gap each hour. Interesting point: the gaps are shorter too -> same amount of request before connection reset?
Maybe the MS600 accepts only a max number of requests per connection. Reset connection by default after 50 requests?
Same with 20 sec request interval. It works for 55-58 requests. Followed by 11-18 unanswered requests. Than:
That is interesting. Today I also saw very long gaps (up to 15 minutes). So not only the Modbus responses are missing, the inverter itself is not sending any packets either. During the analysis, I noticed that I had forgotten to call the close() function to delete internal structures during a graceful disconnect. Half-open TCP connections could be the result. Fix is checked in the 0.8.0 branch. (That should fix your seen bug - point no 4)
Today I also implemented a monitoring function that resets the connection after 2.5 minutes without receiving any packets. This will hopefully keep the dropouts to a minimum. However, the actual cause is not yet clear to me. Which DSP firmware do you have? I have V5.1.09 on it after an update to 800VA.
I have an idea.
Before the Modbus payload, there are four bytes (offset 0x17 directly after the message ID), which could be a packet counter or a reset timestamp. I have set this byte to a fixed value of b'\x00\x01\xa3\x28'. But in my traces, I saw that this value changes with every request from the TSUN cloud. I have five examples:
2024-04-30 10:32:37 00 01 a3 06
2024-04-30 10:37:41 00 01 a3 08
2024-04-30 10:52:54 00 01 a3 0e
2024-04-30 11:33:28 00 01 a3 14
2024-04-30 15:20:23 00 01 a3 28
And you are wright, the resets are very regular. We can see it in the Power On Time
graph:
Now I check, what will happen with all four bytes set to 0x00.
Today I saw a gap from 13:15 until 18:00. My timeout handler worked as expected and close the TCP connection properly (server loop stoped). But the inverter didn't establish a new connection.
Maybe I have a network problem. It is possible, that the inverter roamed to another Accesspoint in that moment. (I have three APs here) But wenn the inverter don't make a reconnection, then I see no chance to mitigate the problem from the proxy side.
I will invest some more time to analyse it.
I also had gaps larger than usual (AVM AP) this afternoon, so likely no local issue on your side.
I attach my report from TSUN website.
device-report-2024051319514161.xlsx
BTW: I do not use the proxy.
Today a German TSUN handler wrote on his web page, that beginning with the 20th of May customer can switch to the Smart App even for GEN3 inverters. Maybe this will include a new firmware which supports the SolarmanV5 protcol.
The article is only in German available: https://priwatt.de/blog/tsun-wechselrichter-update-800-watt/
With the proxy version 0.10 the connection is really stable here. But I have to deactivate the polling mode
. It seems to me, that the inverter has a problem with the frequent MODBUS request every minute.
To deactivate the polling mode
add a line to your config.toml and set modbus_polling
to false for the GEN3 inverter
See also Inverter config
With an MS600 (GEN3) inverter with DSP version 5.1.09, I regularly see gaps in the data transmission. An initial analysis has shown that the TCP connection is stable and TCP keep-alive packets are also being answered.
We may be able to get the inverter out of this state by reestablishing the connection. I am not aware of a way to restart the DSP using a magic packet. I will try to recognize the situation by time monitoring and then close the TCP connection from the proxy side (sending a FIN packet) in the hope that the inverter will then send data again immediately.