Définition des sondes Oregon dans FHEM

Quelques trucs et astuces pour définir les capteurs Oregon dans FHEM avec un RFXtrx433, en particulier le capteur de température et humidité que j’utilise, le THGR122NX. Rien de mystérieux (c’est dans la doc de référence et le wiki), mais il faut le savoir, les définitions générées automatiquement n’étant pas optimales…

Utiliser plus de capteurs identiques que de canaux paramétrables

Sur un THGR122NX il est possible de paramétrer un canal de communication parmi trois. Donc en principe, on ne pourra utiliser que trois capteurs de ce type dans une même installation. Il se trouve que les capteurs remontent un identifiant supplémentaire sur 1 octet, généré à l’initialisation (changement de pile…). Le module TRX de FHEM permet de faire usage de cet identifiant, ce qui permet d’utiliser plus de capteurs. Pour cela, il suffit de  d’utiliser l’attribut longids suivi des types de capteurs pour lesquels utiliser un identifiant long. Par exemple :

define TRX TRX /dev/ttyUSB2@38400
attr TRX longids THGR228N

Il vaut mieux renommer ses capteurs avec un nom parlant de manière à pouvoir changer sa définition au moment du changement de piles. Dans l’exemple çi après, temp_hum_exterieures est le nom du capteur, et dans la définition du capteur THGR228N_6d_2 on retrouve d’abord son type (THGR228N), l’identifiant sur 1 octet susceptible de changer lors d’une réinit (6d) et le canal (2) :

define temp_hum_exterieures TRX_WEATHER THGR228N_6d_2

Lors d’un changement de piles, un nouveau capteur est autocréé à la fin du fichier fhem.cfg :

1. noter son identifiant (par exemple THGR228N_6e_2
2. changer la définition du capteur qui a un nom symbolique

   define temp_hum_exterieures TRX_WEATHER THGR228N_6e_2

3. enlever les lignes qui ont été générées automatiquement

Obtenir des logs moins bavardes mais néanmoins complètes

Source : wiki FHEM : RFXtrx et Oregon THGR132N FileLog Type text

Les capteurs Oregon remontant leurs informations à un rythme effréné, les événements générés par chaque capteur sont très nombreux. Du coup les logs d’événements deviennent assez vite volumineuses et les graphiques qui les utilisent mettent longtemps à charger. Par ailleurs ça augmente le temps passé en traitement d’événements, et ça charge la machine inutilement si ce n’est pas nécessaire.

Exemple:

2013-09-07_18:11:16 temp_hum_etage T: 26.6 H: 66 D: 19.7 BAT: ok
2013-09-07_18:11:16 temp_hum_etage dewpoint: 19.7
2013-09-07_18:11:59 temp_hum_etage temperature: 26.6
2013-09-07_18:11:59 temp_hum_etage humidity: 66
2013-09-07_18:11:59 temp_hum_etage battery: ok
2013-09-07_18:11:59 temp_hum_etage T: 26.6 H: 66 D: 19.7 BAT: ok
2013-09-07_18:11:59 temp_hum_etage dewpoint: 19.7
2013-09-07_18:12:42 temp_hum_etage temperature: 26.6
2013-09-07_18:12:42 temp_hum_etage humidity: 66
2013-09-07_18:12:42 temp_hum_etage battery: ok

Dans cette log on voit :

• la ligne de rapport d’état du capteur (qui contiennent les valeurs de température T, humidité H, éventuellement point de rosée D, et état de la pile BAT)
• les lignes de valeurs individuelles des métriques

Il y a moyen d’optimiser tout ça en contrôlant la génération d’événements avec les attributs event-min-interval, event-on-change-reading et event-on-update-reading :

Définition du capteur

La définition suivante du capteur permet de ne remonter un événement que toutes les n secondes, sauf si une valeur de mesure a changé, auquel cas un événement est généré sans attendre :

# capteur Oregon jardin
define temp_hum_exterieures TRX_WEATHER THGR228N_6d_2
# un événement toutes les 10mn (600s) sauf si changement état
attr temp_hum_exterieures event-min-interval state:600
attr temp_hum_exterieures event-on-change-reading state
attr temp_hum_exterieures event-on-update-reading .*

Avec cette définition :

• les événements « state » remontent au moins toutes les 10 mn, plus les changements d’état : ça permet de limiter la taille du fichier log qu’on utilisera pour les graphiques
• les autres événements remontent systématiquement : c’est utile par exemple pour les calculs de moyenne (commande average) ou si on veut remonter les infos dans emoncms. Si on n’a pas ce besoin, on peut limiter les événements en remplacer les deux dernières lignes par :

attr temp_hum_exterieures event-on-change-reading .*

Définition de la log et des graphes

La définition de log ci-après permet de :

• générer un fichier log par mois (%Y-%m)
• ne récupérer que la ligne d’état du capteur, en filtrant les lignes de valeur des métriques (expression régulière temp_hum_exterieures:T\x3a.*)

# Log
define FileLog_temp_hum_exterieures FileLog ./log/temp_hum_exterieures-%Y-%m.log temp_hum_exterieures:T\x3a.*

La log est maintenant moins bavarde (10mn entre les 2 1eres lignes identiques) :

2013-09-08_22:53:04 temp_hum_etage T: 24.7 H: 76 D: 20.2 BAT: ok
2013-09-08_23:03:06 temp_hum_etage T: 24.7 H: 76 D: 20.2 BAT: ok
2013-09-08_23:05:15 temp_hum_etage T: 24.7 H: 75 D: 20.0 BAT: ok

Pour afficher correctement la log température/humidité, il faut utiliser le graphique de type temp4hum6, qui interprète les lignes de statut, et pas temp4hum4 qui interprète les lignes des métriques

attr FileLog_temp_hum_exterieures logtype temp4hum6:Temp/Hum,text
define weblink_temp_hum_exterieures SVG FileLog_temp_hum_exterieures:temp4hum6:CURRENT
attr weblink_temp_hum_exterieures label "Exterieur Min $data{min1}, Max $data{max1}, Last $data{currval1}"