Manage the presence of one or multiple users
Hello, do we have an idea of how to proceed?
-
The most used in v3 was the presence via Bluetooth (via a scenario « When this device is detected via Bluetooth, then I am at home ». « When this device is no longer detected for more than X minutes, then I am no longer at home »)
-
Next, perhaps the « estimated » presence via Owntracks (via 2 scenes, like « when I enter this geographical perimeter, then I am at home », « when I leave this perimeter, I am out of the house »
-
Finally, there is the presence via Wi-Fi network detection, which makes less and less sense now that iOS and Android rotate their MAC address to avoid this kind of tracking on public networks
Should we do as in v3, linking a device to a user? (not a fan)
Or do this through a scene? Or create a new dedicated UI service?
Or is the topic still up for discussion?
Why not with a facial recognition camera like Netatmoâs Welcome?
Or a button on the Gladys dashboard that triggers a scene (but this solution also requires clicking the button again when you leave).
Some leads found on the Net:
http://sarakha63-domotique.fr/presence-dans-la-domotique-les-solutions/
IFTTT seems to be the most suitable, but it has become paid, except for very limited use.
I found this.
But this solution seems to partially replace Gladys.
No, absolutely not, I agree! It was horrible to understand and not logical at all.
I think either in a scene, or in a dedicated service, to be seen what makes the most sense.
After thinking about it, I think a scene is the most flexible and works for the most people because everyone can add the conditions they want.
So, in my opinion, we need to create the necessary triggers/actions.
In the case of Bluetooth, we need to find a way to do this:
in a scene.
- So an action « change user presence » in the scenes allows to switch a user to « at home » or « no longer at home »
- Make sure that the scan of Bluetooth devices properly triggers an event when a Bluetooth device is seen after not having been seen for a while, and see the most logical way to catch this event in the scenes (via the trigger « device state changed »? Or a new trigger?)
- Make sure there is an action in the scenes that allows to retrieve the last detection date of a device. In my opinion, the « retrieve last state » box already does the job, we just need to make sure that this box stores the datetime of the last event in the scene variables, and that we are then able to compare this date in the action « continue only if ».
With this action, the user can create a scene that runs every 10 minutes, and checks « has device XXX been seen less than 10 minutes ago? ». If yes, continue only if, and perform the action block « change user presence » to « out of the house ».
What do you think @AlexTrovato?
Thanks @gaetanb76 for your research!
I agree, weâll see how to « store / retrieve the last detection date of a device » (add a « last_seen_date » column on device?).
Then, weâll also need to identify from the scene the devices that can be used as presence detection, in order to correctly implement the search on the service side (add a « user_presence » column on device? and the appropriate function on the service side « lookForDevice »?).
The problem with that is that we donât have the history. Couldnât it be a device_feature that would therefore have states?
I donât think there necessarily needs to be any adaptation, it could just be a device_feature specific to home detection
Indeed, device_feature may do the trick.
For info, my nut mini keychain is detected 
in the Bluetooth devices.
Think about adding it to the list of devices managed by Gladys.
It should only be added if it is managed for its function, presence management, which is not the case here.
Note, the list of devices that Gladys manages is a list that records devices « really managed and tested by a user », not devices that Gladys « sees » but does not really manage.
Indeed, thatâs exactly what I was thinking and wanted to comment on yesterday before being offline (15,000 households due to an excavator).
My nut is only recognized. I canât do anything with it for the moment.
Itâs also the case for my Qubino and Fibaro Z-wave modules which are only On/Off. No position setting for my roller shutters, no different modes for my heating (comfort, eco, frost protection), no feedback.
Thatâs why I didnât put them on the list.
Iâve merged the first feature, the ability to perform an action in scenes that says « the user is at home » or « the user is no longer at home ».
@AlexTrovato Next step: How could we create a trigger in the « Device Seen » scenes? (which could work with potentially Bluetooth, Wi-Fi, or other technology)
The goal is to be able to create a scene:
- WHEN « a device is seen: Nut Bluetooth »
- THEN « User âč john âș seen at home âč my home âș »
Potentially, this could just be a « device.state-changed » trigger but with a special « detection » deviceFeature? What do you think?
I think the « detection » or « human » or « presence » feature is the simplest way to manage this, and it also implies that itâs a special feature. For Bluetooth, we can perform regular scans, and if we detect the presence of the device, we update this feature.
We just need to try not to spam events but to properly filter devices with this feature.
However, it wonât be the Bluetooth service that can say that the Nut device is a presence device, but the Nut service that can create a device with this feature.
Or alternatively, allow this feature on all devices, with an option when creating it.
I would go for « detection » or « presence ».
That might be the most practical, but itâs just one brand among hundreds of others. If we have to make a service per brand, we wonât get far ^^
In any case, itâs just a checkbox to add in the Bluetooth device creation form, which will add the feature, and then the user can create their scene « when device XXX is seen » THEN « mark XXX at home XXX ».
What do you think?
Iâll buy it!
Iâm more for « presence », « detection » makes me think of « motion ».
However, I think we already have a « presence » feature (from memory).
Iâll check if itâs not used for something else.
Otherwise, Iâll schedule it for Bluetooth 
Added to the TODO list