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

[sesardelaisla (Sésar de la Isla)]

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!

[DigiH]

Looking forward to your feedback.

@sesardelaisla

Cheers!

Cheers! and have a nice Easter!

[sesardelaisla (Sésar de la Isla)]

@DigiH

The actual device tracker AWAY time can be adjusted with the presenceawaytimer value

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:

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:

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.

@DigiH

Same with the Easter holidays here and am going away for a few days as well from tomorrow morning

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.

[DigiH]

@sesardelaisla

Is not possible to adjust this TRACKER_TIMEOUT setting on a per-device basis?

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

@sesardelaisla

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

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.

Theengs Compatible Devices

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.

[sesardelaisla (Sésar de la Isla)]

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!