Detect battery level for ThermoPro TP357, TP358, TP359 and TP393

[pointhi]

Description:

The given nibble is responsible for the battery reading. I also verified it using a power supply.
There is also a ticket with the same findings: Bluetooth-Devices/thermopro-ble#11

• 0... battery is low
• 1... something in-between
• 2... battery is full

Checklist:

• The pull request is done against the latest development branch
• Only one feature/fix was added per PR and the code change compiles without warnings
• I accept the DCO.

[DigiH]

Hi @pointhi

Thanks for this suggested addition to the ThermoPro decoder. I am however not a big fan of arbitrary battery level conversion 😉 with the suggested change showing 100% only for when the battery is completely full, but as soon as it reaches 99% and anything in between 1%-99% as 50%, and then showing a complete 0% even when the battery is low and likely still running the device fine for a few days or longer.

How do you feel about implementing this as a proper binary sensor by pulling states 1 and 2 together as Normal, while state 0 then translates to Low, and have the discovery of the property accordingly. I would say this binary battery status is there for cases exactly like this.

https://www.home-assistant.io/integrations/binary_sensor/

Similar to our implementation of trl_433 devices, where some only send 0/1 Low/Normal, while only the ones sending a full range 0-100 value will show as XX%.

[DigiH]

@pointhi

I assume you have one of the ThermoPro thermometers. If you want to make the following changes and test it out with my above suggestion:

      "batt":{
         "decoder":["value_from_hex_data", "manufacturerdata", 9, 1, false, false],
         "post_proc":["*", 50, "max", 100]
      }

to

      "batt_low":{
         "condition":["manufacturerdata", 9, "bit", 0, 1, "|", "manufacturerdata", 9, "bit", 1, 1],
         "decoder":["static_value", false]
      },
      "_batt_low":{
         "condition":["manufacturerdata", 9, "bit", 0, 0, "&", "manufacturerdata", 9, "bit", 1, 0],
         "decoder":["static_value", true]
      }

and

const char* _TPTH_json_props = _common_TH_props;

should have already been changed to _common_THB_props if it were an additional percentage battery property, but now with the binary boolean battery status it needs to be defined separately. Hence also the property name change to batt_low for users without discovery for their controllers.

const char* _TPTH_json_props = "{\"properties\":{\"tempc\":{\"unit\":\"°C\",\"name\":\"temperature\"},\"hum\":{\"unit\":\"%\",\"name\":\"humidity\"},\"batt_low\":{\"unit\":\"status\",\"name\":\"battery\"}}}";
/*
R""""(
{
   "properties":{
      "tempc":{
         "unit":"°C",
         "name":"temperature"
      },
      "hum":{
         "unit":"%",
         "name":"humidity"
      },
      "batt_low":{
         "unit":"status",
         "name":"battery"
      }
   }
})"""";*/

Newly discovered the battery status for the ThermoPros should then nicely be shown as a binary battery sensor with

or

[pointhi]

I tried it out with HomeAssistant, and it should be fine. We loose one intermediate state for the battery but this is still better than no battery information at all, and the one I care about anyway is low battery.

[DigiH]

With your previous implementation of "max", 100 I also assumed that the 4-bit byte could also have the other values higher than 2, when for 4, 8 and c, indicating 100%/full previously would be wrong, as I think it is only bits 0 and 1 indicating the battery status
4 - 0100
8 - 1000
12 - 1100
where all three should correctly show low battery, as they do now.

But this is all pure conjecture from me, as I do not own any ThermoPro thermometers myself, so don't know if this could be higher than 2, possibly indicating some other additional value or setting.

Many thanks again for your contribution!

[DigiH]

@pointhi you don't have the ThermoPro TP393 by any chance?

As this is the only one with a rechargeable battery out of the lot. In this circumstance I could imagine that any of the two remaining bits of index 9 might indicate the charging state true/false, and then it would also make sense to differentiate between the 100% and below states, to indicate when the device has reached a full charge during a charging session.

This could then be implemented separately only when charging, and is best left until someone with a TP393 can verify this.

[pointhi]

No, I do not own a TP393