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

ESPHome
41

Thanks for your time and your understanding! I hope it helped for the purpose of increasing the devices database, and to help other users to add such Feasycom beacons straight forward.

I will play around with the settings but it should work for my purpose, actually better than esphome. I use it for this only, and I think it will be easier to manage this with your gateway/addon, so I will probably uninstall esphome until I need it for another purpose. I will give you further feedback for you and anyone’s reference in a few days after having the opportunity to fully test.

Cheers! :beers:

1 Like
42

Looking forward to your feedback.

Cheers! and have a nice Easter!

1 Like
43

Is not possible to adjust this TRACKER_TIMEOUT setting on a per-device basis? Not important for my use case but it would be great to have such an option for not being to create an external binary sensor with different delay_off parameters on top of the gateway one.

Apart from this, I tried to add another fob I have. This device is one of this Chinese popular iTags/fobs:

itag
itag386×511 17.8 KB

Actually, you can see two entries with different manufacturer IDs. Physically, they look exactly the same. However, they are really not. I noticed this in the past because one has not a standard battery UUID (or hasn’t at all), so I wasn’t able to add a battery sensor to it through esphome. Perhaps a firmware difference?:

I see the devices in MQTT Explorer:

mqtt-itag
mqtt-itag997×96 27.5 KB

All history entries have the same structure (no long topic content with the:

{"id":"FF:FF:10:0C:FA:5A","mac_type":0,"adv_type":0,"name":"iTAG","manufacturerdata":"0501ffff100cfa5a6602010300","rssi":-63}

{"id":"5B:07:4B:15:46:96","mac_type":0,"adv_type":0,"name":"iTAG  ","manufacturerdata":"05019646154b075b3fa2e2ee00","rssi":-71}

You can see there are not any "model":"iBeacon","model_id":"IBEACON" strings in the content.

Is this the reason why the Beacon-XXXX sensors are not being created for such fobs? Is it because these devices are still not in your db? Do let me know whether you want to add them. Happy to provide further info about them if needed.

No rush mate. I expect a delayed response. Just wanted to update the thread according to my latest tests. I will keep updating if news come up. :slight_smile:

44

Currently not, the TRACKER_TIMEOUT is generally applied to all device trackers.

I have exactly the same iTAG kind of trackers from the popular Chinese shop, got them quite some time ago, so also made sure that they are correctly recognised as device trackers. They are also mentioned at the top of our compatible devices list.

Now comes the big BUT - mine broadcast the same name, but have manufacturerdata which is only 8 characters long, compared to your 26. So the only reason yours are not currently being recognised as device trackers is the longer manufacturerdata your versions braodcast. It has nothing to do with any missing iBeacon protocol.

I suppose it’s just a fact with those cheap little Chinese trackers, that the identical plastic covers for them are being mass produced and used by different companies, which in turn put slightly different electronic components inside with different firmware installed.

Even yours not only differ in the missing/existing standard battery service/char, but one has its MAC address in the manufacturerdata the correct way, while the second one has it in reverse. So between the two of us we already have the sme looking iTAGs with three different firmwares.

As it was just a very small change to the existing decoder I submitted the change so that yours will also be recognised as device trackers now. The decoder change will be in the development test version of the OpenMQTTGateway binaries by tomorrow, i.e. after about 03:00 UTC tonight after the nightly builds have finished.

1 Like
45

Thank you so much for taking some time to explain this and for including my iTags in the latest builld. I learnt a lot with all the feedback you gave through all your posts!

Cheers!

1 Like
46

Hello @DigiH,

Trust this message finds you well!

I am still using the solution based on Theengs you suggested. However, it has not ever been stable and fully reliable. Problem is that the beacon is not detected sometimes upon moving away from the ATOM M5 Lite I still have. I have updated the ESP32 based device with the latest stable version, but still no luck. Behaviour is quite random. It works, but it is not perfect. Any advise, please?

47

Hi @sesardelaisla

Are you only using OpenMQTTGateway on your ATOM M5 Lite, or also still Theengs Gateway (HA Add-on) or other multiple OpenMQTTGateway instances?

In any case you should use the latest development version of OpenMQTTGateway on your ATOM M5 Lite, instead of the latest release version, which is available at

Let us know if this addresses the issues you are seeing.

48

I am using OpenMQTTGateway for the ATOM M5 Lite and I also have Theengs GW installed in HA as an add-on. Should I remove Theengs?

As for the development version, I eventually installed the latest release. I thought that after all the tests we did together, I had to install the release. I just reinstalled the dev version and will give further feedback after a few days. Thanks!

49

I stopped the Theengs addon GW. Just realized that it is no needed to execute it, and I guess it could interfere with MQTT.

However, still having issues: if I power the beacon off, the M5 still report it on. I think I should restart from the beggining, following all your past steps one by one


50

Can you have a look at which value you have for presenceawaytimer in your M5’s BTtoMQTT settings? The default is 120000 ms (120 seconds), so after 2 minutes every device tracker not received any longer should be reported as AWAY, if the device tracker has been set up and discovered correctly.

For that you might also want to post your device tracker discovery message, visible under the homeassistant > device_tracker > AABBCCDDEEFF-tracker > config.

51

Do you mean one of these settings? I think it is the BT: Presence/Tracker timeout set to 2 min. However, I am not sure because it is not displayed in ms.

IMG_8887
IMG_88871290×2481 284 KB

This is the topic:

homeassistant/device_tracker/001D439A010A-tracker/config

And this is the value:

{"stat_t":"+/+/BTtoMQTT/001D439A010A","name":"FEASY-tracker","uniq_id":"001D439A010A-tracker","val_tpl":"{% if value_json.get('rssi') -%}home{%- else -%}not_home{%- endif %}","source_type":"bluetooth_le","device":{"ids":["001D439A010A"],"cns":[["mac","001D439A010A"]],"mf":"Feasycom","mdl":"FEASY","name":"108-010A-9A010A","via_device":"OMG_ATOM_L"}}

Thanks for taking some time to help. :slight_smile:

52

Yes, that is the one, presented in seconds in the HA gateway UI. The discovery message also looks fine.

So if your Feasy Beacon tracker does not get set as AWAY 2 minutes after you switched it off or it leaves the the reception range, can you monitor its MQTT message outputs. The last message received after switching it off should be

{"id":"00:1D:43:9A:01:0A","state":"offline"}

and with no rssi key in the message it should trigger the AWAY status accordingly following the value template in the discovery message.

Working fine for me with the latest development version of OpenMQTTGateway and the latest HA.

53

That’s actually the problem: It does not get set as away. I also have latest HA and dev OpenMQTTGateway. A few days ago, it did change randomly. However, after installing the dev version on the M5 as advised, it never changes at all to away status.

54

What about monitoring the actual MQTT messages with MQTT Explorer, as described above, looking at the history of the messages. What is the last messages (after 2 minutes) when siwting off the beacon?

55

Beacon has been off since last night, so I just powered it on and then back off. This is what I see:

imagen
imagen947×116 5.27 KB

{"stat_t":"+/+/BTtoMQTT/001D439A010A","name":"FEASY-tracker","uniq_id":"001D439A010A-tracker","val_tpl":"{% if value_json.get('rssi') -%}home{%- else -%}not_home{%- endif %}","source_type":"bluetooth_le","device":{"ids":["001D439A010A"],"cns":[["mac","001D439A010A"]],"mf":"Feasycom","mdl":"FEASY","name":"108-010A-9A010A","via_device":"OMG_ATOM_L"}}

It is strange because I don’t see any update on the topic after both actions (I did them at 10:53 and took the screenshots at 10:56):

imagen
imagen819×862 30.9 KB

Do also note that the topic is retained. Is that normal? It seems the device status change is not making the topic to be updated. I think it just does some sort of random refreshes after certain time.

56

I think I was looking at the wrong place. I can see the beacon here:

image

It is strange that the MAC address is not the device’s real one (it should be DC:0D:30:16:D0:38). Shouldn’t be the same? I see the real MAC here when the device is online:

{“id”:“00:1D:43:9A:01:0A”,“mac_type”:0,“adv_type”:0,“name”:“108-010A”,“rssi”:-43,“distance”:0.042283,“servicedata”:“27021992dc0d3016d03864”,“servicedatauuid”:“0xfff0”,“brand”:“Feasycom”,“model”:“Beacon”,“model_id”:“FEASY”,“type”:“BCON”,“track”:true,“beaconmodel”:“BP108”,“batt”:100,“plugged-in”:false,“mac”:“DC:0D:30:16:D0:38”,“topic”:“home/presence/OMG_ATOM_L”}

However, such topic updates fine whenever I power on/off the beacon. I don’t care as long MAC does not change (apparently it does not), although I am wondering whether I can change this to UUID method instead as described in the documentation. I will try that later.

Going back to the actual problem, I think it is that the device_tracker entity is not being published to HA. I don’t find any device_tracker with a related 001D439A010A ID:

image
image1462×346 58.4 KB

I think the device_tracker.108_010a_9a010a_feasy_tracker has nothing to do with the current device. Perhaps it is how it was in the past and now it changed for some reason??

57

This is normal with the discovery messages, they need to be retained, and since you also seemed to have just switched on or restarted your Atom Lite, the discovery messages are created afresh. These discovery messages are only for HA to discover the device.

In you second post you correctly viewed the actual beacon broadcast messages, and the final AWAY message with “state”:“offline” is correctly there as the last message, which should set the beacon status to AWAY in HA.

The different MAC addresses are weird, but I am more wondering if the deducted MAC key taken from the servicedata is actually correct, as it ws described in the Feasycom documentation. I wouldn’t worry about it too much at the moment, as it doesn’t seem to be related to the issue you are seeing.

The problem, from what you have shown so far, looks to be the device tracker entry in HA, as everything else, the retained discovery message(s) and the correct “state”:“offline” message once the beacon has been switched off/out of range for more than 2 minutes are all fine.

Yes, the full MAC is usually not shown in the device entry, but only the last three octets, with a hyphen after the model name of the device, plus a space and then the model_id, hyphen and ‘tracker’.

So what really confuses me is that the name in the Feasycom beacon discovery message is

"name":"108-010A-9A010A"

leading to the 108-010A-9A010A FEASY-tracker entry, which should correctly be

Beacon-9A010A FEASY-tracker

So the model “Beacon” has been replaced with “108-010A” for whatever reason.

I’m wondering though which HOME/AWAY entry you are viewing in your dashborad, could it be with the correct, previously discovered name, not showing the correct state, now that the discovery name has changed.

Just tested here with the latest development version as well, and all my discovery messages have the correct naming scheme. So I’m really not sure why your Beacon has the above mentioned naming issue, as it seem to take the actual broadcast name of the device (“name”:“108-010A”) , instead of the discivery message name, which would be “Beacon”.

P.S. - Just to make sure, which binary did you install on your Atom Lite from the development upload page?

58

esp32-m5atom-lite

Is the same than the one you use? Should I try with another one?

I removed the device from HA. The device tracker was also removed from MQTT automatically. Then, I enabled the auto-discovery option and device and tracker were added atomatically again after a few minutes. However, the gateway still does not detect sometimes (sometimes everything works) that the beacon is off/away. When this happens, the home/OMG_ATOM_L/BTtoMQTT/001D439A010A topic does not change to offline either, so I guess the problem is in the gateway itsefl, not the home assistant thing.

59

.
Tried with esp32dev-ble and random behaviour persists: looks like power on updates happen but power off is not updated accordingly sometimes.

60

No, this is the correct binary you should use, I do not have the device myself.

When looking at the newly created discovery message again with MQQT Explorer, how does it look now, still with the same
"name":"108-010A-9A010A","via_device":"OMG_ATOM_L"
?

I haven’t been involved in the development recently, but I will pass on that the “state”:“offline” message is sometimes not being sent. This obviously then prohibits the beacon going to the AWAY state.