Very high cpu usage with >1 instance running about dbus-serialbattery HOT 25 CLOSED

Maybe a reduction of the polling frequency could imrpove the situation? 1sec is great to have but not always needed.

Or poll one battery every second, in a round-robin fashion. For 3+ batteries maybe give the one that is set as the controlling BMS some preference.

from dbus-serialbattery.

Consistancy in time is good, but not having an overloaded CPU is more important. And with 5 Batteries a consistent set of data from 5 sec ago doesn't seem better than having the 'average' state from 2.5s ago.

Do you have an example scenario that would cause problems in the round robin reading scheme but would work with low frequency all at the same time scenario?

from dbus-serialbattery.

But how do I get the aggregated BMS to the cerbo ?

1. Install Venus OS large on the Raspberry Pi
2. Use Node-RED to combine the data from the battery aggregator you want to transfer to the Cerbo GX
3. Install dbus-mqtt-battery on the Cerbo to elaborate the data

from dbus-serialbattery.

I also wondered why I see 2 processes of each Jkbms_Ble. In sum 6

There are different threads that act as watchdog and restart the driver in case of failure.

from dbus-serialbattery.

Bluetooth don't poll the data, but elaborates all what the BMS sends over.

I'm modifying the driver right now to let the user choose, if it should be used in the normal way or as passthough only. In passthrough mode only the data is fetched and no calculations are made. In this case the calculations for CVL, CCL and DCL are not done anymore and it is not recommended to select the battery as battery monitor. You will need a battery aggregator or something else that make these calculations and then select it as battery monitor. This way the data is calculated only once and not per battery.

from dbus-serialbattery.

I had the same impression that the load did not change, but it would be good to have multiple feedbacks.

from dbus-serialbattery.

This is also a great feature, thanks a lot!

from dbus-serialbattery.

For example. The first 3 rows are the batteries, then PV Power, EM24 reading and Lynx Shunt at the bottom.
The batteries still show energy being taken out, while the Lynx Shunt is (correctly) showing energy flowing into them.

Usually the Lynx Shunt reports ~0.2V less than the BMSs.

from dbus-serialbattery.

which Values or Current were shown by your Jkbms at the same time?

from dbus-serialbattery.

Can't tell since the app can't connect as long as the cerbo has them grabbed.
With only the one battery connected, the other two report more or less the same current, which adds up to what the lynx shunt shows.

from dbus-serialbattery.

One instance already take like 17% CPU, which is IMMENSE .. !! We already reported those but ... well ... those has been closed.

from dbus-serialbattery.

We optimized it the best we could. If you compare with a EM* it gets much more data and processes it. Feel free to open a PR to increase performance.
Currently you only could use a Rasperry Pi to connect all BMS and then transfer the aggregated data to the Cerbo.

from dbus-serialbattery.

Maybe a reduction of the polling frequency could imrpove the situation? 1sec is great to have but not always needed.

from dbus-serialbattery.

That will not work. You need to poll the battery at the same moment, else you have a snapshot of different moments. This will result in wrong data and wrong system behaviour.

from dbus-serialbattery.

for my 3 batteries, I'd use a poll scheme like
1->2->1->3->1->2->1->3-> ...
where 1 is my controlling BMS. Yes, the state is now 2 and 4 seconds old instead of the (theoretical) 1, but I think this is miles better than having the state of 1 minute ago or worse for all batteries.
I of course don't know how battery-aggregator et al would be affected by this.

from dbus-serialbattery.

We optimized it the best we could. If you compare with a EM* it gets much more data and processes it. Feel free to open a PR to increase performance. Currently you only could use a Rasperry Pi to connect all BMS and then transfer the aggregated data to the Cerbo.

Reduced poling, as you said .. it will crash the drivers once a day (if i remember correctly) maybe this crash is specific to Jkbms.

from dbus-serialbattery.

it will crash the drivers once a day (if i remember correctly)

Try to disable the "VRM 2-way-communication" in "VRM online portal" settings page I had that crash/reboot once/twice a day too, it went away when I disabled this setting.

from dbus-serialbattery.

Some months ago we switched the Bluetooth connections from polling to callback, since the driver crashed after some hours without reason.

from dbus-serialbattery.

We optimized it the best we could. If you compare with a EM* it gets much more data and processes it. Feel free to open a PR to increase performance. Currently you only could use a Rasperry Pi to connect all BMS and then transfer the aggregated data to the Cerbo.

Hello @mr-manuel ,
I am experiencing the same problem.
100% cpu usage with 3 JK-BMs over bluetooth. ( no other instance. no aggregation, no NodeRed, no GUI)

Can you please explain your proposed solution ?
How can I collect the 3 bms on a raspberry and transfer the "aggregated BMS" to my cerbo ?

installing Venus OS on a raspberry, configuring the 3 bms and use an aggregation of course is no problem.
But how do I get the aggregated BMS to the cerbo ?

Thank you a lot for your help :)

from dbus-serialbattery.

same Issue with 3 connected JK bms over bluetooth.
I only uploaded the picture in case it might help someone.

I also wondered why I see 2 processes of each Jkbms_Ble. In sum 6

from dbus-serialbattery.

I also wondered why I see 2 processes of each Jkbms_Ble. In sum 6

There are different threads that act as watchdog and restart the driver in case of failure.

Just seen htop screenshots from users that use RS485 ... it's something like 3% per BMS (i asked which one he is using) while it's 14% with bluetooth on jkbms.
Why would the bluetooth take that much CPU ?

from dbus-serialbattery.

I'm modifying the driver right now to let the user choose, if it should be used in the normal way or as passthough only. In passthrough mode only the data is fetched and no calculations are made. In this case the calculations for CVL, CCL and DCL are not done anymore and it is not recommended to select the battery as battery monitor. You will need a battery aggregator or something else that make these calculations and then select it as battery monitor. This way the data is calculated only once and not per battery.

that sounds great!

I toyed with the idea of introducing a "battery count" parameter: i.e. calculate the charge/discharge current limit for one battery and multiply it with the "battery count" parameter. This would work great for my 3 identical parallel units (i.e. right now charge limit is 150A, while the 3 units could easily sustain the >300A of the MP2s, with dbus-serialbattery still connected to just one bms).

Thanks!

from dbus-serialbattery.

Could you all please install v1.3.20240510passthrough, change DRIVER_MODE = 0 to DRIVER_MODE = 1 in the config.default.ini and compare the CPU usage between the setting 0 and 1 for about 30 minutes?

from dbus-serialbattery.

in config.ini:

DRIVER_MODE = 0:

load average: 3.40, 3.33, 3.50

DRIVER_MODE = 1:

load average: 3.52, 3.82, 2.77
Also I get "Error: unsupported operand type(s) for +=: 'int' and 'NoneType'. Read trial nr. 3"

and I changed the poll interval to 5000 in the heltec BMS driver, to avoid watchdog resets:

class HeltecModbus(Battery):
    def __init__(self, port, baud, address):
[...]
        self.poll_interval = 5000

I have the impression that a configuration option for the poll_interval (or even a dynamic reduction on overload) would be more effective than tweaking the calculations.

from dbus-serialbattery.

Since there are not many willing to test but only concerning I will close this.

Meanwhile I added an option to change the polling interval.

https://github.com/mr-manuel/venus-os_dbus-serialbattery/blob/d946e3d1d8bf755872bd03f9080f94641ebba4a6/etc/dbus-serialbattery/config.default.ini#L349-L354

from dbus-serialbattery.