Bypass state not recognized correctly on Hub2000

[floriandrott]

If the battery is completely full (100%) the hub goes into bybass mode. The bypass mode is not correctly detected by solarflow.

Home Assistant integration shows

Based on the MQTT topics it should detect the bypass state:

The MQTT value goes to "2" which means bypass on but as shown in picture one, the solarflow-control is not detecting it.

[reinhard-brandstaedter]

What is your minSoc and socSet variables set to?

Is this log right after startup? Did you let it run for a bit? Did you start it at a time when the bypass was on or off?

I'm beginning to think your best options are at this time to: a) not use sf-control's bypass control and let the hub itself do whatever it thiks is correct for BP b) report a problem with Zendure, asking for the same reporting of the BP state like in Hub1200 in the pass property

[floriandrott]

@reinhard-brandstaedter this morning it went directly into

2024-06-05 09:46:23,983:INFO: HUB: S:132.0W [ 132.0,132.0 ], B: 4% ( 4), V:44.0V (44.0), C:-491W, P:True (manual, not possible), F:13.7h, E:433.1h, H:600W, L:600W
2024-06-05 09:46:23,983:INFO: INV: AC:577.6W, DC:610.0W (304.9|306.3), L:600W (300.0W/channel) [800W]
2024-06-05 09:46:23,983:INFO: SMT: T:Smartmeter P:-388.0W [ -385.4,-385.4,-386.3,-386.5,-385.4,-384.2 ]
2024-06-05 09:46:23,983:INFO: Direct connected panel are producing 0.0W, trying to get 154.6W from hub.
2024-06-05 09:46:23,984:INFO: Based on time, solarpower (132.0W) minimum charge power (250W) and bypass state (True), hub could contribute 600.0W - Decision path: 0.2.

So, it occurs also when sf-control is running several hours. Yesterday I was starting sf-control when BP was off. And the log from yesterday was after the startup of sf-control. Now I was runnning sf-control over night without any restart and bypass state is unfortunately true again.

2024-06-05 05:14:25,931:INFO: HUB: S:0.0W [ 0.0 ], B: 19% (19), V:48.3V (48.3), C:-226W, P:True (manual, possible), F:9.2h, E:428.6h, H:218W, L:600W
2024-06-05 05:14:25,931:INFO: INV: AC:208.3W, DC:219.8W (123.1|123.2), L:226W (112.8W/channel) [800W]
2024-06-05 05:14:25,931:INFO: SMT: T:Smartmeter P:114.0W [ 80.2,80.2,85.0,96.8,109.5,139.9 ]
2024-06-05 05:14:25,931:INFO: Direct connected panel are producing 0.0W, trying to get 333.2W from hub.
2024-06-05 05:14:25,932:INFO: Turning hub bypass OFF
2024-06-05 05:14:25,932:INFO: Good morning! We have consumed 63% of the battery tonight!
2024-06-05 05:14:25,932:INFO: Syncing time of solarflow hub (UTC): 2024-06-05, 05:14:25
2024-06-05 05:14:25,932:INFO: Turning hub bypass OFF
2024-06-05 05:14:25,932:INFO: Based on time, solarpower ( 0.0W) minimum charge power (250W) and bypass state (False), hub could contribute 333.2W - Decision path: 0.1.2.1.
2024-06-05 05:14:25,932:INFO: Not setting solarflow output limit to 600.0W as it is identical to current limit!
2024-06-05 05:14:25,932:INFO: Solarflow is willing to contribute 166.5W (per channel) of the requested 333.2!
2024-06-05 05:14:25,933:INFO: Setting inverter output limit to 332W (1 min moving average of 166W x 2)
2024-06-05 05:14:25,933:INFO: Sun: 05:11 - 21:18 Demand: 333.2W, Panel DC: (0.0W), Hub DC: (233.3W), Inverter Limit: 332.0W, Hub Limit: 600.0W
2024-06-05 05:14:25,933:INFO: SMT triggers limit function: 109.5 -> 139.9: executed
2024-06-05 05:14:33,681:INFO: HUB: S:0.0W [ 0.0 ], B: 19% (19), V:48.2V (48.2), C:-268W, P:True (manual, possible), F:9.2h, E:428.6h, H:264W, L:600W
2024-06-05 05:14:33,681:INFO: INV: AC:258.3W, DC:272.7W (176.9|177.3), L:332W (166.0W/channel) [800W]
2024-06-05 05:14:33,681:INFO: SMT: T:Smartmeter P:-17.0W [ 72.8,72.8,78.9,90.2,95.1,89.4 ]
2024-06-05 05:14:33,681:INFO: Direct connected panel are producing 0.0W, trying to get 384.9W from hub.
2024-06-05 05:14:33,681:INFO: Turning hub bypass OFF
2024-06-05 05:14:33,681:INFO: Based on time, solarpower ( 0.0W) minimum charge power (250W) and bypass state (False), hub could contribute 384.9W - Decision path: 0.1.2.1.

The logs are telling me that sf-control is trying to disable BP. Fun fact is that the hub is not in BP mode so sf-control just thinks it is. This behavior started with the latest DEV version. With the version several days ago, it was working ... only the limit variable issue was present.

socSet = 100; minSoc = 3 are my settings.

[floriandrott]

@reinhard-brandstaedter I now switched to the current master version and directly the bypass state is correctly detected.

2024-06-05 09:55:33,077:INFO: Turning hub bypass OFF
2024-06-05 09:57:33,076:INFO: HUB: S:97.5W [ 98.0,98.0,97.5 ], B: 4% ( 4), V:45.8V (45.8), C: 28W, P:False (manual, possible), F:13.9h, E:433.3h, H: 68W, L:600W
2024-06-05 09:57:33,079:INFO: INV: AC:82.0W, AC_Prediction: 82.0W, DC:86.5W, DC_prediction: 86.5W (42.8|43.7), L:100W (50.0W/channel) [800W]
2024-06-05 09:57:33,081:INFO: SMT: T:Smartmeter P:116.0W [ 120.8,120.8,120.5,123.2,118.6,117.2 ] Predict: 121.0W
2024-06-05 09:57:33,081:INFO: Direct connected panel are producing 0.0W, trying to get 159.2W from hub.
2024-06-05 09:57:33,082:INFO: Based on time, solarpower (97.5W) minimum charge power (250W) and bypass state (False), hub could contribute  0.0W - Decision path: 2.2.

[reinhard-brandstaedter]

The current master is behind those changes done for hub2000. Let is run a few days with BP switches to see if it really works. Or did you mean SF firmware?

[floriandrott]

@reinhard-brandstaedter sure I can test this some days. I meant sf-control in regards of using the master branch right now.

I know that master hasn't included the hub2000 changes. Unfortunately I can't use the dev branch at all due to the wrong BP state. I switched to dev and directly sf-control thinks that the hub is in bypass.

2024-06-06 10:47:43,314:INFO: HUB: S:186.6W [ 199.5,199.5,197.7,188.6,180.7,186.6 ], B: 12% (12), V:48.3V (48.3), C:-281W, P:True (manual, possible), F:38.8h, E:458.2h, H:439W, L:600W
2024-06-06 10:47:43,314:INFO: INV: AC:429.9W, DC:448.1W (226.0|227.2), L:600W (300.0W/channel) [800W]
2024-06-06 10:47:43,314:INFO: SMT: T:Smartmeter P:-87.0W [ 85.3,85.3,88.6,38.5,-9.6,-54.8 ]
2024-06-06 10:47:43,314:INFO: Direct connected panel are producing 0.0W, trying to get 334.5W from hub.
2024-06-06 10:47:43,315:INFO: Based on time, solarpower (186.6W) minimum charge power (190W) and bypass state (True), hub could contribute 600.0W - Decision path: 0.2.

As @mavo mentioned in https://github.com/reinhard-brandstaedter/solarflow-control/issues/244#issuecomment-2143986380 there seems an issue with the BP state detection. Due to this sf-control sets the inverter limit to maximum all the time and empties the battery.

You you please check this change and then I would switch back to DEV. But right now if I would use the DEV branch, the battery just drained.

[mavo]

You can modify the code yourself @floriandrott. Did the same.

How to:

1. ssh into the machine running your sf control app (the docker host)
2. docker ps (find the containerId)
3. docker exec -it <containerID> /bin/sh
4. vi solarflow.py
5. find method getBypass() and change this line into return self.bypass_mode == 2
6. write and quit
7. restart the docker container

Additionally, I also added setting the limit in decision path 0.1 for safety reasons to not get a problem with the undefined limit var if BP should be turned off at the end of the day.

MaVo

[reinhard-brandstaedter]

Reverting that change however means that you could be in an undefined state until the hub decides to send an update via MQTT to the passMode topic, which means you will eventually for 2 minutes hang in an undefined state of path 0.1 with an arbitrary default limit variable. Not sure if this is desireable.

[reinhard-brandstaedter]

Did anyone of you ever try to just the the hub run without sf-control steering the bypass? Apparently the hub2000 should do a much better job with the own bypass control. So it would be interesting how it behaves.

[mavo]

Reverting that change however means that you could be in an undefined state until the hub decides to send an update via MQTT to the passMode topic, which means you will eventually for 2 minutes hang in an undefined state of path 0.1 with an arbitrary default limit variable. Not sure if this is desireable.

I don't get this. Why would I end there? At which point in time? When BP is toggled on, or should be toggled off? When the energy level reaches 100%, it sends a MQTT msg with passmode=2, so it would be updated from MQTT's side.

So it means this can only be for BP off scenarios? And there, as I also added in path 0.1 the line limit = demand would mean, it tries to provide what my house consumes... 🤔 Where is the issue of my train of thoughts? Is there any?

[mavo]

Did anyone of you ever try to just the the hub run without sf-control steering the bypass? Apparently the hub2000 should do a much better job with the own bypass control. So it would be interesting how it behaves.

Actually, I did not. Maybe I give it another go... But this is kinda meh, as I cannot see its BP state in HA due to the fact it does not report it in the pass property properly.

[floriandrott]

Did anyone of you ever try to just the the hub run without sf-control steering the bypass? Apparently the hub2000 should do a much better job with the own bypass control. So it would be interesting how it behaves.

@reinhard-brandstaedter do you mean a) not using sf-control at all and just limit the inverter in a different way or b) using sf-control if control_bypass = false and leaving the rest as it is?

Option b I tried it 2 weeks ago but here I saw that the bypass was activated / deactivated several times (everytime when solarpower was falling down under the inverter limit). But I can try this out again. Just let me know if option a or b.

[reinhard-brandstaedter]

@floriandrott option b) this is what gives you exactly how Zendure intended the ByPass to work (or not work). The whole sf-control steering the bypass was ever meant to be experimental, to get long term results if it can be done with less relay switching. For the hub1.2 this is now working well for some weeks, but the extra delays and hazzle with hub2k without an ability to test it properly is annoying.

[floriandrott]

@reinhard-brandstaedter interesting fact I have seen in MQTT explorer:

The hub is now with the setting bypass = auto. The hub switched to bypass = on and in MQTT Explorer I also see pass=1 and passMode=0. Based on this sf-control thinks now that the hub is not in bypass:

2024-06-06 17:46:24,754:INFO: HUB: S:243.2W [ 242.7,242.7,243.2 ], B:100% (100), V:51.1V (51.1), C: 0W, P:False (auto, possible), F:0.0h, E:465.1h, H:238W, L:600W
2024-06-06 17:46:24,754:INFO: INV: AC:141.5W, DC:149.1W (74.2|74.9), L:144W (72.0W/channel) [800W]
2024-06-06 17:46:24,754:INFO: SMT: T:Smartmeter P:249.0W [ 188.6,188.6,202.2,221.5,226.8,238.3 ]
2024-06-06 17:46:24,754:INFO: Direct connected panel are producing 0.0W, trying to get 339.6W from hub.
2024-06-06 17:46:24,754:INFO: Based on time, solarpower (243.2W) minimum charge power (100W) and bypass state (False), hub could contribute 143.2W - Decision path: 2.2.

I think based on the changes for the hub2k, the bypass detection via pass=1 is not working anymore. Really crazy how the hub reacts.

[mavo]

@reinhard-brandstaedter @floriandrott I, today had a floorless day with the changes I mentioned. It enabled the BP exactly once and on disable after the sun was down enough so that house consumption exceeded solar power it did turn it off once. So for me it works as it should be, with the changes I applied.

As I also set the limit to demand on BP disable it just worked without any issue with unset variables.

[reinhard-brandstaedter]

I think based on the changes for the hub2k, the bypass detection via pass=1 is not working anymore. Really crazy how the hub reacts.

So with your observation, that would mean that the hub2k only reports the bypass state via pass when activated from auto mode? That would mean another change to handle that case separately to determine it correctly in sf-control sigh

[reinhard-brandstaedter]

@mavo I think the actual issue was rooted here This line now only sets the (internal) BP state to true when passMode = 2. It used to also falsely set it to true when it was 1. Your code works, yes but still it would leave the state wrong, and it could therefore cause a race condition if the hub pushes an update to passMode just at the wrong time.

[floriandrott]

So with your observation, that would mean that the hub2k only reports the bypass state via pass when activated from auto mode? That would mean another change to handle that case separately to determine it correctly in sf-control sigh

It seems like. Today I will check this again. Maybe it has also something to do with the latest firmware update. For BMS I got the notification to install BMS-Firmware v1.0.14 and I installed it yesterday before bypass was activated. It's just for the battery but maybe it also changed how the bypass-information are reported.

[mavo]

I did also update the BMS Firmware, and running still in manual mode. So I can check today if maybe the BP has really got fixed somehow or if it only works in auto mode as it should be. today = if the sun keeps beating the clouds, battery is at 91% atm, so there is a good chance. Lets see if they did something about the pass property 🤞

[mavo]

Classic case of schade. BP is on, but pass property is still 0. So this is not fixed :-(

[floriandrott]

@reinhard-brandstaedter hub is in auto-mode. Bypass was activated and pass=1. In auto mode it's working.

In HA I also see that bypass state = ON. The sf-control logs are reporting:

2024-06-07 16:23:16,201:INFO: HUB: S:280.0W [ 280.0,280.0 ], B:100% (100), V:52.1V (52.1), C: 0W, P:False (auto, possible), F:0.0h, E:487.7h, H:276W, L:600W
2024-06-07 16:23:16,201:INFO: INV: AC:231.7W, DC:244.6W (123.6|123.6), L:228W (114.0W/channel) [800W]
2024-06-07 16:23:16,201:INFO: SMT: T:Smartmeter P:102.0W [ 105.2,105.2,106.0,103.0,102.8,101.1 ]
2024-06-07 16:23:16,201:INFO: Direct connected panel are producing 0.0W, trying to get 295.2W from hub.
2024-06-07 16:23:16,201:INFO: Based on time, solarpower (280.0W) minimum charge power (50W) and bypass state (False), hub could contribute 230.0W - Decision path: 2.2.

I'm not sure why sf-control is not detecting bypass currently, even it's correctly reported in HA. I'm on the latest DEV branch.

[reinhard-brandstaedter]

Well if the hub2k behaves like the hub1.2k only when in auto mode but behaves differently when manual mode is used then this is a whole new scenario. Right now there is special code for hub2k only considering the passMode property, ignoring the pass property. So that is kind of expected now with this inconsistent behavior of the hub2k. I still think you should report this to Zendure so they fix that.

[Hidri02]

Did anyone of you ever try to just the the hub run without sf-control steering the bypass? Apparently the hub2000 should do a much better job with the own bypass control. So it would be interesting how it behaves.

Had it running cloud connected last week in CT mode (connected to shellyproem3) with bypass set to automatic. It did not switch to bypass when the battery reached the set limit and started throtteling back production from the solar panels to match the current power needs. Whenever the power need spiked up or solar production dropped for a bit because of e.g. clouds the battery would kick in and discharge, only to get recharged again to full after solar power comes back.

So basically it just stayed in a constant state of charging / discharging at the limit while reducing production effiency of the panels, never going into bypass mode.

As for manually setting bypass: That worked flawlessly without issues through the app. However you can not set manual bypass and have CT mode. I had to disable CT mode and re enable later when switching off bypass manually.

[floriandrott]

Alright, I can open a ticket by Zendure. With the latest release (v0.68) I recognized that the sf-control is not really taking the bf-state into account. In HA it is correctly reported with bypass state=ON and also in MQTT it says pass=1. But in the sf-control logs it says:

2024-06-20 18:02:24,091:INFO: HUB: S:22.9W [ 22.4,22.4,22.9 ], B:100% (100), V:53.3V (53.3), C: 0W, P:False (auto, possible), F:0.0h, E:801.4h, H: 0W, L:800W

With that the wrong decision path is taken. In release v0.67 all works fine. @reinhard-brandstaedter so I assume there is something not working with the changes of v0.68.

[reinhard-brandstaedter]

In HA it is correctly reported with bypass state=ON and also in MQTT it says pass=1.

That would mean that the hub2k suddenly would report the bypass just like hub1.2k. Which seems unrealistic without a firmware update. Or it is buggy and sometimes does and sometimes doesn't.

0.67 is not differentiating between Hub1.2k and Hub2k and relies on pass only. If that works then this whole thread and discussion is totally obsolete and was a waste of time. I'm wondering what you Hub2k users have been testing/reporting then :-) Because that would mean my inittial assumption that the Hub2k behaves EXACTLY like the Hub1.2k is true.

So can you please verify this by performing a few manual BP switches (without sf-control running), just by sending the passMode property via MQTT to switch between bypass on/off and observe the pass variable. And keep in mind that the switch is not immediate (it is not a light switch!).

[floriandrott]

@reinhard-brandstaedter as mentioned in here https://github.com/reinhard-brandstaedter/solarflow-control/issues/244#issuecomment-2153209328, the hub2k reports pass correct when bypass-control is handled by the hub. Therefore I run sf-control in the moment with control_bypass=false. That's maybe why sf-control is not picking bypass up correctly in v0.68.

I can give it a try with control_bypass=trueas well. I will also try out manually sending passMode.

[joe63]

@floriandrott

I can give it a try with control_bypass=trueas well. I will also try out manually sending passMode.

Hallo, How is your setup now? control_bypass true or false? how does it work?

[floriandrott]

@joe63 I was running until today on release v0.67 and with control_bypass = false. With the new firmware version of the Hub and the new release, I will give it another try.

[floriandrott]

@reinhard-brandstaedter I tested it again and the hub2k with control_bypass=false reacts as the hub1.2k. Only if control_bypass=true the hub2k differs from hub1.2k.

Would it be possible to gets this included into the code?