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

[sesardelaisla (Sésar de la Isla)]

@DigiH

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.

Too late.

After reinstalling, the MAC list moved to the TheengsGateway hive:

Is this what you expected?

Still shocked with the MAC issue. The FeasyCom App is still displaying the real MAC:

In addition, I see two devices with same MAC and name since yesterday. Tried to reset the device. It worked, because default names and beacons were reset too, but behaviour is still not as the first day. I think it happened after I reset it the first time.

Will try to figure out on my own though, as this is not the purpose of this forum topic.

[DigiH]

@sesardelaisla

Is this what you expected?

Now you should make sure that the option PUBLISH_ALL is turned OFF in the Add-on configuration.

But you should also see the decoded beacon data now, under the starnge new MAC address I suppose.

Could you also share a screenshot of the now undecoded OMG_ESP32_BLE entry for that MAC address in MQTT Explorer?

Also again, if everything worked as expected, under
Settings > Devices & Services > MQTT >

you should also see an auto-discovered entry now for the beacon with
Beacon-XXXXXX

[sesardelaisla (Sésar de la Isla)]

Should I enable the PUBLISH_ADVDATA option? It disabled after reinstalling.

[DigiH]

Yes please, but something is still not right, as your selected message with the new MAC address under Theengs Gateway should now be decoded correctly.

With the PUBLISH_ADVDATA option on though we can see what might be the problem, or if the uninstall and re-install didn’t work properly to pull in the new decoder version for whatever reason.

[sesardelaisla (Sésar de la Isla)]

MAC list went away. Now, this is what I see in MQTT Explorer:

The undecoded topic changes randomly through many MACs.

PUBLISH_ALL: disabled
PUBLISH_ADVDATA: enabled

Unfortunately, it’s beer time with my neighbour. I won’t be able to give you further feedback until later tonight or tomorrow morning, but do feel free to list actions I can do for further testings.

Cheers!

[DigiH]

@sesardelaisla

The undecoded topic changes randomly through many MACs.

That is actually the correct expected behaviour, my bad for asking for it

I think it is actually just an issue with Pypi not listing the latest Decoder release yet fully in their system, as searching the Theengs Decoder still comes up with version 1.7.4

while only clicking on it does the correct new version 1.7.5 show up

so I assume with your last uninstall and reinstall you still got version 1.7.4

Best to enjoy your beers now, and when you get back or get a chance go to pypi.org and search for theengs

If and when the search result also comes up with TheengsDecoder 1.7.5 then uninstall and reinstall the Theengs Gateway Add-on - we might have rushing it all a bit just now

Happy Beer Time

[DigiH]

I’m not sure if you have tried again uninstalling and reinstalling the Theengs Gateway Add-on - possibly also with a HA reboot in between, if possible at all with your set-up - which might actually have been a cache issue before instead of the pypi.org listing issue!?!

The OpenMQTTGateway development branch test builds have also finished now and can be installed through

(Option 1) Upload from the web | Theengs OpenMQTTGateway DEVELOPMENT...

with either the esp32-m5stack-ble or a plain esp32dev-ble binary.

[sesardelaisla (Sésar de la Isla)]

@DigiH

with either the esp32-m5stack-ble or a plain esp32dev-ble binary.

Shouldn’t I try esp32-m5atom-lite build instead, the one I started with?

[DigiH]

@sesardelaisla

esp32-m5atom-lite

That’s the one I actually meant but either should be fine

[sesardelaisla (Sésar de la Isla)]

Done!

This is what I see now in MQTT Explorer:

The 001D… topic has the following content. Device UUID, major and minor parameters are right:

{"id":"00:1D:43:9A:01:0A","name":"108-010A","rssi":-48,"brand":"GENERIC","model":"iBeacon","model_id":"IBEACON","type":"BCON","mfid":"4c00","uuid":"fda50693a4e24fb1afcfc6eb07647825","major":10065,"minor":26049,"txpower":-3}

However, I cannot find any new Beacon-XXXXXX device under MQTT integration. Am I forgetting anything? How should I set PUBLISH_ALL and PUBLISH_ADVDATA. Tried some combinations and nothing changes.

[DigiH]

@sesardelaisla

The 001D… topic has the following content. Device UUID, major and minor parameters are right:

{"id":"00:1D:43:9A:01:0A","name":"108-010A","rssi":-48,"brand":"GENERIC","model":"iBeacon","model_id":"IBEACON","type":"BCON","mfid":"4c00","uuid":"fda50693a4e24fb1afcfc6eb07647825","major":10065,"minor":26049,"txpower":-3}

This is the iBeacon protocol, which I read the beacon send out alternately with its own protocol, which you confirmed in your nRFConnetc screenshot and the previously undecoded message.

So expanding and looking in the history (on the right side of MQTT Explorer) of the 001D… topic you should see the message history, with the above stated iBeacon protocol, which we ignore, but also with the native, now decoded, messages alternating.

I don’t know if you can set the beacon to only send its own protocol broadcasts, and to turn off the iBeacon broadcasts completely, as they are not relevant to how you want to use the beacon with HA.

You might want to set BT: Interval between scans and BT: Interval between active scans in the gateway interface lower from their default 55 seconds to something like 20, so that more messages will be received for this verification.

[sesardelaisla (Sésar de la Isla)]

@DigiH

You might want to set BT: Interval between scans and BT: Interval between active scans in the gateway interface lower from their default 55 seconds to something like 20

I don’t see those specific parameters:

[DigiH]

@sesardelaisla

I don’t see those specific parameters:

I assume that is because you have the BT & IR Atom Lite binary installed

Did you see any other message apart from the iBeacon messages in the MQTT History though?

And can you turn ON SYS; Auto discovery, and then click on PULSA for SYS Restart Gateway?

[sesardelaisla (Sésar de la Isla)]

@DigiH

I assume that is because you have the BT & IR Atom Lite binary installed

Should I try installing one of the options you mentioned earlier?

@DigiH

Did you see any other message apart from the iBeacon messages in the MQTT History though?

There two type of strings in the history: the short ones that can be fully seen in the screenshot and the longer ones:

{"id":"00:1D:43:9A:01:0A","name":"108-010A","rssi":-49,"brand":"GENERIC","model":"iBeacon","model_id":"IBEACON","type":"BCON","mfid":"4c00","uuid":"fda50693a4e24fb1afcfc6eb07647825","major":10065,"minor":26049,"txpower":-3}

@DigiH

And can you turn ON SYS; Auto discovery, and then click on PULSA for SYS Restart Gateway?

Done. I see no changes. Still no “beacon*” devices.

[DigiH]

@sesardelaisla

Should I try installing one of the options you mentioned earlier?

Let’s try it with just the generic esp32dev-ble binary, although from the messages it looks as if the beacon might only be sending iBeacon protocol and other protocol messages.

Before installing the esp32dev-ble binary though, can you turn on the BT: Publish Advanced Data again and see what these other messages apart from the iBeacon protocol are in the history?

If you click on the copy icon behind each message in the history you can also paste them easily in here, instead of having to upload wide screenshots

[sesardelaisla (Sésar de la Isla)]

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

Not sure whether I am copying the same messages, because I think the history scrolls.

[DigiH]

@sesardelaisla

{"id":"00:1D:43:9A:01:0A","mac_type":0,"adv_type":0,"name":"108-010A","rssi":-55,"servicedata":"20000be78000000197f00002c0da","servicedatauuid":"0xfeaa"}

This is not a message which is decoded, but any

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

message, which we went for originally, should be correctly decoded now.

I know it might be a silly question, but you did upload the development binary from the upload page with
Theengs OpenMQTTGateway DEVELOPMENT SHA:bb491a TEST ONLY
at the top, and not from the 1.7.0 release page, which looks virtually identical, but has only got the heading
OpenMQTTGateway v1.7.0 ?

[sesardelaisla (Sésar de la Isla)]

@DigiH

I know it might be a silly question…

Actually it is not. I did install from the release page. Not sure how I got there because your link points to the TEST one. Sorry!

Uploading…

[sesardelaisla (Sésar de la Isla)]

Voilà!

[DigiH]

Great, I thought I was going mad with it not working as it should.

It does happen with the pages looking so alike

The actual device tracker AWAY time can be adjusted with the presenceawaytimer value, which is set to 120 seconds as a default after the last Bluetooth reception of the tracker has been registered, but can be adjusted. And as device-tracker entry it can also be assigned to a person in HA.

So any of the three previously mentioned ways will be possible now, Add-on only, once the updated Theengs Decoder is all fine with PyPi.org, OpenMQTTGateway only, as you are doing now, or OpenMQTTGatway undecoded binary as a proxy antenna for the Theengs Gateway Add-on.

I hope this implementation of the Feasycom beacon helps you use it the way you planned to, and thanks again for your participation in this decoder, as it will also recognise all other Bluetooth beacon models from Feasycom for other users!