" /> Mon para-monde
Flux RSS

lundi 19 mars 2012

ELV Max! Il est temps de passer commande

Excusez la blague à 2 balles, il n'est bien sûr pas question d'acheter quelque chose mais de trouver les commandes que le cube peut recevoir et les réponses qu'il peut fournir.

On a déjà vu quelques commandes :

Le sniffing du réseau et le classique essai/erreur permettent d'en trouver quelques autres :

  • "m:" qui modifie les données de la M:aison
  • "z:" qui est envoyé avant un groupe de commandes
  • "n:" qui met le cube en mode apprentissage
  • "x:" annule une commande en cours de type "n:"
  • "d:" et "e:" qui décodent et encodent une chaine binaire (quel algorithme ? mystère)

Comme les lignes reçues, la macrosyntaxe est <lettre de commande>:<enchaînement de champs séparés par des virgules>.

Dans les champs, les données sont soit codées en hexadécimal ou en texte brut (p. exemple : "z:1e,G,02" ) soit encodées partiellement ou totalement en base64 (p. exemple : "s:AAAAiAAAAAPx4AAI=" )

Toutes les commandes que je trouverai seront rajoutées ici au fur et à mesure avec des liens vers chaque description.

dimanche 18 mars 2012

Quelques ordres S: (S12,S20,S21,S22,S23)

J'ai été très occupé ces derniers temps, pas eu trop le temps d'écrire les articles sur d'autres fonctions S:(end) de l'ELV Max!

En voici quelques unes :

ConfigValve (Commande 0x12)

00     00
01     Bitfield : 76543210
                       10 = broadcast (?)
02     12    COMMANDE
03     00
04     00
05     00
06     AABBCC Adresse d'émission
07     ..
08     ..
09     XX     RoomId
10     XX     Configuration du Boost (1)
11     XX     Configuration du cycle de détartrage (2)
12     XX     Position Max de la valve
13     XX     Position Min de la valve

(1) La configuration du Boost se fait sur un octet sous forme de 2 champs de bits :

  • 3 bits pour la durée du Boost en tranche de 5min
  • 5 bits pour l'ouverture de valve en tranche de 5%

(2) Le détartrage se règle lui aussi sur un champ de 8 bits :

  • 3bits pour le jour (0=Samedi, 1=Dimanche... 6=Vendredi)
  • 5bits pour l'heure de mise en route par tranche de 30 minutes

AddDirectLinkFromTo (0x20) et RemoveDirectLinkFromTo (0x21)

00     00
01     Bitfield : 76543210
                       10 = broadcast (?)
02     20/21    COMMANDE
03     00
04     00
05     00
06     AABBCC Adresse d'émission du périphérique référence
07     ..
08     ..
09     AABBCC Adresse d'émission du périphérique de pilotage
10     ..
11     ..
12     XX Type de périphérique

setGroupRFaddr (0x22) et removeGroupRFaddr (0x23)

00     00
01     Bitfield : 76543210
                       10 = broadcast (?)
02     22/23    COMMANDE
03     00
04     00
05     00
06     AABBCC Adresse d'émission du périphérique à ajouter ou retirer de la pièce
07     ..
08     ..
09     XX     RoomId

On a pas fini, il reste encore quelques commandes s:, en particulier le réglage des programmes journaliers (mode 0x10) et le changement de modes (mode 0x40) qui sont incontournables et un peu velus.

lundi 13 février 2012

ELV Max! commande "s:" syntaxe générale et commande de réglage des températures par défaut (0x11)

La commande "s:" sert à envoyer une commande (send en anglais quoi).

Le format général est s:<chaine en base64>

Pour illustrer voici la commande générée par la modification du décalage de température sur un thermostat dont l'adresse est 00fb6d.

s:AAARAAAAAPttACoiPQkJGAM=

Le décodage ramène une chaine binaire (ici en hexa) :

00 00 11 00 00 00 00 fb 6d 00 2a 22 3d 09 09 18 03
#0 #1 #2 #3 #4 #5 #6 #7 #8 #9 #A #B #C #D #E #F #10

Si on décortique, en premier lieu, on trouve tout de suite à partir de #6 une adresse de périphérique.

Une modification du même paramètre fait varier uniquement l'octet #E tandis que le changement d'autres paramètres de température font varier individuellement les autres octets de #A à #10.

Ces valeurs ne sont cependant pas encodées directement. Ainsi une température qui se règle par pas de 0,5° et encodée sous la forme T°x2 et le décalage de température qui peut aller de -3,5 à 3,5 est encodé par dT°x2+7 .

Au final voici le payload de la fonction 11(hex) :

00     00
01     Bitfield : 76543210
                       10 = broadcast (?)
02     11    COMMANDE (ici réglage des températures par défaut)
03     00
04     00
05     00
06     AABBCC Adresse d'émission
07     ..
08     ..
09     XX     RoomId
10     XX     Température de comfort
11     XX     Température éco
12     XX     Température max réglable sur la tête
13     XX     Température min réglable sur la tête
14     XX     Décalage de température
15     XX     Température lorsqu'une fenêtre est ouverte
16     XX     Durée de la consigne de fenêtre ouverte

Le retour de l'envoi d'une telle commande est une ligne "S:"

Celle-ci contient 3 champs séparés par des virgules :

1 : Ce chiffre semble augmenter de temps en temps
2 : Succés/Echec (0/1)
3 : Ce chiffre diminue au maximum de 1 à chaque commande passée, il peut aussi augmenter le maximum est 30(hex) soit 48(dec).

Je pense que les commandes sont envoyées aux têtes par bloc ou par cycles, le champ 1 identifie le bloc courant et le 3 le nombre d'emplacements libres dans ce bloc. C'est pour cela que le champ 3 ne diminue pas toujours ; des commandes sont envoyées en même temps que d'autres sont reçues.

dimanche 5 février 2012

ELV Max! Contenu de la ligne L:ive

A la différence des lignes de C:onfig qui sont aussi nombreuses qu'il y a de périphériques branchés, la ligne L:ive est unique. Tous les périphériques sont regroupés en une seule ligne.

Par ailleurs il n'y a pas d'information sur le cube dans la ligne L:

Interogation du cube

On peut demander une nouvelle ligne L:ive mise à jour par l'envoi de "l:" (L minuscule) suivi de CR+LF Le cube répond alors par une ligne L: contenant les dernières données dont il dispose.

Structure générale d'une ligne L:

La ligne L: ne possède qu'un champ encodé en Base64

par exemple :
L:CwD7bQASGEcpAAAA

Contenu du champ

L'exemple ci-dessus se décode en :

0b 00 fb 6d 00 12 18 47 29 00 00 00

On repère tout de suite les octets 2,3,4 "00fb6d" correspondant à une adresse. Par ailleurs, le premier octet contient 0x0b correspondant au nombre d'octets qui suivent (lorsqu'il y a plusieurs périphériques connectés, on retrouve à nouveau cette même structure <longueur><contenu> répétée autant de fois qu'il y a de périphériques.

On remarque aussi, pas mal d'octets à 0x00, ca va pas nous aider à dépiauter la bêêête mais ça s'arrange après avoir modifier des éléments de config :) .

Position     Champ
0              1 octet  = longueur du morceau de réponse suivant (je n'ai rencontré que des enregistrements de 11 caractères : 0x0b)
1              3 octets = Adresse
4              1 octet  = ? 
5              1 octet  = ? 
6              1 octet  = ? 
                  bits 1-2 = ?
                  bit 3    = Verrouillage clavier
                  bits 4-6 = ?
                  bits 7-8 = Mode
7              1 octet  = Position de la valve (0-100)
8              1 octet  = Température de consigne réglée sur la tête
9-10           2 octets = Date de fin
11             1 octet  = Heure de fin

Les octets 4-6 ne sont pas souvent modifiés par des actions par la webapp ou par modification des réglages de la tête, les seuls bits modifiés de façon synchrone sont sur l'octet 6 (bits 7 et 8) et correspondent au mode (0b00 : mode auto, 0b01 : mode manu, 0b10 : mode temporaire, 0b11 : mode Boost)

Date et heure ne sont valides que lorsqu'on est en mode "temporaire".

ELV Max! Contenu de la config (ligne C:)

La ligne C: se décompose en 2 champs principaux. Outre l'entête "C:", on retrouve le code d'adressage en hexadécimal sur 6 caractères (donc une fois retransformé, sur 24bits) suivi d'une virgule et à nouveau un contenu encodé en Base64.

C:007ead,7QB+rQAJAQBJRVEwMTEyMjQwAAsABEAAAAAAAAAAAP///////////////////////////wsABEAAAAAAAAAAQf///////////////////////////2h0dHA6Ly93d3cubWF4LXBvcnRhbC5lbHYuZGU6ODAvY3ViZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAENFVAAACgADAAAOEENFU1QAAwAAAAAcIA==

Voici donc la ligne correspondant au périphérique 007ead. Dans le cas présent, il s'agit du cube lui-même et je n'en étudierai pas la config tout de suite car peu intéressante, pour le plaisir voici le décodage (les données alphanumériques sont soulignées, le reste est en hexadécimal) :

ED 007EAD 00 09 01 00 IEQ0112240 00 0B 00 04 40 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0B 00 04 40 00 00 00 00 00 00 00 41 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF http://www.max-portal.elv.de:80/cube 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CET 00 00 0A 00 03 00 00 0E 10 CEST 00 03 00 00 00 00 1C 20

On y découvre entre autre l'URL du backend du portail web (l'adresse du frontend est à http://www.max-portal.elv.de/ ).

Intéressons-nous plutôt aux thermostats.

La config est là-aussi contenue dans un champ encodé en base64. Celle-ci étant particulièrement longue, je vous en fait grâce et je vais me contenter d'en faire le détail :

Position     Champ
0              1 octet  = ?
1              3 octets = Adresse
4              1 octet  = Type de périphérique (0=Cube?, 1=Thermostat)
5              1 octet  = ?
6              10 octets= Numéro de série (IEQXXXXXXX)
16             1 octet  = Température de confort (*)
17             1 octet  = Température Eco (*)
18             1 octet  = Température maximale de réglage (4.5° soit 0x09 = valeur de 'off')
19             1 octet  = Température minimal de réglage (30.5° soit 0x3d = valeur de 'on')
20             1 octet  = Décalage de réglage température (*)
21             1 octet  = Température en cas d'ouverture de fenêtre (*)
22             1 octet  = Durée de changement de consigne en cas d'ouverture de fenêtre (*)
23             1 octet  = bitfield de 8 bits
                3 bits   = durée du Boost (*)
                 5 bits   = valeur de valve du Boost (*)
24             1 octet  = bitfield de 8 bits
                3 bits   = Jour du cycle de détartrage de la valve (*)
                 5 bits   = heure de détartrage de la valve (*)
25             1 octet  = position maximum de la valve ? (255) peut-être dépendant du réglage initial de course
26             1 octet  = position de départ de la valve ? (0) peut-être dépendant du réglage initial de course
27             début des programmes journaliers (7 groupes = 1 par jour) (*)
(*) les valeurs sont modifiables depuis la webapp

Les températures sont exprimées en multiples de 0,5° (Température = Valeur/2)

La liste des jours commence le Samedi(=0 ???) jusqu'au Vendredi (=7)

Le décalage de température est exprimé en multiples de 0,5° à ajouter à -3,5° (Décalage = Valeur/2 - 3.5)

La durée du boost se calcule donc par Durée = (Valeur & 0xE0)>>5 et la valeur de valve par Valve = (Valeur & 0x1F)

Idem pour le détartrage : Jour = (Valeur & 0xE0)>>5 et Heure = (Valeur & 0x1F)

Un programme journalier est constitué de 26 octets, 13 blocs de 2 octets pour être plus précis soit 13 paliers programmables par jour. Sur ses 16bits (composant les 2 octets MSB et LSB), sont encodées 2 grandeurs : la température de consigne et l'heure de fin.

0TTTTTTH.HHHHHHHH

La Température est à nouveau exprimée en multiple de 0,5 tandis que l'heure est exprimée en multiple de 5 minutes

Donc partant du principe qu'on lit les octets un par un, on a :

Température = ((MSB & 0x7E)>>1)/2
Heure de fin = ((MSB & 0x01)*256+LSB)*0.5

Il me reste donc 2 champs dont je n'arrive pas à comprendre la signification (0 et 5).

Demander une ligne de C:onfig

Il est possible de demander la ligne de configuration d'un périphérique spécifique si on connait son adresse.

Pour cela il faut envoyer la commande "c:" suivie de l'adresse en hexadécimal par exemple (terminer par CR+LF) :

c:007ead
C:007ead,<........................>

Le résultat est la ligne C: telle qu'on peut la voir en haut de l'article. Si l'adresse est inconnue, il n'y a pas de réponse.

Méthodologie

La méthode pour repérer tout cela est principalement de lancer depuis l'interface web des commandes unitaires puis de récupérer la configuration immédiatement après afin d'isoler les différences et d'en tirer une signification.

Pour les champs non modifiables (température maxi ou min), il faut faire des essais ("si c'était une température, si je divise par 2 est-ce que ca donne une valeur qui a du sens ?") éventuellement avec le manuel pas loin

samedi 28 janvier 2012

J'ai découvert une commande de plus sur ELV Max!, ben j'aurais préféré m'en passer... :)

Alors que je bidouillais le Cube via netcat, j'ai lancé quelques commandes de la forme <lettre><:><cr><lf>

Et bien, ca m'a permis de découvrir à mon corps défendant la commande "a:" que l'on peut désormais surnommer "Reset sauvage de toute les métadonnées".

4 petits caractères suffisent à ramener le cube dans un état immaculé :

H:IEQ0112240,007ead,0109,00000000,2ee8c053,00,32,0c011c,0c2b
M:
C:007ead,7QB+rQAJAQBJRVEwMTEyMjQwAAsABEAAAAAAAAAAAP///////////////////////////wsABEAAAAAAAAAAQf///////////////////////////2h0dHA6Ly93d3cubWF4LXBvcnRhbC5lbHYuZGU6ODAvY3ViZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAENFVAAACgADAAAOEENFU1QAAwAAAAAcIA==
L:

On voit le champ M: vide, l'absence de données L:ive et une seule ligne de config pour le Cube lui-même...

La bonne nouvelle, c'est qu'après avoir fait le réapprentissage d'un thermostat, il semble que la config soit retrouvée (retéléchargée du la tête ?)

H:IEQ0112240,007ead,0109,00000000,233903cd,04,32,0c011c,0d04
M:00,01,VgIBAQZCdXJlYXUA+20BAQD7bUlFUTAxODQ5OTkHQnVyZWF1MQEB
C:007ead,7QB+rQAJAQBJRVEwMTEyMjQwAAsABEAAAAAAAAAAAP///////////////////////////wsABEAAAAAAAAAAQf///////////////////////////2h0dHA6Ly93d3cubWF4LXBvcnRhbC5lbHYuZGU6ODAvY3ViZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAENFVAAACgADAAAOEENFU1QAAwAAAAAcIA==
C:00fb6d,0gD7bQEBFP9JRVEwMTg0OTk5KiI9CQcYAzAM/wBESFUIRSBFIEUgRSBFIEUgRSBFIEUgRSBFIERIVQhFIEUgRSBFIEUgRSBFIEUgRSBFIEUgREhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIERIVGxEzFUURSBFIEUgRSBFIEUgRSBFIEUgREhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIA==
L:CwD7bQASGEcpAAAA

On peut noter au passage que le champ 6 de H: a changé (00 -> 04) mais je ne sais pas pourquoi..

vendredi 27 janvier 2012

ELV MAX! Lignes Host (H:) et Maison (M:)

Revenons à l'étude de la réponse initiale du Cube Max!

Le format le plus global est :

  • un ensemble de lignes commençant toutes par une lettre suivie d'un "deux points" lui même suivi d'un contenu
  • chaque ligne est terminée par un marqueur assez classique : cr/lf (carriage return/line feed)

Voici ce que j'ai pu tirer pour l'instant des lignes H et M

H:

Contient des données très basiques sur le système : Les champs du contenu sont séparés par des virgules

H:IEQ0112240,007ead,0109,00000000,35e2322f,00,32,0c011b,0909

que l'on peut découper en :

  • IEQ0112240 = numéro de série du Cube (invariant dans la même installation, il est imprimé sous le cube), format alphanumérique
  • 007ead = nombre constant (on le retrouve ailleurs sur la première ligne C:, on le verra plus tard), c'est donc d'une certaine manière un moyen d'adressage, format hexadécimal sur 3 octets
  • 0109 = la version du microcode embarqué a priori (le code a changé après une mise à jour)
  • 00000000 = euh comment dire... des zéros ?
  • 35e2322f = un nombre variant totalement à chaque connexion, probablement un identifiant de connexion mais on ne le retrouve nulle par ailleurs, format hexadécimal sur un long (32bits)
  • 00 = encore des 0... impossible d'en savoir la signification
  • 32 = toujours 32 là aussi... impossible d'en tirer une conclusion
  • 0c011b = là aussi un invariant
  • 0909 = Est-ce que ca ne serait pas 9 heures 09 (si c'est le cas, le cube n'est pas à l'heure :) ), à voir lorsqu'on passera

M:

M:00,01,VgIHAQdDdWlzaW5lAP4uAgtTYWxsZSBkJ2VhdQD99QMNQ2hhbWJyZSBMdWNhcwCWrAQTQ2hhbWJyZSBGcmVkIExvdWxvdQCZbwUGQnVyZWF1APttBg1TYWxsZSBkZSBiYWluAPx4BwVTYWxsZQCWkgcBAP4uSUVRMDE4NDgxMgdDdWlzaW5lAQEA/fVJRVEwMTg0NzQ0C1NhbGxlIGQnZWF1AgEAlqxJRVEwMTg2MTYyDUNoYW1icmUgTHVjYXMDAQCZb0lFUTAxODMzMTcTQ2hhbWJyZSBGcmVkIExvdWxvdQQBAPttSUVRMDE4NDk5OQZCdXJlYXUFAQD8eElFUTAxODUxNjYNU2FsbGUgZGUgYmFpbgYBAJaSSUVRMDE4NjExNw9TYWxsZSDDoCBtYW5nZXIHAQ==

La ligne M: là aussi contient des champs séparés par des virgules. Et là aussi les 2 premiers sont invariants d'une connexion à l'autre (toujours 00 et 01) Suit un champ beaucoup plus long qui semble codé mais on note qu'on a affaire à des caractères tous "imprimables" et qu'en fin de ligne on retrouve des "=" typiques du remplissage final en base64

Si on décode ce 3ème champ comme du base64 on récupère en effet un contenu contenant des éléments reconnaissables et cohérents (les caractères non imprimables ont été supprimés) :

V(...)Cuisine(...)Salle d'eau(...)Chambre Lucas(...)Chambre Fred Loulou(...)Bureau(...)Salle de bain(...)Salle(...)IEQ0184812 Cuisine(...)IEQ0184744 Salle d'eau(...)IEQ0186162 Chambre Lucas(...)IEQ0183317 Chambre Fred Loulou(...)IEQ0184999 Bureau(...)IEQ0185166 Salle de bain(...)IEQ0186117 Salle à manger(...)

Dans ce contenu binaire on peut retrouver une certaine organisation : Il y a 3 sous-ensembles.


** un préambule de 2 octets au contenu inconnu
** une structure décrivant les pièces (organisation logique)
** une structure décrivant les périphériques (organisation physique)

Format de la liste des pièces

Le premier octet contient le nombre de pièces définies (roomCount). A sa suite, on retrouve répétée roomCount fois une structure définissant une pièce :

  • Nombre de caratères du nom de la pièce (1 octet)
  • Nom de la pièce (X octets cf supra)
  • ID de la pièce (1 octet)
  • 3 octets dont le contenu ressemble au champ qualifié d'adressage sur la ligne H:, mais il ne semble pas utilisé (ID est utilisé ensuite)

Immédiatement après la liste des pièces on attaque la liste des périphériques (thermostats) Le principe est le même que la liste des pièces.

Format de la liste des périphériques

Le premier octet contient le nombre de périphériques définis (devCount).

La aussi on retrouve devCount fois une structure de périphérique :

  • Type de périphérique (1 octet) 0=Cube, 1=Tête thermostatique, peut-être y en a t'il d'autres pour par exemple le thermostat mural (mais je n'en ai pas)
  • 3 octets "d'adressage", le contenu de ce champ se retrouve comme premier champ des lignes C: suivantes permettant de les rattacher à un périphérique
  • 10 octets de numéro de série
  • 1 octet de nombre de caractères du nom du périphérique
  • Nom du périphérique (X octets ci-dessus)
  • ID de la pièce de rattachement (1 octet)

Voilà, avec la ligne M: on peut construire la structure de notre maison.

La prochaine fois, je m'attaque à la ligne C: qui donne la config courante d'un périphérique.

mercredi 25 janvier 2012

ELV MAX! Début d'exploration

Je vais vous épargner le détail de la méthodologie mais pour faire simple. Il faut sniffer le réseau entre l'appli java qui réside sur l'ordinateur et le boîtier. Pour cela, j'ai fait brutal (parce que bien sur l'appli ne marche que sous Windows) : j'ai intercalé un ordi entre les 2, mis en place l'IP forwarding et lancé mon fidèle wireshark (un logiciel de capture de trame réseau et d'analyse). On peut aussi bien sur capturer directement sur l'ordinateur "source".

Voici les premiers constats :

  • l'appli se connecte à son lancement au cube sur le port 80, on se dit alors Chouette il y a un serveur web embarqué. Hélas on déchante vite car une fois l'appli connectée, impossible d'initier une autre connexion TCP/IP vers le port 80. Le cube ne supporte qu'un seul logiciel de commande à la fois...
  • il ne s'agit pas de HTTP non plus. En effet, toute connexion même sans envoi de requête génère une réponse du cube. Voici un exemple de réponse à l'ouverture d'une connexion (sans rien envoyer) :
H:IEQ0112240,007ead,0109,00000000,673a0152,00,32,0c0110,1306

M:00,01,VgIHAQdDdWlzaW5lAP4uAgtTYWxsZSBkJ2VhdQD99QMNQ2hhbWJyZSBMdWNhcwCWrAQTQ2hhbWJyZSBGcmVkIExvdWxvdQCZbwUGQnVyZWF1APttBg1TYWxsZSBkZSBiYWluAPx4BwVTYWxsZQCWkgcBAP4uSUVRMDE4NDgxMgdDdWlzaW5lAQEA/fVJRVEwMTg0NzQ0C1NhbGxlIGQnZWF1AgEAlqxJRVEwMTg2MTYyDUNoYW1icmUgTHVjYXMDAQCZb0lFUTAxODMzMTcTQ2hhbWJyZSBGcmVkIExvdWxvdQQBAPttSUVRMDE4NDk5OQZCdXJlYXUFAQD8eElFUTAxODUxNjYNU2FsbGUgZGUgYmFpbgYBAJaSSUVRMDE4NjExNw9TYWxsZSDDoCBtYW5nZXIHAQ==

C:007ead,7QB+rQAJAf9JRVEwMTEyMjQwAAsABEAAAAAAAAAAAP///////////////////////////wsABEAAAAAAAAAAQf///////////////////////////2h0dHA6Ly93d3cubWF4LXBvcnRhbC5lbHYuZGU6ODAvY3ViZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAENFVAAACgADAAAOEENFU1QAAwACAAAcIA==

C:00fdf5,0gD99QECFP9JRVEwMTg0NzQ0KCA9CQcYAzAM/wBESFiFRNhY8FEDRSBFIEUgRSBFIEUgRSBFIERIWIZE2VEDRSBFIEUgRSBFIEUgRSBFIEUgREhYbETeWORRAkUgRSBFIEUgRSBFIEUgRSBESFhsRN5Y5FD3RSBFIEUgRSBFIEUgRSBFIERIWGxE2VEDRSBFIEUgRSBFIEUgRSBFIEUgREhYbETeWORRAkUgRSBFIEUgRSBFIEUgRSBESFhsRNhRFUUgRSBFIEUgRSBFIEUgRSBFIA==

C:0096ac,0gCWrAEDFP9JRVEwMTg2MTYyKCA9CQcYAzAM/wBEYFD+RSBFIEUgRSBFIEUgRSBFIEUgRSBFIERgUP5FIEUgRSBFIEUgRSBFIEUgRSBFIEUgQElUYkDTUQVBIEEgQSBFIEUgRSBFIEUgRSBASVRiQNNRBUEgQSBBIEUgRSBFIEUgRSBFIERgUP5FIEUgRSBFIEUgRSBFIEUgRSBFIEUgQElUYkDTUQVBIEEgQSBFIEUgRSBFIEUgRSBASVRiQNNRBUEgQSBBIEUgRSBFIEUgRSBFIA==

C:00fb6d,0gD7bQEFFP9JRVEwMTg0OTk5KCA9CQcYAzAM/wBEVFEKRSBFIEUgRSBFIEUgRSBFIEUgRSBFIERUUQpFIEUgRSBFIEUgRSBFIEUgRSBFIEUgRFRRCkUgRSBFIEUgRSBFIEUgRSBFIEUgRSBEVFEKRSBFIEUgRSBFIEUgRSBFIEUgRSBFIERUUQpFIEUgRSBFIEUgRSBFIEUgRSBFIEUgRFRRCkUgRSBFIEUgRSBFIEUgRSBFIEUgRSBEVFEKRSBFIEUgRSBFIEUgRSBFIEUgRSBFIA==

C:00fc78,0gD8eAEGFP9JRVEwMTg1MTY2KCA9CQcYAzAM/wBFIEUgRSBFIEUgRSBFIEUgRSBFIEUgRSBFIETRVPBFIEUgRSBFIEUgRSBFIEUgRSBFIEUgPSA9ID0gPSA9ID0gPSBFIEUgRSBFIEUgRSA9ID0gPSA9ID0gPSA9IEUgRSBFIEUgRSBFID0gPSA9ID0gPSA9ID0gRSBFIEUgRSBFIEUgPSA9ID0gPSA9ID0gPSBFIEUgRSBFIEUgRSA9ID0gPSA9ID0gPSA9IEUgRSBFIEUgRSBFIA==

C:00996f,0gCZbwEEFP9JRVEwMTgzMzE3KCA9CQcYAzAM/wBEYFR0ROpRFEUgRSBFIEUgRSBFIEUgRSBFIERgVHRE6lEURSBFIEUgRSBFIEUgRSBFIEUgREhUYkTSVQNFIEUgRSBFIEUgRSBFIEUgRSBESFRiRNJVA0UgRSBFIEUgRSBFIEUgRSBFIERgVHRE6lEURSBFIEUgRSBFIEUgRSBFIEUgREhUYkTSVQNFIEUgRSBFIEUgRSBFIEUgRSBESFRiRNJVA0UgRSBFIEUgRSBFIEUgRSBFIA==

C:00fe2e,0gD+LgEBFP9JRVEwMTg0ODEyKCA9CQcYAzAM/wBEVFR4UMBU8EUgRSBFIEUgRSBFIEUgRSBFIERUVHhQwFTwRSBFIEUgRSBFIEUgRSBFIEUgRE9UbUzbVPBFIEUgRSBFIEUgRSBFIEUgRSBET1RtTNtU8EUgRSBFIEUgRSBFIEUgRSBFIERPVG1M21TwRSBFIEUgRSBFIEUgRSBFIEUgRE9UbUzbVPBFIEUgRSBFIEUgRSBFIEUgRSBET1RtTNtU8EUgRSBFIEUgRSBFIEUgRSBFIA==

C:009692,0gCWkgEHFP9JRVEwMTg2MTE3KCA9CQcYAzAM/wBEVFUJRSBFIEUgRSBFIEUgRSBFIEUgRSBFIERUVQlFIEUgRSBFIEUgRSBFIEUgRSBFIEUgRFRVCUUgRSBFIEUgRSBFIEUgRSBFIEUgRSBEVFUJRSBFIEUgRSBFIEUgRSBFIEUgRSBFIERUVQlFIEUgRSBFIEUgRSBFIEUgRSBFIEUgRFRVCUUgRSBFIEUgRSBFIEUgRSBFIEUgRSBEVFUJRSBFIEUgRSBFIEUgRSBFIEUgRSBFIA==

L:CwD99QkSGA0oAN0ACwCWrAkSGAAoAN8ACwD7bQkSGAAnANcACwD8eAkSGAAeAKkACwCZbwkSGAAqAP8ACwD+LgkSGC8qAM8ACwCWkgkSGGQqAMsA
  • Les paramètres comme on peut le voir ne sont pas très intuitifs, il va falloir creuser.
  • Certains éléments sont invariants et permettent d'avoir quelques indices : Le premier champ de la ligne H: reprend exactement le numéro de série situé sous le Cube. Je l'appelle ligne "Hôte" ("Host" en anglais)
  • L’enchaînement de ces lignes est immuable mais certains éléments varient beaucoup (par exemple le 5ème champ de la ligne H: différent à chaque reconnexion et ne semblant suivre aucune logique de progression) ou peu (Le contenu de la ligne L: )
  • Les données situées après la virgule des lignes C: sont probablement des données spécifiques à chaque élément du système (1 ligne par élément) car on trouve 8 lignes dans 2 formats (1 ligne dans 1 format et 7 dans un autre) et j'ai 7 thermostats et 1 cube. De plus la ligne H: qui contient le n° de série du Cube possède en champ 2 "007ead" présent en entête de la ligne C: dont le format diffère des autres. A priori ces données ne varient pas si on ne dérègle rien dans l'appli, j'imagine que ce sont les lignes de configuration. Petit nom, "Config".

Il va falloir décoder ces lignes maintenant.

Si on continue de suivre le fil des événements réseaux, l'appli envoie des commandes "l:" qui entraînent la réémission d'une ligne "L:" qui au bout d'un certain temps peut discrètement varier. J'imagine qu'il s'agit des données "live", zou voila le nom trouvé. La ligne M... faut voir...

Au final on se sent revenu au bon vieux temps où la place disque/réseau/ram était chère. On va pouvoir s'amuser ! :)

mardi 24 janvier 2012

Domotiqueuh tiqueuh tiqueh

Non, je ne me transforme pas en Soeur sourire mais depuis quelques mois j'avais mis en place des corps thermostatiques sur certains des radiateurs de la maison et en ce début d'année, j'y ai installé les têtes thermostatisques adaptées