Request: Allow for Hub only control (optional DTU)

[Hidri02]

In my setup I don't have a DTU to control my HM800 inverter. My 4 panels are directly attached to my SF Hub 2000 with 1 AB2000 battery.

I understand that using the inverter for output control is quicker and more efficient and the support for direct panel input to the inverter is amazing as well! However it would still be nice to have the option to use SF-control without it for those of us that don't have a DTU and but still want to manage our SF locally without being dependent on the availability Zendures cloud. Also eliminating the need for an internet connection.

There are also some things SF-control does better than Zendure imo. E.g. bypass control. When I tried the app 2 weeks ago it wouldn't trigger the bypass when my battery was charges to my set limit of 90% :/

I have already adapted the code a bit for my own needs to get this working in my setup. If you are okay with adding this as an option, I would spend some more time to make it configurable and create a pull request.

[reinhard-brandstaedter]

There were so many problems with limiting the hub directly in the past that I'm reluctant to do a SF-only limiting. However a path forward (to not influence the rest of the code too much), I'd suggest to implement a "dummy-dtu" class that basically mimics a proper DTU and whose limit function just sets the hub's own output limit, and reports other needed metrics where available... On the other hand...getting a DTU (esp. for hoymiles) shouldn't be that big effort and provides other benefits as well.

[Hidri02]

So far it is working pretty well for me. But I will test it for a bit longer to see if any issues arise.

Of course there are situations where some power is sent to grid. But that amount seems to be quite small. I have also thought about including a "priority" mode like Zendure implemented in their app for Smart-CT mode. Basically it changes the behaviour of the output calculation to output less than the current demand as to have a buffer for which it can better react. In my current setup this also gets disabled when the battery reaches a certain threshold and solar is still producing more than the required demand. Basically before the battery gets full we can afford to be more aggressive with the output and risk losing more to the grid as otherwise we would lose production because of full batteries and panels getting capped to what inverter is legally allowed to output. (This is considering oversized panels) It would also help to adjust the output limit function to allow for quicker adjustments whenever lowering the output significantly. Ignoring the timer. (This is something that exists for DTUs but not directly for the SF Hub limit function ^^)

I'd suggest to implement a "dummy-dtu"

Interesting, I haven't thought about that before. It would definitely still require some modification to limitHomeInput as it will set the hub output there to whatever is possible and calculated to be needed via hub_contribution_ask. This seems to give it more than what is actually needed, just staying within limits and then expecting the DTU to do the output adjustment. Since this would interfere with the limit set calculation of the DTU dummy. This would have to be looked at it. Its also unclear how the adjustment algorithms you implemented for how quickly the DTU gets adjusted would work together with the Hub. I will try to look into it. My current solution just adds a variable for if inverter_control true or false and then skips most of limitHomeInput adding a few lines there to adjust the hub output. I will share what I did there when I get back to my computer.

On the other hand...getting a DTU (esp. for hoymiles) shouldn't be that big effort and provides other benefits as well.

Ah, what other benefits are there to it besides faster adapting and support for direct panels? I can only think about efficiency monitoring? While I am not completely opposed to getting a DTU, it will be another piece of equipment that I will need power for year around and fiddle with to update and integrate. Especially if I want to strip it from its cloud needs as well :s

[reinhard-brandstaedter]

Of course there are situations where some power is sent to grid. But that amount seems to be quite small. I have also thought about including a "priority" mode like Zendure implemented in their app for Smart-CT mode. Basically it changes the behaviour of the output calculation to output less than the current demand as to have a buffer for which it can better react. In my current setup this also gets disabled when the battery reaches a certain threshold and solar is still producing more than the required demand. Basically before the battery gets full we can afford to be more aggressive with the output and risk losing more to the grid as otherwise we would lose production because of full batteries and panels getting capped to what inverter is legally allowed to output. (This is considering oversized panels) It would also help to adjust the output limit function to allow for quicker adjustments whenever lowering the output significantly.

That's already covered. The "priority" mode is achieved with a min_charge_level which guarantees that the battery is charged first before giving anything away. Think of it like the first xxx Watts that are generated go to the battery. Then there is a max_discharge level that ensures not more than yyy Watts is drawn from the battery. Then there is also a rapid change detection which ensures a quick adjusting to fast demand changes.

While I am not completely opposed to getting a DTU, it will be another piece of equipment that I will need power for year around and fiddle with to update and integrate. Especially if I want to strip it from its cloud needs as well

An OpenDTU/AhoyDTU requires a few milliwatts and has no cloud dependency ;-) IMO it's a good embedded device to have to monitor your inverter and your panels, for optimizing your solarproduction etc.