Temporary poor connection to HMS-400-1T

[MichaMEG]

What happened?

Sometimes the connection works well, but occasionally the data displayed is not fully updated.

To Reproduce Bug

Sometimes the connection works well, but occasionally the data displayed is not fully updated:
"Aktuelles Limit: 400 W | 100 %
Letzte Aktualisierung: vor 455 Sekunden"
At the same time, we read out too 600-HM without any problems.
Strangely enough, the performance data is still sometimes updated. Sometimes there are no problems for hours.

Expected Behavior

I would have expected a smooth display

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

c144b68

Relevant log/trace output

16:23:50.966 > TX RealTimeRunData 865.00 MHz --> 15 84 88 16 84 80 16 33 64 80 0B 00 66 75 8C F6 00 00 00 00 00 00 00 00 3C 7A EE 
16:23:51.629 > RX Period End
16:23:51.629 > All missing
16:23:51.629 > Nothing received, resend whole request
16:23:51.629 > TX RealTimeRunData 865.00 MHz --> 15 84 88 16 84 80 16 33 64 80 0B 00 66 75 8C F6 00 00 00 00 00 00 00 00 3C 7A EE 
16:23:52.140 > RX Period End
16:23:52.140 > All missing
16:23:52.140 > Nothing received, resend whole request
16:23:52.140 > TX RealTimeRunData 865.00 MHz --> 15 84 88 16 84 80 16 33 64 80 0B 00 66 75 8C F6 00 00 00 00 00 00 00 00 3C 7A EE

Anything else?

generic_esp32s3

Please confirm the following

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

[crisi-solar]

Ich kann nach umfangreichen Tests bestätigen dass bei mir für mein Problem HoymilesZeroExport mit openDTU - hängt in der Früh "reserve85/HoymilesZeroExport#211"
ausschließlich die openDTU dafür verantwortlich ist.

Mit Ahoy 0.8.84 funktioniert es ohne Probleme mit den Hoymiles WR und auch mit HoymilesZeroExport!

[tbnobody]

It would have been usefull to know that you are sending limits in the first place.

Commands inserted by the API or by the WebUI have always a higher priority than automatically inserted commands (like statistics data). That means if you are sending limits to often, there is no chance to execute the statistics command anymore.

[MichaMEG]

But that has nothing to do with my bug report.

I have a suspicion that if I set the transmit power to -2 dBm it seems to work, but I still have to watch it a bit.

[MichaMEG]

There were problems again this morning, after lowering to -5 it is running again for the time being.

[MichaMEG]

That's not it either.
As soon as I change the transmission power a little, it works for the rest of the day.

[MichaMEG]

I have now replaced the power supply unit and the USB cable.
The cable was included with the OpenDTU Fusion, but it seems a bit thin and my mobile phone only wants to charge extremely slowly with it.
It seems to work reliably with the very powerful USB-C power supply and cable I'm using now.
I will probably get the USB-C power supply from the Raspberry Pi 4 for the OpenDTU.
That should easily suffice for this purpose and is relatively cheap.

[MichaMEG]

It was the power supply.
Assumption:
The power supply should not drop below 5 volts under load and the cable should be of high quality

[pioneer-01]

It was the power supply. Assumption: The power supply should not drop below 5 volts under load and the cable should be of high quality

What power supply do you use now?

[MichaMEG]

At the moment:
https://www.amazon.de/2er-Pack-25W-Ladeger%C3%A4t-Ladekabel-Netzteil-Schwarz/dp/B0BTPLNNP3?pd_rd_w=dqGPK&content-id=amzn1.sym.9097fbb8-3538-4cca-b6af-bbe5a0206861&pf_rd_p=9097fbb8-3538-4cca-b6af-bbe5a0206861&pf_rd_r=76311E0RNMPX43QV0EXR&pd_rd_wg=C1mTL&pd_rd_r=3d731e7c-7ad8-49fa-887a-c1d22bd51796&pd_rd_i=B0BTPLNNP3&psc=1&ref_=pd_bap_m_grid_dv_rp_0_13_i
with this cable:
https://www.amazon.de/RAVIAD-Ladekabel-Schnellladekabel-Samsung-Galaxy/dp/B0B4NPG92J?pd_rd_w=D0FfD&content-id=amzn1.sym.16f1919d-aebd-4593-95d7-5427f5ff6740&pf_rd_p=16f1919d-aebd-4593-95d7-5427f5ff6740&pf_rd_r=AYKMERGDJ5ARYBFRCVP6&pd_rd_wg=27jbm&pd_rd_r=ac89742f-c312-4880-a047-f016c71a1d60&pd_rd_i=B0B4NPG92J&psc=1&ref_=pd_basp_m_rpt_ba_s_4_pr_sc

[MichaMEG]

It has improved a lot, but it still happens from time to time.
Is there anything that can be improved to make it more stable?
I'm going to order a Raspberry Pi power supply now, but I think there's still a small problem.

[ms49434]

It has improved a lot, but it still happens from time to time. Is there anything that can be improved to make it more stable? I'm going to order a Raspberry Pi power supply now, but I think there's still a small problem.

I can see from your report that you are using the default frequency of 865 MHz for the communication with the HMS inverter. Could you please adjust the frequency to a higher value, i.e. 868.25 MHz and report if it makes a difference or not.
Please be reminded that it can take up to 15 minutes to reconnect after changing the frequency.

[MichaMEG]

I will and will report back in a few days.
Thank you very much

[MichaMEG]

Unfortunately, this did not help either.
After switching to a different transmission power, regardless of the direction, the reception is back.
But it was worth a try, thank you

[MichaMEG]

Mit dem Netzteil vom Raspberry 5 läuft es jetzt relativ stabil.
Wobei das Netzteil etwas übertrieben ist (25 Watt bei 5.1 Volt.
Falls es mal in der Webanzeige hängt, hilft meistens ein Reload im Webbrowsers.

[MichaMEG]

OK, now it works with the Raspberry Pi power supply.

[MichaMEG]

Just when you think all is well...
It's happened again

[stefan123t]

@MichaMEG Do you have the condensators close to the NRF/CMT Module ? Can you post an image of your hardware ?

[MichaMEG]

It is the original from this website:
https://shop.allianceapps.io/products/allianceapps-opendtu-fusion?pr_prod_strat=jac&pr_rec_id=b9045cc91&pr_rec_pid=8454540132680&pr_ref_pid=8439160406344&pr_seq=uniform

and with 1306 Display

[stefan123t]

@MichaMEG why don’t you try OpenDTU-OnBattery and use the built in Dynamic Power Limiter with that. I assume the reserve85 solution is sending too frequent ActivePowerLimit commands to the OpenDTU and does not wait for confirmation of the new Power Limit through the REST API before sending the next command. This can render the inverter unresponsive for at least 15 minutes.

[MichaMEG]

Sorry, I'm not setting a power limit, that must be a misunderstanding.
I just want to know how much the inverters produce and not limit anything.

[stefan123t]

@MichaMEG i must have mistaken this because in your first post you mentioned the 100%/400W Active Power Limit and crisi-solar mentioned his use of the reserve85 tool which indeed sets the Active Power Limit.

So you do have 2x HM-600 and 1x HMS-400-T1 connected / configured in your OpenDTU Fusion board from Alliance Apps.
Did you have to connect the foil antennas yourself or were they pre-connected by Alliance Apps ?
The beefy power supply you have should be sufficient for the OpenDTU Fusion board.

Can you please send us the first seven digits of your serial ID plus a screenshot / copy of your Inverter Info as it contains a couple of details, e.g. model type, build date / week, HW Version, etc. which we need to further analyse the issue.
We have seen new HMS versions lately which have issues with the channel hopping / default RF frequency of 865 MHz preset for the HMS models. That is why the comment from @ms49434 was actually good advice.

[stefan123t]

Also see #2137 for another similar issue with HMS models with Firmware-Version 1.0.27 and Firmware-Build Date 2023-06-05 10:24:00 or later.