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é »
Bonjour, je n’arrive ni a faire reconnaitre ma montre connecté par l’integration Bluetooth, ni a trouver l’IP de mon tel dans l’intégration LAN.
Sur la recherche du LAN il ne me trouve jamais plus d’une 10aine d’appareil alors qu’un Scan IP depuis mon PC m’en trouve 25…
L’IP de mon tel est bien atteinte par un ping depuis mon serveur gladys.
Puisqu’il existe une intégration pour gérer la présence dans une zone via Owntracks. Pourquoi cette présence dans une zone ne peut pas être utilisée comme indicateur de présence sur un tableau de bord ou dans une scène ?
Salut @Steph38230,
Le suivi d’appareils connectés (montres, téléphones, etc.) fonctionne très mal en Bluetooth et en Wi-Fi. C’est en grande partie volontaire : les constructeurs ont mis en place de nombreuses techniques pour empêcher le tracking des personnes (rotation des adresses MAC, protections côté OS, etc.).
Le but est de rendre beaucoup plus difficile l’identification et le suivi d’un appareil dans le temps, ce qui est plutôt une bonne chose du point de vue de la vie privée.
C’est tout à fait possible 
Tu fais 2 scènes :
- « Si l’utilisateur A rentre dans la zone X » → « Marquer l’utilisateur A comme à la maison »
- « Si l’utilisateur A sort de la zone X » → « Marquer l’utilisateur A comme absent »
De mon côté, pour la gestion de la présence, j’ai mis en place 2 raccourcis sur mon téléphone :
Mon téléphone fait lui même la détection de l’entrée/sortie de zone, et ensuite il fait une requête à Gladys (via l’Open API Gladys Plus : Open API | Gladys Assistant )
Ça marche super et je pense que c’est la façon la plus optimisée en batterie de faire, car c’est le téléphone qui gère toute l’intelligence et donc c’est optimisée par Apple
1 « J'aime »
Super. Merci je mets ça en place tout de suite 
1 « J'aime »
Je vois que cette intégration est souvent mal comprise donc j’ai renommé l’intégration « Bluetooth » en « Présence Bluetooth » :
Et dans l’intégration j’ai rajouté une petit message pour que ce soit plus clair :
4 « J'aime »
Ce correctif est disponible dans Gladys Assistant 4.71 :
J’ai installé Owntracks sur mon tel et sur celui de ma femme.
Dans Gladys j’ai généré 2 clés API. Ca marche très bien pour moi, mais la localisation de ma femme ne remonte pas sur Gladys.
Dans Open API j’ai généré 2 clé API avec nos 2 prénoms correspondant au Tag des utilisateurs
Sur l’appli Owntracks de Sylvie je vois bien des envois d’info vers Gladys dans le log, mais elle n’apparait pas du tout sur la carte et n’est pas detectée en entrée ou sortie de zone.
Il faut faire quelque chose d’autre comme elle n’est pas « l’utilisateur principal » ou ca devrait marché et c’est alors surement un pb de config de Owntracks sur son IPhone (je hais les Iphone )
Tu as bien généré la clé d’API de ta femme sur le compte Gladys Plus de ta femme ? D’après ton screenshot, j’ai l’impression que non !
1 « J'aime »
Il faut donc que je lui crée son compte GladysPlus en tant qu’Admin pour qu’elle puisse accéder au paramètre OpenAPI ?
Exact ! Quitte à lui retirer l’accès admin après, mais pour créer une clé d’API, il faut être administrateur
1 « J'aime »