[FEATURE] BMS Wakeup triggered via MQTT command

[mt-mrx]

Is your feature request related to a problem? Please describe

I have Daly BMS capable of 60A which is way overpowered for what I'm doing. I'm charging my battery (small capacity) sometimes with really low power values (currently 0 - 100W but planned 0 - 400W) and I noticed that the BMS does not recognize any power flowing into the battery if it's below 30W. So if I charge the battery with > 30W everything is fine, but when my charging power is, e.g. 20W and maybe fluctuating between 0W and 20W for a long while the BMS goes to sleep. When it's asleep I don't know if it still monitors the cell voltages and would shutoff the ChargeFET in case a cell reaches a too high cell voltage, I believe it wouldn't.

Describe the solution you'd like

I would like to wake up the BMS by an external trigger sent via MQTT regularly while my charger is enabled. For example I would like to sent "true" to "Device_Control/Wake_BMS". Daly2MQTT would need to subscribe to that topic and trigger the wakeupHandler(true) function.

So basically whenever I start the charger I want to trigger ever couple of minutes the wake signal to make sure the BMS stays awake.

Describe alternatives you've considered

An option would be to use the auto wake function but that would mean the BMS stays awake all the time, even when the charger is off. Another option would be to change the "Enable BMS wakeup" setting using an MQTT command but that could lead to wearing out the flash if it's changed to often.

Additional context

No response

[softwarecrash]

normal the BMS wake up when you start charge or discharge, yours not?

[mt-mrx]

Yes it wakes up when I start charging, but when the charging power then stays below 30W it reports "stationary" and after an hour of charging it with e.g. only 20W continuously it goes to sleep and does not wake again until the charging power goes above 30W. It also reports "0A" Pack_Current even though I'm charging it slowly.

[softwarecrash]

Okay, i can build in this feature

[softwarecrash]

added in V2.7.0

[mt-mrx]

I had a look at the code, did you mean to include the check for "_settings.data.relaisFunction == 4" ? Not sure what the relay has to do with the wake signal.

[softwarecrash]

@mt-mrx that have nothing to do with the wake function.

[mt-mrx]

Then shouldn't be

code link if (_settings.data.relaisFunction == 4 && messageTemp == "true")

instead be

if (messageTemp == "true")

?

[softwarecrash]

Then shouldn't be

code link if (_settings.data.relaisFunction == 4 && messageTemp == "true")

instead be

if (messageTemp == "true")

?

whoops copy&paste error, fixed now

[all-solutions]

So if I charge the battery with > 30W everything is fine, but when my charging power is, e.g. 20W and maybe fluctuating between 0W and 20W for a long while the BMS goes to sleep.

You can set this up with the PC software. See here

[mt-mrx]

@all-solutions thanks a lot for that tipp, didn't know that this was possible! Need to check it out.

@softwarecrash waking the BMS via MQTT with version 2.7.0 works fine as well.

[mt-mrx]

@softwarecrash I just realized that waking the BMS via MQTT does work, but it does not go back to sleep by itself when I'm no longer sending wake up signals.

When I publish a single wake up signal to the Wemos it wakes the BMS and to me the code looks like it publishes back on the "Device_Control/Wake_BMS" topic also "true" and since it still listens to that topic it will get that message back, will wake the BMS and then the loop goes on and on. I don't really understand the reasoning behind the logic that the Wemos publishes back to the same Device_Control topic when it receives a command on one of those topics.

The same happens if I send a "dalybms/Device_Control/Pack_ChargeFET false" and the code blocks for the other Device_Control topics look to be using the same logic.

If I send:

$ mosquitto_pub -u mqtt -P .... -h ... -p 1883 -t 'dalybms/Device_Control/Wake_BMS' -m 'true'

I get an endless loop of the following until I restart the Wemos:

$ mosquitto_sub -i "myhost|debugsub" -u mqtt -P ... -h ... -p 1883 -t 'dalybms/Device_Control/Wake_BMS' -v | ts "%H:%M:%.S"
11:20:28.118924 dalybms/Device_Control/Wake_BMS true
11:20:28.124704 dalybms/Device_Control/Wake_BMS true
11:20:28.128152 dalybms/Device_Control/Wake_BMS true
11:20:28.131900 dalybms/Device_Control/Wake_BMS true
11:20:28.138157 dalybms/Device_Control/Wake_BMS true
11:20:28.142921 dalybms/Device_Control/Wake_BMS true
11:20:28.145229 dalybms/Device_Control/Wake_BMS true
11:20:28.149064 dalybms/Device_Control/Wake_BMS true
11:20:28.153544 dalybms/Device_Control/Wake_BMS true

[softwarecrash]

@softwarecrash I just realized that waking the BMS via MQTT does work, but it does not go back to sleep by itself when I'm no longer sending wake up signals.

When I publish a single wake up signal to the Wemos it wakes the BMS and to me the code looks like it publishes back on the "Device_Control/Wake_BMS" topic also "true" and since it still listens to that topic it will get that message back, will wake the BMS and then the loop goes on and on. I don't really understand the reasoning behind the logic that the Wemos publishes back to the same Device_Control topic when it receives a command on one of those topics.

The same happens if I send a "dalybms/Device_Control/Pack_ChargeFET false" and the code blocks for the other Device_Control topics look to be using the same logic.

If I send:

$ mosquitto_pub -u mqtt -P .... -h ... -p 1883 -t 'dalybms/Device_Control/Wake_BMS' -m 'true'

I get an endless loop of the following until I restart the Wemos:

$ mosquitto_sub -i "myhost|debugsub" -u mqtt -P ... -h ... -p 1883 -t 'dalybms/Device_Control/Wake_BMS' -v | ts "%H:%M:%.S"
11:20:28.118924 dalybms/Device_Control/Wake_BMS true
11:20:28.124704 dalybms/Device_Control/Wake_BMS true
11:20:28.128152 dalybms/Device_Control/Wake_BMS true
11:20:28.131900 dalybms/Device_Control/Wake_BMS true
11:20:28.138157 dalybms/Device_Control/Wake_BMS true
11:20:28.142921 dalybms/Device_Control/Wake_BMS true
11:20:28.145229 dalybms/Device_Control/Wake_BMS true
11:20:28.149064 dalybms/Device_Control/Wake_BMS true
11:20:28.153544 dalybms/Device_Control/Wake_BMS true

i use this mehtod for me as "ACK" version, so my mqtt broker is a bit stupid. i will remove the callback

[mt-mrx]

You could ACK back on something like "Device_Control_Result/\<command>".

[softwarecrash]

dalybms/Device_Control/Wake_BMS

good idea ill make it as dalybms/Device_Control/Wake_BMS_Result

my broker only send as changed things, so i dont notice this loop

[softwarecrash]

@mt-mrx fixed with V2.7.1