Vérifier l'état des piles de ses périphériques avec sa zibase et un scénario unique !

Voici quelques temps, j'avais créé un scénario pour analyser l'état des piles de nos périphériques et être prévenus si l'un d'entre eux avait des piles faibles.

Je n'avais jamais fait d'article sur le sujet mais je profite de la sortie il y a quelques jours du firmware 717 de la zibase pour en parler.

En effet, au préalable, il était possible d'entrer une liste d'identifiants de périphériques pour qu'un scénario se déclenche. Il fallait, au préalable repérer les id de tous ses périphériques et en cas de changement de piles, il ne fallait pas oublier de modifier le scénario.

Depuis le firmware 717 de la zibase, ce n'est maintenant plus utile car il est possible d'entrer comme stimuli autant de périphériques que souhaité.

Le premier scénario ci-dessous analyse l'état des piles (nommé Piles - Analyse ETAT ; original :-D):


Cette première partie vous montre comment il est facile d'entrer plusieurs périphériques comme stimuli (nous avons coupé la capture car la liste est longue :-D).

La suite du scénario Piles - Analyse ETAT :


J'ai paramétré un calendrier fixe pour que ce scénario ne soit lancé que pendant une heure chaque jour. En effet, cela permet de ne pas être alerté continuellement lorsque qu'un périphérique a des piles faibles. Le calendrier est donc paramétré pour ne continuer le scénario qu'entre 20 heures et 21 heures selon la capture ci-dessous (corrigé avec bon image) :

 

La deuxième action permet au scénario de ne se lancer que toutes les 30 secondes. Cela évite d'être alerté de trop nombreuses fois qu'un périphérique a des piles faibles tout en s'assurant que le scénario sera appelé par toutes les sondes. Oui, je sais; c'est de la bidouille mais je n'ai pas trouvé mieux. N'hésitez pas à laisser des commentaires si vous avez une solution plus "intelligente".

La troisième action trouve l'identifiant de la sonde qui a déclenché le scénario et le met dans une variable (V10 pour nous).

La suite (et fin) du scénario Piles - Analyse ETAT est la suivante :


On calcule l'expression ((I2LSL1)LSR3). Cela ne parle pas forcément aux néophytes mais voici les explications de ce calcul : la variable I2 pour toutes les sondes est codée sur 4 bits signifiants (valeur 0 ou 1 pour chaque bit) :
  • bit 0 (0....7) = Boitier Ouvert (Open/Tamper)
  • bit 1 = Alarme
  • bit 2 = Batterie basse (détecteur ou sonde) si bit vaut 1 alors batterie basse
  • bit 3 = Trame de supervision (alive)
Par exemple, pour un capteur ouvert, pas en alarme et avec des piles faibles, cela donne :

bit 0 = 1
bit 1 = 0
bit 2 = 1
bit 3 = 0
L'opérateur LSL1 décale d'un bit à gauche et LSR3 de 3 bit à droite et nous pouvons donc lire le bit 2 directement et vérifier que si celui-ci est positif. Si c'est le cas, cela signifie que les piles du périphériques ayant déclenché le scénario sont faibles. Désolé pour ces explications techniques mais si vous ne les comprenez pas, c'est pas grave, ça marche :-D.

Dans ce cas, on fait appel au scénario Piles - Alerte Etat (simplissime) qui se présente comme suit :


Ce scénario fait juste appel au service pushing box qui permet d'être alerté via de nombreux services (pour ma part, j'utilise twitter, notifry et karotz). Je ne détaille pas l'utilisation de Pushingbox car de nombreux articles le font déjà très bien. Je vous invite par exemple à consulter les articles suivant http://www.touteladomotique.com/index.php?option=com_content&view=article&id=342&Itemid=14&limitstart=2 ou http://www.domotique-info.fr/2012/03/guide-pushingbox-domotique/.

Par contre, petit détail que vous pouvez voir dans le scénario, il est possible de passer des variables dans l'appel PUSHINGBOX. Nous lui passons donc la variable V10 qui contient l'identifiant de la sonde concernée ce qui nous permet de savoir quelle est la sonde qui a des piles faibles.











Alarme ZIBASE via le nouveau module

Après plusieurs effractions dans notre commune, nous souhaitions profiter de notre Zibase pour être prévenus en cas d'intrusion et faire fuir les indésirables visiteurs sans pour autant investir dans un système d'alarme.

Bien sur l'utilisation du X10 pour la sirène et la télécommande n'ont pas un grand gage de sécurité (c'est le moins que l'on puisse dire) mais c'est notre choix.

Nous avions déjà effectué des scénarios pour l'alarme mais le nouveau module ZIBASE nous a donné envie d'aller un peu plus loin. Tout d'abord, nous disposions déjà de :
  • deux détecteurs de mouvements,
  • un karotz,
  • une caméra : EDIMAX 7010 PTN
Nous avons acquis en plus :
  • une sirene SH10; c'est une sirène très bon marché à 35 euros qui n'est pas d'une puissance extraordinaire, qui est en X10 filaire (sécurité très moyenne et problématique si le courant est coupé) mais qui a le mérite de faire carillon et alarme,
  • une télécommande Chacon 54591.
Ces deux éléments X10 nécessitent bien évidemment la présence d'un RPT ou un TM13 pour assurer la conversion du X10RF envoyé par la zibase en X10CPL.

Rentrons dans le vif du sujet. Nous pensions qu'il serait simple de mettre en place tout cela grâce au "nouveau" (cela fait quelques mois) module alarme mis à notre disposition par ZODIANET. Finalement, celui-ci dispose de certaines limites qu'il nous a fallu contourner d'où l'intérêt de cet article.
Tout d'abord; voici la configuration du scénario que nous avons nommé "Alarme" :

 

Vous pouvez consulter la documentation ZODIANET (point "?" dans le module alarme) qui explique bien le fonctionnement du module et notamment que les actions placées après une action "METTRE EN PLACE UN SYSTEME D'ALARME" ne sont exécutées qu'une fois la sirène déclenchée (ou non si pas déclarée), c'est à dire après le délai de pré-alerte.

Néanmoins, à ce stade, trois explications importantes :
  • La sirène n'est pas configurée dans le module de l'alarme puisque  le module ne fait qu'un ON sur le périphérique désigné comme "sirène". La plupart des sirènes disponibles sur le marché nécessitent soit :
    • une alternance de on/off continu pour continuer à faire sonner la sirène;
    • une alternance de on/on continu pour continuer à faire sonner la sirène (c'est le cas de la SH10).
  • La sirène est configurée comme "buzzer" puisque le module fait un on sur le périphérique désigné en tant que "buzzer" et cela a pour effet de faire une sonnerie carillon sur la sirène SH10. Cela permet donc d'être alerté par une sonnerie carillon que l'alarme est en fonctionnement pendant la durée configurée dans le "délai de pré-alerte";
  • La télécommande nommée "ALARME" n'est pas une télécommande physique mais une télécommande virtuelle qui permettra  de fonctionner sans télécommande physique ou avec plusieurs télécommandes physiques.
Donc, de notre coté, deux périphériques déclarés :
  • La télécommande virtuelle nommée "ALARME" déclarée comme suit :

  • La télécommande physique nommée "TELECOMMANDE ALARME" (utilisée par notre femme de ménage) déclarée comme suit :

 à laquelle sont associés deux scénarios "Alarme - Simule off" et "Alarme - Simule on" pour simuler l'activation et la désactivation de l'alarme comme présenté ci-dessous :

 
 
 

Le script "sev 2 CS101" simule le on et "sev 2 CS100" simule le off (source documentation "?" du module alarme).

Voilà donc notre télécommande virtuelle et notre télécommande physique prêtes à faire fonctionner l'alarme.

Nous avons bien évidemment déclaré la sirène SH10 comme périphérique X10 et nommé de façon original le périphérique "SIRENE" comme suit :


Rien de plus simple comme tous les périphériques X10.

Revenons au scénarios "Alarme". Toutes les actions déclarées après l'action "Mettre en place un système d'alarme" sont exécutées sur le déclenchement de l'alarme. Nous avons choisi 4 actions :

  • "Sirene-activer" qui va activer la sirène (voir un peu plus loin pour le descriptif de ce scénario et des différents scénarios liés),
  • "Lance Cam EDIMAX" qui va activer l'enregistrement de la vidéo via la caméra EDIMAX 7010PTN décrit dans le précédent article ici,
  • Un petit appel à l'API pushing box pour faire les actions souhaitées (pour nous, twitter, karotz et notifry),
  • "Stop Cam EDIMAX" qui va arrêter l'enregistrement de la vidéo via la caméra EDIMAX 7010PTN décrit dans le précédent article ici.
Voici les écrans correspondants :



Revenons au scénario "Sirène - Activer" et aux scénarios liés. Le scénario "Sirène - Activer" se présente comme suit :


Ce scénario alloue des tickets illimités au scénario "Sirene - Gestion"  et le lance. Le scénario "Sirene - Gestion" est paramétré comme présenté sur l'écran ci-dessous :


Ce scénario lance un ON sur le périphérique "SIRENE" (paramétré sur l'adresse X10 : B16) et appel le scénario "SIRENE - Réarmement" qui fait l'action suivante :


Ce scénario ré-appelle donc le scénario "Sirene - Gestion" et crée donc une boucle infinie d'appels provoquant des commandes X10 ON sur le périphérique "SIRENE" déclaré à l'adresse X10 B16. C'est le seul moyen que j'ai trouvé pour stimuler la sirène et qu'elle continue de sonner.

Bien évidemment, il faut aussi un scénario permettant de désactiver la sirène nommé "Sirène - Desactiver" et faisant les actions suivantes :


La première action est de désactiver le scénario "Sirene - Gestion" pour arrêter la boucle infinie de ON et la deuxième de lancer plusieurs ordres X10 OFF à l'adresse X10 B16 (adresse X10 du périphérique "SIRENE") afin d'arrêter la sirène. Nous avons lancé plusieurs ordres OFF volontairement afin que la zibase prenne bien en compte les OFF après la boucle infini de ON.

Voilà, je pense vous avoir tout dit sur notre mini système d'alarme et j'espère que cela vous aidera dans cette démarche qui finalement n'est pas si simple que cela ne peut y paraître.

Allez, tous à vos zibases !!!