J’ai acheté il y a déjà quelques temps une carte IPX800 v2 1 pour compléter mon installation à base de capteurs et actionneurs RF433 (et aussi Zigbee Light Link).
Objectifs :
- pouvoir gérer de manière fiable quelques actionneurs « critiques » : contrôle de la ventilation de la salle de bain ou du chauffage central (bien que je n’ai jamais constaté de problème avec celui-ci)
- domotiser mes télérupteurs.
- récupérer les valeurs du compteur d’eau
La carte électronique rentre juste dans un boîtier DIN acheté chez Conrad, ce qui m’a permis de le mettre dans mon tableau électrique avec une petite alimentation électrique 9V Legrand.
A posteriori j’aurais mieux fait de prendre une IPX800 V3 qui a une alimentation plus standard (12V), est déjà dans un boitier DIN adapté et a des possibilités plus étendues. Mais la V2 fait l’affaire et est quand même moins chère.
Comme le système nerveux de ma domotique est basé sur FHEM, j’ai interfacé l’IPX800 avec ce dernier. Pas besoin d’écrire un module en Perl, on va se débrouiller avec deux modules génériques : HTTPMOD pour l’IPX et readingsProxy pour les applications de celui-ci (ex: télérupteur, relais simple, compteur d’eau…)
Ce qui est décrit ci-après est a priori utilisable sur IPX800 v3, l’API étant en principe la même, avec plus de fonctions sur la v3.
Principe général
Le principe général est de définir un device représentant l’IPX800, de type HTTPMOD :
- 4 entrées in1 à in4 qui pourront prendre l’état on ou off
- 2 entrées analogiques an1 et an2
- 2 compteurs count1 et count2
- 8 actionneurs out1 à out8 qui pourront prendre les valeurs 0 et 1 (les relais 1 à 8 de la carte)
Pour piloter un actionneur, on disposera des commandes suivantes
- Pour activer la sortie outX en mode fugitif :
set IPX800 fugitive X
- Pour basculer l’état de la sortie X :
set IPX800 toggle X
- Pour mettre à 0/1 la sortie X :
set IPX800 up X
/set IPX800 down X
On peut définir ensuite des devices représentant des configurations logiques : par exemple, un télérupteur ou un relais
Définition de l’IPX800
Le module HTTPMOD interrogera à intervalle régulier (30s) la page XML de statut de l’IPX (remplacer ipx par le nom ou l’adresse IP de l’IPX). On ne génère d’événement qu’aux changements d’état ou toutes les heures (si nécessaire, pour les graphiques).
define IPX800 HTTPMOD http://ipx/status.xml 30 attr IPX800 event-min-interval 3600 attr IPX800 event-on-change-reading .* attr IPX800 stateFormat out1 out2 out3 out4 out5 out6 out7 out8
Si on met un mot de passe à l’IPX, il faut la définir ainsi
define IPX800 HTTPMOD http://admin:pass@ipx/status.xml 30
Readings
[update 14/07/2016 : mis à jour avec la nouvelle syntaxe, la précédente n’étant bientôt plus supportée]
On va maintenant définir les différents readings. Pour chacun d’entre eux, on a besoin de définir une expression régulière qui matche la valeur recherchée. Cette dernière doit être notée entre parenthèses.
Par exemple, pour le statut de la sortie relais out1 (identifiée led0 dans l’API IPX800) :
attr IPX800 reading00Name out1 attr IPX800 reading00Regex <led0>(\d)</led0>
readingXExpr permet de retravailler la valeur extraite de l’expression régulière pour lui donner la forme souhaitée . Si par exemple on veut normaliser à on / off la valeur de l’entrée in1 (identifiée btn0 dans l’API IPX800) qui peut prendre les valeurs up et dn :
attr IPX800 reading08Name in1 attr IPX800 reading08Regex <btn0>(.*)</btn0> attr IPX800 reading08OExpr {($val eq "up")?"off":"on"}
Un autre exemple avec les entrées analogiques :
attr IPX800 reading12Name an1 attr IPX800 reading12Regex <an1>(\d*)</an1>
Commandes set
Il est possible de définir des commandes set, à l’aide des attributs suivants :
- setXName permet de donner le nom de la commande
- setXURL définit l’URL à utiliser
- setXMin et setXMax qui permettent de contrôler le range de valeurs ($val) autorisées : dans la définition qui suit, les relais 7 et 8 (led6 et led7) ne doivent être utilisés qu’en mode fugitif (actionneurs de télérupteurs). Il faut donc interdire les commandes on, off et toggle pour ceux-ci.
- setXIExpr va nous permettre de passer les bonnes commandes HTTP pour les sorties : les commandes .cgi utilisent une numérotation des ports de 0 à 7 et la commande preset.htm une numérotation de 1 à 8 …
attr IPX800 set01Name fugitive attr IPX800 set01URL http://ipx/rlyfs.cgi?rlyf=$val # cgi : val de 0 à 7 : attr IPX800 set01IExpr { $val - 1 } attr IPX800 set01Hint 1,2,3,4,5,6,7,8 attr IPX800 set01Min 1 attr IPX800 set01Max 8 attr IPX800 set02Name toggle attr IPX800 set02URL http://ipx/leds.cgi?led=$val # cgi : val de 0 à 7 attr IPX800 set02IExpr { $val - 1 } attr IPX800 set02Hint 1,2,3,4,5,6 attr IPX800 set02Min 1 attr IPX800 set02Max 6 attr IPX800 set03Name up attr IPX800 set03URL http://ipx/preset.htm?led$val=1 attr IPX800 set03Hint 1,2,3,4,5,6 attr IPX800 set03Min 1 attr IPX800 set03Max 6 attr IPX800 set04Name down attr IPX800 set04URL http://ipx/preset.htm?led$val=0 attr IPX800 set04Hint 1,2,3,4,5,6 attr IPX800 set04Min 1 attr IPX800 set04Max 6
Définition de devices utilisant les entrées/sorties de l’IPX
Télérupteur
Prenons par exemple un circuit électrique à base de télérupteur 2 pôles tel que décrit ici : Lumière, télérupteurs et IPX800 V3.
Il va nous permettre :
- d’une part de pouvoir actionner les lumières du circuit indifféremment avec un poussoir ou une commande FHEM
- d’autre part de pouvoir avoir le retour d’état (avec un délais, puisqu’on utilise un mécanisme de polling HTTP pour obtenir celui-ci)
Dans notre exemple,
- activation du télérupteur : out8
- retour d’état : in1
On définit un device telerupteur
de type readingsProxy dans FHEM. Son état provient du reading btn0 du device IPX800
. Les commandes toggle
, on
et off
propagent la commande set IPX800 fugitive 7
sur l’IPX800 qui permet de faire basculer le télérupteur, dans le cas où elle est nécessaire:
define telerupteur readingsProxy IPX800:in1 attr telerupteur setFn {($CMD ne Value("telerupteur_entree"))?"fugitive 8":undef } attr telerupteur setList toggle on off
Petit (ou gros?) bémol : comme le retour d’état n’est pas instantané (attente du polling HTTP), les commandes off
ou on
ne fonctionneront pas si elle sont trop rapprochées dans le temps. Il est dommage que l’IPX800 v2 ne permette pas de renvoyer une commande URL sur un changement d’état, ce qui nous aurait permis de gérer ça un peu mieux… Ceci dit à l’usage ça ne me pose pas de problème.
Interrupteur simple
Pour commander un ventilateur (connecté sur le relais 6, soit out6) on peut utiliser un device de type dummy et deux notify :
define ventilo dummy
attr ventilo devStateIcon on:vent_ventilation_level_0 off:vent_ventilation
attr ventilo icon vent_ventilation
attr ventilo setList on off
define ventilo_n_on notify ventilo_SDB_bas:on { fhem "set IPX800 up 6" }
define ventilo_n_off notify ventilo_SDB_bas:off { fhem "set IPX800 down 6" }
L’intérêt par rapport à l’utilisation de readingProxy est que l’état du device est mis à jour immédiatement. L’inconvénient est que la
Liens
IPX800
API
Le jeu de commandes de l’IPX800 v2 est plus réduit que celui de de la v3. L’API décrite ci-après est celle de la v3 (superset de la v2) :
FHEM