OpenDTU Fusion losing connection to HMS-1600-4T

[Uendji]

What happened?

Almost every morning after a few hours working fine, connection to HMS is lost. Sometimes it works for two or three days, then connection lost until next morning. But HMS is still working and I am still able to send MQTT-commands such as reducing power or restart converter. But no more info from OpenDTU till next morning. Restarting DTU or powercycle DTU also no effect...

To Reproduce Bug

read above

Expected Behavior

NOT losing connection

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

v24.4.12

Relevant log/trace output

RX Period End
12:48:26.983 > All missing
12:48:26.983 > Nothing received, resend count exeeded
12:48:27.059 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 78 00 00 00 00 00 00 00 00 B9 BE 8F 
12:48:27.828 > RX Period End
12:48:27.828 > All missing
12:48:27.828 > Nothing received, resend whole request
12:48:27.828 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 78 00 00 00 00 00 00 00 00 B9 BE 8F 
12:48:28.623 > RX Period End
12:48:28.623 > All missing
12:48:28.623 > Nothing received, resend whole request
12:48:28.623 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 78 00 00 00 00 00 00 00 00 B9 BE 8F 
12:48:29.419 > RX Period End
12:48:29.419 > All missing
12:48:29.419 > Nothing received, resend whole request
12:48:29.419 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 78 00 00 00 00 00 00 00 00 B9 BE 8F 
12:48:30.216 > RX Period End
12:48:30.216 > All missing
12:48:30.216 > Nothing received, resend whole request
12:48:30.216 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 78 00 00 00 00 00 00 00 00 B9 BE 8F 
12:48:30.966 > RX Period End
12:48:30.966 > All missing
12:48:30.966 > Nothing received, resend count exeeded
12:48:31.022 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 78 00 00 00 00 00 00 00 00 AD AA 9B 
12:48:31.260 > RX Period End
12:48:31.260 > All missing
12:48:31.260 > Nothing received, resend whole request
12:48:31.260 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 78 00 00 00 00 00 00 00 00 AD AA 9B 
12:48:31.506 > RX Period End
12:48:31.506 > All missing
12:48:31.506 > Nothing received, resend whole request
12:48:31.506 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 78 00 00 00 00 00 00 00 00 AD AA 9B 
12:48:31.752 > RX Period End
12:48:31.752 > All missing
12:48:31.752 > Nothing received, resend whole request
12:48:31.752 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 78 00 00 00 00 00 00 00 00 AD AA 9B 
12:48:31.998 > RX Period End
12:48:31.998 > All missing
12:48:31.998 > Nothing received, resend whole request
12:48:31.998 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 78 00 00 00 00 00 00 00 00 AD AA 9B 
12:48:32.201 > RX Period End
12:48:32.201 > All missing
12:48:32.201 > Nothing received, resend count exeeded
12:48:32.201 > Fetch inverter: 116494405291
12:48:32.201 > Request SystemConfigPara
12:48:32.248 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:32.295 > RX Period End
12:48:32.295 > All missing
12:48:32.295 > Nothing received, resend whole request
12:48:32.295 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:32.341 > RX Period End
12:48:32.341 > All missing
12:48:32.341 > Nothing received, resend whole request
12:48:32.341 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:32.388 > RX Period End
12:48:32.388 > All missing
12:48:32.388 > Nothing received, resend whole request
12:48:32.388 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:32.433 > RX Period End
12:48:32.433 > All missing
12:48:32.433 > Nothing received, resend whole request
12:48:32.433 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:32.480 > RX Period End
12:48:32.480 > All missing
12:48:32.480 > Nothing received, resend count exeeded
12:48:32.527 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 80 00 00 00 00 00 00 00 00 A7 C6 0B 
12:48:33.032 > RX Period End
12:48:33.032 > All missing
12:48:33.032 > Nothing received, resend whole request
12:48:33.032 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 80 00 00 00 00 00 00 00 00 A7 C6 0B 
12:48:33.577 > RX Period End
12:48:33.577 > All missing
12:48:33.577 > Nothing received, resend whole request
12:48:33.577 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 80 00 00 00 00 00 00 00 00 A7 C6 0B 
12:48:34.122 > RX Period End
12:48:34.122 > All missing
12:48:34.122 > Nothing received, resend whole request
12:48:34.122 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 80 00 00 00 00 00 00 00 00 A7 C6 0B 
12:48:34.669 > RX Period End
12:48:34.669 > All missing
12:48:34.669 > Nothing received, resend whole request
12:48:34.669 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 80 00 00 00 00 00 00 00 00 A7 C6 0B 
12:48:35.172 > RX Period End
12:48:35.172 > All missing
12:48:35.172 > Nothing received, resend count exeeded
12:48:35.251 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 80 00 00 00 00 00 00 00 00 7D DD D0 
12:48:36.015 > RX Period End
12:48:36.015 > All missing
12:48:36.015 > Nothing received, resend whole request
12:48:36.015 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 80 00 00 00 00 00 00 00 00 7D DD D0 
12:48:36.811 > RX Period End
12:48:36.811 > All missing
12:48:36.811 > Nothing received, resend whole request
12:48:36.811 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 80 00 00 00 00 00 00 00 00 7D DD D0 
12:48:37.607 > RX Period End
12:48:37.607 > All missing
12:48:37.607 > Nothing received, resend whole request
12:48:37.607 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 80 00 00 00 00 00 00 00 00 7D DD D0 
12:48:38.402 > RX Period End
12:48:38.402 > All missing
12:48:38.402 > Nothing received, resend whole request
12:48:38.402 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 80 00 00 00 00 00 00 00 00 7D DD D0 
12:48:39.154 > RX Period End
12:48:39.154 > All missing
12:48:39.154 > Nothing received, resend count exeeded
12:48:39.202 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 80 00 00 00 00 00 00 00 00 69 C9 C4 
12:48:39.448 > RX Period End
12:48:39.448 > All missing
12:48:39.448 > Nothing received, resend whole request
12:48:39.448 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 80 00 00 00 00 00 00 00 00 69 C9 C4 
12:48:39.700 > RX Period End
12:48:39.700 > All missing
12:48:39.700 > Nothing received, resend whole request
12:48:39.700 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 80 00 00 00 00 00 00 00 00 69 C9 C4 
12:48:39.941 > RX Period End
12:48:39.941 > All missing
12:48:39.941 > Nothing received, resend whole request
12:48:39.941 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 80 00 00 00 00 00 00 00 00 69 C9 C4 
12:48:40.187 > RX Period End
12:48:40.187 > All missing
12:48:40.187 > Nothing received, resend whole request
12:48:40.187 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 80 00 00 00 00 00 00 00 00 69 C9 C4 
12:48:40.390 > RX Period End
12:48:40.390 > All missing
12:48:40.390 > Nothing received, resend count exeeded
12:48:40.390 > Fetch inverter: 116494405291
12:48:40.390 > Request SystemConfigPara
12:48:40.443 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:40.500 > RX Period End
12:48:40.500 > All missing
12:48:40.500 > Nothing received, resend whole request
12:48:40.500 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:40.552 > RX Period End
12:48:40.552 > All missing
12:48:40.552 > Nothing received, resend whole request
12:48:40.552 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:40.598 > RX Period End
12:48:40.598 > All missing
12:48:40.598 > Nothing received, resend whole request
12:48:40.598 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:40.644 > RX Period End
12:48:40.644 > All missing
12:48:40.644 > Nothing received, resend whole request
12:48:40.644 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:40.702 > RX Period End
12:48:40.702 > All missing
12:48:40.702 > Nothing received, resend count exeeded
12:48:40.759 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 88 00 00 00 00 00 00 00 00 67 A1 A4 
12:48:41.222 > RX Period End
12:48:41.222 > All missing
12:48:41.222 > Nothing received, resend whole request
12:48:41.222 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 88 00 00 00 00 00 00 00 00 67 A1 A4 
12:48:41.766 > RX Period End
12:48:41.766 > All missing
12:48:41.766 > Nothing received, resend whole request
12:48:41.766 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 88 00 00 00 00 00 00 00 00 67 A1 A4 
12:48:42.311 > RX Period End
12:48:42.311 > All missing
12:48:42.311 > Nothing received, resend whole request
12:48:42.311 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 88 00 00 00 00 00 00 00 00 67 A1 A4 
12:48:42.857 > RX Period End
12:48:42.857 > All missing
12:48:42.857 > Nothing received, resend whole request
12:48:42.857 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 88 00 00 00 00 00 00 00 00 67 A1 A4 
12:48:43.359 > RX Period End
12:48:43.359 > All missing
12:48:43.359 > Nothing received, resend count exeeded
12:48:43.412 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 88 00 00 00 00 00 00 00 00 BD BA 7F 
12:48:44.203 > RX Period End
12:48:44.203 > All missing
12:48:44.203 > Nothing received, resend whole request
12:48:44.203 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 88 00 00 00 00 00 00 00 00 BD BA 7F 
12:48:45.000 > RX Period End
12:48:45.000 > All missing
12:48:45.000 > Nothing received, resend whole request
12:48:45.000 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 88 00 00 00 00 00 00 00 00 BD BA 7F 
12:48:45.796 > RX Period End
12:48:45.796 > All missing
12:48:45.796 > Nothing received, resend whole request
12:48:45.796 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 88 00 00 00 00 00 00 00 00 BD BA 7F 
12:48:46.598 > RX Period End
12:48:46.598 > All missing
12:48:46.598 > Nothing received, resend whole request
12:48:46.598 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 88 00 00 00 00 00 00 00 00 BD BA 7F 
12:48:47.343 > RX Period End
12:48:47.343 > All missing
12:48:47.343 > Nothing received, resend count exeeded
12:48:47.437 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 88 00 00 00 00 00 00 00 00 A9 AE 6B 
12:48:47.637 > RX Period End
12:48:47.637 > All missing
12:48:47.637 > Nothing received, resend whole request
12:48:47.637 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 88 00 00 00 00 00 00 00 00 A9 AE 6B 
12:48:47.883 > RX Period End
12:48:47.883 > All missing
12:48:47.883 > Nothing received, resend whole request
12:48:47.883 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 88 00 00 00 00 00 00 00 00 A9 AE 6B 
12:48:48.128 > RX Period End
12:48:48.128 > All missing
12:48:48.128 > Nothing received, resend whole request
12:48:48.128 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 88 00 00 00 00 00 00 00 00 A9 AE 6B 
12:48:48.374 > RX Period End
12:48:48.374 > All missing
12:48:48.374 > Nothing received, resend whole request
12:48:48.374 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 88 00 00 00 00 00 00 00 00 A9 AE 6B 
12:48:48.578 > RX Period End
12:48:48.578 > All missing
12:48:48.578 > Nothing received, resend count exeeded
12:48:48.578 > Fetch inverter: 116494405291
12:48:48.578 > Request SystemConfigPara
12:48:48.623 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:48.670 > RX Period End
12:48:48.670 > All missing
12:48:48.670 > Nothing received, resend whole request
12:48:48.670 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:48.715 > RX Period End
12:48:48.715 > All missing
12:48:48.715 > Nothing received, resend whole request
12:48:48.715 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:48.762 > RX Period End
12:48:48.762 > All missing
12:48:48.762 > Nothing received, resend whole request
12:48:48.762 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:48.810 > RX Period End
12:48:48.810 > All missing
12:48:48.810 > Nothing received, resend whole request
12:48:48.810 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:48.855 > RX Period End
12:48:48.855 > All missing
12:48:48.855 > Nothing received, resend count exeeded
12:48:48.904 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 90 00 00 00 00 00 00 00 00 67 0B 16 
12:48:49.406 > RX Period End
12:48:49.406 > All missing
12:48:49.406 > Nothing received, resend whole request
12:48:49.406 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 90 00 00 00 00 00 00 00 00 67 0B 16 
12:48:49.952 > RX Period End
12:48:49.952 > All missing
12:48:49.952 > Nothing received, resend whole request
12:48:49.952 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 90 00 00 00 00 00 00 00 00 67 0B 16 
12:48:50.498 > RX Period End
12:48:50.498 > All missing
12:48:50.498 > Nothing received, resend whole request
12:48:50.498 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 90 00 00 00 00 00 00 00 00 67 0B 16 
12:48:51.043 > RX Period End
12:48:51.043 > All missing
12:48:51.043 > Nothing received, resend whole request
12:48:51.043 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 90 00 00 00 00 00 00 00 00 67 0B 16 
12:48:51.546 > RX Period End
12:48:51.546 > All missing
12:48:51.546 > Nothing received, resend count exeeded
12:48:51.594 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 90 00 00 00 00 00 00 00 00 BD 10 CD 
12:48:52.395 > RX Period End
12:48:52.395 > All missing
12:48:52.395 > Nothing received, resend whole request
12:48:52.395 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 90 00 00 00 00 00 00 00 00 BD 10 CD 
12:48:53.186 > RX Period End
12:48:53.186 > All missing
12:48:53.186 > Nothing received, resend whole request
12:48:53.186 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 90 00 00 00 00 00 00 00 00 BD 10 CD 
12:48:53.982 > RX Period End
12:48:53.982 > All missing
12:48:53.982 > Nothing received, resend whole request
12:48:53.982 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 90 00 00 00 00 00 00 00 00 BD 10 CD 
12:48:54.779 > RX Period End
12:48:54.779 > All missing
12:48:54.779 > Nothing received, resend whole request
12:48:54.779 > TX AlarmData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 11 00 66 20 FA 90 00 00 00 00 00 00 00 00 BD 10 CD 
12:48:55.529 > RX Period End
12:48:55.529 > All missing
12:48:55.529 > Nothing received, resend count exeeded
12:48:55.628 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 90 00 00 00 00 00 00 00 00 A9 04 D9 
12:48:55.822 > RX Period End
12:48:55.822 > All missing
12:48:55.822 > Nothing received, resend whole request
12:48:55.822 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 90 00 00 00 00 00 00 00 00 A9 04 D9 
12:48:56.068 > RX Period End
12:48:56.068 > All missing
12:48:56.068 > Nothing received, resend whole request
12:48:56.068 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 90 00 00 00 00 00 00 00 00 A9 04 D9 
12:48:56.313 > RX Period End
12:48:56.313 > All missing
12:48:56.313 > Nothing received, resend whole request
12:48:56.313 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 90 00 00 00 00 00 00 00 00 A9 04 D9 
12:48:56.558 > RX Period End
12:48:56.558 > All missing
12:48:56.558 > Nothing received, resend whole request
12:48:56.558 > TX SystemConfigPara 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 05 00 66 20 FA 90 00 00 00 00 00 00 00 00 A9 04 D9 
12:48:56.762 > RX Period End
12:48:56.762 > All missing
12:48:56.762 > Nothing received, resend count exeeded
12:48:56.762 > Fetch inverter: 116494405291
12:48:56.762 > Request SystemConfigPara
12:48:56.857 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:56.960 > RX Period End
12:48:56.960 > All missing
12:48:56.960 > Nothing received, resend whole request
12:48:56.960 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:57.006 > RX Period End
12:48:57.006 > All missing
12:48:57.006 > Nothing received, resend whole request
12:48:57.006 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:57.052 > RX Period End
12:48:57.052 > All missing
12:48:57.052 > Nothing received, resend whole request
12:48:57.052 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:57.099 > RX Period End
12:48:57.099 > All missing
12:48:57.099 > Nothing received, resend whole request
12:48:57.099 > TX ChannelChangeCommand 868.00 MHz --> 56 94 40 52 91 80 19 02 44 02 15 21 14 14 A8 
12:48:57.146 > RX Period End
12:48:57.146 > All missing
12:48:57.146 > Nothing received, resend count exeeded
12:48:57.192 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 98 00 00 00 00 00 00 00 00 A7 6C B9 
12:48:57.599 > RX Period End
12:48:57.599 > All missing
12:48:57.599 > Nothing received, resend whole request
12:48:57.599 > TX RealTimeRunData 865.00 MHz --> 15 94 40 52 91 80 19 02 44 80 0B 00 66 20 FA 98 00 00 00 00 00 00 00 00 A7 6C B9

Anything else?

[FrodoVDR]

I can confirm the bug, with the April update the connection to the HMS inverters is unstable. I have reset my Fusion to the last March version, since then the connections to my 3 HMS inverters (2x HMS 1800, 1x HMS 2000) are stable again.

[crisi-solar]

Habe den selben Fehler! Bei mir ist jedoch der Balken gelb und nicht rot.
@FrodoVDR welche SV hast du genau genommen? Hast du die Fusion mit dem USB-C-Stecker?
Kannst du bitte den Downloadlink posten?

[FrodoVDR]

Ich hatte den mit usb genommen:
https://github.com/tbnobody/OpenDTU/releases/download/v24.4.12/opendtu-generic_esp32s3_usb.bin

[Uendji]

@FrodoVDR You told us you rolled back to more stable version from March. Which one of the March's version is the more stable one. V24.4.12 is from April (and the last one) which is NOT stable...
Cheers
P.S. right now I have the same broken connection...

[Juergen2453]

https://github.com/tbnobody/OpenDTU/releases/download/v24.3.31/opendtu-generic_esp32s3_usb.bin

https://github.com/tbnobody/OpenDTU/releases

[FrodoVDR]

@Uendji I was asked which version I had used, I assumed that it was the support case.
Of course I used the latest March version to temporarily fix the error.
https://github.com/tbnobody/OpenDTU/releases/download/v24.3.31/opendtu-generic_esp32s3_usb.bin

[Uendji]

thx a lot... I flashed 24.3.31 a few hours ago with the result, connection came up again without waiting until tomorrow morning. Strange behaviour. I'm very curious as to what the reason is. Again thx and have a nice weekend.

[Uendji]

P.S. I found a filled event log after it came up again:

06:14:48	06:14:48	1	Wechselrichter gestartet
15:23:06	15:23:06	2	Time calibration
15:23:11	15:23:11	2	Time calibration
15:23:47	15:23:47	2	Time calibration
15:23:52	15:23:52	2	Time calibration
15:23:55	15:23:55	2	Time calibration
15:24:00	15:24:00	2	Time calibration
15:24:28	15:24:28	2	Time calibration
15:24:33	15:24:33	2	Time calibration
15:24:36	15:24:36	2	Time calibration
15:24:41	15:24:41	2	Time calibration
15:25:17	15:25:17	2	Time calibration
15:25:22	15:25:22	2	Time calibration
15:25:25	15:25:25	2	Time calibration
15:25:30	15:25:30	2	Time calibration

[Uendji]

FYI: same problem with 24.3.31. connection just broken...

[niekniek89]

I have the same issue, but with 1x HM-1500.
With the upgrade to the April release, I also keep losing connection to the inverter.
After a reboot of the ESP32, it continues to work for a while.
However, over time, it loses the connection with the inverter again.

downgraded to v24.3.15 last weekend, and has been running stable for 3 days now.

[tehre85]

Have/Had the same problem also with older images.
Im using only one HMS-1800-4t and I recognized the connection error especially when the PV power is heavily changing, like sunny to cloudy and vice versa.
Connection is stable if conditions are stable, normally I will have 76-80db using the CMT2300A on standard frequency.
Let me know if any more input will be helpful.

[justwords28]

Same problem for me with Hoymiles HMT-2250 and OpenDTU Fusion, but already since i updated months ago.

[Uendji]

For me the question is: Is it a problem with the Fusion hardware or is it a problem with openDTU which maybe can be corrected. I can still return the Fusion board but will I find a more reliable system for HMS? Looking for advice...
Cheers

[justwords28]

Software…

[mr-p666]

Yes, software!
Like @justwords28 same problem but on different hardware with my HMT-2250.

[tehre85]

Don’t think it’s the DTU hardware, maybe the frequency of the Inverter is shifting a little bit and the connection of DTU and HMS/T is getting broken.
As said my experience is, if the inverter is getting abrupt load, both parties will get out of sync. In some cases the connection gets back fast in others the seconds of time outs will reach +1k…

[TomdieMaus]

DTU mit USB aktuellste Version

ich nutze die DTU in Verbindung mit dem ioBroker und dem openDTU-Adapter.
Habe auch den HMS1600-4T. Genau das beschriebene Verhalten.
Habe aber den openDTU-Adaper gestoppt und morgens hat die openDTU Verbindung zum HMS aufgebaut.
Von unterwegs habe ich am Tag den Adapter im ioBroker gestartet und kurz drauf hatte die DTU keine Verbindung mehr.
Das stoppen des Adapters im ioBroker und die DTU hat sich wieder verbunden.
Abends konnte ich das Verhalten leider nicht mehr beobachten, aber hier war die Sonne geringer und lag weit unter den
Bedarf der Wohnung. --> HMS musste nichts begrenzen.
Ich stell jetzt auf MQTT um, und beobachte das ganze mal.
Als es angefangen hat, hatte ich keine Änderung an der DTU gemacht.
(außer die Einstellung im Wechselrichter, dass die Werte in der Nacht genullt werden sollen)

[Uendji]

As I mentioned in my first post, connection is still working while no data is showing in openDTU. I can still send commands like limiting output via MQTT to openDTU and it is still sent to HMS and HMS responds as desired...
Is there a chance a developer will give us a statement?

[h11odxD]

I just upgraded to the v24.4.12 for my HM-1500 and I got the no connection to the inverter problem, like the people before me, so nothing new from there

but I noticed that nobody mentioned, that there is a problem with the inverter config, which now has a problem with the serial number

Unknown format

as there is mention in the release notes of a new serial parser function, maybe this could be the culprit
ea28903

I hope this helps and many thanks for your great project!

UPDATE:
I had now more time to investigate this issue with my instance and something else totally messed up my opendtu instance during update
as the serialnumber indeed wasnt correct, but even with the correct serial it didn't work again
so after a factory reset everything is back to normal!

[niekniek89]

v24.3.15

After 3,5 days, he stopped also with this version....
I'am now trying release 24.2.16.

[mager33]

Same problem here, very unstable with HM300, HMS1600, HMS2000; will try 24.4.24

[justwords28]

I updated my OpenDTU Fusion yesterday to 24.4.24 but today it stopped working with my HMT-2250. Also tried restart, power off/on,
changing of power adapter, but no effect. Before i tried to downgrade to some version of 2023 (december), but after that the dtu menu remained empty, even restoring pin config did not help. Maybe we need to switch to ahoyDTU?

[justwords28]

Just tried AhoyDTU - so far no problems. However I did not succeed to integrate mqtt in Home Assistant. Maybe because there is already opendtu configured (injust copied the opendtu-settings for mqtt in Ahoydtu).

[justwords28]

I now flashed a very old firmware from September 2023 on my OpenDTU-Fusion-Board and did a software reset to default settings - now Wifi will not connect with the standard-wifi-password "openDTU42". Any idea?

[justwords28]

So I got it back running after fiddling with a lot of settings and changing the frequency to 868 MHz

[pyro2k9]

I do have the same problem since updating to 24.4.24. I updated from 24.1.xx. Before it worked much more stable. Now connection is unstable. When changing the transmission power to another value (higher or lower doesn't matter), I works one time.

I use a HMS-2000

[mager33]

I've downgraded to the first versiosn from Feburary that knows the HMS2000, reduced polling time from every 10sec and reduced update frequency of power adjustments to every 10 sec, too. That made it stable again. I have 1x HM-300, 2x HMS-1600 (new version) and 1x HMS-2000 (new version) I just won't do any updates from now :-)  

[tbnobody]

I've downgraded to the first versiosn from Feburary that knows the HMS2000

HMS-2000 is supported since the beginning of last year (2023).

reduced polling time from every 10sec and reduced update frequency of power adjustments to every 10 sec, too.

What was your previous polling time and update frequency? If you are updating too often you are filling up the command queue with update requests and no polling commands will be executed anymore. And if you are publishing too often, there is no time to execute the time critical polling commands anymore.

[Uendji]

If you are updating too often you are filling up the command queue with update requests and no polling commands will be executed anymore. And if you are publishing too often, there is no time to execute the time critical polling commands anymore

Where do I find these values?

[tbnobody]

Where do I find these values?

• https://www.opendtu.solar/firmware/configuration/dtu_settings/#poll-interval
• https://www.opendtu.solar/firmware/configuration/mqtt_settings/#publish-interval

The limit update interval depends on your own algorithm and how you are setting the current limit (web api, mqtt, etc). if you send this value too often... see above...

[niekniek89]

what is "best practice" on a normal install?
mqtt on 10 and dtu polling on 5 (as in the screenshots)?

[justwords28]

I do have the same problem since updating to 24.4.24. I updated from 24.1.xx. Before it worked much more stable. Now connection is unstable. When changing the transmission power to another value (higher or lower doesn't matter), I works one time.

I use a HMS-2000

Same with me. I change power settings now every morning. After that it works for around 24 hours. Strange. Also i reset the polling Intervall back from 10 to 5 seconds. I really hope someone will look at this bug, the downgrades did not work for me.

[MLG1087]

A user in the discussion forum just said that i should use an other power supply (stronger one). I used it and since that the DTU got every update since 2 hours.

btw v24.1.26 is installed

[justwords28]

Did not work for me. But 2 hours is not enough to test. For me the dtu always works for 24 hours. After that i have to change transmitting power, than it works again for 24 hours.

[justwords28]

Just installed v24.5.6 - sadly the problem persists. After reboot no data could be fetched. The trick with changing transmission power still works.

[MetaChuh]

@tbnobody
q&d for now, would be to implement:
after a dtu reboot, following a delay, change the transmission power forth and back, until this issue is isolated.

[justwords28]

Since yesterday the trick of changing transmission power no longer works for me since yesterday. Started several downgrades, got it to work for yesterday by vhaning frequency to 93,5. Today nothings works. Seems openDTU Fusion is somehow wrecked. Does the normal openDTU also have these problems? I tried AhoyDTU (different hardware) but when i copied the matt-settings that used to work with OpenDTUFusion, Home Assistant would not get any data.

[MetaChuh]

@justwords28
thanks for your feedback regarding the no longer working of the transmission power workaround.

regarding the hardware:
we currently can not isolate these issues to a certain hardware platform, regardless of if self made, community driven, or retail, as we do not have enough reproducible scenarios at our private test setups.

thx & greetings

[TomdieMaus]

Ich habe es wie folgt bei mir feststellen können:
Wenn ich vor dem Start des Wechselrichter am Morgen, die Verbindung zum meiner Steuerung trenne, startet die DTU ganz normal.
Bei mir reicht es, den Adapter im Iobroker zu stoppen und erst nach dem Start des Wechselrichter und der Verbindung der DTU mit dem Wechselrichter, kann ich den Adapter ohne Probleme starten.

Kann das jemand von euch bestätigen bzw. testen?

[chris299]

ich habe heute das update auf die 24.5.6 gemacht und direkt danach ging keinerlei Kommunikation mit meinem HMS-1600 mehr. mit dem HMS-400 dagegen lief es weiterhin einwandfrei. sehr seltsam. danach diverse downgrades versucht, bis runter zur 31.3.24 aber die Kommunikation kam nur sporadisch zurück. Selbst ein powercycle des HMS-1600 half nichts. erst ein power-cycle der openDTU half. (soft-reset half nichts)
Ich bleib auch erstmal wieder bei der 31.3. weil ich seit der 24.4.24 ebenfalls das 0-Werte Problem aus #1959 (comment) sehe (aber auch nur beim HMS-1600)

[FIr3baL]

I think we are facing the same issue.

We installed our system around mid of april. OpenDTU connected just fine from the beginning and had no connection problems for about 2 weeks.

At a cloudy day we noticed, that no data was delivered anymore and saw the time counter running up with no response from hms. The terminal output looked just the same as in screenshot from @Uendji above.

Then i tried fix it by moving the dtu next to the hms, changing settings like send power, restarting openDTU, updating firmware etc.
But the only solution was to reset configuration to "factory defaults". After configuring everything from scratch it worked like on day 1.

Today, about 2 weeks later, we had the 2nd connection lost this morning. Sadly i didn't save the message history. But i remember it stated the following: hms started around 5:54 am and had some under-voltage and under-frequency logs until the connection was lost at about 6:08 am

• HMS-2000-4T (new version)
• ready-to-use openDTU from derdtushop "Open DTU OpenDTU für Hoymiles HMS & HMT Reihe. Lan Plug & Play mit Gehäuse."

P.S.: Just saw, that open-dtu still received the hms logs from this morning after reconfiguration:

P.P.S.: With a closer look, i can see by received values in Home-Asistant , that both times, the disconnect did not appear in the morning, but during the day. First time at about 11:30, other day at 13:45. So my observation is, that is has nothing to do with low voltage in the very early morning or such.

[AndreasBeeA]

Experiencing the same issue using 24.6.29 with hms1600-4T

[stefan123t]

@Uendji I do not have an HMS/HMT inverter. But I live under the impression that GPIO3 has to be configured and connected to the CMT2300A in both your OpenDTU Fusion board and the pin_mapping.json

@tbnobody or is OpenDTU still fine without GPIO3, which is a hard requirement in Ahoy afaik ?