OpenDTU slow down with two inverters and one not reachable

[leahoswald]

Hey,

I have a somehow special problem. I have two inverters on in normal operation and one that is connected to a Solix E1600. This second inverter is offline during the time the battery is charged because the output to the inverter is set to zero for this time. After the battery is fully charged, the solar power is bypassed to the inverter, and it is online again. During the night, the battery powers the inverter. This is possible with the "send request at night option". But I observed a problem while the second inverter is offline due to charging. In this time the openDTU is very slow, sometimes not responding at all and request (interval is set to 5sec) for the first normal inverter go up to >30sec.

I would guess that the openDTU is trying too hard to reach the offline inverter. I think I could turn off the requests during loading time with an external script via API but maybe it would be a good idea to implement some slowdown mechanism if an inverter is not reachable for a longer time.

The log shows messages like this (if it works at all during the problem):

11:30:05.097 > All missing
11:30:05.097 > Nothing received, resend whole request
11:30:05.097 > TX ActivePowerControl Channel: 75 --> 51 84 82 66 23 80 17 29 68 81 0B 00 17 70 00 00 0F 05 23 
11:30:19.188 > RX Period End
11:30:19.188 > All missing
11:30:19.188 > Nothing received, resend whole request
11:30:19.188 > TX ActivePowerControl Channel: 61 --> 51 84 82 66 23 80 17 29 68 81 0B 00 17 70 00 00 0F 05 23 

If this qualifies as a bug I would also open an issue.

[stefan123t]

I think this is not a bug but more a Feature Request.

You should not set the inverter to off by using an ActivePowerLimit of 0%, because then the inverter does not receive further commands any more. It is best practice to go only down to 2-3/5% according to the Hoymiles DTU. Anything below the threshold of 20W the Inverter may not be able to receive / respond anymore.

I do think it is possible to set such a low limit and turn the inverter off. This was IMHO also recommended as a Feature Request in the past, instead of 0% ActivePowerLimit the DTU sets the low threshold of 2/3% and turns the inverter off.

Regarding your original observation that despite the inverter being off / below low-limits the DTU continues to try to reach the inverter this is indeed current behaviour. Maybe some (existing/additional) status flags could be used to skip trying to connect to such an unavailable Inverter until it is turned on again ?

But then that maybe out of scope for the base OpenDTU according to judgement from @tbnobody our main developer and maintainer of the trunk.

Did you verify whether OpenDTU-OnBattery does include some solution for this situation with its DPL Dynamic Power Limit and other BMS connectivity ?

[leahoswald]

You should not set the inverter to off by using an ActivePowerLimit of 0%, because then the inverter does not receive further commands any more. It is best practice to go only down to 2-3/5% according to the Hoymiles DTU. Anything below the threshold of 20W the Inverter may not be able to receive / respond anymore.

I don't set it off by intention using a limit of 0. The battery between the solar modules and the inverter (HM600) is just not sending any power during charging to prioritize charging.

I'm totally okay if you say it's out of scope. I can handle it by connecting the battery API and the openDTU API and just disable and reenable the requests depending on the battery status. I was just a little surprised that this is causing an instable state on openDTU. So I wanted to report it just to be sure that it's not a bug or something.

Did you verify whether OpenDTU-OnBattery does include some solution for this situation with its DPL Dynamic Power Limit and other BMS connectivity ?

Never heard of it before but I will have a look.

[tbnobody]

I was just a little surprised that this is causing an instable state on openDTU.

Background is, that in this case the command queue fills up and consumes all the available memory. No commands inserted by the MQTT or Web API will be deleted or skipped. If some commands take too long there is no chance to process the queue.
On the other hand, automatic commands (like query for current inverter data) will only be inserted into the queue if it's empty.

I have it on my long term todo list to optimize the queue handling and remove duplicated PowerLimit commands.

[stefan123t]

I believe #1088 somewhat matches your explanation and should solve this once fixed / implemented.

[leahoswald]

I guessed something like that. Then I will work around it for the moment and thanks to all of you for openDTU :)

[github-actions[bot]]

This discussion has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns.