Module Virtuel Présence Maison

[biboun]

Salut, 

 

Je pensais coder un petit truc qu'il me semble manquer dans le HC2, et avant de le faire, je voulais, d'une verifier que ça existe pas déjà  et que je l'ai loupé, de deux récuperer quelques conseils sur la façon de récuperer les infos.

 

Voilà , à  part le panel event, que je trouve super buggé dans sa gestion des filtres et de l'affichage, il n'y a pas une vision très synthétique de ce qui se passe dans la maison (il y a bien quelques bribes dans l'appli ipad, mais ça reste limité)

 

Ce que je pensais faire:

 

Récuperer l'info de dernièr acces/changement/retour d'info de tous les capteurs connus pour pouvoir indiquer une présence humaine dans la maison: capteurs de porte, allumage de lumière, détection de présence, j'en passe.

L'idée ensuite tout bêtement d'agréger tout ça pour définir s'il semble y avoir qqun à  la maison, et la date de la dernière présence certaine, et du dernier élément de présence connu.

Ensuite afficher ces quelques infos dans un module virtuel que l'on peut consulter en un clin d'oeil.

On peut imlaginer à  terme pilote des comportements à  partir de la présence/non présence déduite: proposer d'armer l'alarme, baisser le chauffage, faire un "welcome" au retour etc..

 

C'est qqch  que l'on voit dans les videos de fibaro ( pour l'oeil de sauron notamment), mais il ne me semble pas l'avoir vu dans les features.

 

 

D'autre part, techniquement je vois plusieurs moyens de stocker les actions, soit une scene qui écoute l'ensemble des modules concernés et update le module virtuel à  chaque event, soit interroger directment la base d'event du HC2 en lua, ou via l'api, savez-vous si ces events sont exposés?

 

 

Mercii ! 

[JossAlf]

De mon côté je gère l'absence par une variable que je mets à  jour de 4 façons :

 

1/ (Rarement) Manuellement par le biais d'un VD.

 

2/ En fonction d'un calendrier avec une scène de façon automatique si la maison est en mode "Normal".

En gros du lundi au vendredi : "Présents" de 17h00 à  8h00 et "Absents" de 8h00 à  17h00.

WE "Présents" 24/24

 

3/ Toujours "présents" avec une scène de façon automatique si la maison est en mode "Invités".

"Présents" 24/24 7/7

 

4/ Toujours "absents" si la maison est en mode "Vacances".

 

Ca pourrait s'améliorer avec une situation GPS, mais comme je n'ai pas d'alarme sonore ça se gère très bien pour le moment. Et c'est parfaitement WAF ! 

 

J'avais commencé comme tu souhaites le faire à  utiliser des variables qui checkaient les portes (j'en ai 4 qui sont utilisées tout le temps) et les lumières (j'ai pas encore de capteur de mouvement), mais comme j'utilise un simulateur de présence, il fallait que je mette des conditions à  n'en plus finir ...

Si porte 1 ouverte puis fermée, puis portail ouvert puis fermé, si pas de lumière, alors attendre x minutes et mettre à  jour variable "statut maison".

Si portail s'ouvre, puis porte 1 s'ouvre, puis alarmes désactivées alors mettre à  jour variable "statut maison"...   pfff

 

En plus il ne faut pas se prendre les pieds dans le tapis et arrêter la surveillance (du style tu n'a pas éteins un lumière ou mal fermée un fenêtre et paf la maison passe en mode présence...) 

 

Maintenant si tu trouves un truc WAF et nickel je suis preneur 

[biboun]

Bah justement, à  force de lire tous ces sujets sur l'IA et tout, je me dis qu'il faut bien commencer à  penser a des trucs malin,s ou la maison essaye de "déduire" l'état.

Bien sà»r il ne faut rien engager de préjudiciable à  partir de déductions, mais ça va déjà  permettre de voir à  quel point c 'est fiable.

 

Pour le moment, j'essaye déjà  de recuperer les "Last Events", si je pouvais éviter d'avoir une scène qui trigger sur tous mes modules, ça serait plus simple à  maintenir et faire évoluer..

[Lazer]

Pour récupérer les events par l'API HTTP, c'est simple :

http://<IP>/api/panels/event?from=1352509026&to=1392509026&type=time

Le From et le To sont des Timestamps UNIX.

 

J'ai constaté que les events sont supprimés au bout d'un certain temps, et que plus tu génères d'événements, plus ce temps diminue. Logique puisque la HC2 doit attribuer une mémoire de taille fixe pour stocker les événements.

 

 

[biboun]

Merci, j'avais trouvé cette méthode aussi, mais je trouve ça étrange de devoir faire appel à  sa propre api pour communiquer depuis l'interieur du système (établir une connection http vers soi même pour faire une requête à  son propre système me semble être une solution de repli)

 

j'ai moyennement confiance dans leur historique, j'ai notamment des capteurs, qui malgré le fait qu'ils ont "report logs" de configuré, n'apparaissent jamais dans les logs.

De plus, dans les logs on ne peut pas savor si une lumiere par exemple a été activée par un interrupteur ou par une scene, ce qui peut fausser la deduction de présence.

 

J'arrive déjà  à  récuperer le dernier "breach" des capteurs de porte et présence ( LastBreach), je vais probablement devoir faire un petit "watcher" qui déclenche sur les evenements liés aux modules pilotés par interrupteur, afin de m'assurer que l'origine de l'event est bien une action physique...

 

J'aimerai faire un module avec peu de config, donc je vais tenter d'automatiser au max la detection des modules, pour le moment c'est bien parti...

[Lazer]

Si les triggers de ta scène se réveillent constamment à  chaque événement, fait gaffe que ça ne surcharge pas ta HC2. Bon après ça dépend du nombre de modules que tu vas surveiller.

 

Pour savoir comment a été allumé la lumière, j'avais imaginé la solution suivante :

- si une scène allume la lumière, création d'une variable globale juste avant

- si un détecteur de mouvement allume la lumière, création d'une variable globale juste avant

- ensuite, lorsque l'événement associé à  l'allumage de lumière se déclenche automatiquement (suite aux 2 conditions précédentes ou à  appui sur l'interrupteur), il suffit de regarder l'état des variables globables pour en déduire la source de l'événement.

 

En ce qui concerne l'API HTTP, c'est le principe même des interfaces Web 2.0 en AJAX. Toutes les requêtes sont effectuées par du Javascript en asynchrone en mode HTTP vers le serveur Web situé en local.

Cela évite de recharger complètement la page comme ce serait le cas si c'était réalisé de manière traditionnelle en PHP.

Le panneau des graphiques de consommation fonctionne de la même façon.

A mon avis, c'est la meilleur façon de faire.

Ce qu'on peut éventuellement reprocher à  Fibaro, c'est de ne pas (encore) avoir mis à  disposition une API pour consulter les événement en LUA.

[biboun]

En fait j'ai déjà  un trigger qui se reveille sur tous les capteurs de présence et portes, c'est mon alarme custom ( que je vais d'ailleurs jarter au profit de ce que propose desromais fibaro, à  l'époque ça n'existait pas), ça ne semble pas poser de problème, surtout si je ne reagit qu'aux allumages/extinctions de lampes, ça fait tes peu d'events comparé aux capteurs de présence qui déclenchent des 100 aines de fois en journée qd on est là .

 

Pour la principe de l'appel à  l'API, je suis ok pour le principe lorsque le but est d'afficher une page dans un navigateur qui de toute façon fait des requettes http, mais quand on veut juste faire des taches de recuperation et comparaison de données au sein du lua: utiliser les requettes http du lua, et passer par l'api pour recuperer un json que l'on va encore devoir décomposer, ou alors faire un simple  fibaro:getValue(id, "lastBreached"), la seconde méthode "devrait" être plus efficace non ?

[Lazer]

Si ça marche déjà  comme ça, pas de problème alors

 

Oui, effectivement, parser des pages HTML/JSON/XML c'est pas franchement optimal pour un script qui s'exécute sur la HC2. J'espère que Fibaro va améliorer ce langage de script, car y'a du potentiel, mais on pourrait vraiment faire des trucs beaucoup plus puissants assez facilement.

[biboun]

En fait, je vais peut être effectivement pouvoir faire plus simple, si je suis sur que l'event manager marche comme il faut, je pourrais juste faire la requete suivante:

 

 

/api/panels/event?last=1&type=id    

 

ça me sort le dernier event, j'ai plus qu'à  comparer son timestamp à  l'os.time et je suis bon. (ça sous-entend de ne prendre dans les logs que des choses utiles, pas les remontées de temperatures...)

 

Je pense au final savoir pourquoi il me manque certains detecteurs dans l'event manager, je crois que ce sotn mes dsb005 qui avaient été intégrés avant la mise à  jour pour bien les supporter, je crois qu'ils sont mal reconnus (ils ont une coche de gestion d'energie que n'a pas celui que j'ai réinclus recemment...)

[Lazer]

Moi je n'ai jamais constaté que le gestionnaire d'event ne soit pas fiable. Je veux dire que je vois tous les événements que je m'attends à  y trouver.

D'ailleurs, c'est même très pratique pour détecter un module qui est hors de portée Z-Wave : tu le déclenches (mouvements, appui sur l'interrupteur, réveil, etc...) et tu vois dans les events si il apparait ou pas.

 

Par contre, dans mes événements, la plupart des infos sont des remontées des capteurs de T°C, HR%, LUX, etc... et ça a tendance à  être assez bavard par moment !!!

Donc si tu ne prends que le dernier événement via l'API, tu risques de louper des événements qui se succèdent trop vite.

[biboun]

en fait, j'avais déjà  décoché les logs pour tous les capteurs qui à  mon sens n'ont pas d'interêt (à  activer pour debug) , temperature, hygro, lumi.

De ce fait il ne me reste que de l'utile.

 

En revanche, je viens de debusquer un joli bug que je traine depuis le début et que je vais finir par ariver à  expliquer:

 

Déjà  j'ai forcé la reconfiguration des modules à  batteries et reveillé tous mes dsb05 aeon 4-1  , de ce fait ils reaparaissent tous dans les logs, et leur panneau de config avancé à  légerement changé.

Par contre, je viens de revoir apparaître un vilain bug.

malgré la config adaptée du dsb05 (id 5 reglé à  2 pour ceux que ça interesse), le capteur renvoie 255 ( au lieu de 1) en cas de présence.

Le HC2 détecte bien la présence quand-même, mais celà  ne remonte pas dans le "last breach"

Je sais que d'ici 24h, sans aucune explication, le capteur va se remettre à  renvoyer 1, et tout va rentrer dans l'ordre... (et pourtant là  il a bien reçu la config itou..)

 

 

EDIT : j'ai parlé trop vite en fait ils n'apparaissent toujours pas, je vais surement devoir les réappairer pff..

 

je crois que je vais d'abord finir mon module qui detecte la liste des capteurs et renseigne une variable globale, que je vais implémneter dans tous mes scripts, car les 4-1 c'est 4 id à  changer à  chaque fois, relou...

[JM13]

Je vais peut être faire un "hors sujet" mais pourquoi ne pas utiliser le panneau de localisation pour déterminer s'il y a une présence "connue" ?

[biboun]

Ca n'est pas hors sujet du tout, c'est aussi un indicateur à  prendre en compte

Ca sous entend qu'il fonctionne vraiment et que toutes les personnes disposent d'un appareil compatible.

Tous les tests que j'ai pu faire m'on montré que à  part bouffer la batterie, ça ne générait aucune donnée fiable...

 

Je ne demande qu'à  me tromper, auquel cas je pourrais effectivement le prendre en compte dans ma pondération de déduction de présence.

 

Vous avez déjà  eu satisfaction, à  part en regardant la vidéo de démo fibaro "lili i'm coming home ..."

[Lazer]

Ah tiens, tu pourrais aussi faire un ping via le Wifi des smartphones pour ajouter àl’algorithme de détection de présence. Ca ne boufferas pas de batteries (enfin sauf si tu fait un ping toutes les secondes àlongueur de journée)

[biboun]

Oui aussi, maisj´ai souvenur d un post ou krikoff en parlait pour son module freebox, et avait subi des problemes de mise en veille, faut que je check.

Si ca repond pas c est pas forcement une absence, mais si ca repond c surement une presence ( sauf oubli du telephone a la maison)

Envoyé de mon iPhone àl'aide de Tapatalk

[JM13]

Après réflexion :-)... je pense que le ping est en effet la solution la plus simple et donc robuste. Nos smart phones étant des parfaits mouchards ...autant les utiliser.

[Lazer]

Oui mais comme le dis Biboun, c'est pas non plus fiable à  100% : celui-ci peut être en 3G/4G (Wifi coupé), en mode avion, à  court de batterie, oublié à  la maison, etc... sans oublier les appareils pommés qui coupent le Wifi tout seuls (Android aussi, en fonction du réglage appliqué dans les paramètres)

 

Donc il faut un algo qui se passe sur plusieurs critères pour prendre la décision de présence ou non (smartphone, détecteur de présence, détecteur d'ouverture, etc...)

[biboun]

Oui l idee est justement experimentale, je reflechis a une ponderation par plusieurs parametres

Envoyé de mon iPhone àl'aide de Tapatalk

[biboun]

J'avance doucement mais sà»rement, j'ai fait la première brique, qui permet de scanner et detecter les modules de présence (avec des possibilités d'exclusion)

ensuite je check a intervalle regulier qui a eu le derier acces et je met à  jour mon vd en fonction, pour le moment c 'est très basique, mais l'idée est de remonter une info par domaine ( présence, actions, ping, variables) et de pondérer cet ensemble pour définir une présence.

 

j'ai surtout eu l'occasion de régler plusieurs bugs qui me faisaient dire que l'historique étatit buggé, ainsi que le "last breach"

 

J'en ai tiré 2 conclusions:

DSB05: si vous les avez inclus il y a longtemps, des mises à  jour ont chnagé la gestion, il faut les réinclure pour qu'ils puissent apparaitre dans l'historique (au passage s'ils sont inclus d'avant, il présentent une config relative à  la consommation d'energie qui ne devrait pas exister)

 

DSB05, et présence en générale, je crois.

si un capteur renvoie 255 à  la présence, au lieu de 1, le champ "last breach n'est pas updaté", sur le dsb05, malgré la config de l'id5 à  la valeur 2, il peut continuer  de renvoyer 255, il faut en fait rebooter la box apres avoir ré-inclus ces modules ( trouvé dans le bugtracker, et semble exister pour d'autres capteurs), serait réglé en 3.902 alpha-la blague)

 

Je vais pouvoir sortir un V0.1 du module virtuel, qq'un se sent de tester ?

[Lazer]

Je veux bien tester, mais par contre je n'ai plus de détecteur de mouvement (j'ai éteint mon Fibaro àcause du bug décrit sur le topic dédié). D'après ce que j'ai vu, il prenait la valeur 255 lors des mouvements.

[biboun]

c'est quoi le bug, en 2 mots?

pour les soucis de retour 255 au lieu de 1, ça se resoud avec un reboot en géneral..bizarre, en tout cas 255 semble le pas etre pris en compte pour le "last breach"

 

Du coup pour tester, il te reste quoi comme capteurs ? ça peut marcher avec motion_sensors door_sensors et windows_sensors  pour cette brique.

 

Je dois encore faire une petite modif dans le code, j'ai trouvé un bug hier dans la façon dont je stocke la liste des capteurs à  tester ( je les stock pas en dur dans le code, je trouve ça relou dès qu'on change un id, du coup j'ai un boutton de detection, mais la variable globale qui les stocke est un peu "fragile", faut que je cause à  Krikroff, je crois que son VM freebox souffre du même bug).

 

je t'en recause dans le week-end

[Lazer]

Le bug, Fredric et moi l'avons constaté, sur cette page.

En gros, le motion_sensor se transforme en temperature_sensor

 

 

 

Bon par contre, je n'ai aucun des détecteurs que tu mentionnes, donc je ne pense pas que je vais pouvoir tester du coup...

Enfin, si j'ai bien un détecteur d'ouverture, mais c'est en extérieur sur le portail quand il s'ouvre (à  chaque fois qu'on rentre et qu'on sort)

[biboun]

En effet, bug chiant, moi qui pensait que les detectuers aeon etaient de sombres merdes, je ne pensais pas que fibaro pouvait faire aussi dans le bug vicieux ( surtout pour celui a qui ça a déclenché l'alarme..)

 

Donc pour le MV , pour le moment effectivement si t'as pas de capteurs de présence, cette "brique" ne servira à  rien ( j'ai revu au détours de nos divers posts que tu avais effectivement opté pour une vraie alarme, d'ou l'absence de capteurs de présence/porte/fenetre zwave  )