Resistance and decimal places of voltage...

[EasilyBoredEngineer]

@syssi you're everywhere mate :) Thankyou for your amazing contributions. I am now using 3 of them - your dl24 one, your JBD one and your JK-BMS one. Now I just have to work out how to combine them all into one repository.

I may be in touch in the future to ask your permission to use these for an APNIC project I'm currently doing.

Syssi - I have a an DL24 and what I'm wondering about is two things:-

1. The voltage measurement of the device goes to several decimal places, but this repository seems to round to 1 decimal place. Approximately where would I look in your code base to find the cause of that? It might seem like an unnecessarily level of precision, but if you're working with Lithium Iron Phosphate batteries with a very flat voltage curve the extra digits are very useful.
2. The DL24 has a measure of internal resistance. That would be an interesting thing to graph, but it doesn't seem to be incorporated as a sensor. Any idea where I'd look to do that?

Thankyou!

Matt

[EasilyBoredEngineer]

With regards to the 'resistance' I wonder if that might be your 'unknown' four byte value at https://github.com/syssi/esphome-atorch-dl24/blob/main/docs/protocol-design.md

[syssi]

Hi Matt! Welcome back and nice to see you here too!

1. Please try to increase the accuracy_decimals of the voltage sensor:

sensor:
  - platform: atorch_dl24
    atorch_dl24_id: atorch0
    voltage:
      name: "${name} voltage"
      accuracy_decimals: 6

If the additional decimal places are always 0 the resolution of the BLE payload is lower as the values at the display (this applies to some other measurements too unfortunately).

2. Let's give it a try! I will print the value to the log for testing. If it's the resistance I will introduce a new sensor entity to expose the measurement.

[syssi]

I am now using 3 of them - your dl24 one, your JBD one and your JK-BMS one. Now I just have to work out how to combine them all into one repository.

If pointing to my repositories using the YAML isn't enough you can create a dedicated project repository, create a "components" folder and copy all required external components into this folder:

components/jk_bms_ble/
components/jbd_bms_ble/
components/atorch_dl24/

If you refer to this new repository at your YAML now ESPHome will be able to recognize and compile the external components retrieved from the new project repository.

[syssi]

I've double checked some response examples of my dummy load:

FF.55.01.02.00.00.20.00.4E.20.00.13.FA.00.00.00.11.00.00.00.00.00.00.00.00.25.00.02.21.1A.3C.00.00.00.00.09
FF.55.01.02.00.00.20.00.4E.1E.00.13.FA.00.00.00.11.00.00.00.00.00.00.00.00.25.00.02.21.1B.3C.00.00.00.00.08
FF.55.01.02.00.00.20.00.4E.21.00.13.FB.00.00.00.11.00.00.00.00.00.00.00.00.25.00.02.21.1C.3C.00.00.00.00.15
FF.55.01.02.00.00.20.00.4E.20.00.13.FC.00.00.00.11.00.00.00.00.00.00.00.00.25.00.02.21.1D.3C.00.00.00.00.16
FF.55.01.02.00.00.20.00.4E.1B.00.13.FC.00.00.00.11.00.00.00.00.00.00.00.00.25.00.02.21.1E.3C.00.00.00.00.0A
FF.55.01.02.00.00.20.00.4E.23.00.13.FD.00.00.00.11.00.00.00.00.00.00.00.00.25.00.02.21.1F.3C.00.00.00.00.1C
 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
                                                   ^^^^^^^^^^^^^^^^^^^^^^^

You could increase the log level to VERY_VEROSE to see the raw response payload. Please check byte 17-24. It's always 0x00 on DC meters. On AC meters the bytes are used for some additional measurements:

https://github.com/syssi/esphome-atorch-dl24/blob/main/components/atorch_dl24/atorch_dl24.cpp#L313-L322

TL&DR: The resistance isn't available at the BLE notification payload.