search

suaveolent / ha-hoymiles-wifi

Home Assistant custom component for Hoymiles DTUs and the HMS-XXXXW-2T microinverters
MIT License
96 stars 5 forks source link

Loses connection to DTU after updating Power Limit 50 to 200 times #16

Open Holger2024 opened 4 months ago

Holger2024 commented 4 months ago

Describe the bug I run an HA automation to update the Power Limit. After updating the power level 50 to 200 times, the connection is lot again

To Reproduce Steps to reproduce the behavior: 1: Create this automation: alias: Update Power Level every 15 sek description: "" trigger:

2: Execute for some time and the connection drops (I never got it to work longer than 30 min).

Additional context I don"t think it"s an issue with my network or hardware, as I was running "https://github.com/DennisOSRM/hms-mqtt-publisher" for 8 weeks without any connection issues or drops.

PS: the couple minutes that the connection has worked, it was really awesome to see the "Nulleinspeisung" work :)

suaveolent commented 4 months ago

Thanks for reporting. I will have a look at it.

Might be a hardware limitation, though.

Just to make sure: You are not running the HMS-MQTT-Publisher simultaneously right? Because overlapping requests might also cause this issue.

Holger2024 commented 4 months ago

Thanks for looking into it.

Yes, the MQTT Publisher is removed. In HA, I"m just running Tasmota and Node Red to calculate that "input_number.hoyinput"

Hope you can reproduce it.

suaveolent commented 4 months ago

I have been running the following automations for > 40 minutes without any issue.

description: ""
trigger:
  - platform: time_pattern
    seconds: /15
condition: []
action:
  - device_id: c1d24b63a517e65901e501bde86219a7
    domain: number
    entity_id: 9058c21d26332a83612ecc2bbbba7f7b
    type: set_value
    value: 99
mode: single
alias: Power limit test 2
description: ""
trigger:
  - platform: time_pattern
    seconds: /20
condition: []
action:
  - device_id: c1d24b63a517e65901e501bde86219a7
    domain: number
    entity_id: 9058c21d26332a83612ecc2bbbba7f7b
    type: set_value
    value: 100
mode: single

So it's most likelely not due to too many requests. Do you see anything in your logs why this issue might occur? Are you running the latest version of the integration (0.1.4) and SW/HW version of the DTU ( "dtu_hw_version": "H00.01.00", "dtu_sw_version": "V00.01.11")?

Holger2024 commented 4 months ago

To get better insights, I also reset / rebooted everything completely (Router / Solar / Battery / Inverter / HA) And it took 2.5h until the connection crashed again. image

I"m running H 01.00 and S 01.08 and I have the 0.1.4 version

Which logs / items should I look for?

In the host log files I found this a couple minutes after the connection dropped - Last response from inverter at: 14:42:35: Feb 28 14:44:13 homeassistant kernel: audit: type=1334 audit(17091353.809:306): prog-id=84 op=LOAD Feb 28 14:44:13 homeassistant systemd-timesyncd[950]: Network configuration changed, trying to establish connection. Feb 28 14:44:13 homeassistant systemd-timesyncd[950]: Contacted time server 192.168.0.1:123 (192.168.0.1). Feb 28 14:44:13 homeassistant systemd[1]: Started Journal Gateway Service.

suaveolent commented 4 months ago

It seems like you are running an older version of the DTU SW. Can you try updating to the latest version to see if it fixes your problem ?

sts0210 commented 4 months ago

I am not sure if I have the same problem, I did not investigate as much as @Holger2024 yet but my issue presents itself the same way: After a while of tweaking power limit through HA the connection to the Hoymiles is lost and can not be recovered again. At the same time the inverter looses connection to my local Wifi which can only be recovered by entering the password again through the app.

This here indicates that this can happen if we set values too often. Also the fact we need to re-enter our local wifi connect data again is part of my problem. So there might just be an issue with setting values too often? Do you block repeated setting of values or can we as users break this?

I am running H00.01.00 / V00.01.11 on the DTU and H00.04.00 / V01.00.08 on the Micro

suaveolent commented 4 months ago

Yes that could indeed be the issue. Currently I am not limiting the amount of set operations.

I might introduce a limit to prevent this from happening.

Holger2024 commented 4 months ago

A small update for this situation:

Sunday I will try to upgrade SW of inverter and will report news.

Thanks

suaveolent commented 4 months ago

Thanks, can you maybe also try to increase the set interval (e.g. to 30s) to see if that fixes the problem?

I could then implement an according timer to prevent the user from trying to set the value too often.

sts0210 commented 4 months ago

I removed the component from HA and built an integration with a custom solution using hoymiles-wifi and MQTT. I built it so that no 2 interactions with the inverter are faster than 35 seconds (30 seems not be be enough because the inverter occasionally does not respond to queries...or hoymiles-wifi does filter these out). Meaning, if I want to set the power limit, it will skip the next async_get_real_data_new instead. First tests indicate the problem seems to be gone. But I have not had the luck of too much sun, so testing has been very limited.

suaveolent commented 4 months ago

Thanks, that could be one solution I could implement.

philiip11 might have found an even better solution, removing these limits alltogether: https://github.com/suaveolent/hoymiles-wifi/issues/4

I'm currently investigating the options.

Holger2024 commented 4 months ago

I had moved to a setup, where I only update the power level if it needs to change with a minimum update cycle of 5 seconds (With 30 Seconds the wasted energy would be too high).

Via the hoymiles cloud app I restarted the DTU every couple hours (not the inverter) and it worked good. Even if the connection was lost, a restart of the DTU would solve the problem within seconds. In that way it was running straight 72 hours until the sun was too weak yesterday to upcharge the battery.

Doing a restart via the integration would not help with the connection issue.

I hope this helps to decide on the options.

suaveolent commented 3 months ago

Thanks, most likely approach will be to auto restart the DTU every day. I'm still evaluating the options.

Holger2024 commented 3 months ago

I still see the disconnects - probably as I'm operating the inverter 24/7. With less power-level updates, I currently restart the DTU about 2-4 times per day.

Is there a way that I can reduce the frequency & scope of connections to the DTU in the configuration/code somewhere? E.g. I only need the voltage of one port from the inverter. All the other information is not really needed for my setup.

suaveolent commented 3 months ago

I still see the disconnects - probably as I'm operating the inverter 24/7. With less power-level updates, I currently restart the DTU about 2-4 times per day.

Is there a way that I can reduce the frequency & scope of connections to the DTU in the configuration/code somewhere? E.g. I only need the voltage of one port from the inverter. All the other information is not really needed for my setup.

These values are all retrieved in a single call. So it does not matter if you retrieve the voltages from one port or all.

What you can try is increasing the poll interval of the config and the app info. However, bear in mind tha the app info is used to get the current power level of the inverter.

You can find these values in: https://github.com/suaveolent/ha-hoymiles-wifi/blob/main/custom_components/hoymiles_wifi/const.py Line 16 and Line 17.

herrfk commented 3 months ago

Hello, I'm new here. Please excuse my bad english. The currently implemented power limitation should not be used for zero feed-in. The reason: As I understand it, the power limitation is currently transmitted "persistently" to the DTU, i.e. it is written directly into the Eprom. And these write cycles are limited. (I did it too, zero feed-in via automation, and it destroyed the inverter in four weeks). That's why I've been researching this fact for a few days. And in Ahoy or OpenDTU there is a limitation on the performance of both "persistent", i.e. writing to the EPROM, and "non-persistent" i.e. volatile. The "nonpersistent" method is probably also used directly by the original Hoymiles DTU for zero feed-in. Is it possible, analogous to Ahoi or OpenDTU, to include the "non-persistent" performance limitation? So if that's even possible. This would be very nice and the absolute game changer for zero feed-in with the new Hoymiles inverters.

Otherwise, a strong achievement for the integration into HA, and thank you for your commitment to it. Everything works without errors! The installation is very easy even for beginners. Perfect! 👍

suaveolent commented 3 months ago

Hello, I'm new here. Please excuse my bad english. The currently implemented power limitation should not be used for zero feed-in. The reason: As I understand it, the power limitation is currently transmitted "persistently" to the DTU, i.e. it is written directly into the Eprom. And these write cycles are limited. (I did it too, zero feed-in via automation, and it destroyed the inverter in four weeks). That's why I've been researching this fact for a few days. And in Ahoy or OpenDTU there is a limitation on the performance of both "persistent", i.e. writing to the EPROM, and "non-persistent" i.e. volatile. The "nonpersistent" method is probably also used directly by the original Hoymiles DTU for zero feed-in. Is it possible, analogous to Ahoi or OpenDTU, to include the "non-persistent" performance limitation? So if that's even possible. This would be very nice and the absolute game changer for zero feed-in with the new Hoymiles inverters.

Otherwise, a strong achievement for the integration into HA, and thank you for your commitment to it. Everything works without errors! The installation is very easy even for beginners. Perfect! 👍

Thank you so much for your input! I will put a warning to indicate that this setting should not be used too often. I will also look into how Ahoy or OpenDTU achieve the zero feed in option.

Holger2024 commented 2 months ago

That is really a bummer and I can be happy that I didn't reach that limit yet. I didn't really find a lot of info on that topic in google. Does anyone know, if setting the limit via the cloud interface is also writing it to the EPROM?

suaveolent commented 2 months ago

I am using the same command as the cloud interface, so yes it will also write to EEPROM.

thhoppst commented 2 months ago

Any news about of writing persistent to EEPROM or non-persistent? Can i destroy my device when i often set the PowerLimit ?

ThomWee commented 1 month ago

Would it be enough to disable the call to set_power_limit in number.py to stop the plugin sending data to the DTU / inverter? So I can ensure that my EEPROM does not die soon!? I had last week already a weird outage of my Inverter and now I'm worried that it already has first symptoms because of the described behavior.

suaveolent commented 1 month ago

If you are not setting the number via Home Assistant you should be safe. The set_power_limit should not be used for zero-feed-in realisation via e.g. automations.

Anthuzad commented 1 month ago

I'd be interested to realize zero-feed-in through my HM inverter and this plug-in (great work btw :) ), so are there any alternatives or is ist just not possible because every setting of the limit through HA writes to the EEPROM? I'd really like to set the limit through HA because my whole setup is integrated there.

PS: If it is important, I use a Hoymiles HMS-800W-T2 inverter.

suaveolent commented 1 month ago

Unfortunately I have not yet found a way to do so. I also did not find anything useful for such a feature in the official Hoymiles app.

Maybe we can ask Hoymiles if the inverter supports it? If there is an official way, I could most certainly integrate it in the custom component.

Anthuzad commented 1 month ago

I found something in the Ahoy issues https://github.com/lumapu/ahoy/issues/667, there also is a project specifically to communicate with the HMS-800W-T2: https://github.com/DennisOSRM/hms-mqtt-publisher

Maybe their method of communicating would be a way forward?

suaveolent commented 1 month ago

Unfortunately the way ahoy communicates with the inverter is completely different.

I know the project by Dennis, it is exactly the same way this integration communicates with the inverter.

github-actions[bot] commented 2 weeks ago

This issue is stale because it has been open for 30 days with no activity.

tehzap commented 2 weeks ago

So, I do understand that I may not use the Home Assistant Power Limitation to control my inverter (HMS-800W-2T). What would be a working alternative to write to the non-persistent volume with this inverter model?

suaveolent commented 2 weeks ago

So, I do understand that I may not use the Home Assistant Power Limitation to control my inverter (HMS-800W-2T). What would be a working alternative to write to the non-persistent volume with this inverter model?

Unfortunately we did not yet find a solution for that. The only way to communicate with the Inverter is via the DTU, and if the DTU does not expose such a functionality, there is no way of achieving it.