After some playing and tweaking over the weekend I believe adjusting the minrssi setting as well as the presenceawaytimer will allow me to do the things I hope to do.
Still not sure I understand “presuseuuid” vs “pubuuid4topic”. If there is a short explanation of the difference that would be awesome.
For my Galaxy watch I gathered a bit more data if you are interested.
For the distance topics, is this measured in feet, meters, or just a relative number that gets bigger as the rssi goes down??? I also assume you have a chart of rssi to distance or a calculation you use to calculate the distaance. I would be interesed in those if they are easy to provide!
Lastly, I would like to update the rest of my sensors so please let me know when these changes have been merged in or when a new release with them will be coming out!
Not using either one myself and not having any real experience with them, all I know as well is the descriptions from the docs
and
So pubuuid4topic keeps the id as the device’s MAC address while presuseuuid also seems to change the id to the uuid for the presence message.
Please let us know if you see any other findings.
For my Galaxy watch I gathered a bit more data if you are interested.
“manufacturerdata”: “7500010002000103ff00004304”,
As I expected, the manufacturerdata starts with "750001000200010…", so it could be possible to create a tracker decoder for the galaxy watches. Since your two sample messages of your Galaxy watch clearly indicate that it has randomly changing MAC addresses though, currently this would only work as a general Home/Away Device Tracker with Theengs Gateway and its singular presence messages - similar to how we are already doing it for Apple Watches - and only if you find a way to retrieve the Identity MAC Address and Identity Resolving Key (IRK) for your Galaxy watch.
Everything OpenMQTTGateway is open source and easily viewable in the code on GitHub
As you can see there, and as I have mentioned above, the most accurate calculation will actually be with devices which have a user settable txpower (@ 1 metre) property. With any other trackers a generic calibration value is being used, so with these it should be more taken as just a relative number.
Lastly, I would like to update the rest of my sensors so please let me know when these changes have been merged in or when a new release with them will be coming out!
Just finishing off some last refinements and testing with the new code, then it should be ready to be merged in the next days.
So now that I have been able to update all of my OMG Gateways with the new code I wanted to give you an update on where I am. First, all sensors and trackers are working properly as verified with MQTT Explorer and Home Assistant. I made some tweaks to the minrssi level as well as the presenceawaytimer to try and arrive at a stable view of my presence with each beacon. This first image is of my Home Assistant presence for my BlueCharm beacon measured over a 10 minute window as I walked through my home:
This is very much the kind of result I was looking to achieve and it does accurately represent my movement through the house. For comparison I took a look at my wife’s tile in Home Assistant for the same time period. In this case though the device was stationary and had not moved. See the below image:
This is not what I would expect or hope to see for a beacon which is not moving. I would agree if it was positioned at a location where the three gateways that it bounces between were all receiving about the same signal level this is possible. I will have to do more testing with the tile moving and placed definitively closer to one OMG versus the others. But I was hoping to avoid what appears to be a good bit of jumping around of the location of the beacons as was shown in the first image. It is not clear to me what the tile transmit level of the Tile is which could be different from the BlueCharm and that could also possibly impact the results.
This is an image of the BlueCharm beacon taken at a different period of time but for the same 10 minute duration at the physical location the TIle had been in earlier in the day and not moving. It clearly is more stable and is connected to the OMG which is I believe the closest.
So quick question or two on the mimrssi setting. I assume this setting simply ignores received results below the threshold set and effectively discards them. I suspect this applies to all devices which are seen by each gateway. So to try and further increase the minrssi settings for my Tile experiencing jumping around I could eventually stop seeing other sensors which I want to see like my Hot Tub thermometer? So, does the minrssi apply to all sensors there is data received on or only the tracker sensors? I assume the first based on what see??? Would then it be of value to add a separate minrssi setting specific for trackers with the other one being for all non tracker sensors? Just a thought???
Anyway this is great progress towards an accurate presence detection in my home and I suspect others would like this in Home Assistant as well. Thanks again!
You should have a look at the messages from the Tile in MQTT Explorer, to see what might be happening with its RSSI value, and if it looks stable or if it might actually be jumping around.
Correct, as commented in config_BT.h
any device with an RSSI below the set value is not being reported/published over MQTT. And yes, this applies to all sensors received by the respective gateway.
If and how the Tile might actually vary its RSSI transmissions for possible better reception in case it gets lost or some other Tile specific functionality, I do not know.
My suggestion would be to optimise your OMG_01-OMG_XX gateways with MinimumRSSI to best match your home for correctly tracking your BlueCharm and the troublesome TIle. If some other snesors might fall off the grid because of the restricted MinimumRSSI setting the best idea would be to add one additional gateway, with no RSSI restriction to catch your Hot Tub thermometer etc. but with a white-list to only publish such sensors and with HASS presence turned off as not to interfere with your room location tracking.
Thanks for all the great information and suggestions. I will continue my adventure looking to optomize my Home Assistant world with OpenMQTTGateway.
WHile I understand the suggestion to use a separate gateway for special sensors as I adjust rssi levels, I am trying to avoid having a bunch of ESP gateways. I have 10 OMG’s now as well as 6 ESP Home gateways. Gotta think about this for a bit if there is no way to split that into two. But I do understand. Thanks again!
