Archives de la catégorie : Tutoriels

Domotiser son arrosage

Problématique

Nature-tree-plantation

Mettre en place un système permettant de piloter son système d’arrosage n’est pas très complexe. On peut le faire, par exemple, en utilisant des électrovannes 24v pilotées par une IPX800. La difficulté pour automatiser l’arrosage est plutôt de savoir quand et combien arroser. C’est justement l’objet de ce billet.

Réserve en eau du sol

Réserve Utile (RU) : quantité d’eau du sol utilisable par une plante.

La plante puise l’eau dont elle a besoin dans le sol considéré comme un réservoir.

Réserve Facilement Utilisable (RFU) : quantité d’eau qu’une plante peut trouver dans le sol sans « forcer ».

Pour fabriquer de la matière sèche au moyen de la photosynthèse, les plantes absorbent du gaz carbonique de l’air par les stomates des feuilles. En condition favorables d’alimentation hydrique, ces stomates sont ouverts. C’est le cas quand de la RFU est disponible.

Réserve Difficilement Utilisable (RDU) : quantité d’eau qu’une plante peut trouver dans le sol en « forçant ».

En condition de stress hydrique, les stomates se ferment (régulation stomatique). Il y a alors arrêt de l’absorption de gaz carbonique et donc de la photosynthèse. C’est ce qui se produit quand la RFU est consommée et que la plante est contrainte de puiser dans la RDU.

Enfin, lorsque la RDU est consommée, la plante atteint son point de flétrissement permanent. L’ean restante dans le sol n’est plus utilisable car la plante a atteint sa capacité maximale de succion (voisine de 15 bars). La plante flétrit puis meurt si ce taux d’humidité perdure.

(suite…)
Publié dans Domotique, Tutoriels | Laisser un commentaire

Jeedom sur Raspberry Pi 2

raspberry-pi-2-Jeedom

Objectif

L’objectif de ce billet est de présenter la mise en œuvre du contrôleur domotique Jeedom sur un Raspberry Pi 2 afin de piloter une installation Z-Wave en utilisant le contrôleur Z-Wave Aeon Labs Z-Stick Series 2 (plugin Jeedom payant nécessaire : 7€).

Préparation du Raspberry Pi 2

Le 2 février 2015, la fondation Raspberry Pi annonce la sortie du Raspberry Pi 2, 6 fois plus puissant que le modèle B+. Il est équipé d’un processeur Broadcom BCM2836, de quatre cœurs ARMv7 à 900 MHz et de 1 Go de RAM. Il permet de faire tourner correctement Jeedom alors que son prédécesseur était largement sous dimensionné pour cette tâche.

Pour commencer, il faut se procurer un Raspberry Pi 2, un boîtier adapté, des dissipateurs thermiques, une alimentation +5V/2A micro-USB et enfin une carte mémoire micro SD très rapide (c’est important pour obtenir un système réactif).

(suite…)
Publié dans Domotique, Contrôleurs, Tutoriels, Raspberry, Système | Tagué , | 18 commentaires

Xavante : Handler de type fonction WSAPI

Objectif

wsapi

J’ai présenté dans un précédant billet comment mettre en œuvre un serveur web WSAPI-Xavante. L’objectif de ce billet est de présenter plus en détail la mise en œuvre d’une fonction permettant de répondre à une requête de type GET ou POST en s’appuyant sur la librairie WSAPI.

L’intérêt d’utiliser WSAPI est de bénéficier de librairies facilitant l’interprétation de la requête ainsi que la génération et la bufferisation de la sortie.

(suite…)
Publié dans Domotique, Tutoriels, Eloise | Tagué | Laisser un commentaire

WSAPI et Xavante : serveur Web Lua

Introduction

Image23

Contexte

L’objet de ce tutoriel est de détailler l’installation et le fonctionnement d’un serveur web permettant d’héberger un programme Lua : WSAPI-Xavante. La documentation concernant ce serveur web n’est pas très prolixe, pas très pédagogique et pas très francophone, d’où tout l’intérêt de ce tutoriel.

Dans mon cas d’utilisation, je compte héberger « l’intelligence » de ma domotique. C’est parce que celle-ci est développée en Lua que j’ai choisi un serveur web Lua : Xavante basé sur l’API WSAPI

WSAPI

wsapi

WSAPI est une API permettant aux applications Web Lua de s’abstraire du serveur Web. Ainsi, une application codée en utilisant l’API WSAPI peut fonctionner sur n’importe quel serveur supportant cette API (actuellement CGI, FastCGI et Xavante).

WSAPI fournit un ensemble de librairies destinées à faciliter de traitement des requêtes ainsi que la bufferisation des sorties.

Xavante

xavante

Xavante est un serveur Web HTTP 1.1 Lua qui utilise une architecture modulaire basée sur des gestionnaires (handlers) de correspondance d’URI (URI mapped handlers). Xavante implémente des gestionnaires de fichier, des gestionnaires de redirection et des gestionnaires WSAPI. Ces gestionnaires sont respectivement utilisés pour des fichiers, des réécritures d’URI et des fonctions WSAPI. La correspondance d’URI se fait via l’écriture d’expressions régulières au sens Lua du terme.

(suite…)
Publié dans Domotique, Tutoriels, Eloise | Tagué | Laisser un commentaire

Capteur SHT-X3 (humidité, température et luminosité)

Présentation

gce-electronics-capteur-humidite-temperature-et-luminosite-sht-x3

Le SHT-X3 est un module comportant 3 capteurs : humidité , température et luminosité. Les mesures sont rapportées sous la forme d’une tension comprise entre 0 et 3,3V. Il est destiné à être câblé à 3 entrées analogiques d’une IPX800, mais est compatible Arduino ou tout système disposant d’entrées analogiques. Il doit être alimenté par une tension comprise entre 3,3V à 5V comme celle que fournit l’IPX800.

En combinant le contenu de ce billet avec les billets Communication entre Vera Lite et IPX800 et Vera UI7 : créer ses devices virtuels, il est possible d’utiliser les capteurs du SHT-X3 comme des capteurs Z-Wave avec la Vera.

(suite…)
Publié dans Domotique, Tutoriels, Modules | Tagué | Laisser un commentaire

Vera UI7 : créer ses devices virtuels

Problématique

virtuel

Il peut être intéressant de créer des devices virtuels sur son interface UI7 afin de les utiliser pour afficher des valeurs moyennes (ex : moyenne de plusieurs sondes de température) ou encore des valeurs de capteurs non Z-Wave (ex : sonde de luminosité câblée sur une IPX800).

Nous allons voir dans ce tutoriel comment créer des devices virtuels de température, de luminosité et d’humidité. Ces devices réagiront comme des devices Z-Wave classiques et pourront être utilisés dans des scénarios ou déclencher des triggers.

(suite…)
Publié dans Domotique, Tutoriels | Tagué | Laisser un commentaire

Vera UI5 : Créer son propre Plugin

creer

Problématique

La création d’un plugin pour la box domotique Vera sous UI5 n’est pas une opération très simple et les tutoriels simples et en français pour en décrire les étapes ne sont pas légion sur Internet. Ce billet, rédigé sous la forme d’un tutoriel, à pour vocation de décrire les différentes étapes permettant la création d’un plugin équivalent au plugin Virtual ON/OFF Switches mais comportant 3 états plutôt que deux.

Ce billet n’est pas achevé. Il est cependant en standby pour une question de temps, mais aussi parce que la sortie de UI7 (personnellement, je ne l’attends pas avant 2015) va changer la donne.

Structure d’un Plugin

Un plugin Luup est composé de plusieurs fichiers dont certain sont optionnels.

4 fichiers permettent d’implémenter le fonctionnement du plugin.

  • D_GenericPlugin1.xml, Device description file (1) – Ce fichier est le principal, il permet de décrire le device implémenté par le plugin. C’est à partir de ce fichier que tous les autres sont atteints. Il s’agit en fait d’un fichier xml de spécification de device UPnP (UPnP device description file). Voici quelques liens utiles pour l’écriture de ce fichier : Luup Plugins ; Luup Plugins By Hand.
  • S_GenericPlugin1.xml, Service File (0 à n) – Ce fichier est optionnel car la Vera fournit déjà de nombreux Service File décrivant de besoins récurrents comme des switches on/off par exemple. Si les services du plugin n’existent pas déjà, il faut créer un ou plusieurs fichiers Service File et décrire l’implémentation dans le fichier Implementation file. Voici quelques liens utiles renseignant les Service File existants : Luup UPNP Files ; Luup Devices ; Luup UPnP Variables and Actions.
  • I_GenericPlugin1.xml, device Implementation file (1) – Ce fichier contient le code Lua nécessaire pour mettre en œuvre les services spécifiés dans le ou les fichiers Service File. Voici quelques liens utiles pour l’écriture de ce fichier : Luup Plugins By Hand ; Luup Declarations ; Luup Lua extensions.
  • L_GenericPlugin1.xml, Lua file (0 à n) – En principe, le code Lua est placé dans le fichier device Implementation file. Cependant, si le code est important, il peut être judicieux de le structurer en plusieurs fichier Lua file et de ne faire que des appels dans le fichier device Implementation file.

2 autres fichiers permettent d’implémenter la partie visuelle du plugin et son interaction dans l’interface UI5. Ces 2 fichiers sont optionnels, ils ne servent que si le plugin doit posséder une interface graphique.

  • D_GenericPlugin1.json, Device interface file(0 ou 1) – Ce fichier n’est utile que pour interagir avec le plugin directement depuis l’interface utilisateur. Dans le cas contraire, le plugin peut toujours être invoqué depuis des scènes, du code Luup, à partir d’appels URL… Ce fichier contient également les liens vers les icônes associés au plugin. Voici quelques liens utiles pour approfondir la questionr : Luup plugins: Static JSON file ; Luup plugin tabs.
  • J_GenericPlugin1.xml, JavaScript files (0 à n) – Appelés par le fichier JSON Device interface file ces fichiers ne sont utiles que pour implémenter des interactions bien particulières (autres que de simples affichages d’étiquettes, de boutons ou de curseurs) au niveau de l’interface.

Informations et sources

Publié dans Domotique, Tutoriels | Tagué , | Laisser un commentaire

Communication entre Vera Lite et IPX800

Vera-IPX800
Problématique

Ce billet propose différentes fonctions qui permette d’utiliser pleinement le contrôleur IPX800 depuis la box Vera Lite. Dans un premier temps, il expose comment consulter ou modifier l’état de l’IPX800. Dans un second temps, il propose un moyen de synchroniser l’état de l’IPX800 avec une structure de donnée dans la Vera Lite afin de bénéficier d’un cache restant synchrone avec les changements d’état de l’IPX800.

Lire un état sur l’IPX800
Connexion à l’IPX800 en Lua :
local socket=require("socket")
 
function josdConnexionIPX800()
  local addresseIP="192.168.0.34"  -- adresseIP de l'IPX
  local port=9870 -- par defaut le port de lIPX est 9870
  local client = assert(socket.connect(addresseIP, port))
  client:send("key=<motdepasse>") -- Si l'interface est protégée par un mot de passe
  client:receive() -- Si l'interface est protégée par un mot de passe
  return (client)
end
</motdepasse>

Attention, à partir du micrologiciel version 3.05.46, si l’interface de l’IPX800 est protégée par un mot de passe, ce dernier doit être envoyé juste après la connexion comme indiqué ci-dessus (remplacer <motDePasse> par le mot de passe).

Fonction interne Lua de lecture d’un état de l’IPX800 :

function josdGetIPX800(indice,commande)
  if (type(indice)=="string") then indice=tonumber(indice) end
  assert(type(indice)=="number" and indice>=1 and indice< =8)
  local client=josdConnexionIPX800()
  commande=commande..tostring(indice)
  client:send(commande)
  local reponse=client:receive()
  assert(client:close())
  local etat=assert(string.match(reponse,'=([0-9]*)$'))
  return tonumber(etat)
end
Fonction Lua de lecture de l’état d’une entrée de l’IPX800 :
function josdGetEntreeIPX800(indice)
  return josdGetIPX800(indice,"GetIn")
end
Fonction Lua de lecture de l’état d’une sortie de l’IPX800 :
function josdGetSortieIPX800(indice)
  return josdGetIPX800(indice,"GetOut")
end
Fonction Lua de lecture de l’état d’un compteur d’impulsion de l’IPX800 :
function josdGetCompteurIPX800(indice)
  return josdGetIPX800(indice,"GetCount")
end
Fonction Lua de lecture de l’état d’une entrée analogique de l’IPX800 :
function josdGetEntreeAnalogiqueIPX800(indice)
  return josdGetIPX800(indice,"GetAn")
end
(suite…)
Publié dans Domotique, Contrôleurs, Tutoriels | Tagué , , , | Laisser un commentaire

IPX800 fonction Push

pushbutton
Problématique

La technique de Push permet d’exécuter une requête HTTP lorsqu’une entrée ou une sortie de l’IPX800 change d’état. C’est le meilleur moyen pour informer en temps réel un autre dispositif internet, comme une box domotique, d’un changement d’état de l’IPX800. L’IPX800 propose deux façons de paramétrer des Push :

  1. Un paramétrage centralisé commun à toutes les entrées et sorties
  2. Un paramétrage individualisé pour chacune des entrées et chacune des sorties

Malheureusement, avec la dernière version en date du micrologiciel (3.05.38), les deux techniques, bien qu’utilisables ne fonctionnent pas parfaitement.

Paramétrage centralisé du Push
IPX800PushCentralisé

Le paramétrage du Push centralisé est accessible de la manière suivante : M2M → PUSH. Voici les différents champs à remplir :

  • Server: <adresse recevant le push>, par exemple 192.168.0.44
  • Port: <le port, par exemple 3480 pour une box Vera
  • Bien cocher Enable puis cliquer sur Save
  • Path: <requête>, par exemple /data_request?id=lr_JH&data=$M&$I
(suite…)
Publié dans Domotique, Contrôleurs, Tutoriels | Tagué | 1 commentaire