Bonsoir,
Dans les scenes, on peut utiliser l’action ‹ Vérifier la présence › or il semblerait que cela ne gere que le cas l’utilisateur quitte la maison. Y a-t-il une raison?
D’avance merci,
Salut @Romuald_Pochet !
Oui, pour définir la présence, il faut utiliser l’action « Utilisateur vu à la maison » à la suite d’un trigger (exemple: un capteur Bluetooth vu à la maison).
La philosophie de cette façon de gérer la présence est de permettre les détections « multiples » et permettre à l’utilisateur de faire vraiment ce qu’il veut (détection bluetooth, GPS, reconnaissance faciale, clic sur un bouton, …),
J’ai écris un tutoriel dans le cas du Bluetooth (mais qui est valable quelle que soit le mode de détection):
@Romuald_Pochet J’ai vu ta PR, le problème de ton approche est que la détection va être trop lente !
L’intérêt de faire un déclencheur, c’est que l’utilisateur est mis comme « à la maison » instantanément, et non pas via une scène exécutée de manière périodique.
La détection d’absence, par nature, ne peut fonctionner que via une approche périodique (on vérifie toutes les X minutes), afin de laisser une marge si jamais le capteur n’est pas vu une fois mais est vite revu.
L’action de scène le spécifie d’ailleurs :
Bonsoir,
Je suis d’accord sur le principe en place, juste que je n’aime pas créer une scene 
Ne serait-il pas envisageable de mettre, sur les pages des intégrations, pour les « devices de type présence » la possibilite de choisir un utilisateur afin de gérer la (non)-présence automatiquement? Pour « ceux qui veulent », les scenes permettront toujours de faire du spécifique.
Actuellement, chaque utilisateur est détecter via ‹ Lan Manager ›, sauf moi qui a également un Tile (bluetooth) mais je n’ai pas trop de soucis a gérér les 2 de manière indentique (même si il est vrai que si l’un des 2 manque cela pourrait indiquer un soucis).
PS: ayant 3 intégrations en cours, j’imaginais un template pour chaque intégration, du style:
- page ‹ Configuration ›: définition des parametres (/config: pour obtenir/mettre à jour, /status: pour obtenir l’état)
- page ‹ Découverte ›: affichage des devices « pures » de l’intégration
- page ‹ Devices ›: affichage des devices au style ‹ Gladys › (avec sélection pièce, user dans le cas des devices de type présence, mise à jour des features…) et ce manère indépendante de l’intégration…
ça fait un peu boite noire non ? Comment gérer le multi-device dans ce cas là ?
On peut en parler sur un autre sujet si tu veux, c’est vrai qu’on pourrait créer un set de component « tout prêt » pour les intégrations pour simplifier un peu les développement et uniformiser l’interface des intégrations 
Ce qui se passe maintenant:
mono-device:
- Device présent = utilisateur présent (via scene)
- Device absent depuis x minutes = utilisateur absent (via scene « Verifier la presence »)
multi-device:
- Un device présent = utilisateur présent (via scene, donc on pourrait imaginer quelque chose de plus compliqué, genre tous les devices doivent être présents)
- Aucun device présent depuis x minutes = utilisateur absent (via scene « Verifier la presence »)
Je suppose que le cas mono-device est probablement le plus courant. Pour le multi-device, on peut imaginer, avoir un device « nécessaire » (le GSM par ex.) et un device « suffisant » (un token bluetooth par ex.). Je sais que c’est pas évident, mais même maintenant. J’irais même juste qu’a définir un utilisateur sur les device qui ont une feature « Présence ».
Mon cas: J’ai un GSM et un Tile, je peux oublier mon Tile qui est souvent dans mon sac a dos du boulot « suffisant », par contre mon GSM c’est plus rare « nécessaire ».
Concernant le phenomene boite noire, l’avantage c’est de fournir un comportement « qui-marche » pour les utlisateurs « non-initiés »
Je suis pas hyper d’accord, on pousse à un comportement qui marche mal et donc justement les utilisateurs non-initiés vont juste abandonner la détection de présence.
Il faut être réaliste, la détection de présence c’est utile si t’es détecté instantanément, si il faut attendre entre 0 et 2 minutes pour que ta maison se remette en mode « présent », ça devient inutile ^^
Tout a fait d’accord mais je ne parle pas de gérer le retour à la maison via un quelconque fréquence de scan (surtout que la detection de présence que ce soit lan-manager ou bluetooth est déjà basée sur une fréquence de scan), cette boîte pourrait agir directement suite à un changement d’état comme on le fait avec les scenes.
Ok je comprend mieux, mais du coup ça fait un peu doublon avec le déclencheur non ?
Actuellement la scène recommandée c’est:
« Quand mon porte clé Bluetooth est détecté » ALORS « Mettre utilisateur « PG » comme à la maison »
et toi tu propose:
« Quand mon porte clé Bluetooth est détecté » ALORS « Mettre l’utilisateur « PG » comme à la maison si mon porte clé Bluetooth est détecté »