My Mi Scale is constantly being detected even when not in use and using /home_presence/ as presence detector is useless as it only returns a single object (usually Mi Scale).
Well, it returns also other objects that are more relevant for presence detection (if you have) so just forget the Mi Scale id for your presence detection system.
2 Likes
I think a more useful presentation would be to post to /home_presence/device/{last_seen, gateway_id}
This way, you can subscribe to the presence of the devices you want and instantly know where it was last seen.
Now that we know that you are using openHAB, did you have a look at the openHAB presence detection example in the Docs?
Put that together with a white-list - and where does it still not work for you or is not useful with the current setup?
I have about 20+ Bluetooth devices in my vicinity, but can nicely filter out only the five I want to work with in openHAB with the above.
I have looked at the section and it is extremely primitive. It only shows when a device appears in range of a gateway but does nothing about consolidating input from multiple gateways.
If the data is posted to the format I suggested above, it would allow a single rule for all gateways instead of 1 rule per gateway per device.
Useless in the headline, extremely primitive in the last post. Do you honestly think this is the best way to suggest new features?
This is already possible!! One single, not even very complex, rule to process presence detection with multiple gateways.
If the extremely primitive example in the Docs didn’t make you go “oh yeah, great start, now I can take that further to do exactly what I want”, then maybe it’s time to for some not so primitive rule writing and topic naming excercises.
Or did you really expect a fully fleshed out working example tailored exactly to your needs there?
Not sure why you’re being so confrontational. If you have nothing to offer to the topic, maybe just avoid it entirely? I don’t see why the two descriptions are contradictory in any way. The example is extremely primitive in implementation but still fundamentally useless for what I’m trying to achieve. Nowhere in my posts have I ever asked for a tutorial or guide, that’s just you projecting intentions on others.
Regarding the underlying issue, the message posted to /home_presence is simply a duplicate of the ones posted under each individual gateway. There’s simply no purpose to it other than making it easier to access that same data already available. So if there’s already code implementing a half baked use for it, why not go all the way with proper formatting?
The proposed solution to the original post was to forget/blacklist one of the devices is terribly inadequate and contravenes the ethos of OMG being a multifunctional gateway because:
- Now you have to maintain two different gateways if you want to obtain input from certain devices that constantly broadcast old data while also use it for presence detection
- Phones also produce useless ambient data because of the mac address spoofing which means the only reliable use is to whitelist devices, which brings about the same either or functionality issues.
Home_presence was added for HASS compatibility here :
Because of the condescending and patronising tone in your posts.
Not duplicate, but similar info, though very different in the rssi and distance information. Together with the already existing different names of the gateways - something you suggested should be newly implemented as gateway_id for whatever reason - this can easily be used to know exactly to which gateways a beacon is closest, and therefor be nicely used for presence and location detection.
Phones or any other ambient bluetooth devices will always be seen by all the OMG gateways. The advantages of white/black lists being that devices which you’re not interested in will be filtered out on the gateway, and won’t spam the MQTT broker. So your Mi scale will always be in the MQTT broker messages, unless you introduce a white/black list.
If the /home_presence/ transmissions are useless to you, why don’t you just ignore them completely and use the alternate
home/OMG/BTtoMQTT/XXXXXXXXXXXX
transmissions, which are sent out simultaneously, and with which you can then directly subscribe to only the MAC address XXXXXXXXXXXX device you want?