Closed MichaMEG closed 6 days ago
Ich kann nach umfangreichen Tests bestätigen dass bei mir für mein Problem HoymilesZeroExport mit openDTU - hängt in der Früh "https://github.com/reserve85/HoymilesZeroExport/issues/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!
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.
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.
There were problems again this morning, after lowering to -5 it is running again for the time being.
That's not it either. As soon as I change the transmission power a little, it works for the rest of the day.
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.
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
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?
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
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
Anything else?
generic_esp32s3
Please confirm the following