tbnobody / OpenDTU

Software for ESP32 to talk to Hoymiles/TSUN/Solenso Inverters
GNU General Public License v2.0
1.82k stars 508 forks source link

OpenDTU loses connection to inverter after OpenDTU update #1265

Open tobox opened 1 year ago

tobox commented 1 year ago

What happened?

I was running an old version from january on my OpenDTU, and it worked flawlessly for month. Then I saw that many new firmwares were available, and I flashed a (then) current version 2 weeks ago (using a cable, since the old firmware was too old). The RF chip was detected properly and everything was working nicely. But after a day or 2 there was no more communication between OpenDTU and the inverter (TSUN TSOL 1600). Rebooting the OpenDTU fixed the issue multiple times. Immediately after the reboot all values appeared.

2 Days ago I updated to the current firmware (OTA), and the device seemed to be working properly. But the next day: no new values. Rebooting the OpenDTU helped.

To Reproduce Bug

Usually it occurs every few days.

Expected Behavior

Communication should just work without reboot.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

v23.8.8

Relevant log/trace output

Here is a sample output of the console window in the error state:

11:21:16.125 > Nothing received, resend whole request
11:21:16.125 > TX SystemConfigPara Channel: 40 --> 15 71 90 08 22 17 19 00 82 80 05 00 64 E4 7E 08 00 00 00 00 00 00 00 00 A6 99 1E
11:21:16.351 > RX Period End
11:21:16.351 > All missing
11:21:16.351 > Nothing received, resend count exeeded
11:21:17.343 > Fetch inverter: 116171900822
11:21:17.343 > Request SystemConfigPara
11:21:17.390 > TX RealTimeRunData Channel: 61 --> 15 71 90 08 22 17 19 00 82 80 0B 00 64 E4 7E 0D 00 00 00 00 00 00 00 00 38 A9 BB
11:21:17.943 > RX Period End
11:21:17.943 > All missing
11:21:17.943 > Nothing received, resend whole request
11:21:17.943 > TX RealTimeRunData Channel: 75 --> 15 71 90 08 22 17 19 00 82 80 0B 00 64 E4 7E 0D 00 00 00 00 00 00 00 00 38 A9 BB
11:21:18.496 > RX Period End
11:21:18.496 > All missing
11:21:18.496 > Nothing received, resend whole request
11:21:18.496 > TX RealTimeRunData Channel: 3 --> 15 71 90 08 22 17 19 00 82 80 0B 00 64 E4 7E 0D 00 00 00 00 00 00 00 00 38 A9 BB
11:21:19.048 > RX Period End
11:21:19.048 > All missing
11:21:19.048 > Nothing received, resend whole request
11:21:19.048 > TX RealTimeRunData Channel: 23 --> 15 71 90 08 22 17 19 00 82 80 0B 00 64 E4 7E 0D 00 00 00 00 00 00 00 00 38 A9 BB
11:21:19.600 > RX Period End
11:21:19.600 > All missing
11:21:19.600 > Nothing received, resend whole request
11:21:19.600 > TX RealTimeRunData Channel: 40 --> 15 71 90 08 22 17 19 00 82 80 0B 00 64 E4 7E 0D 00 00 00 00 00 00 00 00 38 A9 BB
11:21:20.104 > RX Period End
11:21:20.104 > All missing
11:21:20.104 > Nothing received, resend count exeeded
11:21:20.148 > TX SystemConfigPara Channel: 61 --> 15 71 90 08 22 17 19 00 82 80 05 00 64 E4 7E 0D 00 00 00 00 00 00 00 00 F6 A6 74
11:21:20.402 > RX Period End
11:21:20.402 > All missing
11:21:20.402 > Nothing received, resend whole request
11:21:20.402 > TX SystemConfigPara Channel: 75 --> 15 71 90 08 22 17 19 00 82 80 05 00 64 E4 7E 0D 00 00 00 00 00 00 00 00 F6 A6 74
11:21:20.655 > RX Period End
11:21:20.655 > All missing
11:21:20.655 > Nothing received, resend whole request
11:21:20.655 > TX SystemConfigPara Channel: 3 --> 15 71 90 08 22 17 19 00 82 80 05 00 64 E4 7E 0D 00 00 00 00 00 00 00 00 F6 A6 74
11:21:20.908 > RX Period End
11:21:20.908 > All missing
11:21:20.908 > Nothing received, resend whole request
11:21:20.908 > TX SystemConfigPara Channel: 23 --> 15 71 90 08 22 17 19 00 82 80 05 00 64 E4 7E 0D 00 00 00 00 00 00 00 00 F6 A6 74
11:21:21.159 > RX Period End
11:21:21.159 > All missing
11:21:21.159 > Nothing received, resend whole request
11:21:21.159 > TX SystemConfigPara Channel: 40 --> 15 71 90 08 22 17 19 00 82 80 05 00 64 E4 7E 0D 00 00 00 00 00 00 00 00 F6 A6 74
11:21:21.384 > RX Period End
11:21:21.384 > All missing
11:21:21.384 > Nothing received, resend count exeeded
11:21:22.364 > Fetch inverter: 116171900822
11:21:22.364 > Request SystemConfigPara
11:21:22.410 > TX RealTimeRunData Channel: 61 --> 15 71 90 08 22 17 19 00 82 80 0B 00 64 E4 7E 12 00 00 00 00 00 00 00 00 08 25 18
11:21:22.965 > RX Period End
11:21:22.965 > All missing

Anything else?

No response

tobox commented 1 year ago

I just found this issue:

https://github.com/tbnobody/OpenDTU/issues/1105

Strangely, I had no problem with older firmwares. But it might be worth trying.

MartinRieser commented 1 year ago

I have the same issue with [v23.8.22] (also [v23.7.22] did not work) Now I downgraded to [v23.6.11] and I have communication with the inverter again.

tbnobody commented 1 year ago

There is nothing between these two versions which should lead to this behavior: https://github.com/tbnobody/OpenDTU/compare/v23.6.11...v23.7.22

Did you move the NRF Module between the hardware? Especially if the distance between DTU and inverter is longer or contains walls etc. it is possible that just a little bit different alignment of the antenna can cause connection issues.

cbielow commented 1 year ago

Same issue here: Hardware: Hoymiles HMS2000 + BlinkyParts OpenDTU CMT Firmware: v23.10.9 Distance to inverter: about 20m, with 1 wooden wall (shed) and a 3-layer glass window (kitchen) in between.

The box was running fine for a few days. Then, after maybe someone moved it a tiny bit, it lost connection to the inverter spuriously, and once its disconnected only a hard reboot (disconnect cable) helps. Then in most cases the connection was re-established upon reboot, but lost again after a few minutes.

Solution: connection strength seemed to be the problem. Changing the alignment of the antenna helped a bit, but what did trick was increase the CMT2300A Transmitting power: by 10dBm. Now everything runs smoothly...

cbielow commented 1 year ago

@tbnobody Would it make sense to try increasing the transmitting power automatically in those scenarios? In my case, that solved the problem in 5 seconds after changing it in the webinterface. Maybe some kind of 'auto transmitting power' mode? I can see that this might make the system unstable, depending on the power supply/cable/ and capacitor used, but giving a hint in the webinterface should remedy this problem.

breuerm710 commented 1 year ago

@tbnobody not sure it is the same issue just another flavor but I experienced the following. I have a lot of "2 DTU command failed" messages, so I thought increasing the NRF transmitting power from low to medium or max might help. When I do it, I loose the connection and even a reboot does not bring it back. Switching back to low or minimum brings back the connection. I reproduced this a couple of times. Power supply change does not help and I'm sure the power supplies are OK. [2023.09.28], HM300

Sn0w3y commented 8 months ago

Same issue here, 100% same Messages in Log as OP

stefan123t commented 3 months ago

@tobox what is the current state of this issue with your inverter ?

The TSUN TSOL-1600 has the leading model / manufacture year / calendar week 1161 7 (= Year 2021) CW 19

According to our Readme.md this is equivalent with a HM 4-in-1 model:

Class Models Serial range
HM_1CH HM-300/350/400-1T 1121
HM_4CH HM-1000/1200/1500-4T 1161

The results you have shown in the Serial Console log are normal behaviour when the Inverter does not respond. We would need to have the log from the time it worked until it stopped working in order to make some sense of it. So the console output in the error state alone is not really helping us determine the cause of your issue.

@cbielow you have an HMS-2000 which uses the CMT2300A radio module which has some power / RSSI information. The other users have an NRF24L01+ radio module which only has a qualitative / boolean RSSI value >=/< 64dB

@breuerm710 you have an HM300 so this is the same radio chip as tobox, only less channels on your model. The solution you provided is actually a best practice: start with LOW or MIN transmitting power and only slowly and gradually increase the power setting in case you do get no connection. I had the same issue and solution with my first experiments.

Changing the NRF transmitting power has an impact on voltage stability, i.e. with MAX or HIGH output of the PA+LNA amplifiers on the NRF module the voltage may drop and you are not receiving / sending reliably anything from/to the inverter. Please follow the link tobox has provided and add the capacitors close to the NRF module to smooth and secure the voltage of the NRF module.

@Sn0w3y there are just too little details about your issue / setup, though the same error message does only tell us for sure that communication between DTU and inverter does currently not work.