Lors d’une récente mise à jour, la Zibase s’est vu donner la possibilité de déclencher un scénario par plusieurs modules.  Cela est une bonne nouvelle qui permet de ne pas avoir à créer plusieurs fois un même traitement pour effectuer des actions identiques: un scénario par module.  Cela permet également de limiter l’utilisation de la mémoire mise à disposition pour le développement des scénarii.  Je vais donc remplacer mes scenarii de gestion des sondes de température par un scénarii unique.

Présentation

Aujourd’hui j’ai créé un scénario par sonde qui permet d’appeler un script PHP sur mon NAS via une requête HTTP.  Le script à pour but d’enregistrer en base de données le relevé de chaque sonde.

Le script prend en paramètre 3 éléments:

• la zone de l’habitation dans laquelle se trouve la sonde
• la température mesurée
• l’hygrométrie mesurée

Le scénario final fera la même chose… et plus!

Je souhaite :

• qu’il communique au script les données relevée
• qu’il surveille le niveau des batteries de la sonde
• qu’il surveille le bon fonctionnement de la sonde. 

Quitte à faire des modifications autant en profiter!

Mise en place du scénario

Mes scénarii existants pour chaque sonde s’appelaient tous du style “Log T xxxxx” où xxxxx était un mot qualifiant la localisation de la sonde (Extérieur, Salon,…).  Mon nouveau scénario s’appellera simplement “Log T”.

Pour déclencher un scénario il ne faut plus cocher la case “PERIPHERIQUE” en précisant le périphérique qui servira de déclencheur.  Il suffit de cocher “Liste d’IDs de déclenchement” et de renseigner les ID des sondes.

Pour obtenir l’ID des sondes il suffit de consulter son paramétrage et de relever la valeur de son identifiant radio.

Identification de la sonde

Toujours lors de cette récente mise à jour, il est maintenant possible d’identifier le module déclenchant un scénario.  Cela se fait via les variables de “sondes/détecteurs” I7, I8 et I9.

• I7 représente le type de capteur/détecteur, on le retrouve dans sensors.xml avec 10 ajouté.
• I8 représente le MSB, soit l’octet de poids fort de l’ID 
• I9 représente le LSB, soit l’octet de poids faible de l’ID

Variable I7

Elle indique quel type de module à déclenché le scénario.

Concernant I7 c’est le fichier sensors.xml qui vous le donnera.  Ce fichier vous pouvez l’obtenir en vous connectant en local chez vous sur votre Zibase.  Avec  votre  explorateur internet préféré en spécifiant comme adresse du site, l’adresse IP de votre Zibase.

Pour rappel, l’adresse IP de la Zibase est disponible via le configurateur dans l’onglet Système:

Le fichier sensors.xml est alors disponible sur le site de votre Zibase:

Concernant ma sonde de température extérieure au a comme identifiant OS439183364 je peux lire la donnée correspondante dans le fichier sensors.xml du style :

<ev type=”7″ pro=”OS” id=”439183364″ gmt=”1319715771″ v1=”224″ v2=”32″ />

On aura dans la variable I7 la valeur issue de “type =” : 7 +10 = 17

Variable I8

La variable I8 est déterminée à partir de l’ID du module qui déclenche le scénario. I8 représente le MSB (More Significant Bit), soit l’octet de poids fort de l’ID du module. Pour une sonde Oregon, c’est la référence de la sonde.

Variable I9

La variable I9 est déterminée à partir de l’ID du module qui déclenche le scénario.   I9 représente le LSB (Less Significant Bit), soit l’octet de poids faible de l’ID du module.  Pour une sonde Oregon I9 est constitué avec l’adresse en point fort (D15-D8), et le N° canal de sonde en point faible (D7-D0).

Comment obtenir les valeurs de I8 et I9?

Il y a pour cela 2 manières: par test et par le calcul.

Méthode par test :

Il suffit simplement de créer un scénario de test qui sera déclenché par le module pour lequel on souhaite obtenir les valeurs de I7, I8 et I9. 

Le scénario à créer sera le suivant:

Il suffira de patienter pour voir afficher les valeurs dans le “Suivi d’activité de la Zibase”:

Méthode par le calcul :

Si vous êtes à l’aise avec les bases numériques continuez à lire.  Si vous ne l’êtes pas trop vous pouvez soit lire le précédent article publié sur Abavala : Partons sur de bonnes bases mathématiques et continuer.  Sinon cette explication théorique ne vous apportera rien de plus que la méthode par l’expérience.  L’exposé suivant n’apporte rien de plus qu’une explication aux calculs des valeurs de I8 et I9.

• prendre l’ID de la sonde : OS439183364
• retirer les lettres OS ou OC : 439183364
• Convertir cet ID en base 10 en base hexadécimale :0x1A2D6804

Pour convertir un nombre en base 10 => base hexadécimale allez simplement sur Google et dans la zone de recherche tapez “439183364 in hex”.  Vous aurez le résultat de la part de la calculatrice Google!

• prendre ce nombre hexadécimal et séparer le MSB du LSB : c’est tout bête
  • MSB = I8 = 1A2D
  • LSB = I9 = 6804

Ce sont bien les valeurs en hexadécimal que l’on peut lire dans le suivi d’activité de la méthode par expérience ci-dessus.  Par contre on est toujours en hexadécimal et par encore en valeur décimale.  Continuons

• Pour I8, la donnée est en entiers signés sur 16 bits
• convertir la valeur I8 en base binaire 16 bits : 0001101000101101
• Le premier bit étant = 0 on a un entier positif en lecture directe.  On peut convertir I8 en base 10 : I8 = 6701

Là aussi Google est votre ami.  La recherche Google à lancer est “0x1A2D in binary” (faire attention que le résultat Google ne vous donne pas forcément un résultat en 16 bit)  puis “0x1A2D in decimal”

• Pour I9, la donnée est en entiers signés sur 16 bits
• convertir la valeur I9 en base binaire (Google : 0x6804 in binary) : 0110100000000100
• Le premier bit étant = 0 on a un entier positif en lecture directe.  On peut convertir I9 en base 10 : I9 = 26628

Dans le cas où le premier bit du nombre binaire est à 1 il s’agit alors d’un entier négatif.  Il faut le transformer en entier positif en faisant l’inverse de la méthode “Complément à deux” présenté dans l’article Partons sur de bonnes bases mathématiques.

Ex: I9= CE02 en hexadécimal

• on convertir I9 en binaire (Google: 0xCE02 in binary) : 1100111000000010
• Le premier bit est à 1 on a donc un entier négatif.  Il faut faire l’inverse de la méthode “Complément à deux”
• lui soustraire la valeur 1 binaire (Google: 0b1100111000000010 – 0b0000000000000001) : 1100111000000001
• au nombre binaire trouvé remplacer les 1 en 0 et les 0 en 1 : 0011000111111110
• convertir en decimal (Google : 0b0011000111111110 in decimal) : 12798
• comme il s’agit d’un entier négatif I9 = -12798

Utilisation des variables I7, I8, I9 dans le scénario

Comme on vient de la voir les valeurs de I7, I8 et I9 peuvent être soit constatées soit calculées.

Dans mon exemple comme tous les modules sont de sondes de température Oregon du même modèle on aura toujours en I7 et I8 les mêmes valeurs.  Elles ne sont pas discriminantes.  Seule la valeur de I9 nous sera au final utile.

Afin de me simplifier la vie j’ai choisit de considérer les sondes par un numéro qui m’est propre : Sonde 1, sonde 2, sonde 3,…

Dans le scénario de gestion des sondes “Log T” j’effectue le test suivant pour savoir s’il s’agit de la sonde 1.

Si Valeur absolue(I9) ET i9delaSonde1) – i9delaSonde1 +1 >0 alors c’est la sonde 1

ce qui revient à écrire

(ABS(I9)AND12798)-12798+1  avec 12798 la valeur attendue de I9 pour ma sonde “extérieur” ou sonde 1

Cela se traduit  par la mise en place de l’action suivante qui stocke le numéro de la sonde dans la variable V5.

 

Ce test est à mettre en place pour toutes les sondes que l’on souhaite enregistrer en base et surveiller.

Enregistrer en base les températures relevées

Si vous vous souvenez dans mon script la zone était “codée en dur” dans l’appel au script PHP par HTTP.

Il suffit simplement dans le scénario “Log T”  de communiquer au script PHP appelé sur le NAS la valeur de V5 qui fera office d’identifiant de la Zone.

Surveiller le niveau de batteries des sondes

Afin de surveiller le niveau des batteries des sondes et être prévenu une fois par jour de l’état des piles afin de les changer, on utilisera ici le principe décrit dans le chapitre “les mathématiques en domotique” dans l’article Partons sur de bonnes bases mathématiques.

L’état des batteries des sondes sera stocké dans la variable V6 et sera testé tous les jours à midi.  Un avertissement sera alors envoyé.

Pour cela il suffit de rajouter dans le scénario “Log T” l’enregistrement de l’état de la batterie de la sonde lue (ex sonde 1) sur le bit de la variable binaire V6 qui lui est dédiée (ex: sonde 1 => bit 1).  Cela se fait par l’ajout de l’action suivante:

En ce qui concerne les sondes Oregon, si on détecte une batterie faible la valeur de la variable I2 est >0.

La surveillance se fait ensuite par un autre scénario “T Batteries” déclenché tous les jours à midi:

 Il lance le scénario “T Batteries HS” en cas de batteries faibles.

Surveiller le bon fonctionnement des sondes

Afin de surveiller le bon fonctionnement des sondes et être prévenu une fois par heure en cas d’anomalie, on utilisera ici le principe décrit dans le chapitre “les mathématiques en domotique” dans l’article Partons sur de bonnes bases mathématiques.

L’état de fonctionnement des sondes sera stocké dans la variable V7 et sera testé toutes les heures de 8h à 22h.  Un avertissement sera alors envoyé.

Pour cela il suffit de rajouter dans le scénario “Log T” l’enregistrement de la réception de données de la part de la sonde (ex sonde 1) sur le bit de la variable binaire V7 qui lui est dédiée (ex: sonde 1 => bit 1).  Cela se fait par l’ajout de l’action suivante:

A chaque fois que la sonde emet, le scénario “Log T” est executé et donc le bit de la variable V7 associé est positionné à 1.  La remise à 0 de la variable V7 se fait via le scénario de surveillance.

La surveillance se fait ensuite par un autre scénario “T Sondes” déclenché toutes les heures de 8h à 22h.  Dans mon exemple j’ai 3 sondes.  Si toutes les sondes fonctionnent correctement la valeur binaire de V7 sera 111 ce qui équivaut à 7.  Donc si tout va bien V7=7.  Si au moins une des sondes ne répond plus alors V7-7  < 0 ce qui déclenche l’envoi de l’alerte. Ce qui revient à tester V7-7+1 <= 0

 

Il lance le scénario “T Sondes HS” en cas de non fonctionnement d’une sonde.

Ce scénario fait la mise à 0 de la variable V7 contenant l’état de bon fonctionnement des sondes.

Conclusion

C’est très agréable de ne pas avoir à recréer des scenarii pour chaque sonde que l’on souhaite surveiller ou pour lesquelles les relevés doivent être stockés en base.

L’utilisation de variables pour stocker les états des batteries ou bien le bon fonctionnement des sondes est bien utile pour récuperer ces informations en dehors de la Zibase via les API existantes. Elles peuvent ainsi être utilisés dans votre interface HomePress!

Il aurait été plus simple de pouvoir gérer les ID des sondes et autres modules un peu plus intuitivement sans avoir à passer par les variables I8 et I9.  Mais bon si l’on teste la sonde avant afin de connaître ses valeurs de I7, I8, I9 on n’est tout de même pas obligé de les calculer!  Les scénarios perdent quand même en lisibilité mais le gain de place en mémoire est quand même très appréciable.

Faites le test!