Parlons de Gladys V4

Je n’enregistre pas la ville au final :slight_smile:

Juste le pays + région. C’est d’ailleurs très très imprécis vu que juste basé sur l’IP. Honnêtement à Bali il se trompe de 1200km environ…

Et pour encore plus fausser ça, je fais un arrondi à l’entier de la latitude/longitude donnée (qui de base est déjà fausse), pour au final avoir une précision à plus ou moins 100km sur le point deja imprécis.

Donc… le résultat est vraiment imprécis et personne ne peut rien faire de ça :stuck_out_tongue: si vous voulez on pourra regarder au cas par cas ce que le système trouve avec vos IP, et voir si le système est bien hyper imprécis comme souhaité!

1 « J'aime »

Oui c’est pas une mauvaise idée ! Surtout que si on veut que l’ensemble des objets connectés se connectent à notre service, il est nécessaire de mettre en place soit un DHCP sur le raspberry pi qui prend le relai de la box soit alors configurer directement le dhcp de la box pour qu’il envoie sur le pi-hole.

Tu peux facilement avec Gladys lancer un docker ?

A priori oui @pierre-gilles a trouvé un package nodejs qui permet de controller le daemon

Top ça ! Bah pourquoi pas moi je veux bien regarder cette partie si vous le souhaitez ! Ca m’intéresse de pas me faire espionner par les chinois :smiley:

D’ailleurs j’ai vu que Pi-Hole gère le DHCP donc potentiellement on peut le laisser tout faire.

Pi hole je l’utilise à la maison, je vois pas trop ce qu’il y a à “domotiser”, une fois installer et configuré tu l’oubli.

Tu voudrai quoi par rapport à gladys ?

J’ai peur qu’on se retrouve à faire du support pi hole

2 « J'aime »

Attention, dans ce cas là, si le Raspberry plante ou cesse de répondre, aucun périphérique n’aura accès au réseau.
Le RPI devient un SPOF (Single Point of Failure) : s’il plante, ça a de grandes conséquences.

L’idée est de limiter les requêtes des objets connectés vers l’extérieur tout simplement.

Dans ce cas la il faut de toute facon faire des changement dans la conf de la box donc logiquement à faire par un utilisateur qui s’y connait. C’est un cas d’utilisation pas nécessairement le cas à mettre en place.

C’est clair et ça pourrait un sujet de discussion où bien même un tutoriel, parce là vu comme c’est parti ça va pas mal polluer le sujet Gladys…

2 « J'aime »

Je sais pas si ça parle à certains, mais j’ai quelques problèmes avec CodeCov depuis que je suis passé à CircleCI sur les builds de branche…

Sur master, codecov arrive à gérer le coverage sans problème, mais pas sur les branches/PR, ou je me prend une erreur:

Pourtant tout semble bon, sur le CI l’upload du fichier de coverage en .lcov semble ok.

https://circleci.com/gh/GladysAssistant/gladys-4-playground/67

Ca fait plusieurs jours, et je sèche un peu, si quelqu’un a une piste… !

(j’ai peut être juste besoin d’être en weekend :joy: )

Ce samedi j’ai travaillé sur la vue de gestion du système.

Pour l’instant quelques chose de simple, pas encore de courbes d’utilisation de RAM, ou de température du CPU, mais ça sera la prochaine étape :slight_smile: Gardons les bases pour cet alpha.

L’onglet “Containers” à droite est facultatif, et ne s’affichera que si l’utilisateur fait tourner Gladys dans Docker.

1 « J'aime »

Super !
De mon côté le service Bluetooth commence a être fonctionnel, mais il me manque quelques billes :

  • remonter les devices déjà existant
  • un device sera-t-il lié a un user comme avant ?
  • quel est le remplaçant de checkUserPresence ?

J’essaie de faire une page de configuration device simple pour l’utilisateur.

Mais le temps est une denrée qui se rarifie :frowning:

Génial! Beau boulot :slight_smile:

Pour l’instant je n’ai pas encore réfléchi à cet aspect :thinking:

En y réfléchissant la maintenant, effectivement ce qu’on cherche à avoir c’est:

  • Quand un périphérique est vu dans un logement, alors marquer l’utilisateur comme « vu » dans le logement.
  • Un utilisateur peut avoir plusieurs périphériques.
  • Un périphérique n’appartient qu’à un utilisateur (sinon ça n’a pas de sens).

Donc la modélisation qu’on avait jusqu’à là dans Gladys 3 est plutôt logique. (un attribut dans la table device).

Néanmoins je pense qu’il faudrait donner un meilleur nom à cet attribut, et surtout le présenter d’une manière tout autre dans l’UI, dans Gladys 3 c’était vraiment pas clair. Pour moi il faut que dans l’UI ce soit une petite UI à part entière dédié à cette détection de présence.

L’attribut dans device ça pourrait être presence_detection_user_id (c’est pas fou, si quelqu’un a une meilleure idée…)

On pourrait par exemple faire un service « Détection de présence », qui expliquerait clairement:

"Certains périphériques ont la possibilités d’être détecté quand ils sont chez vous: via un scan Bluetooth, un scan du réseau Wi-Fi, où via leur géolocalisation. Gladys peut utiliser ces informations pour en déduire si vous êtes chez vous, où au contraire absent.

Si vous souhaitez que Gladys utilise la détection de certains appareils pour vous marquer comme présent à la maison, il faut indiquer à Gladys les périphériques qu’elle peut utiliser pour vous détecter.

Par exemple: si vous avez un porte-clé bluetooth accroché à vos clés, vous pouvez lié ce porte clé à votre utilisateur, et quand il sera vu en bluetooth chez vous, vous serez marqué comme « présent ». Au bout d’un certain délai, si le périphérique n’est plus vu par Gladys, vous serez marqué comme « absent ».

Sélectionnez les périphériques que Gladys peut utiliser pour vous détecter:

[Liste avec checkbox des périphériques avec un deviceFeature de présence ayant remonté de l’information + indication de la dernière information remontée + ordonner la liste par information remontée la plus récente].

Exemple:

  • :ballot_box_with_check: Fitbit Charge 2 (seen 2 min ago)
  • :ballot_box_with_check: Nut Mini (seen 12 min ago)

Gladys peut vous marquer automatiquement comme absent si ces périphériques ne sont pas détecté au bout d’un certains moments.

Activer la détection d’absence automatique :ballot_box_with_check: (par défaut désactivée)
Délai avant absence: 15 minutes (select box avec 4-5 options, genre 5, 10, 15, 30, 45)

"
Niveau développement

Pour récapituler:

  • Un attribut dans la table « t_device », genre presence_detection_user_id, nullable et clé étrangère sur t_user.id.
  • Une nouvelle catégorie de device_feature qui indique que c’est un device_feature de « présence » d’un périphérique. Exemple: { category: « detection », type: « push », min: 1, max: 1 }
  • Une route d’API de GET de device filtered by category.
  • Une route d’API de PATCH de device.
  • Deux variables en DB, genre « ABSENCE_DETECTION_ENABLED », et « ABSENCE_DETECTION_TIMEOUT ».
  • Une tâche dans le scheduler (pas encore développé) de Gladys 4 pour aller checker l’absence potentiel d’un user. Si on fait tout en RAM (comme c’est souvent le cas dans Gladys 4), un passage toute les minutes ne devrait pas poser de problèmes.

Qu’en penses-tu? :smiley:

Je suis pas trop fan du “user_id” dans le device, mais ça semble tout de même assez logique.
Maintenant pour le reste, cela n’impacte pas les dev du service “device”, on peut donc se laisser le temps d’y réfléchir.
Je suis plutôt en accord avec tes propositions, sauf peut-être pour les 2 variable en DB, je pense qu’il les faut comme valeur par défaut, mais aussi pouvoir avoir le “timeout” par device, et ainsi dire si le Nut n’est pas visible au bout d’une minute, ou si mon tél n’est plus visible en WiFi au bout de 5 minutes, alors je suis parti.

Je suis d’accord. Après en terme de modélisation je vois pas trop d’autres solutions.

Je suis d’accord, mais je pense qu’il faut pouvoir les changer aussi. Pouvoir désactiver l’absence automatique c’est primordial!

Et ce que c’est pas beaucoup un timeout par device? On peut stocker ça dans « t_device_param » sinon.

Bonjour à tous,
Un peu de retard sur la migration CalDAV désolé… J’ai un début de code basé sur celui de la v3, mais je fais face à un problème et une aide serait la bienvenue (encore en pleine découverte de l’architecture de la v4). Avant on pouvait identifier la configuration de chaque utilisateur (dans le module google de la v3 par exemple) grâce aux variables utilisateurs, aujourd’hui nous n’avons plus que des variables “classiques”. Elles peuvent être liées à un service mais pas à un utilisateur (ce qui pourtant me semble obligatoire pour ce genre de service lié à un compte). @pierre-gilles peut-être avais tu une vision de la chose quand tu as implémenté la nouvelle architecture ?

Hello!

Ce que je m’étais dis jusque-là, c’est que tout ce qui était variable lié à un utilisateur on le mettrait tout simplement dans la table t_user. Regarde par exemple le chat_id Telegram, je le stocke dans la table user.

Je pense que vu le peu de variable utilisateur ça serait overkill de faire comme dans la v3. C’est un « excès de propreté » je dirais qui en plus est moins performant à l’usage ^^

Dis moi ce que tu en penses!

Merci, je n’avais pas fait attention à telegram. Donc si je comprends bien, j’ai le droit de modifier t_user ? je vais faire comme ça alors.
C’est à ce moment là que je ne suis pas sûr de te suivre. Ça ne me dérange pas du tout de faire de cette façon, surtout comme tu dis vu le nombre de modules utilisant les variables utilisateurs, mais sur le long terme avoir un t_user qui s’allonge en paramètres ne serait il pas dérangeant ? et plus simple pour l’architecture d’avoir dans la table t_variable un user_id (qui puisse être null).

D’après moi, tu ne sera pas dans les temps pour sortir l’Alpha le 26 Juin, tu aura 24 heures de retard.
Comme ça elle sortira le jour de mon anniversaire!!! :crazy_face: :birthday:

1 « J'aime »