Sonde de temperature OTIO Ref 93806-0001

[duodiscus]

Bonjour,

en utilisant mon rfx433 en mode undec j'ai pu analyser la trame de ma sonde de température OTIO Ref 93806-0001
et en extraire la valeur de température

Exemples
20.7 °C
18861487

-18.4 °C
18869284

Il faut considérer les chiffres hexa de rang 5,6 et 8

Quand la température est positive, les chiffres de rang 5 et 6 codent cette tempé en base 16.
Ainsi 14 base 16 donne 20 base 10 et le chiffre de rang 8 correspond à la décimale.

Quant la température est négative, le bit de poids fort du chiffre de rang 5 est à 1.
Le codage de la valeur absolue est comme indiqué précédemment.

Je ne sais pas trop comment interpréter les autres chiffres mais c'est pas très important, ce qui m'intéresse c'est la valeur de la tempé et un identifiant du capteur.

Je pense que le premier chiffre code le n° du canal et les chiffes de rang 2, 3, 4 contiennent un ID.

A présent mon problème c'est de récupérer cette trame dans Domoticz pour la traiter.
Mais Domoticz semble-t-il ne voit pas les trames undec.
Quelqu'un a une idée ??

[duodiscus]

Je complète mon précédent post car j'ai progressé.
Je possède deux sondes de température OTIO (voir photos jointes).
Références : 93806-0001 et 93807-0001
Elles délivrent les trames suivantes.
93806-000
07 03 10 64 18 86 15 88 pour 21.8°C
07 03 10 81 18 86 15 85 pour 21.5°C

93807-0001
07 03 10 85 18 4C 0D 80 pour 13.0°C
07 03 10 89 18 4C 0E 87 pour 14.7°C

(attention, la représentation en hexa ci-dessus est un effet du formatage par hexdump.
En réalité c'est une suite de 64 bits.
En faisant un peu de reverse engineering on peut interpréter une partie du format:
- les bits 1 à 24 bits (6 chiffres hexa) ne varient pas (peut être une identification du capteur/constructeur ...)
- les bits 25 à 32 varient beaucoup (peut être un cks mais en général le cks est en fin de trame ... donc non élucidé.
- les bits 33 à 40 sont constant (valeur 18 en base 16)
- les bits 41 à 48 sont constant mais propre à chaque capteur 86 pour l'un et 4C pour l'autre : j'ai considéré que c'est l'ID du capteur
- le bit 49 est à 1 quand les températures sont négatives et à 0 sinon
- les bits 50 à 56 codent la partie entière de la température (codage binaire pur non signé)
- les bits 57 à 60 sont toujours à 1000
- les bits 61 à 64 codent la partie décimale de la température (codage binaire pur sans non signé)

Avec ce décodage partiel, c'est suffisant pour une intégration (certes un peu sommaire) dans Domoticz.
N'ayant pas trouvé mieux, j'ai écrit un code (en C) qui lit /dev/ttyUSB0 pour récupérer la trame émise par le RFX433 et effectue le décodage et formatte un message selon la syntaxe JSON.

Côté Domoticz, il faut avoir créé deux capteurs virtuels et noter leur IDX car c'est mon code C qui fait l'association ID OTIO- ID Domoticz.
Ne pas oublier aussi de valider les protocoles "Rubicson" et de mettre "undec on" à ON.
Ensuite par un jeu de pipe j'envoie ce message JSON à Domotics par le protocole MTQQ.

L'ennui c'est que deux process ne peuvent pas lire en même temps ttyUSB0. Donc si mon code C lit en permanence ce port, Domoticz ne reçoit plus rien et ne peux plus récupérer les valeurs de mes autres capteurs (Oregon).

J'ai donc fait une "bidouille" qui ne me plait qu'à moitié. (Je suis preneur d'une meilleure solution)
Mon code C est lancé toutes les 5 minutes (voir la crontab) ne monopolise le port USB0 jamais plus de 90 secondes consécutives. Ensuite le port est libéré pour Domoticz.

Ne pas oublier de faire un
sudo crontab -e

et ajouter dans la crontab

Code : Tout sélectionner

*/5 * * * * cat /dev/ttyUSB0 | /home/pi/otio2domoticz 134 89 76 90|  mosquitto_pub -h localhost -t "domoticz/in" -s

Ci-dessous mon code C (fichier otio2domoticz.c)

Code : Tout sélectionner

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>

/* nombre max de capteurs OTIO */
#define MAX_OTIO (10)

int globaltimeout = 3;

/* alarm signal handler */
void alarm_func()
{
        fprintf(stderr, "Timeout %d seconde atteint !\n", globaltimeout);
        exit(0);
}

/* getchar avec timeout */
int mygetchar(int timeout)
{
   int c;

   globaltimeout = timeout;
   alarm(timeout);
   c = getchar();
   alarm(0);
   return c;
}

void main(int argc, char **argv)
{
   unsigned short int c;
   unsigned short int sensorID;
   short int enttemp, dectemp;
   char sign;

   unsigned short tidotio[MAX_OTIO+1], tiddomo[MAX_OTIO+1];
   short int i, j, myargc, nbotio;

   if(argc > MAX_OTIO+1){
     fprintf(stderr, "Trop de capteurs déclarés (ne peut dépasser %d)\n", MAX_OTIO);
     exit(1);
   }

   if ((argc < 2) || ((argc % 2) == 0) ){
    fprintf(stderr, "Manque arguments d'affectation capteurs\n");
    exit(0);
   }

   /* nombre de capteurs à traiter */
   nbotio = (argc-1)/2;

   /* Appairage  ID OTIO a ID Domoticz */
   myargc = argc;
   while (myargc > 1) {
     i = (myargc-1)/2;
     fprintf(stderr, "myargc=%d i=%d\n", myargc, i);
     tidotio[i] = atoi(argv[myargc-2]);
     tiddomo[i] = atoi(argv[myargc-1]);
     myargc -=2;
   }

   /* verification */
   for (i=1; i<=(argc-1)/2; i++)
      fprintf(stderr, "L'ID  OTIO %3d est affecté à l'ID  DOMO %d\n", tidotio[i], tiddomo[i]);

   signal(SIGALRM, alarm_func );
   for(j=0; j<nbotio;j++){
      redo:
      while ((c = mygetchar(90)) != 0x07);
	if ( (c = mygetchar(3) ) !=  0x03)
	   //continue;
	   goto redo;
	   if ( (c = mygetchar(3) ) !=  0x10)
	      //continue;
	      goto redo;
	   /* on saute deux char */
	   mygetchar(3);
	   mygetchar(3);
	   /* on lit ce qui est supposé etre l'ID sensor */
           sensorID = mygetchar(3);
	   /* recherche de l'ID Domo */
	   for(i=1; i<MAX_OTIO; i++)
	      if(sensorID == tidotio[i])
		break;
	   /* lecture signe et partie entière */
	   c = mygetchar(3);
	   sign = (c & 0x80) ? '-': '+';
	   enttemp = (c & 0x7f);
	   /* lire la décimale */
           dectemp = mygetchar(3) & 0x0F; 
	   fprintf(stderr, "ID OTIO:%3u ID DOMO:%d %c%d.%d\n", sensorID, tiddomo[i], sign, enttemp, dectemp);
	   printf("{\"idx\" : %d, \"nvalue\" : 0, \"svalue\" : \"%c%d.%d\"}\n", tiddomo[i], sign, enttemp, dectemp);
   }
}

Le résultat final est illustré par la copie d'écran Domoticz
On voit 4 indications de tempé : l'une provient d'un BME280, une autre de ma sonde OREGON et deux viennent de mes sondes OTIO

[duodiscus]

Je complète encore pour dire que ... ça marche mal ...
Donc il y a encore du travail ...
A suivre ...

[duodiscus]

Bon ... on efface tout et on recommence.

Changement de méthode, j'ai renoncé à essayer de partager ttyUSB0 entre Domoticz et un programme externe d'autant que ...
la bonne nouvelle c'est que j'ai trouvé dans un fond de tiroir une clé DVB-T+FM+DAB et un post sur ce forum indiquant qu'on pouvait
l'utiliser en récepteur 433MHz (récepteur uniquement).

J'ai donc relié ma clé à un RPI Zero W (incluant le Wifi) et j'ai suivi les indications d'installations données sur ce lien

https://enavarro.me/jouer-avec-une-cle-rtlsdr.html


Ensuite, en tapant

Code : Tout sélectionner

rtl_433

j'ai observé que tous mes capteurs Oregon et OTIO étaient reçus.
Mes capteurs OTIO sont vus comme des "Generic temperature sensor 1" mais sont mal décodés.

Chance n°1, tous les sources de rtl_433 sont fournis, chance n° 2, c'est écrit en C (mon langage préféré) et chance n°3, c'est bien écrit et modulaire.
Donc, il suffit d'aller modifier le module qui traite du "Generic temperature sensor 1" et de l'adapter à ses besoins. (Plus tard au lieu de modifier ce module je créerai mon propre module mais je ne sais pas encore comment faire.)

C'est le fichier :

Code : Tout sélectionner

generic_temperature_sensor.c 

qu'on trouve ici:

Code : Tout sélectionner

/etc/modprobe.d/rtl_433/src/devices/

Je l'ai modifié de façon à corriger l'erreur de décodage et à ne me sortir que les deux infos qui m'intéressent : l'ID et la température.

rtl_433 offre plusieurs format de sortie. Il y en a deux intéressants: json et csv. J'ai opté pour csv car le format json n'est pas celui attendu par Domoticz.

Après ces modifications la commande :

Code : Tout sélectionner

rtl_433 -R38 -F csv 

m'affiche chaque fois qu'un message des mes capteurs est reçu des lignes comme celles-ci :

Code : Tout sélectionner

134,22.4
76,18.7

Notez que l'option -R 38 indique à rtl_433 que seul les messages du "Generic temperature sensor 1" doivent être prise en compte.

Il faut ensuite faire l'association ID OTIO avec ID Domoticz et formater tout ça en JSON compatible Domoticz.
J'ai écrit le petit programme en C suivant qui fait le job.
Programme rtl2domo.c

Code : Tout sélectionner

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>

/* nombre max de capteurs OTIO */
#define MAX_OTIO (10)

void main(int argc, char **argv)
{

   unsigned short tidotio[MAX_OTIO+1], tiddomo[MAX_OTIO+1];
   short int i,  myargc, nbotio, sensorID;
   float temp;
   char msg[40];

   if(argc > MAX_OTIO+1){
     fprintf(stderr, "Trop de capteurs déclarés (ne peut dépasser %d)\n", MAX_OTIO);
     exit(1);
   }

   if ((argc < 2) || ((argc % 2) == 0) ){
    fprintf(stderr, "Manque arguments d'affectation capteurs\n");
    exit(0);
   }

   /* nombre de capteurs à traiter */
   nbotio = (argc-1)/2;

   /* Appairage  ID OTIO a ID Domoticz */
   myargc = argc;
   while (myargc > 1) {
     i = (myargc-1)/2;
     fprintf(stderr, "myargc=%d i=%d\n", myargc, i);
     tidotio[i] = atoi(argv[myargc-2]);
     tiddomo[i] = atoi(argv[myargc-1]);
     myargc -=2;
   }

   /* verification */
   for (i=1; i<=(argc-1)/2; i++)
      fprintf(stderr, "L'ID  OTIO %3d est affecté à l'ID  DOMO %d\n", tidotio[i], tiddomo[i]);

   //fflush(stdin);
   /* élimination d'un chaine parasite détectée avec hexdum */
   fgets(msg, 100, stdin);

   for(;;){
      scanf("%d,%f\n", &sensorID, &temp);
      for(i=1; i<MAX_OTIO; i++){
         if(sensorID == tidotio[i])
         break;
      }
      printf("{\"idx\" : %d, \"nvalue\" : 0, \"svalue\" : \"%.1f\"}\n", tiddomo[i], temp);
      fflush(stdout);
   }
}

Noter que quand on lance rtl2domo, il faut lui donner en paramètre des couple d'ID (OTIO et Domoticz) pour qu'il puisse faire l'association.

Il reste à envoyer la sortie JSON au serveur Domoticz et pour ça j'utilise le protocole MTQQ.
Tout ça se traite en une commande :

Code : Tout sélectionner

rtl_433 -R38 -F csv | /home/pi/rtl2domo 134 89 76 90 | mosquitto_pub -l -h 192.168.1.39 -t "domoticz/in"

où la sortie de la commande rtl_433 est envoyé en entrée de mon programme rtl2domo et la sortie de rtl2domo est envoyée en entrée de la commande mosquitto qui publie le message JSON à destination du courtier MTQQ qui se trouve à l'IP 192.168.1.39

Et voilà, ça fonctionne avec un récepteur 433 MHz pour environ 50 € (clé RTL + RPI Zero W + alim). La copie d'écran Domoticz est la même que celle d'un précédent post.
Autre avantage : j'ai séparé le serveur Domoticz du récepteur 433 ce qui me permet de placer ce dernier en un endroit optimal de l'appartement pour recevoir au mieux tous les capteurs.
Autre avantage : autant utiliser le RPI Zero pour d'autres applications : en l’occurrence j'ai monté dessus un capteur BME280 pour mesurer la température et la pression atmosphérique. Là encore j'utilise MTQQ pour envoyer les infos vers le serveur Domoticz.

[duodiscus]

Reste un point assez critique : le réglage des paramètres de la clé RTL.
Avec les paramètres par défaut, la portée est assez limitée en appartement.
J'ai essayé de trouver un optimal : meilleur positionnement et meilleur gain pour capter mes deux sondes, mais sans succès.
En fait il y a d'autres paramètres (à part le gain) qui peuvent influencer la qualité de la réception et la portée.
Mais je ne les maitrise pas encore.
Dans l'attente, je suis obligé de rapprocher une de mes deux sondes de l'antenne de la clé RTL, mais du coup elle ne se situe pas à l'emplacement que je souhaitais.
Si qq'un à une expérience positive sur la résolution des problèmes de portée, je suis preneur.

[Neutrino]

Bonjour Duodiscus,
Merci de nous conter tes aventures !
Pour la portée, rien ne vaut une bonne antenne aussi bien sur l’émetteur que sur le récepteur.
La position est aussi très importante :

Capture.PNG (161 Kio) Consulté 8633 fois

[duodiscus]

Merci Neutrino
Le schéma est intéressant en effet.
Je me situe plutôt dans les cas favorables du schéma.
Curieusement, après avoir sans succès testé diverses valeurs de gain, j'ai fini par supprimer l'option -g et ô surprise ... ça fonctionne
en plaçant mes sondes aux emplacements souhaités. (à force de faire des tests en tous genres, déplacer les sondes, modifier les gains,
j'ai omis de revenir aux fondamentaux ...)

A toutes fins utiles pour ceux qui veulent approfondir le sujet de la propagation en 433 MHz et autres fréquences ISM il y a cette
thèse à télécharger sur ce lien (mais peu applicable à la Domotique en indoor)
https://tel.archives-ouvertes.fr/tel-00573695

[lepetitnicolas]

Bonsoir,
Je viens de tomber sur ce post car j'ai essayé d'associer deux sondes Otio 93807-0001 à Domoticz via mon rflink.... sans succès
Je ne me vois pas m'embarquer dans cette solution , trop complexe pour mon niveau.
Par contre, avez vous pensez à envoyer les trames récupérer via rflink pour demander à l’équipe qui développe le firmware de l'inclure dans une prochaine mise à jour ?
Bonne soirée et encore merci pour ce tuto