Domotique épisode 2 : le chauffage (need help !)

Voici le deuxième billet de la partie domotique, qui est en relation avec mon système de chauffage à air pulsé. En effet, il est de conception récente et il y a largement de quoi se faire plaisir !

Les logements de ma résidence sont équipés d’une chaudière à gaz individuelle. L’eau chauffée par la chaudière passe dans un échangeur eau/air et ce dernier est diffusé dans l’appartement grâce à un ventilateur. Un clapet permet d’autoriser ou non la diffusion de l’air chaud dans chaque pièce :

J’ai donc un thermostat numérique dans chaque pièce, ou plus exactement une sonde de température : ce ne sont probablement pas eux qui prennent la décision de chauffer ou non chaque pièce. Ils se contentent certainement de remonter la température réelle et la consigne à une centrale, qui va elle se charger de la régulation. Ces sondes sont fabriquées par Distech Controls, le modèle est « Allure EC-Smart-Vue« . Elles sont toutes chaînées sur un bus possédant des connecteurs RJ45.

La centrale de régulation est également conçue par Distech Controls. Chez moi, il s’agit du modèle ECB-PTU-307. Cette centrale possède des entrées/sorties numériques et analogiques et peut être programmée en fonction des besoins à la manière d’un petit automate :

D’après ce que j’ai compris, la couche physique est du RS485. Le protocole semble être du « Bacnet » (je n’en avais jamais entendu parler auparavant).

Certaines variantes semblent également utiliser le protocole « Lonworks » qui m’est également inconnu. En effet, la sérigraphie sur le circuit imprimé des sondes fait référence aux deux. De plus, la centrale existe en version ECB-PTU pour Bacnet et ECL-PTU pour Lonworks.

Vous l’aurez deviné, mon but dans cette partie est de m’interfacer sur le bus. Dans un premier temps, une lecture seule pour récupérer la température de consigne et réelle de chaque pièce serait déjà intéressant. Dans un second temps et si cela possible, j’aimerais écrire sur le bus pour modifier les consignes et prendre la main sur le chauffage.

Le démontage de la centrale (pas facile au premier abord ! il y a une vis cachée sous l’autocollant en face avant à droite, en dessous du logo Distech Controls) donne quelques informations sur son fonctionnement :

On discerne bien les blocs d’alimentation, sorties relais, sorties triac, E/S petits signaux numériques et analogiques. Le microcontrôleur STM32F103 est sur une petite carte fille dédiée :

Le mot « Bacnet » est sérigraphié sur cette carte. Je suppose que la carte mère de la centrale est identique pour les versions Bacnet et Lonworks et que le protocole est défini par l’installation de l’une ou de l’autre carte fille. En effet, dans les deux cas la couche physique est une liaison RS485.

On trouve sur cette carte, en plus du microcontrôleur :

• Une mémoire flash sérigraphiée 25PE16VG de 16Mbits (2Mo). Elle est peut-être destinée à stocker le programme exécuté par l’automate, mais je suis surpris par sa capacité relativement importante.
• Un décodeur binaire vers BCD 74HC185 ??? je me demande bien ce qu’il peut faire là, j’ai peut-être mal lu la référence.
• Un transceiver RS485 ISL3172E accompagné de son pont de polarisation à 3 résistances et protégé par deux diodes TVS et deux fusibles.

Le bus descend jusqu’à la carte mère via les 4 broches mâles au pas de 2mm visibles en bas à droite de la première photo. Ensuite, les signaux sont routés sur des borniers à vis nommés NET+ et NET-.

Sous cette carte, on découvre un second circuit d’interface pour un autre bus RS485, entouré en rouge :

En plus gros plan :

Ce second circuit d’interface amène le bus sur le connecteur RJ45 des sondes de température. On y trouve, de gauche à droite, la même structure que sur la carte fille :

• Un fusible CMS pour chaque ligne
• Le pont de polarisation à 3 résistances entouré de deux diodes TVS
• Le transceiver RS485 ISL3172E

Ce transceiver est relié au STM32 via le connecteur débrochable 60 contacts. Je pensais initialement que le connecteur RJ45 et que les bornes NET+/NET- étaient deux moyens de se connecter sur le même bus mais non, il s’agit bien de deux bus distincts. Pour la suite, je vais donc me limiter à l’étude du bus donnant sur le RJ45 étant donné que c’est ici que les thermostats sont connectés.

Son brochage est le suivant (pour rappel, la broche 1 est celle de droite lorsque l’on regarde l’embase femelle de face) :

• 1 : (NC ?) Paire 1
• 2 : (NC ?) Paire 1
• 3 : Alim 15V Paire 2
• 4 : Masse Paire 3
• 5 : Alim 15V Paire 3
• 6 : Masse Paire 2
• 7 : RS485 D+ (B) Paire 4
• 8 : RS485 D- (A) Paire 4

En connectant un oscilloscope sur le bus, on trouve bien les signaux différentiels du RS485. Ici, visualisés sur le même calibre et la même position verticale :

Avec des positions horizontales différentes :

Je créé donc un petit circuit à base de de MAX485 afin de désymétriser la ligne. L’analyseur logique m’indique alors que je récupère un signal série asynchrone valide avec les paramètres suivants :

• 38400 bauds
• 8 bits de données
• parité paire

Plus qu’à les décoder et récupérer au passage les données qui m’intéressent !

L’analyse de la littérature

Je ne connais pas du tout Bacnet. Je me plonge dans des recherches afin de trouver la structure des trames. Il en ressort qu’elles devraient avoir ce format :

Le préambule est constitué de deux octets, 0x55 puis 0xFF. Je m’empresse de regarder sur l’analyseur logique ce que je reçois :

WTF ??

Aucun rapport avec ce que j’ai lu sur Internet. Essayer différents baudrates, LSB ou MSB en premier, inverser le signal n’y change rien. De plus, le préambule n’est pas constant : j’ai souvent 0x03 0x10, mais également 0x02 0x10 ou 0x03 0x03. Même en ignorant ce mauvais préambule, le reste de la trame n’est pas cohérent avec la structure d’un paquet Bacnet.

Pour info, j’ai essayé divers outil sur PC censés décoder les trames Bacnet. Evidemment, aucun n’a fonctionné. J’en suis donc ici, incapable de continuer. Si vous avez une idée lâchez vos com’s !