Closed ts-kris closed 2 years ago
Thanks for the report and fix.
Willl release soon.
Just curious, what is your application?
Try it and if it is OK, please close this issue.
Just curious, what is your application?
Its a demo for using some of our hardware to capture TLM beacon information. The fix is important because without it, there is no indication of specifically what hardware sent the beacon out. e.g. If there are 5 beacons reporting 5 different temperatures and time stamps, there was no way to tell which was which.
Despite Eddystone being more or less discontinued as intended by Google, many BLE beacon EVKs implement Eddystone still out of the box.
Try it and if it is OK, please close this issue.
Looks good to me!
I noticed that in aioblescan, all Eddystone beacons also get rssi and mac appended to them in their .decode() function, but not TLM.
e.g. https://github.com/frawau/aioblescan/blob/master/aioblescan/plugins/eddystone.py#L305-L306 UID beacon does not return https://github.com/frawau/aioblescan/blob/master/aioblescan/plugins/eddystone.py#L358 URL beacon does not return https://github.com/frawau/aioblescan/blob/master/aioblescan/plugins/eddystone.py#L385-L386 EID beacon does not return https://github.com/frawau/aioblescan/blob/master/aioblescan/plugins/eddystone.py#L379 TLM returns and misses out on running the rssi and mac lines before final function return:
https://github.com/frawau/aioblescan/blob/master/aioblescan/plugins/eddystone.py#L387-L393
I'm not sure if this is intended or desired or what, but, I need it in my application. A quick patch removing the return gets me rssi and mac in the final packet decode