Lost connection to hms-1600-4t / frequency hopping

[Paule-Panter]

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

Fetch inverter: 1164945xxxxx
21:23:19.282 > TX RealTimeRunData 865.75 MHz --> 15 94 50 34 70 80 18 28 29 80 0B 00 66 90 31 27 00 00 00 00 00 00 00 00 8B 3A D6 
21:23:19.489 > Interrupt received
21:23:19.686 > RX 865.75 MHz --> 95 94 50 34 70 80 18 28 29 01 00 01 01 10 01 09 00 05 00 06 00 10 00 10 00 00 96 | -12 dBm
21:23:19.942 > Interrupt received
21:23:19.956 > RX 865.75 MHz --> 95 94 50 34 70 80 18 28 29 02 3C C9 00 00 3C 01 08 4A 08 4A 00 FE 01 01 00 06 BE | -12 dBm
21:23:19.965 > Interrupt received
21:23:19.975 > RX 865.75 MHz --> 95 94 50 34 70 80 18 28 29 03 00 06 00 10 00 10 00 00 3C 74 00 00 3B 76 08 4B CF | -12 dBm
21:23:19.987 > Interrupt received
21:23:19.992 > RX 865.75 MHz --> 95 94 50 34 70 80 18 28 29 04 08 38 09 56 13 89 00 3D 00 00 00 02 03 E7 01 4F E8 | -12 dBm
21:23:20.001 > Interrupt received
21:23:20.008 > RX 865.75 MHz --> 95 94 50 34 70 80 18 28 29 85 00 01 3E 76 40 | -12 dBm
21:23:20.017 > RX Period End
21:23:20.017 > Success
21:23:29.023 > Fetch inverter: 1164945xxxxx
21:23:29.036 > TX RealTimeRunData 865.75 MHz --> 15 94 50 34 70 80 18 28 29 80 0B 00 66 90 31 31 00 00 00 00 00 00 00 00 EB DC 46 
21:23:29.078 > Interrupt received
21:23:29.087 > RX 865.75 MHz --> 95 94 50 34 70 80 18 28 29 01 00 01 01 10 01 09 00 05 00 06 00 10 00 10 00 00 96 | -12 dBm
21:23:29.130 > Interrupt received
21:23:29.138 > RX 865.75 MHz --> 95 94 50 34 70 80 18 28 29 02 3C C9 00 00 3C 01 08 4A 08 4A 00 FC 01 01 00 06 BC | -13 dBm
21:23:29.180 > Interrupt received
21:23:29.190 > RX 865.75 MHz --> 95 94 50 34 70 80 18 28 29 03 00 06 00 0F 00 0F 00 00 3C 74 00 00 3B 76 08 4B CF | -12 dBm
21:23:29.229 > Interrupt received
21:23:29.238 > RX 865.75 MHz --> 95 94 50 34 70 80 18 28 29 04 08 38 09 54 13 8A 00 3D 00 00 00 02 03 E8 01 4F E6 | -12 dBm
21:23:29.269 > Interrupt received
21:23:29.278 > RX 865.75 MHz --> 95 94 50 34 70 80 18 28 29 85 00 01 3C 87 B3 | -12 dBm
21:23:29.622 > RX Period End
21:23:29.622 > Success

Anything else?

No response

Please confirm the following

• [X] I believe this issue is a bug that affects all users of OpenDTU, not something specific to my installation.
• [X] I have already searched for relevant existing issues and discussions before opening this report.
• [X] I have updated the title field above with a concise description.

[btuerk89]

Hi,

i can confirm this bug or maybe expected behavior which is not considered in OpenDTU. I do use the HMS-2000-4T, but seems this belongs to complete HMS series.

What happend at my side: Connection gets sometimes lost since a few days ago. (Not sure if it is the case since the beginning I installed my inverter begin of July.) Restart of inverter (over night or manual disconnetion of modules) solved the problem.

Today connection loss happened again and checked for issues here. Test with changing the frequency to a neigbour band solved the problem immediately. (in my case from 864.00 to 873.75 MHz)

BR

[stefan123t]

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.

[btuerk89]

Seriennummer 1164948xxxxx Produktionsjahr 2023 Produktionswoche 48 Modell HMS-2000-4T Ermittelte max. Leistung 2.000 W Bootloader-Version 0.1.1 Firmware-Version 1.0.27 Firmware-Erstellungsdatum 2023-06-05 10:24:00 Hardware-Teilenummer 270692628 Hardware-Version 01.10

[Paule-Panter]

Seriennummer 1164945xxxxx Produktionsjahr 2023 Produktionswoche 45 Modell HMS-1600-4T Ermittelte max. Leistung 1.600 W Bootloader-Version 0.1.1 Firmware-Version 1.0.27 Firmware-Erstellungsdatum 2023-06-05 10:24:00 Hardware-Teilenummer 270680326 Hardware-Version 01.10

Today everything was fine. No frequency switching seen. No lost connection. But today it was cloudy and raining, the days with problems always sunny and hot. Maybe that could be also interesting.

[broth-itk]

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. First it showed "Alarm" state in S-Miles cloud but then went green shortly after.

Now with Hoymiles DTU disconnected and OpenDTU back online, I wait for the inverters to answer ;-)

[Paule-Panter]

Today i get the failure again. I fetch some logs and screenshots from the spectrum after the frequency changed already. See attached logfile with some additional comments, what i have done at some timestamp.

For me it looks like the openDTU sends some

TX ChannelChangeCommand 868.00 MHz

(hopefully with the correct payload to the selected frequency) commands, but there is no reaction from the inverter. (Maybe because the inverter is tuned to a other frequency?) The inverter ignores the commands and continues to sending at his selfselected frequency (865.5MHz in this case)

I then set the frequency seen at the spectrum in the openDTU menu and the current values were immediately available again

20240713_openDTU_console.log

OpenDTU expected @ 865.75MHz / inverter sends @ 865.5MHz

OpenDTU send channelSwitching Commands @ 868MHz, but inverter ignores them?

set frequency in OpenDTU @ 865.5 MHz, gets immediately connected to inverter and fetch actuall data.

[Paule-Panter]

I have just seen again that the inverter has changed frequency. I set openDTU to the frequency recognised in the spectrum (this time 866 MHz) and the connection is up and running again.

[Seppl01]

Same issue here: 2x HMS-1600-4T 1164a00xxxxxx

Update: Changed the settings (868Mhz and poll intervall from 5s to 10s) and actually it's working fine :)

[bytecorner-jan]

I do have the same issue, but my setup has one HMS-2000-4T and one HMS800-2T. The HMS800 does always reconnect in the morning. HMS2000 is the only one that is controlled (i.e. commands send to) I noticed that the opendtu is sending commands for every received mqtt message also when the inverter is not sending anything.

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".

[stefan123t]

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. So do not set a new limit too frequently or when it ain‘t necessary.

The Dynamic Power Limiter in OpenDTU-OnBattery has a hysteresis set to +/-30W to make it nly reasonable updates.

[spcqike]

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 Produktionsjahr | 2023 Produktionswoche | 23 Modell | HMS-2000-4T Ermittelte max. Leistung | 2.000 W Bootloader-Version | 0.1.0 Firmware-Version | 1.0.16 Firmware-Erstellungsdatum | 2022-08-03 15:20:00 Hardware-Teilenummer | 270692630 Hardware-Version | 01.00

@Paule-Panter

I set openDTU to the frequency recognised in the spectrum (this time 866 MHz) and the connection is up and running again.

have you tried just saving the DTU field without any changes, too?

[stefan123t]

@Paule-Panter @btuerk89 @spcqike thanks for your details Especially the Firmware Version and Firmware Build date may give us some additional hints.

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

[broth-itk]

@stefan123t

Here is the information from my three inverters. With the one in bold I observed the connectivity issues.

Today I had the same problem again, out of the blue not available. Frequency was set to 865MHz. Reboot of DTU did not help. After changing to 868MHz and wit ~15 minutes all inverters, inclusing the "missing one", were found again.

Serial 1164807xxxxx Production Year 2022 Production Week 7 Model HMS-1800-4T Detected max. Power 1,800 W Bootloader Version 0.0.1 Firmware Version 1.0.27 Firmware Build Date 2023-06-05 10:24:00 Hardware Part Number 269635841 Hardware Version 01.00

Serial 1164813xxxxx Production Year 2022 Production Week 13 Model HMS-2000-4T Detected max. Power 2,000 W Bootloader Version 0.0.1 Firmware Version 1.0.27 Firmware Build Date 2023-06-05 10:24:00 Hardware Part Number 269644033 Hardware Version 01.00

Serial 1124831xxxxx Production Year 2022 Production Week 31 Model HMS-350-1T Detected max. Power 350 W Bootloader Version 0.1.2 Firmware Version 1.0.14 Firmware Build Date 2021-12-09 12:46:00 Hardware Part Number 270541056 Hardware Version 02.00

[stefan123t]

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 ?

[broth-itk]

@stefan123t

The 15 minutes are an estimation and are unrelated to zero export or ActivePowerLimit. Maybe due to the documentation mentioning the time until the inverters are using the new frequency.

What about other inverters in the neighborhood? There are possibly some. Can they interfere with our communication in a way that one unit gets lost?

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. These stats help actually a lot to evaluate the EF environment.

[stefan123t]

@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. The documentation in the Protocol Wiki is based on analysing the leaked Hoymiles DTU source code on gitee.com, traces created by Ahoy and OpenDTU users and observations during reverse engineering the protocol. The 15 minutes dead / no answer time were actually witnessed by both lumapu and tbnobody during development of the ActivePowerLimit command and subsequent SystemConfigParam query.

[broth-itk]

@stefan123t

I was thinking of counters on the OpenDTU side. This would help judging the link quality between DTU and the inverters. RSSI values would help as well if NRF/CMT support that.

[stefan123t]

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. That way you could calculate a differential value between consecutive queries or comparisons, eg based on a certain interval / number of packets exchanged.

[fir3bird]

Unfortunately it seems like I also face this issue. I cannot get my OpenDTU connected to my Hoymiles HMS-1600-4T. Manually tried several difference frequencies and never had success. The status information at least shows a successfully connected CMT2300 module.

Since I do not have access to a spectrum analyzer I cannot tell if the frequencies I have tested correspond to my inverter. Maybe a "auto" frequency scanner might be a solution? Like scanning for radio stations in a car. Sorry, might be a stupid idea - I am not that introduced into RF applications. :-)

[stefan123t]

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

[fir3bird]

@stefan123t I can confirm, that it is the model without W. First seven digits of the serial number are the same like the ones from Seppl01: 1164a00xxxxxx

[RS2480]

@fir3bird How did you coonect the cmt2300 and what did u write in the mapping file? I am also facing a issue . HMS350 holymiles with opendtu, esp32,cmt2300 . Hello everyone, I need a help i have used HMS350 to use with opendtu with esp-wroom-32 and cmt 2300. I followed the steps on the opendtu documentation but I am not getting the live data of the inverter on the opendtu platform.

my pin mapping file looks like this

[ {

"name": "Generic NodeMCU 38 pin", "Cmt": { "clk": 12, "cs": 27, "fcs": 26, "sdio": 14, "gpio2": -1, "gpio3": -1 },

"eth": { "enabled": false, "phy_addr": -1, "power": -1, "mdc": -1, "mdio": -1, "type": -1, "clk_mode": -1 } } ]

[stefan123t]

@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: Firmware Version 1.0.27 Firmware Build Date 2023-06-05 10:24:00

i think Bernhard @broth-itk may have upgraded his 2022 HMS to that firmware version, too ?

[fir3bird]

@RS2480 To answer your question what my pin mapping looks like:

[
    {
        "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.

[broth-itk]

@stefan123t Both HMS-1800 and HMS-2000 inverters running 1.0.27 in my case.

[stefan123t]

Bernhard @broth-itk that would somehow confirm the hunch that your Model HMS-350-1T Firmware Version 1.0.14 Firmware Build Date 2021-12-09 12:46:00 is not affected by the issue, right ?

Or is this also impacted if it is the sole / first inverter instead of the last ?

[broth-itk]

@stefan123t

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. Maybe coincidence.

[fir3bird]

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. The logs do not even show interrupt received like it does for Paule-Panter.

My logs

12:30:50.928 > RX Period End
12:30:50.928 > All missing
12:30:50.928 > Nothing received, resend count exeeded
12:30:50.977 > TX SystemConfigPara 868.00 MHz --> 15 A0 09 48 F5 80 16 40 84 80 05 00 66 BF 2A 54 00 00 00 00 00 00 00 00 D3 AF 0D 
12:30:51.233 > RX Period End
12:30:51.233 > All missing
12:30:51.233 > Nothing received, resend whole request
12:30:51.233 > TX SystemConfigPara 868.00 MHz --> 15 A0 09 48 F5 80 16 40 84 80 05 00 66 BF 2A 54 00 00 00 00 00 00 00 00 D3 AF 0D 
12:30:51.490 > RX Period End
12:30:51.490 > All missing
12:30:51.490 > Nothing received, resend whole request
12:30:51.490 > TX SystemConfigPara 868.00 MHz --> 15 A0 09 48 F5 80 16 40 84 80 05 00 66 BF 2A 54 00 00 00 00 00 00 00 00 D3 AF 0D 
12:30:51.745 > RX Period End
12:30:51.745 > All missing
12:30:51.745 > Nothing received, resend whole request
12:30:51.745 > TX SystemConfigPara 868.00 MHz --> 15 A0 09 48 F5 80 16 40 84 80 05 00 66 BF 2A 54 00 00 00 00 00 00 00 00 D3 AF 0D 
12:30:52.004 > RX Period End
12:30:52.004 > All missing
12:30:52.004 > Nothing received, resend whole request
12:30:52.004 > TX SystemConfigPara 868.00 MHz --> 15 A0 09 48 F5 80 16 40 84 80 05 00 66 BF 2A 54 00 00 00 00 00 00 00 00 D3 AF 0D 
12:30:52.207 > RX Period End
12:30:52.207 > All missing
12:30:52.207 > Nothing received, resend count exeeded
12:30:52.207 > Fetch inverter: 1164AXXXXXXX
12:30:52.207 > Request SystemConfigPara
12:30:52.256 > TX ChannelChangeCommand 868.00 MHz --> 56 A0 09 48 F5 80 16 40 84 02 15 21 20 14 12 
12:30:52.408 > RX Period End
12:30:52.408 > All missing
12:30:52.408 > Nothing received, resend whole request
12:30:52.408 > TX ChannelChangeCommand 868.00 MHz --> 56 A0 09 48 F5 80 16 40 84 02 15 21 20 14 12 
12:30:52.459 > RX Period End
12:30:52.459 > All missing
12:30:52.459 > Nothing received, resend whole request
12:30:52.459 > TX ChannelChangeCommand 868.00 MHz --> 56 A0 09 48 F5 80 16 40 84 02 15 21 20 14 12 
12:30:52.612 > RX Period End
12:30:52.612 > All missing
12:30:52.612 > Nothing received, resend whole request
12:30:52.612 > TX ChannelChangeCommand 868.00 MHz --> 56 A0 09 48 F5 80 16 40 84 02 15 21 20 14 12 
12:30:52.664 > RX Period End
12:30:52.664 > All missing
12:30:52.664 > Nothing received, resend whole request
12:30:52.664 > TX ChannelChangeCommand 868.00 MHz --> 56 A0 09 48 F5 80 16 40 84 02 15 21 20 14 12 
12:30:52.819 > RX Period End
12:30:52.819 > All missing
12:30:52.819 > Nothing received, resend count exeeded
12:30:52.872 > TX RealTimeRunData 868.00 MHz --> 15 A0 09 48 F5 80 16 40 84 80 0B 00 66 BF 2A 5C 00 00 00 00 00 00 00 00 DD C7 6D 
12:30:53.084 > RX Period End
12:30:53.084 > All missing
12:30:53.084 > Nothing received, resend whole request
12:30:53.084 > TX RealTimeRunData 868.00 MHz --> 15 A0 09 48 F5 80 16 40 84 80 0B 00 66 BF 2A 5C 00 00 00 00 00 00 00 00 DD C7 6D 

I double checked solder joints and config and the DTU lite stick from hoymiles was disconnected.

[Paule-Panter]

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. Please open a separate thread.

Anyway: It seems to me you have a first time connection problem as there is interrupt receiving. Maybe you should define a gpio1 pin connected to your cmt-modul in your file. I looked into my config: i only connected gpio3 (cmt) to the gpio4 (not pin4) of the esp32

And make a corresponding hw-connection between the both modules. And double, double check the pin/gpio reference table for your specific esp32- & cmt-moduls

So, and please open up a new thread for your problem.

Paule

[Paule-Panter]

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 ;-)

[swatermann]

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

[lehmartin]

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 Production Year 2023 Production Week 14 Model HMS-2000-4T Detected max. Power 2,000 W Bootloader Version 0.1.0 Firmware Version 1.0.16 Firmware Build Date 2022-08-03 15:20:00 Hardware Part Number 270692628 Hardware Version 01.00

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)?

[lehmartin]

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.

[spcqike]

in my experience, you dont need to change the frequency, its enough to just save the DTU settings page, again.

Is there any way to set a different frequency automatically, e.g. via MQTT?

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

https://www.opendtu.solar/firmware/web_api/

[lehmartin]

in my experience, you dont need to change the frequency, its enough to just save the DTU settings page, again.

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

[stefan123t]

CMT: Buffer full.

@Paule-Panter can you confirm the CMT: Buffer full. error in the USB Serial Console ? It may not be visible in the Web Console as it may arise after WiFi connection is lost.

@swatermann can you attach a log from the restarting the ESP until it shows the above error code ? We still lack the first occurrence of this error hence a detailled and long log is necessary to debug. Thanks!

[swatermann]

@stefan123t

Poll Inverval: 10s CMT2300A Frequency: 865.5MHz

LOG file attached log.txt

[stefan123t]

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

[Paule-Panter]

CMT: Buffer full.

@Paule-Panter can you confirm the CMT: Buffer full. error in the USB Serial Console ? It may not be visible in the Web Console as it may arise after WiFi connection is lost.

I have just started the usb serial log. Have to wait now to a new connection loss.

As reported three weeks ago, it is currently running reasonably stable. I'll check this over the next few days and upload the corresponding log file extract in the event of an error