OpenDTU loses connection to inverter after OpenDTU update

[tobox]

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]

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]

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]

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]

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]

@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]

@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]

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