Closed mpvader closed 3 months ago
I added dbus-parallelbms to this issue.
which is new per v3.40, so a regression: all systems will have an increase of CPU load due to that when comparing v3.33 to v3.40.
on a CCGX that is in the example system 6%. On Cerbo and Ekrano it will be less; but still not good and not needed.
This will likely come out as a v3.41 soon.
dbus-generator-starter
will only be started when any of the following hold (ready on a branch):
com.victronenergy.settings/Settings/Relay/Function
== 1 com.victronenergy.genset
com.victronenergy.dcgenset
The parallel BMS service strictly only needs to run when there are at least two Lynx Smart BMSes present, or when they were present but one of them disappeared from dbus. The Lynx smart BMS appears as com.victronenergy.battery
on dbus, so the easiest would be to have dbus-parallel-bms
run whenever there is at least one service starting with com.victronenergy.battery
.
However, this will lead to the service also running when other devices registering themselves as com.victronenergy.battery
are connected:
We can rule out the above by looking at the /ProductId
as well. If that's any of the four productIds of the Lynx Smart BMS, start the service. The only case thats not covered then is when there is (and will always be) only 1 Lynx Smart BMS in the system. Handling this as well requires some additional logic because dbus-parallel-bms
is designed to keep its service alive when all but one of the parallel BMSes are down. So we can't simply down the service when there's less than 2 Lynx BMSes.
I'd say starting dbus-parallel-bms
when there's 1 or more services starting with com.victronenergy.battery
which have the correct product ID is sufficient. @mpvader?
I'd say starting dbus-parallel-bms when there's 1 or more services starting with com.victronenergy.battery which have the correct product ID is sufficient. @mpvader?
Agree. As a result, the only situation in which it runs while not required, is for systems having one Lynx Smart BMS. Which is already an enormous improvement; and we anyway already have further improvements on the horizon by doing the dbus monitoring/consuming far more efficiently.
Included per v3.50~7, and backported to v3.41~1.
thanks, nice.
Trivial change and on a CCGX this saves 6 to 7% + another 6% for dbus-parallelbms of CPU. See screenshot, make sure to look at the v3.40 one.
Slack thread