Buenas noches,
En las escenas, se puede usar la acción ‹ Verificar la presencia › o parece que solo gestiona el caso de que el usuario salga de casa. ¿Hay alguna razón?
Gracias de antemano,
¡Hola @Romuald_Pochet!
Sí, para definir la presencia, hay que usar la acción « Usuario visto en casa » después de un disparador (ejemplo: un sensor Bluetooth visto en casa).
La filosofía de este modo de gestionar la presencia es permitir las detecciones « múltiples » y permitir al usuario hacer realmente lo que quiera (detección Bluetooth, GPS, reconocimiento facial, clic en un botón, …),
He escrito un tutorial en el caso del Bluetooth (pero que es válido independientemente del modo de detección):
@Romuald_Pochet He visto tu PR, el problema de tu enfoque es que la detección será demasiado lenta.
El interés de hacer un disparador es que el usuario se marca como « en casa » instantáneamente, y no a través de una escena ejecutada de manera periódica.
La detección de ausencia, por naturaleza, solo puede funcionar mediante un enfoque periódico (se verifica cada X minutos), para dejar un margen en caso de que el sensor no se vea una vez pero se vea rápidamente de nuevo.
La acción de la escena lo especifica, de hecho:
Buenas noches,
Estoy de acuerdo con el principio en vigor, solo que no me gusta crear escenas 
¿No sería posible añadir, en las páginas de integraciones, para los « dispositivos de tipo presencia » la posibilidad de elegir un usuario para gestionar la (no)-presencia automáticamente? Para « quienes quieran », las escenas siempre permitirán hacer cosas específicas.
Actualmente, cada usuario es detectado a través de ‹ Lan Manager ›, excepto yo que también tengo un Tile (bluetooth) pero no tengo muchos problemas en gestionar los dos de manera idéntica (aunque es cierto que si falta uno de los dos podría indicar un problema).
PD: teniendo 3 integraciones en curso, imaginaba una plantilla para cada integración, del estilo:
- página ‹ Configuración ›: definición de los parámetros (/config: para obtener/actualizar, /status: para obtener el estado)
- página ‹ Descubrimiento ›: visualización de los dispositivos « puros » de la integración
- página ‹ Dispositivos ›: visualización de los dispositivos al estilo ‹ Gladys › (con selección de habitación, usuario en el caso de los dispositivos de tipo presencia, actualización de las características…) y de manera independiente de la integración…
¿No es un poco una caja negra? ¿Cómo gestionar el multi-dispositivo en este caso?
Podemos hablar de ello en otro tema si quieres, es cierto que podríamos crear un conjunto de componentes « listos para usar » para las integraciones para simplificar un poco el desarrollo y uniformizar la interfaz de las integraciones 
Lo que ocurre ahora:
mono-dispositivo:
- Dispositivo presente = usuario presente (a través de escena)
- Dispositivo ausente durante x minutos = usuario ausente (a través de escena « Verificar la presencia »)
multi-dispositivo:
- Un dispositivo presente = usuario presente (a través de escena, por lo que podríamos imaginar algo más complicado, como que todos los dispositivos deben estar presentes)
- Ningún dispositivo presente durante x minutos = usuario ausente (a través de escena « Verificar la presencia »)
Supongo que el caso mono-dispositivo es probablemente el más común. Para el multi-dispositivo, podríamos imaginar tener un dispositivo « necesario » (el GSM, por ejemplo) y un dispositivo « suficiente » (un token Bluetooth, por ejemplo). Sé que no es evidente, pero incluso ahora. Incluso iría tan lejos como para definir un usuario en los dispositivos que tienen una función « Presencia ».
Mi caso: Tengo un GSM y un Tile, puedo olvidar mi Tile que a menudo está en mi mochila del trabajo « suficiente », pero mi GSM es más raro « necesario ».
En cuanto al fenómeno de la caja negra, la ventaja es proporcionar un comportamiento « que funciona » para los usuarios « no iniciados »
No estoy muy de acuerdo, se fomenta un comportamiento que funciona mal y, por lo tanto, los usuarios no iniciados simplemente abandonarán la detección de presencia.
Hay que ser realistas, la detección de presencia es útil si eres detectado instantáneamente. Si tienes que esperar entre 0 y 2 minutos para que tu casa vuelva al modo « presente », se vuelve inútil ^^
Totalmente de acuerdo, pero no hablo de gestionar el regreso a casa mediante alguna frecuencia de escaneo (especialmente porque la detección de presencia, ya sea mediante lan-manager o bluetooth, ya se basa en una frecuencia de escaneo), esta caja podría actuar directamente tras un cambio de estado como hacemos con las escenas.
Vale, lo entiendo mejor, pero entonces parece un poco redundante con el disparador, ¿no?
Actualmente la escena recomendada es:
« Cuando se detecta mi llavero Bluetooth » ENTONCES « Poner al usuario « PG » como en casa »
y tú propones:
« Cuando se detecta mi llavero Bluetooth » ENTONCES « Poner al usuario « PG » como en casa si se detecta mi llavero Bluetooth »
Hola, no logro que mi reloj conectado sea reconocido mediante la integración Bluetooth, ni encontrar la IP de mi teléfono en la integración LAN.
En la búsqueda de LAN nunca encuentra más de una decena de dispositivos, mientras que un escaneo IP desde mi PC encuentra 25…
La IP de mi teléfono sí es alcanzable mediante un ping desde mi servidor Gladys.
Si existe una integración para gestionar la presencia en una zona mediante OwnTracks, ¿por qué esta presencia en una zona no puede usarse como indicador de presencia en un tablero o en una escena?
Hola @Steph38230,
El seguimiento de dispositivos conectados (relojes, teléfonos, etc.) funciona muy mal en Bluetooth y Wi-Fi. Esto es en gran parte intencional: los fabricantes han implementado numerosas técnicas para evitar el seguimiento de las personas (rotación de direcciones MAC, protecciones del lado del sistema operativo, etc.).
El objetivo es hacer mucho más difícil la identificación y el seguimiento de un dispositivo a lo largo del tiempo, lo cual es bastante bueno desde el punto de vista de la privacidad.
¡Es totalmente posible!
Haces 2 escenas:
- « Si el usuario A entra en la zona X » → « Marcar al usuario A como en casa »
- « Si el usuario A sale de la zona X » → « Marcar al usuario A como ausente »
Por mi parte, para la gestión de la presencia, he configurado 2 accesos directos en mi teléfono:
Mi teléfono detecta él mismo la entrada/salida de la zona, y luego hace una solicitud a Gladys (a través de la API abierta de Gladys Plus: Open API | Gladys Assistant)
Funciona muy bien y creo que es la forma más optimizada en batería de hacerlo, ya que es el teléfono el que gestiona toda la inteligencia y, por lo tanto, está optimizado por Apple
Genial. Gracias, lo pongo en marcha ahora mismo 
Veo que esta integración suele ser mal entendida, por lo que he renombrado la integración « Bluetooth » a « Presencia Bluetooth »:
Y en la integración he añadido un pequeño mensaje para que sea más claro:
Esta corrección está disponible en Gladys Assistant 4.71:
He instalado Owntracks en mi teléfono y en el de mi esposa.
En Gladys he generado 2 claves API. Funciona muy bien para mí, pero la ubicación de mi esposa no se envía a Gladys.
En Open API he generado 2 claves API con nuestros 2 nombres correspondientes a la etiqueta de los usuarios
En la aplicación Owntracks de Sylvie veo bien envíos de información a Gladys en el registro, pero no aparece en el mapa y no es detectada al entrar o salir de una zona.
¿Hay que hacer algo más como ella no es el « usuario principal » o debería funcionar y entonces seguramente es un problema de configuración de Owntracks en su iPhone (odio los iPhone )
¿Has generado correctamente la clave API de tu esposa en la cuenta Gladys Plus de tu esposa? Según tu captura de pantalla, ¡parece que no!
¿Tengo que crear su cuenta GladysPlus como Administrador para que pueda acceder a la configuración de OpenAPI?
¡Exacto! Aunque después le quitarás el acceso de administrador, pero para crear una clave de API hay que ser administrador