Lost connection to hms-1600-4t / frequency hopping #2137
Comments
|
Hi, i can confirm this bug or maybe expected behavior which is not considered in OpenDTU. What happend at my side: Today connection loss happened again and checked for issues here. BR |
|
Do you both have fairly new HMS models ? Can you post the first seven digits of your serial number (first 4 are the model, then follow three digits one for year and two for calendar week). The remaining five are the weekly unit production number which is unique. Could this be a new firmware on the imverter side ? I read a report that the german Netzbehörde has requested some changes to the RF protocol. Maybe this is to avoid sticking to one channel for too long. |
|
Seriennummer 1164948xxxxx |
|
Seriennummer 1164945xxxxx Today everything was fine. |
|
To share my findings: Today I had the same problem with my HMS-1800-4T, Firmware 1.0.27 It was shown offline/red but did produce power and was blinking green. Eventually I got it back online when disconnecting OpenDTU from power, powering up the Hoymiles DTU and waiting a bit. Now with Hoymiles DTU disconnected and OpenDTU back online, I wait for the inverters to answer ;-) |
|
Today i get the failure again. For me it looks like the openDTU sends some
(hopefully with the correct payload to the selected frequency) I then set the frequency seen at the spectrum in the openDTU menu and the current values were immediately available again OpenDTU expected @ 865.75MHz / inverter sends @ 865.5MHz OpenDTU send channelSwitching Commands @ 868MHz, set frequency in OpenDTU @ 865.5 MHz, gets immediately connected to inverter and fetch actuall data. |
|
I have just seen again that the inverter has changed frequency. |
|
Same issue here: Update: |
|
I do have the same issue, but my setup has one HMS-2000-4T and one HMS800-2T. The last days I disabled in the evening mqtt command sending, and did not have any issues reconnecting in the morning. I would suggest only sending commands when the inverter is "online". |
This is a known issue the command pipeline is not very long, but if you queue ActivePowerLimit commands this may actually prevent your OpenDTU to make normal contact / send queries to your inverter, but instead will try to set the limit first. Also setting the limit too frequently can prevent the inverter from responding to any other requests for some 15 or even more seconds. The Dynamic Power Limiter in OpenDTU-OnBattery has a hysteresis set to +/-30W to make it nly reasonable updates. |
|
i guess i have the same problem. but in my case its enough to just save the "DTU" settings, without changing anything. (no reboot or such things) i reduced the send power and changed the frequency to 869MHz, because i had lots of problems. with -3dBm and 869MHz the problems only occur once in a while, mostly in the morning hours Seriennummer | 1164923xxxxx
have you tried just saving the DTU field without any changes, too? |
|
@Paule-Panter @btuerk89 @spcqike thanks for your details @Seppl01 @bytecorner-jan @broth-itk can you please provide the first seven digits of your Serial Number plus the requested details from the Inverter Info ? @Paule-Panter @spcqike IMHO when you change / save the settings the OpenDTU code runs a reinitialisation of several components. Hence this would explain why it is able to sync to the new frequency again. |
|
Here is the information from my three inverters. Today I had the same problem again, out of the blue not available. Serial 1164807xxxxx Serial 1164813xxxxx Serial 1124831xxxxx |
|
Thanks Bernhard @broth-itk for looking this up! I am a bit tricked because you mentioned the 15 minutes wait time before the inverter(s) responded again. Please refer to the SystemConfigParam description of the protocol. We use it to verify the ActivePowerLimit has been set correctly. It is quite timing sensitive and may render an inverter unresponsive for ~15 minutes! Do you have a zero export or similar ActivePowerLimit control for your inverters and if for which ? |
|
The 15 minutes are an estimation and are unrelated to zero export or ActivePowerLimit. What about other inverters in the neighborhood? There are possibly some. Are thoses interferences detectable? I think about my own products when we were implementing communication statistics per unit, like how many messages were sent, how many repetitions and how many failures (no reponse) happened. |
|
@broth-itk The RX/TX Packet Loss counters of your Inverter can be read using the GetLossRate command, that is probably what you are referring to. |
|
I was thinking of counters on the OpenDTU side. |
|
RSSI values are only supported by the CMT link. The NRF link (chip and library) only has pseudo RSSI, i.e. < or >= 64dBi as a Boolean. Yes you could create counters on the OpenDTU/Ahoy side as well and even compare them with the counters on the inverter side after executing the GetLossRate command mentioned above. |
|
Unfortunately it seems like I also face this issue. I cannot get my OpenDTU connected to my Hoymiles HMS-1600-4T. Since I do not have access to a spectrum analyzer I cannot tell if the frequencies I have tested correspond to my inverter. |
|
@fir3bird the DTU can only connect to HMS-1600 not HMS-1600W can you double check the HMS Model you have and report the first seven digits of your HMS, ie Model and built year / calendar week ? |
|
@stefan123t I can confirm, that it is the model without W. |
|
@fir3bird How did you coonect the cmt2300 and what did u write in the mapping file? I am also facing a issue . my pin mapping file looks like this [ "name": "Generic NodeMCU 38 pin", "eth": { |
|
@RS2480 you have not connected the GPIO2/3. I believe either is required, i just don’t know which 🤷 But your first time setup question is probably not related to this issue posted by @Paule-Panter please consider to use the Discord chat instead for your problem. @tbnobody regarding the original issue of @Paule-Panter it might be good to start a frequency sweep across all possible CMT2300A frequencies in order to send the ChannelChangeCommand, eg in case the inverter hasn’t answered for a while. To me this looks like somewhere in Fall 2023 the HMS firmware was upgraded for all new HMS inverters to: i think Bernhard @broth-itk may have upgraded his 2022 HMS to that firmware version, too ? |
|
@RS2480 [
{
"name": "Generic NodeMCU 38pin",
"cmt": {
"sdio": 14,
"clk": 12,
"cs": 27,
"fcs": 26,
"gpio3": 34,
"gpio2": 35
}
},
{
"name": "Generic NodeMCU 38pin + I2C Display",
"cmt": {
"sdio": 14,
"clk": 12,
"cs": 27,
"fcs": 26,
"gpio3": 34,
"gpio2": 35
},
"display":{
"data": 21,
"clk": 22,
"type": 2
}
}
]But yours might look different. It depends how you soldered your CMT2300A to your ESP32. For my problem: I am still out of luck. I already checked the solder joints twice if there is something broken. But I would have expected to see an error in the system info anyway if that would have been the case. I checked different frequencies now, but always without success. |
|
@stefan123t Both HMS-1800 and HMS-2000 inverters running 1.0.27 in my case. |
|
Bernhard @broth-itk that would somehow confirm the hunch that your Model HMS-350-1T Or is this also impacted if it is the sole / first inverter instead of the last ? |
|
I have not seen the HMS-350T-1T with 1.0.14 going down/offline as the others did. Beside that observation, I started to notice the issue with the last few versions which were released. |
|
I received my DTU lite stick from hoymiles today and the stick connects immediately to my HMS-1600-4T. But I still cant get my OpenDTU connected. My logs I double checked solder joints and config and the DTU lite stick from hoymiles was disconnected. |
Your problem looks totally different than the discussed one in that thread. Anyway: And make a corresponding hw-connection between the both modules. So, and please open up a new thread for your problem. Paule
|
|
A short interim report from my system: At the moment it is working for the most part. At least to the that I can live with it. The DTU loses the connection to the WR on some days (for whatever reason). But after a while it always finds it again on its own without me having to intervene. I also do NOT have to wait until the next day or restart the WR. The only change that I am aware of is setting the frequency in the DTU to 868.00 MHz. As the channel change commands always seem to be sent on this channel, I thought the channel was a good fit. Fortunately, the spectrum on the channel at my location is not being used for anything else. Since then the DTU has at least found the WR again after a while. Maybe i have to look deeper to that, if i want to create a "nulleinspeisung". Up to that i have to relax at the beach ;-) |
|
Hi there, I also encountered this problem, my inverter is brand-new, the serie number is 1164A011xxxx. I tried different frequencies and tried to connect after restarting the module every time. The console window is no longer updated after about 5-10 minutes. Check it in Putty and the error is CMT: Buffer full. Someone say to wait 15 minutes or even hours. I waited for a whole day, but no attempt was made to connect successfully. In putty always reported the same error. Can anyone help me? Best Regards
|
|
Hello there, same problem here: HMS-2000-4T (so using the CMT module), connection after (re)starting works for a few hours (both directions, can successfully set a custom power limit), sometimes even for a day or two, then the connection drops even though the inverter still works (LED flashes green once each second which indicates regular operation). Serial number is 1164914xxxxx. Operates on 865 MHz by default. More info below: Serial 1164914xxxxx Edited to add: Had a connection drop just one hour ago, so I tried different frequencies. Changing the frequency from 865.00 to 864.75 MHz helped! So the changing frequency seems to be the culprit. Is there any way to set a different frequency automatically, e.g. via MQTT? This way one could implement a workaround in e.g. Home Assistant (where the frequency is changed as soon as the connection drops)? |
|
I can confirm that every time my inverter loses connection to OpenDTU, changing the frequency works. The new frequency was always in the range of 865.00 +/-0.50 MHz. |
|
in my experience, you dont need to change the frequency, its enough to just save the DTU settings page, again.
not that i know. but you can send a http post request and "click save". of course you can also set another frequency there. just have a look at the web_api doc |
@spcqike tried your suggestion, doesn't work, I have to find the right frequency to work. Using the same as before and just hitting the save button has no effect. As soon as I find the correct frequency, data is being received again. |
@Paule-Panter can you confirm the @swatermann can you attach a log from the restarting the ESP until it shows the above error code ? |
|
Poll Inverval: 10s LOG file attached |
|
@swatermann thanks this is almost instantly in your case. I also only see Interupt received but no RX data from the CMT module being parsed. Please have a look at the GPIO2/3 IRQ setting in your CMTs pin_mapping.json I assume there may be some wire monkeys 🙈 in your case. I would suggest to log a separate issue as the others have their issue only after several hours. You can use the [/] slash commands Details and Code Block to collapse/expand and format your log while editing. Or simply attach it as a log file using drag and drop. |
I have just started the usb serial log. As reported three weeks ago, it is currently running reasonably stable. |
|
All the issues #1476 #1550 #1627 #1921 #1961 #2056 and especially this #2137 do exhibit problems with the ChannelChangeCommand and ultimately loose the connection to the inverter. @Paule-Panter thanks for your Pictures / Screenshots of the RF Signal here #2137 (comment) Here is the current implementation / documentation in the OpenDTU source: OpenDTU/lib/Hoymiles/src/commands/ChannelChangeCommand.cpp Lines 9 to 18 in dc5eb96 According to the logfiles from @broth-itk we can now see the ChannelChangeCommand recorded on his original Hoymiles DTU in the wild. Actually it is repeated quite frequently, i.e. five time ChannelChangeCommand 0x56 interleaved with one time RealTimeRunData_Debug 0x15 0x0b. @broth-itk can you confirm my understanding of your Serial IDs ?
ChannelChangeCommand DTU Training
ChannelChangeCommand Inverter Reply
|
|
Thanks for this very interesting analysis!
|
|
Everyday after a couple of hours the connection to my HMS-1600 is lost and only regained around six hours later. So I have a connection for a couple of hours at the start and the end of each day but not in between. Let me know if I can help to solve this issue. |
|
@SG-fabian: At least for me (problem stated here), changing the frequency helped, so I wrote an automation in Home Assistant which is a workaround for now. You could try changing the frequency and find whether that's the problem for you, too. |
|
@broth-itk I have merged the above two sequences from DTU outgoing / A: and Inverter incoming / B:. awk '{out = ""; for (i = 4; i <= NF; i++) {out = out " " $i}; print $2, $3, $1, out}' channel_change.txt | sort > channel_change_merged.txtIn order to have it easier readable I have replaced your above DTU and Inverter IDs as follows:
Especially interesting is the following Init / Training Sequence, which we have seen with one of the earliest DTU WLite as well. Welche Kommandos (MainCmd) und Sub Kommandos (SubCmd) gibt es ?
Details
|
|
Here's another observation: Like I already wrote my OpenDTU unit usually loses the connection before noon und regains it in the evening. But on cloudy days with a power output under 100 watts the connection is much more stable. So maybe the changes in frequency are somehow be related to the generated power? If I had to guess I'd say that the converter circuits create some kind of interference. Maybe this helps to isolate the issue. |
|
i have observed similar behavior with my HMS-2000, but not at 100W but at ~ 700-800W. after a restart of my DTU and a "save cycle" of my DTU settings (to apply the set frequency, at 12:47) everything works as usual again
|
What happened?
Sporadically the dtu lost the connection between dtu and inverter.
Then the inverter is showing red in dtu.
Next day (after dc cut off) the connection will reestablished.
A other way i found, is to look at a spectrum analyser. There are some periodicaly burst at a nearby frequency visible. If i tune the DTU to this frequency (e.g. 865.25MHz) the dtu gets immediately actual data.
After a while (some hours) the inverter switches (i dont know why) the frequency to e.g. 865.75MHz. Then the dtu cant receive any data from the inverter.
If I retuned the dtu to the frequency, where some burst visibility from the inverter, then it get immediately reconnected and gets actuall data.
At the Console i could see, that the dtu sometimes try to switch to 868.00MHz.
But at the spectrum analyser i see the burst at other frequencies.eg 865.25 / 865.75Mhz
Maybe the HMS1600-4t look for a undisturbed channel and switch to that channel.
Is there a well known procedure for a channel switch ? (initiated from both side)
Or is a automaticly frequency scanning available, that could be retriggered after a connection lost to the inverter?
To Reproduce Bug
Switch on a hms1600-4t.
Wait until the connection to the inverter is lost.
Look at a external spectrumAnalyser for a peridically pattern.
Tune to this frequency.
Get fresh inverter data.(successful reconnect)
Expected Behavior
No lost connection /
Automatic reconnect.
Install Method
Pre-Compiled binary from GitHub
What git-hash/version of OpenDTU?
git Hash v24.6.29
Relevant log/trace output
Anything else?
No response
Please confirm the following
The text was updated successfully, but these errors were encountered: