Fetch and parse battery status from a non standard BLE device with ESPHome

ESPHome
1

Hello Everyone.

I have one Feasycom FSC-BP108 iBeacon device which I use to track whether our dog is in the house or not, so automations trigger according to certain conditions. The iBeacon status is checked through ESPHome. The device works great. It is possible to create beacons through its App with different UUIDs and parameters (TX power, UUID, major/minor fields, etc.). However, I can’t monitor the battery status because there are not any 180f service_uuid nor 2a19 characteristic_uuid. Those are supposed the standard UUIDs where such information is usually stored.

After some research and according to the device’s documentation, I know that the battery status is present in the iBeacon advertising data. The highlighted byte is the related one:

adv data
adv data600×575 55.7 KB

So basically, what I should do is to fetch such advertisement data from service_uuid fff0, parse that byte, store it an a variable and create a battery device class sensor according to such variable. However, I know how to create a sensor, but I don’t know how to fetch and parse it. There is not any characteristic_uuid containing such information. Actually, all characteristic UUID under such service UUID branch are empty. I guess advertisement information is linked directly to such service UUID, but I am not sure:

bluetility
bluetility1830×276 40.6 KB

This is my current esphome yaml config for the related ESP32 device:

esphome:
  name: sade-feasy-beacon
  friendly_name: Sade Feasy Beacon

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: !secret api_key

ota:
  password: !secret api_password

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Sade-Feasy-Beacon"
    password: "39UztmCfJ1hR"

captive_portal:

esp32_ble_tracker:
  scan_parameters:
    duration: 5s #300s
    interval: 1s
    window: 1s
    active: true

ble_client:
  - mac_address: DC:0D:30:16:D0:38
    id: sade_ibeacon

binary_sensor:
# Presence based on iBeacon UUID
  - platform: ble_presence
    ibeacon_uuid: 'FDA50693A4E24FB1AFCFC6EB07647825'
    name: "Sade iBeacon"
    timeout: 30s
  
sensor:
  # RSSI based on iBeacon UUID
  - platform: ble_rssi
    ibeacon_uuid: 'FDA50693A4E24FB1AFCFC6EB07647825'
    name: "Sade iBeacon RSSI"
  - platform: ble_client
    type: characteristic
    ble_client_id: sade_ibeacon
    name: "Sade iBeacon Battery"
    service_uuid: 'fff0'
    characteristic_uuid: '2a19'
    icon: 'mdi:battery'
    unit_of_measurement: '%'

I know there is an option to parse data using Lambda, but my knowledge is not that high. :frowning: Has anyone had to customize the battery sensor according to a non-standard BLE device like this? Any advice, please?

2

Hi @sesardelaisla

As we already include iBeacon voltage for iBeacons supporting this with our Theengs Gateway HA Add-on, and the Feasycom Bluetooth Beacons sending out BLE advertising broadcasts with the battery, and other information, included, it should be easy to add a dedicated decoder for the Feasycom FSC-BP108, which would also include auto-discovery of the battery and other properties and as a BLE device tracker.

Let us know if you are interested in working on this together, with you supplying some sample Theengs Gateway data samples and testing a decoder.

1 Like
3

Hi @DigiH,

Thanks for your feedback! Happy to help and contribute. I usually prefer to keep workflows as simple as possible, so I am not sure whether having to use an addon in addition to esphome is the way I’d like to achieve what I want to do. I think it is something that can be done with esphome itself, although not 100% sure. However, as long as it works, I am fine with it. Furthermore, I am always happy to contribute even if it will eventually not be my final setup. Perhaps it will work for the purpose to understand better how beacons work.

I will install the addon and play around with it. In the meantime, please do let me know what you need to get logs/dumps/data for researching. Cheers!

4

Hi @sesardelaisla

Thanks for your offer to help. I’ve actually already created a decoder which should cover all the Feasycom Bluetooth beacons, auto-discovering them as BLE device trackers, giving the model type of the beacon received, the battery level and a plugged-in status, as some of the Feasycom beacons are actually powered by USB.

For your sample data from nRFConnect this decoded as
{"brand":"Feasycom","model":"Beacon","model_id":"FEASY","beacontype":"BP108","batt":100,"plugged-in":false}
in the MQTT message, with beacontype, batt and plugged-in being auto-discovered.

Before merging this it would be great if you could confirm the undecoded data you receive through the Add-on though, with the configuration option PUBLISH_ADVDATA turned ON, and monitoring the undecoded MQTT output with MQTT Explorer. One single MQTT message with the serviceuuid “fff0” will be enough.

5

I get this upon starting the addon:

[17:16:58] INFO: Creating TheengsGateway configuration...
[17:17:01] INFO: IDENTITIES: 
[17:17:01] INFO: BINDKEYS: 
[17:17:01] INFO: Starting TheengsGateway...
ERROR:BLEGateway:No Bluetooth adapters found.

The addon stays up and running though.

Before moving forward, should I fill the ADAPTER field of the addon with something related to my esp32, the one connected to my esphome instance? How can the addon reach the beacon? Or should I just enable my HASS host bluetooth adapter for the addon to use it, so the addon can get the raw data through it?

6

The latter please, to enable the HASS host bluetooth adapter for the add-on.

I assume you also have the MQTT integration enabled and an MQTT broker for other integrations? Otherwise it might be too involved to just help with this new decoder :wink:

7

I have an MQTT broker installed. It is just the BT thing the one I have to “fix”. However, that will require to enable it in the BIOS and to do some aditional stuff. Currently, I use an external WiFi/BT ESP32 for the purpose. Please, allow me a few days and will get back to you here. Cheers!

8

If you have a spare ESP32 lying around an alternative would also be to install OpenMQTTGateway on it, as it uses the same Theengs Decoder as the Theengs gateway Add-on, specifically the
esp32dev-ble-datatest
binary from the web upload page.

This would also avoid you having to fiddle with the BIOS and allow you to test the Feasycom decoder by tomorrow as well without any changes to your HA machine set-up.

Either way, thanks again for your support and commitment in helping with this decoder! :slight_smile:

9

Will definitely try this. I have some ESP32 dev boards and also M5Stack Atom Lite around so I agree it is much better than changing current configs and devices.

However, it is Easter holidays time here, so the time I’ll have to play with it is not high, at least without getting a ticket by my wife. :wink: I will do my best though. Honestly, I am very keen on finding the way to move forward with this. Thanks!

EDIT: Couldn’t wait and I am already flashing one of my Atom Lites. :wink: Will try to fully set it up asap and will give you further feedback.

10

Same with the Easter holidays here :wink: and am going away for a few days as well from tomorrow morning, so I fully understand.

:grin:

With the Atom Lite you might need to install the
esp32-m5atom-lite
binary, which would also allow for its IR capabilities, and then manually turn on BT: Publish Advertisement data in its HA gateway interface, but I;'m not sure, the generic ESP32 esp32dev-ble-datatest binary could also work, with this option already turned on.

11

Done!

mqttgw

This is the one I installed for obvious reasons… :wink:

According to the addon config, these should be the right topics:

mqtt topics

However, I see in the explorer that BTtoMQTT is under OMG_ATOM_L (btw, I already see some clients info there :slight_smile:). Should I reconfigure the Atom (best approach in my understanding), the addon, or just leave it as is? Could you advise on next steps, please?

EDIT: I just recalled that the + sign is a wildcard, so I guess there is no need to change anything. Please, confirm.

12

With the Atom Lite Gateway you just need to turn on the auto-discovered gateway option
BT: Publish Advertisement data
on manuallt. Can yo see it in the auto-discovered gateway options?
Settings > Devices & Services > MQTT > OMG_ATOM_L

No need to change any of the topic settings, they are preconfigured fine for the HA defaults.

Once that BT: Publish Advertisement data option is turned on you should see messages coming in for your so far undecoded Feasycom beacon as well, under its MAC address.

13

image
image1290×2604 270 KB

:sunglasses:

I will get the data and paste it here.

1 Like
14

I am afraid that the device’s MAC is not in the list. I’ve been waiting around 5’ and I also forced scan with the “BT: Force scan” option. :frowning:

nomac

Beacon MAC is DC:0D:30:16:D0:38.

15

Strange… I have gone through all MACs and the first one in the list is reporting the following:

,{"id":"00:1D:43:9A:01:0A","mac_type":0,"adv_type":0,"name":"108-010A","rssi":-47,"servicedata":"27021992dc0d3016d03864","servicedatauuid":"0xfff0"}

That name 108-010A is the original beacon name. I changed the name to “Sade” and MAC is not related. However, the servicedata string contains the original MAC, so I believe this is the related topic:

27021992dc0d3016d03864

Actually, I read somewhere that these devices’ MAC can be changed, although I haven’t seen any option in the App to do it.

1 Like
16

That is the on :slight_smile: I’m also also not sure why it comes up with a different MAC address as its broadcast address.

But it does confirm all the details I set up the new decoder with, so once the decoder has been merged this will appear as the above stated

{"brand":"Feasycom","model":"Beacon","model_id":"FEASY","beacontype":"BP108","batt":100,"plugged-in":false}

I will merge the decoder now and will release a small dot release of Theengs Decoder with it.

After that you can either
• wait about 2 hours until the next development test build of OpenMQTTGateway has been built and released at

to then install the test built version of the
esp32-m5atom-lite
binary

• or install the current version 1.7.0 of the
esp32dev-ble-mqtt-undecoded
binary. This will turn the ESP32 into a proxy antenna for the Theengs Gateway add-on, without you requiring to activate the Bluetooth adapter on your system. It does require you to uninstall and reinstall the Theengs Gateway Add-on though, as with the add-on this is the easiest way of getting the latest decoders.

• or just uninstall and reinstall the Theengs Gateway Add-on, if and once your HA system Bluetooth adapter has been turned on.

I will give you a shout in a few minutes once the decoder has been merged and the dot update of Theengs decoder is ready for option 2 and 3.

Thanks again for all your collaboration! :slight_smile:

1 Like
17

I will try the second option. I think it will be the easiest one at this point. I hope the esp32dev-ble-mqtt-undecoded works fine with the Atom Lite.

18

I would have suggested that as well, and I hope so too, but think it should work fine.

You might as well try that already until I’m ready to ask you to uninstall and reinstall the Theengs Gateway Add-on.

BTW, If you untick the Erase Flash option during the web install all your WiFi and MQTT credentials should be kept with the new binary.

1 Like
19

Is esp32dev-ble-mqtt-undecoded working ok on your Atom Lite?

If so, everything else is also ready for aTheengs Gateway uninstall and reinstall, so that it pulls in the latest version of Theengs Decoder with the now included Feasycom beacon decoder included.

20

It seems it is working fine. I see new MQTT OMG_ESP32_BLE device.

Reinstalling the addon…