U-Bolt Pro Bluetooth Status

[nowjon]

Edit: Deleted as DigiH has verified we're not implementing this with theengs decoder due to privacy concerns.

[DigiH]

Hi @nowjon,

great finds to get us started to include the U-Bolt Pro into Decoder - thanks!

Would you also be able to monitor the BLE broadcasts you are receiving with MQTT-Explorer to give us additional information of the broadcast messages?

I think you are using OpenMQTTGateway to receive these broadcasts, am I correct?

If so, once we have an initial decoder ready for testing, we can give you instructions on how to test it with OMG, to further refine it.

Thanks

[nowjon]

Correct, and yes I can provide that info from MQTT-Explorer, is there something specific you want from the application or do you know how to export the Value History and I can provide that?

Here's an example of my two locks from MQTT-Explorer:
Back Door:
REDACTED
Front Door:
REDACTED

Please note, the name doesn't always show up, like in this one:
REDACTED

[DigiH]

Please note, the name doesn't always show up, like in this one: {"id":"AC:4D:16:31:8A:8E","mac_type":0,"manufacturerdata":"0d007f0600e102030001aa","rssi":-88}

This was actually one of the things I wanted to see, if a name was also being broadcast, great for helping to uniquely identify devices.

So when you say it doesn't always show up, is it just sporadically, or quite common for broadcasts without the name?

A longer history of MQTT-Explorer broadcasts would help a lot here, or just plain mosquitto_sub outputs, as I also don't know if and how the history in MQTT-Explorer might be exported.

[nowjon]

I was able to have Node-Red listen to OpenMQTT/Locks/BTtoMQTT/F05ECDC93C77 and write the payload to a log file. The below is 1 minute of the events (not doing anything with the door during this time)
REDACTED

Here's some info from nRF Connect
REDACTED

[DigiH]

I was able to have Node-Red listen to OpenMQTT/Locks/BTtoMQTT/F05ECDC93C77 and write the payload to a log file. The below is 1 minute of the events (not doing anything with the door during this time)

This is perfect, thanks. It also shows that there are enough broadcasts with the name included within that minute, to be able to use this as a device identification.

Here's some info from nRF Connect

Thanks, only the first page here is relevant for a freely manufacturerdata broadcast BLE decoder, all the other pages show the service/characteristics only available for connections to the device, and some of them being encoded.

I will create a quick test decoder from your examples and info.

Will you be able to build an OMG test build with Platformio ton test this decoder?

[nowjon]

only the first page here is relevant for a freely manufacturerdata broadcast BLE decoder

I've gone ahead and removed the extra screenshots.

Will you be able to build an OMG test build with Platformio ton test this decoder?

I've never done something like that before. I see there are steps on the OpenMQTTGateway docs, I can attempt to follow those steps if that is what you're referring to. I'm currently running esp32dev-ble-cont

[DigiH]

There are also longer codes, which aren’t caught all the time, unfortunately, by the ESP32, not sure if this is distance related or what, but I’m fairly sure

Your reception seems to be not the best, with the rssi being between -93 and -83. Moving the ESP32 with OMG closer to the door/lock should help, and the WiFi reception for it should hopefully still be fine as well.

I've never done something like that before. I see there are steps on the OpenMQTTGateway docs, I can attempt to follow those steps if that is what you're referring to. I'm currently running esp32dev-ble-cont

While it might sounds a bit daunting at first, using Visual Studio Code with the Platformio extension to build and upload your own OMG build is not that difficult. There is more information at

https://docs.openmqttgateway.com/upload/builds.html#configure-upload-with-platformio

but the easiest start is to follow the two steps here

https://platformio.org/install/ide?install=vscode

Once you have done that I can talk you through downlaoding the OMG source, opening it, making one simple change to direct to the new U-Bolt test decoder, then just build and upload the esp32dev-ble-cont environment with the new decoder.

[nowjon]

I just jammed the bolt with my hand while the door was open and it's code currently is:
REDACTED
I think your theory may be right.

[DigiH]

I just jammed the bolt with my hand while the door was open and it's code currently is:
0d007f0600e101030100b8
I think your theory may be right.

Thanks for the confirmation. I have amended the decoder accordingly. You can now again do

Clean All, then Build, then Upload

to make sure you have these latest decoder changes on your gateway.

Will the lock-locked/unlocked state-open/closed and jammed properties then be sufficient states for the U-Bolt decoder?

I think most of the other data and possible meanings are also encrypted/rotated, therefore not accessible for Theengs Decoder, as to give at least some of the locks functionality some privacy/security feature, as with the ones above which we are including in the decoder now, every passer-by with a phone and a bit of knowledge will also be able to view these current states of your front door.

Signing off here for the night, but hope you can run some more tests with the new decoder changes to see if everything is working fine for you.

[DigiH]

Hi @nowjon,

I have currently temporarily removed the U-Bolt Pro test decoder branch.

With the above mentioned privacy/security concerns, and this decoder eventually also ending up in the Theengs App, this would easily make it available on every phone to go through the streets and check for any U-Bolt Pro locks and their loecked/unlocked - open/closed statuses.

So we are debating if integrating such a decoder into Theengs Decoder would not in the end be more helpful to potential burglars/home invaders than to actual owners of the locks.

As you saw yourself how easy it is to decode the basic lock/unlocked, open/closed and jammed states, please be aware that these states can be monitored by anyone within Bluetooth reception of your home.

I wonder if the app for the lock allows to disable these freely broadcast state messages.

[nowjon]

I just checked and verified there is no setting for disabling anything related to Bluetooth in the app.
Ideally I'd like the Z-Wave integration to be better but no progress has been made as far as I'm aware by the company to address the issues with it.

[DigiH]

Quite frankly, I would think that if and when they release firmware updates with better Z-wave support they would also stop the free BLE transfer of the lock's states, addressing the security/privacy concerns.

For these reason we have also unanimously decided not to include the U-Lock decoder into the Theengs projects.

While this isn't helpful for the integration of your lock into your home system, I hope you do understand out reasoning behind this.

Thanks