[FrequencyManager] Search the band for unreachable HMS inverters

[functionpointer]

HMS inverters, especially HMS-1600-4T, have been notorious for losing connection with OpenDTU.
See #2137, #2278, #2277

It seems the inverter moves to a neighboring frequency, and ChangeChannelCommand can't bring it back.
However, if we find the new frequency and tune to it, OpenDTU can communicate just fine.

This PR introduces a FrequencyManager, that automatically searches for the frequency of unreachable HMS inverters.
The search starts around the configured frequency (inverterTargetFrequency) and slowly moves away.
To prevent spamming the whole band, the search is slow and does not increase the number of messages sent.

On every fetch (5s by default DTU_POLL_INTERVAL), each message is sent up to 5 times (1 + MAX_RESEND_COUNT). This stays the same, but FrequencyManager will decide the frequency for each of them.
The first one will always be on inverterTargetFrequency, while the following ones slowly move away by this formula:

((failed_fetch_count + cmd_retransmit_count) % 20) * (cmd_retransmit_count%2==0?-1:1) * channel_width.

Example with inverterTargetFrequency=865
first fetch: 865; 864.75; 865.25; 864.50; 865.50;
second fetch: 865; 864.50; 865.50; 864.25; 865.75;
third fetch: 865; 864.25; 865.75; 864; 866;

At this point, I have not tested the code yet. I plan on doing that in the coming few days.
Comments or testing is welcome.
Code reviews only to a limited extent, I think that should wait until we know the strategy works.

[tbnobody]

Wouldn't it make more sense to implement it the same way as the original dtu does it?
#2137 (comment)

[functionpointer]

I don't quite see a well-defined strategy in those logs.
If you see one, I would be happy to implement it.

The current strategy is a fairly simple, and it has been reliable for a few days now.
In fact, I have not seen any inverter not on the inverterTargetFrequency even once (according to HA history).
Maybe that's due to insufficient testing, or maybe it is sufficient to ChangeChannelCommand on more frequencies than invBootFrequency.

[functionpointer]

This has been working great for me

[fr-fhe]

This has been working great for me

Hello,
Still working great after 5 days ?

My inverters are hell since there's some sun.
When power > 1000W (HMS-1600), they lost frequency.

Impatient to have your version.

[schlimmchen]

@tbnobody Do you agree that approving the workflow is okay? @fr-fhe could test these changes if there was a firmware ready to install.

[fishpepper]

I compiled and installed commit functionpointer@802ca4e one day ago. Seems to work as before, but unfortunately it did not fix the issue for me.

The HMS2000 (blue) stops reporting when reaching around 900W of power. The HMS 800 (orange) works and reports fine:

Both seem to produce just fine, its only the connection to the DTU dropping out.

This looks rather strange to me. Always stopping to send data at around 900W and returning to normal when going below 900W....
I think this might be not only a frequency hopping issue (at least in my case). Maybe the inverter warms up and shifts the frequency? I just added the inverter and DTU temperature and the rx stats to my logging and will report back after some sunny days.

[functionpointer]

@fishpepper that is unfortunate. Could you post some console logs during the outage?
This PR is specifically written to address frequency shifting.

[fishpepper]

I did reset "CMT2300A frequency" in the settings yesterday to the default and today the service was running fine above 900W for the first time in months. Maybe saving this setting triggered a reset in something used by the frequency hopping?
I have no serial log right now as the device is outside in the shed, i will continue watching it and add a raspberry pi if necessary,

[functionpointer]

You don't actually need a Raspberry Pi, the console on the webpage is enough. Make sure you capture several minutes.

FYI i wrote a longer term logging script, if you want to automate capturing logs: https://github.com/functionpointer/OpenDTU-Logger

[fishpepper]

perfect! logger is running. i will report back with positive or negative results! any ideas why setting the base frequency made a difference?

[functionpointer]

It is possible you lost connection to the radio entirely (SPI TX timeout). That is fixed by adjusting frequency or power. I was planning on fixing that issue in a separate PR.

…

On Fri, 21 Mar 2025, 19:52 fishpepper, ***@***.***> wrote: perfect! logger is running. i will report back with positive or negative results! any ideas why setting the base frequency made a difference? — Reply to this email directly, view it on GitHub <#2573 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFHHKQQMC3NEOJR7QP6E732VRNYRAVCNFSM6AAAAABYO7X4Q6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBUGIYDANBYGA> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: fishpepper]*fishpepper* left a comment (tbnobody/OpenDTU#2573) <#2573 (comment)> perfect! logger is running. i will report back with positive or negative results! any ideas why setting the base frequency made a difference? — Reply to this email directly, view it on GitHub <#2573 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFHHKQQMC3NEOJR7QP6E732VRNYRAVCNFSM6AAAAABYO7X4Q6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBUGIYDANBYGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[fishpepper]

A total connection loss is unlikely, the HMS800 reported fine.

Unfortunately the HMS2000 lost the connection again at ~900W

Temperature does not seem to be the issue.

I have a log file of the whole day. I attached the part where it lost connection to this post (~9:40 the first time, recovered and then lost it completely at 9:42):
opendtu_log1.txt
I replaced the serial numbers with the xxx__HMS200/HMS800

[fishpepper]

one more dataset where the connection is lost and restored:

and one picture where it is easier to see the dropouts:

and the log file
opendtu_log2.txt