Add data type for MAC/hardware id

[matt7aylor]

Firstly I'd like to say great work on this project, we make a few simple Bluetooth sensors and had been looking for a specification exactly like this to format our data.

We are currently working on a portable air quality sensor that could be used at home with Home Assistant but also on the go with a mobile app. We have a working prototype of this (including a basic mobile app) but since iOS/macOS devices do not give access to the MAC address it makes it hard to identify the device, especially if there is more than one. This makes it more difficult to label or link the device with the same entity on Home Assistant or other platform. I notice you actually identify the same problem in your parser code, e.g. parser.py L120 and parser.py L143-148

It would be great if a MAC data type (6 bytes) could be added to the BTHome v2 format for devices that want to use it to help with such scenarios.

(It might also be worth considering if there is a nice way to make this work with encryption in future but since encrypted devices will anyway require some means of setting a key, the MAC could also be set in the application at that point, so for our uses it may not be required.)

[Ernst79]

Should be possible to add that. Will look into it a.s.a.p.

[matt7aylor]

Fantastic, thanks. Do you think we could nominate a 'proposed' object id for now while the rest of the implementation is being done. We've been testing with 0x99 just to have something recognisable but it would be good to use the one that will hopefully eventually make it into the specification.

[Ernst79]

Sorry, have been busy with some other xiaomi-ble stuff.

I was thinking about changing this first byte after the uuid (BTHome Device Information). Currently we have:

bit 0: “Encryption flag”
bit 1-4: “Reserved for future use”
bit 5-7: “BTHome Version”

I’m thinking to change this to

bit 0: “Encryption flag”
bit 1: “MAC included”
bit 1-4: “Reserved for future use”
bit 5-7: “BTHome Version”

If bit 1 = 1, then the next 6 bytes are the MAC address in reversed order.

this mac is optional, but if used, it has to be the same as the mac in the beginning of the advertisement, otherwise the entire advertisement will be rejected.

[Ernst79]

I've created a PR to add support for MAC's in the payload, as described above. Are you able to do a review?

I'll update the docs if the proposed change is ok

[matt7aylor]

Yeah, I think that's a much better way of doing it. We've tested it out a bit this week with some sensors we have made and your parser, working well. Will add review to the PR (might be from my colleague).

[Ernst79]

added in 2.6.0

[pvvx]

this mac is optional, but if used, it has to be the same as the mac in the beginning of the advertisement, otherwise the entire advertisement will be rejected.

This eliminates relaying of remote devices.

[mhaberler]

added in 2.6.0

in the bthome docs Bit 1 is still marked as reserved

[IvoGruber]

added in 2.6.0

in the bthome docs Bit 1 is still marked as reserved

@matt7aylor @mhaberler We decided not to document that feature since it reopens privacy issues that MacOS is trying to address by hiding/randomizing the MAC addresses.

See PR #323 for more details. Please, continue discussion in PR #328. We try to implement a new feature there that will solve the use case without that privacy issue.