Please don’t update any more for the time being, as the previous test build SHA:c21e2e has been overwritten by the nightly development build, where the above changes haven’t been merged into yet.
Not necessarily until the next official release, but once the above changes have been merged into development, then you can install any of the nightly test builds at the above URL.
Can I update my devices wirelessly or do I need to bring them back to my computer to add the DEV firmware?
There are two ways to update your gateways without having to fetch each one to hook up to your comoputer
• By accessing the WebUI’s Firmware Upgrade section of your gateways.
• By using Visual Studio Code with the PlarformIO extension installed, so you can create your own builds, which would also make it easier to set all relevant settings in advance of each install, like WiFi and MQTT credentials, but also BLE scan intervals etc.
The “pubuuid4topic” is only applicable to recognised iBeacon protocol devices, like the one you seem to have. For all other unknown devices which might randomly change their MAC address there is currently only a possibility to uniquely identify them with Theengs Gateway’s Resolving random private addresses functionality, if you know its Bluetooth Identity Address and corresponding Identity Resolving Key. As this is currently only implemented in Theengs Gateway it will only be practically available for Home/Away Device Tracker utilisation.
You best bet to not have your other undecodable unwanted Bluetooth devices not being published to your broker is to apply a white- or black-list to your OMG gateways.
May I ask what these Room Shields actually are? Do they possibly broadcast BLE advertisement data which might hold decodable information? To see that you can set Advertisement and Advanced Data to true on one or more, or your test gateway.
However the range of the Bluetooth gateways appear to be pretty significant and receives data at longer distances than I would have expected. This is not much of an issue with the BlueCharm Tracker, but with the Tile tracker being with my wife’s keys on the kitchen table the presence seems to jump around quite a bit though the tile is not moving.
…
I am curious if a sensitivity slider could be added which could be adjusted to lower the sensitivity or range to trackers. Might this make the Tile less susceptible to jumping around?
There are two issues here. First the gateway’s sensitivity, which cannot be easily adjusted by a slider, as this option is so rarely used by users that it is not included in the HA UI section of the gateways as not to produce too much clutter. There is the option of setting the minimum RSSI accepted to publish device data, which does exactly what you want to do, reduce or increase the sensitivity of each individual gateway as to with which single strength received it will publish a trackers data or not. This is best set individually for each gateway, as their individual ranges very likely vary.
For the Tile there is also a difference that it requires active scanning, which, if not set to the same interval as passive scanning (intervalacts vs. interval in the BTtoMQTT data), could produce this kind of jumping you are seeing. Also keep in mind that active scanning has a slightly detrimental effect on the device’s battery life, whereas passive scanning doesn’t affect it at all.
Generally though, the best trackers for the most precise room tracking are BLE trackers which allow you to set their txpower @ 1 m, like some generic iBeacons for example. By testing these devices’ reception with ones individual gateways exactly at 1 metre distance, and then setting this value accordingly, the calculated RSSI based distance calculation is more accurate and the minimum RSSI mentioned above can also be more precisely set.
I also own a Samsung Galaxy Watch 4. I am not sure what it sends out as BLE messages but I did note that it periodically shows up in MQTT Explorer with Data like this:
Once you set the Advertisement and Advanced Data to true you will see that your Galaxy watch actually sends a lot more data. From the little experience I have with these watches I would say that its manufacturerdata likely starts with "750001000200010…". If this is restricted to the Galaxy watches, or if Galaxy phones might have the same manufacturerdata, and if the remaining data does contain any useful decodable information or not I also do not know. Let’s see what yours broadcasts 
At least the very obvious part of the manufacturerdata would likely allow for creating a decoder to also make Galaxy watches a sensor, with automatic device tracker discovery. If it does change it’s MAC address however, again this would currently only be possible with Theengs Gateway and its Identity MAC/IRK functionality - if you can get information on how to find these out for your Galaxy watch.
While all the above linked to setting possibilities can be done in MQTT Explorer’s Publish section, which you might have used for this so far, keep in mind that this is also possible in the Console section of the WebUI.
Hope you have a great weekend ahead!
Thank you, and have a great weekend, too!
