Anyone with Apple AirPods (Pro) or Beats Solo/Studio Buds interested in helping to finalise a decoder for them?

[DigiH]

Hi all,

Anyone with the above mentioned ear buds? I have a decoder pretty much ready, but due to the lack of owning any such devices I cannot test it any further to finalise it ;)

So anyone interested to help with finishing the decoder, which would publish the model, colour, state and battery levels of the right and left AirPods and case and their charging states, as well as using them as device trackers, let me know.

Thanks

[myhomeiot]

@DigiH It's not straight forward, you can check my implementation for ESPHome maybe you find it's useful.
Thanks for great work, hope it's helps.

[DigiH]

Thanks @myhomeiot , but I have already merged the Apple AirPods/ Beats Buds a few months ago, with the help of a user with AirPods Pro, not having any myself.

Still missing some Beats Buds models and colour options, but that can only be extended properly by user submissions ;)

https://decoder.theengs.io/devices/AppleAirPods.html

[myhomeiot]

You can add following devices and color:
0a20 -> AirPods Max (Lightning)
1420 -> AirPods Pro 2 (Lightning, previously 2nd gen)
2420 -> AirPods Pro 2 (USB-C, previously 2nd gen)

11 -> Green

In my case your decoder always swap left and right battery % and charging state and not correctly detects state of buds In case, Out of the case, In ear.

[myhomeiot]

While I suppose we both base a lot of the decoding on the Continuity Proximity Pairing details, I was wondering where you got the LR/RL reversal from, and also the depending various states?

I found it experimentally using my AirPods. For Max ear state (In Case, In Ear), charging state and battery % reported as for right buds and doesn't required swap but it's still required for Beats Solo³ (others I don't know).

Yes, I have access to AirPods Max Lightning in green and Beats Solo³ :)

I'm not very familiar with your decoder (I'm more involved in ESPHome and Passive BLE Monitor), but, yes, I will try to help and test it.

[DigiH]

I found it experimentally using my AirPods. For Max ear state (In Case, In Ear), charging state and battery % reported as for right buds and doesn't required swap but it's still required for Beats Solo³ (others I don't know).

@myhomeiot Thanks to your extensive experimenting I have amended and expanded our decoder. From your mapping I deducted that the LR or RL swap is indicated by bit[1] of the 4-bit byte (or bit[4] of octet state byte if you prefer), i. e.

It will be interesting to see if further LR - 8, 9, c etc. might occur with additional different AirPods/Buds models, and if the remains 3 bits might actually also have their significance.

With all the swapping though, and no chance to verify it with any AirPods myself, I'm not completely sure now if LR is bit[1] = 0 and RL is bit[1] = 1, or if it is actually the reverse ;)

You could test the decoder by installing the development version of OpenMQTTGateway, which includes the amended decoder.

The esp32dev-ble binary is fine for uploading to any standard ESP32 dev kit/WROOM board.

https://docs.openmqttgateway.com/dev/upload/web-install.html

While OpenMQTTGateway doesn't yet support random MAC address resolving with an IRK, you can set randommacs to true, so that you will see the published decoded AirPods and Beats Buds in MQTT Explorer, albeit with changing MAC addresses about every 15 minutes, but fine for LR/RL verification.

Just make sure to set disc (HA auto-discovery) to false, so you won't get lots of discovered AirPods and Beats Buds with different MAC addresses.

I would very much appreciate it if you could verify the LR/RL, but also understand if the above with trying the development build of OpenMQTTGateway might be a bit too involved :)

I'm not very familiar with your decoder (I'm more involved in ESPHome and Passive BLE Monitor), but, yes, I will try to help and test it.

The BLE version of OpenMQTTGateway is similar to HA BLE-Monitor in that it decodes BLE advertising data, with the addition of decoders being able to state if devices are fine with passive scanning or if they require active scanning, and the possibility to set different time intervals for passive and active scanning, and also an auto-discovery as BLE device_trackers for certain devices, these AirPods and Beats Buds included to allow for Home/Away recognition of them.

Once the decoder is in a release of Theengs Decoder it will also be available in Theengs Gateway, along with its Home Assistant Add-on. But you could also pip install Theengs Gateway and then overwrite the included pip release version of Theengs Decoder by building and installing the current development branch, if that sounds easier to you. This would also already allow for Identity MAC resolving and proper discovery.

Any help with verifying the LR/RL swap would be greatly appreciated, and thanks again for the very helpful map in your implementation.

[myhomeiot]

Nice job! I will try to do my best and test it but it's can take time :(

[myhomeiot]

It will be interesting to see if further LR - 8, 9, c etc. might occur with additional different AirPods/Buds models, and if the remains 3 bits might actually also have their significance.

This looks like truth, but I doesn't try to find this dependency because not yet sure it's will persist for other devices. AirPods generates at least 10 more states which I doesn't include in the map because don't understand the meaning of them, but current map enough to confidently determine the state.

[DigiH]

I have complied a few more model versions, but will also now try to reduce the size of the decoder ;)

In the meantime you can have a look at the added model versions for your implementation

https://github.com/DigiH/decoder/blob/ff95034325b8837ec25fc464a1d169ae9320d282/src/devices/APPLEAIRPODS_json.h#L12-L31