[FrequencyManager] Search the band for unreachable HMS inverters #2573
Conversation
functionpointer
force-pushed
the
frequencymanager
branch
from
d184fbd to
f7274b0
Compare
|
Wouldn't it make more sense to implement it the same way as the original dtu does it? |
|
I don't quite see a well-defined strategy in those logs. The current strategy is a fairly simple, and it has been reliable for a few days now. |
Fixes HMS inverters losing connection sometimes. Fixes tbnobody#2277, tbnobody#2278, tbnobody#2137. HMS inverters sometimes decide to change their own frequency. They no longer listen to our inverterTargetFrequency and not on inverterBootFrequency. FrequencyManager deals with this by slowly scanning the band once isReachable()==false
functionpointer
force-pushed
the
frequencymanager
branch
from
a42ab37 to
802ca4e
Compare
|
This has been working great for me |
Hello, My inverters are hell since there's some sun. Impatient to have your version. |
|
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.... |
|
@fishpepper that is unfortunate. Could you post some console logs during the outage? |
|
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? |
|
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 |
|
perfect! logger is running. i will report back with positive or negative results! any ideas why setting the base frequency made a difference? |
|
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:
***@***.***>
|
|
A total connection loss is unlikely, the HMS800 reported fine. Unfortunately the HMS2000 lost the connection again at ~900W 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): |
|
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 |
|
Huh, it seems to not answer on any frequency. I have pushed a small change that restores old behavior for ChangeChannelCommand. Could you test it? |
|
sure! just uploaded commit 90882579c73b6418f7bdd1748c459422292f538d. I will report back :) Thanks! |
|
Unfortunately this did not help. Actually, 9088257 seems worse than 802ca4e. The reception loss seems to be more frequent: before: I only had one day of full receiption above 900W (21.03.25) with 802ca4e. Am i the only one testing? Would it help others to post the binaries somewhere? I will revert back to 802ca4e for now. |
I've been running this pull request ever since functionpointer published it. But I've never had connection problems before.
|
|
Aw that's disappointing :( Do you have logs of the new (90882579) version losing connection? |
I think the problems exist when running an HMS2000 with firmware revision 1.0.27 and another HMS 800 (?) with the same DTU. How is your setup?
I just ordered one to give it a try and/or upgrade the firmware of the HMS2000. |
|
I am running:
Before this PR, I had connectivity issues every few days. Every time one or two of the HMS1800's were affected. HMS800 never had issues. With both versions of this PR it has been working great. Not a single connection loss for weeks now. |
|
I am running
The DTU is 4m away from the HMS. The HMS800 is always working fine, the HMS2000 usually stops around 900W. With the first commit i had one single day where it worked fine all day. My DTU settings are (just to be safe i did not mess those up):
|
|
I'm running three HMS-1600-4T, but only two are added to the OpenDTU.
If you suspect there might be some kind of interference between your HMS-2000 and HMS-800, you could try disconnecting your HMS-800 and see if the 900 W anomaly still exists. |
|
good idea, i will disconnect the panels of the HMS800 tonight and report back :) |
|
I unplugged the HMS800 (DC and AC) and disabled it in openDTU. Connection was lost at 895W :( I will try the original DTU now. |
Actually, i think that is a good sign. Interference would be pretty annoying to deal with. This way the problem is inherent to the HMS2000 inverter itself. If the original DTU works, i think it is time to try a few different |
|
I would suggest testing your HMS-2000 with the original hoymiles DTU - maybe your HMS-2000 is defective. You never know. |
|
The original DTU connected jsut fine and happily reports 1.2kW right now. I will keep watching it.
It keeps producing. You can also see this in the following graph (only HMS2000 Power and Yield per Day shown): Is there an easy way to capture the original DTU traffic? Something like #1650 ? |
|
Ok, good to know for sure your HMS-2000 is working as expected. |
|
The openDTU is 4m from the HMS2000 and HMS800 (both at the same location). Direct line of sight. The hoymiles DTU is currently placed ~10m with several metal objects in between. I doubt my problems are due to reception/transmit power :( |
|
I don't think it's due to too little Power but maybe too much power. There can be radio interference due to placement and too much RF Power. Try the same location as your hoymiles DTU. |
|
The hoymiles DTU is now 3m from the HMS800 and HMS2000. I will have to wait for more sun tomorrow :) |
|
Data misinterpretation seems unlikely, both my HMS1800 happily reported over 1000W for several hours today. Thats why my assumption is self-interference. At high power levels, the converters might make noise that interferes with the radio. The hoymiles DTU might be switching to different frequencies that still work. That's why I suggested trying some frequencies in the DTU settings. Ideally with the older commit 802ca4e. It should allow changing the channel more quickly |
|
The mystery is why the hoymiles DTU works. I think i will crack it open tomorrow afternoon and attach a Salae logic analyzer to the SPI bus and capture some logs. That way we will see how the DTU manages to keep the connection alive :) |
|
Hoymiles DTU in close proximity worked fine as well. |
|
I have a question on the ChannelChangeCommand. If you look at my old log: The log says 868.00MHz, 864.75 MHz, and 865.25MHz but the command that is being sent is always the same: You change the frequency at the CMT3200 but the packet you send always contains 865 MHz (0x14) as target? |
Yes. At First the inverter always listens at 865. With the Channel change command the frequency will be Changed to the working frequency. |
|
May I ask about your DTU hardware? I also had poor reception of an HMS device when production was high. |
|
@broth-itk posted some new DTU Pro S logs with actual Channel Change Command Sequence here:
These used to be his IDs and SW
I have been able to determine the following ChannelChangeCommand Here are the HMS ChannelChangeCommand We can also see the following Similar there is Maybe @rejoe2 can recall what these Commands were used for in the ancient MI Gen2 protocol, i.e. pre Gen3 HM and HMS/HMT ? Similar to the I will have to search through the |
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
ChangeChannelCommandcan'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, butFrequencyManagerwill 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:Example with
inverterTargetFrequency=865first 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.