search

reinhard-brandstaedter / solarflow-control

A tool to automatically control Zendure's Solarflow hub with more flexibility to match home power demand
67 stars 12 forks source link

Calculations based on solarpower do not work reliably if batteries are full #231

Closed mdillmann closed 4 months ago

mdillmann commented 4 months ago

Hi, im running the latest release with my HUB 2000 and noticed something wierd. The HUB 2000 seems to report solarpower based on the load acutally drawn from the panels. So if batteries are fully charged, the solarpower based on the load drawn from the inverter.

2024-05-01 10:34:57,713:INFO: HUB: S:305.1W [ 305.1,305.1 ], B:100% (100|100), V:53.4V (53.5|53.3), C: 0W, P:False (auto), F:0.0h, E:53.5h, H:303W, L:800W 2024-05-01 10:34:57,713:INFO: INV: AC:291.9W, AC_Prediction: 291.9W, DC:306.6W, DC_prediction: 306.6W (196.7|109.9), L:296W (148.0W/channel) [800W] 2024-05-01 10:34:57,715:INFO: SMT: T:VZLogger P:225.6W [ 240.3,240.3,240.3,238.2,235.8,231.8 ] Predict: 240.3W 2024-05-01 10:34:57,715:INFO: Direct connected panel are producing 0.0W, trying to get 503.7W from hub. 2024-05-01 10:34:57,715:INFO: Based on time, solarpower (305.1W) minimum charge power (0W) and bypass state (False), hub could contribute 305.1W - Decision path: 2.2. 2024-05-01 10:34:57,715:INFO: Not setting solarflow output limit to 800.0W as it is identical to current limit! 2024-05-01 10:34:57,715:INFO: Solarflow is willing to contribute 152.5W (per channel) of the requested 503.7! 2024-05-01 10:34:57,716:INFO: Setting inverter output limit to 304W (1 min moving average of 152W x 2) 2024-05-01 10:34:57,716:INFO: Sun: 06:00 - 20:45 Demand: 503.7W, Panel DC: (0.0W), Hub DC: (291.9W), Inverter Limit: 304.0W, Hub Limit: 800.0W

Sun is fully shining and the power to the home is not raised as the computation only sees solarpower as what is consumed and NOT what would be available.

Things can get worse and in a deadlock state. This morning: 2024-05-01 10:28:57,701:INFO: HUB: S:0.0W [ 0.0 ], B:100% (100|100), V:53.4V (53.5|53.3), C: -16W, P:False (auto), F:0.0h, E:53.4h, H: 16W, L:800W 2024-05-01 10:28:57,701:INFO: INV: AC:18.9W, AC_Prediction: 18.9W, DC:19.9W, DC_prediction: 19.9W (14.8|7.7), L: 20W (10.0W/channel) [800W] 2024-05-01 10:28:57,703:INFO: SMT: T:VZLogger P:484.1W [ 484.3,484.3,484.0,484.0,483.9,483.7 ] Predict: 484.3W 2024-05-01 10:28:57,703:INFO: Direct connected panel are producing 0.0W, trying to get 485.1W from hub. 2024-05-01 10:28:57,704:INFO: Based on time, solarpower ( 0.0W) minimum charge power (0W) and bypass state (False), hub could contribute 0.0W - Decision path: 2.2. 2024-05-01 10:28:57,704:INFO: Not setting solarflow output limit to 800.0W as it is identical to current limit! 2024-05-01 10:28:57,704:INFO: Solarflow is willing to contribute 0.0W (per channel) of the requested 485.1! 2024-05-01 10:28:57,704:INFO: Not setting inverter output limit as it is identical to current limit! 2024-05-01 10:28:57,705:INFO: Sun: 06:00 - 20:45 Demand: 485.1W, Panel DC: (0.0W), Hub DC: (21.4W), Inverter Limit: 20.0W, Hub Limit: 800.0W 2024-05-01 10:29:51,018:INFO: Reading last full time: 2024-05-01 10:29:51

The inverter was in "standby", with limit 20W, HUB 2000 drew this minimal load from the panels but calculations smooted to 0. So the current algo assumed, no solarpower available and did not raise the inverter limit even demand was there. I nuged the system by directly setting the inverter-limit to 100% via openDTU.

Not sure if HUB 2000 does something different there. Perhaps introducing an artificial "solarpower" while batteries are 100% full would work ?

reinhard-brandstaedter commented 4 months ago

The hub’s “normal” behavior at 100% battery while bypass is off is to limit the solarinput down. So in your situation you are actually waiting for the hubs firmware to enable the bypass properly.

reinhard-brandstaedter commented 4 months ago

Once your hub switches bypass on you should see solarpower go up again and feed in from the hub. sf-control will then also adjust the limit accordingly. You can tey this my manually turning BP on or wait for the firmware which should do this (can take some time)

mdillmann commented 4 months ago

Thanks for the clarification. The hub did not switch bypass on for several hours this morning :-(.

Is it neccesary for solarflow-control to have BP set to auto ? Because I'm wondering how things would work if BP is permanently disabled ? We have socSet so know the desired battery-level and the actual battery level. Would it be a problem to simply assume if batteries are full and no BP set, we could draw as much as needed from the hub (and max inverter) to satisfy the demand ?

reinhard-brandstaedter commented 4 months ago

I'm actually finishing the bypass control via sf-control right now. There will be a new master build with that soon. There has been some work in the past week on that with mixed results on that new feature, but it is looking good now. I recommend running the hub with min/max SoC of 0/100 and then give the control_bypass option a try, letting sf-control steer the bypass.

reinhard-brandstaedter commented 4 months ago

Is it neccesary for solarflow-control to have BP set to auto ? Because I'm wondering how things would work if BP is permanently disabled ? We have socSet so know the desired battery-level and the actual battery level. Would it be a problem to simply assume if batteries are full and no BP set, we could draw as much as needed from the hub (and max inverter) to satisfy the demand ?

The behavior of the SF Hub before the bypass was introduced was exactly the same as if you would now disable the bypass: Once the battery is full, or reached the socSet, it would simply turn down solarinput. So, having the BP off, means there is nothing we can do once the battery reaches it's configured max, except discharging the battery and then let it charge again. So bypass is definitely the better option here.