Presentation
rPilote est une interface pour Raspberry Pi permettant de contrôler deux circuits de chauffage électrique disposant d’un fil pilote 4 ou 6 ordres.
Note: This project is documented in French because to the best of my knowledge, the electric heater control system described herein (known as “fil pilote” or “protocole GIFAM”) and on which this project is based is only found in France. Should evidence to the contrary arise, I will happily translate this page to English :)
Licence
- La partie matérielle (y compris le firmware) de ce projet est publiée sous licence Creative Commons BY-NC-SA (“NC” pour Non-Commercial).
- La partie logicielle (à l’exclusion du firmware) de ce projet est publiée sous licence GPLv2
Avertissement
Les informations et méthodes ici décrites sont fournies “telles-quelles” SANS GARANTIE D’AUCUNE SORTE, IMPLICITE OU EXPLICITE. L’utilisation des concepts, examples et informations se fait à vos risques et périls. Il peut y avoir des erreurs ou des imprécisions qui pourrait endommager vos appareils. Procédez avec prudence, et bien qu’il soit très improbable que des accidents surviennent en suivant les avis ou procédures décrites dans ce document, l’auteur n’endosse aucune responsabilité pour tout dommage prétendument causé en ce faisant.
Par ailleurs, ce montage étant raccordé au secteur, je rajoute l’avertissement suivant:
SOYEZ EXTRÊMEMENT PRUDENT : DES TENSIONS POTENTIELLEMENT MORTELLES SONT PRÉSENTES SUR CE MONTAGE LORSQU'IL EST UTILISÉ.
Objectifs
Les objectifs principaux de ce projets sont :
- L’appareil doit être sûr, simple et fiable
- L’appareil doit pouvoir gérer indépendamment 2 fils pilotes
- L’appareil doit assurer un basculement automatique dans un état connu (“Hors-Gel”) en cas de défaillance du Raspberry Pi
- L’appareil doit être économique (en pièces et en énergie consommée)
- Le système doit être facile à assembler et à programmer
L’idée sous-jacente est de permettre à un Raspberry Pi de contrôler 2 fils pilotes via GPIO.
L’essentiel de “l’intelligence” du système est donc déportée sur le Raspberry Pi, l’interface se limitant purement à son rôle (d’interface) tout en assurant la sécurité électrique et logique du système (notamment par la garantie du retour au Hors-Gel en cas de panne du Raspberry Pi).
Schéma
Voici le schéma du design actuel :
Explication du schéma
Le schéma est relativement simple : sachant que les ordres du fil pilote sont générés par l’assemblage des deux demi-alternances du 220V et que l’intensité maximale admise sur le fil pilote est de 100 mA, on utilise pour chaque fil pilote commandé (le schéma est symétrique) 2 optotriacs MOC3023M pour contrôler chacune des demi-alternances générées par une simple diode 1N4004. Il s’agit d’optotriacs à phase aléatoire : en effet, il n’est pas nécessaire d’utiliser la version à détection de zéro puisque la “charge” (selon toute probabilité une entrée logique ou la Gate d’un autre triac, d’impédance élevée donc) est insensible à la phase lors de la mise sous tension. Le fusible inséré sur le fil de phase est une mesure de sécurité indispensable en cas de problème (court-circuit ou autre).
La partie basse tension du circuit fait appel à un PIC12F508 dont le rôle consiste à assurer l’état de démarrage du système, le basculement automatique en cas de défaillance, le contrôle des optotriacs et l’indication d’état (via DELs). L’interfaçage entre le PIC et le Raspberry Pi se fait au moyen de 2 GPIOs utilisés suivant la technique du bit banging, l’un servant d’horloge et l’autre de données. Pour simplifier le système, la communication est uni-directionnelle (du rPi vers le PIC).
Il est a noter que le PIC ainsi que le reste du circuit est alimenté sur le +5V en provenance du Raspberry Pi, afin de ne pas surcharger l’alimentation +3.3V, celle-ci n’étant pas capable de délivrer un courant important, en particulier sur les premières versions de Raspberry Pi. Bien que les GPIOs de ce dernier aient pour référence +3.3V à l’état logique haut, le circuit fonctionne sans problème : en effet, les entrées du PIC suivent les niveaux logiques TTL et peuvent donc fonctionner dans cette configuration.
La consommation électrique de l’ensemble est réduite au strict minimum (environ 100mW) puisque ce montage est censé rester sous tension en permanence, du moins pendant la saison de chauffe. Ceci explique l’utilisation de la version 3023 de l’optotriac, qui garantit le bon fonctionnement du circuit avec de très faibles courants de contrôle. De même la valeur des résistances des anodes des DELs bicolores est également choisie afin de réduire au maximum la consommation de celles-ci, tout en préservant leur “lisibilité”.
La DEL bicolore de chaque circuit fournit des informations sur le mode de chauffe actuel du circuit concerné. Avec une DEL verte/rouge, on obtient le code couleur suivant:
- Rouge : Délestage
- Vert : Hors-Gel
- Orange : Eco
- Éteint : Confort
En cas d’utilisation des modes “Confort -1°C” et “Confort -2°C”, on obtiendra un clignotement lent de couleur orange correspondant à la période de ces deux ordres.
Nota : L’alimentation de chaque fil pilote (via L1, L2) devra se faire depuis le même interrupteur différentiel que celle des radiateurs commandés, sous peine de risquer un déclenchement de celui-ci.
Modularité
Le schéma proposé étant constitué de deux moitiés identiques, il est tout à fait possible de n’implémenter qu’un unique circuit de contrôle en supprimant l’autre moitié.
Implémentation
Voici une implémentation du schéma en composants traversants sur un PCB de 50 x 46 mm (avec un PCB assemblé pour illustration) :
La liste des composants se trouve ici.
Le guide d’assemblage se trouve ici.
Cette implémentation se veut efficace et élégante (oui j’aime la symétrie ;-) : le routage proposé sépare clairement la partie 220V de la partie contrôle, pour d’évidentes raisons de sécurité. Le schéma étant très simple, le choix du simple-face permet de réduire encore le coût du système en simplifiant sa fabrication.
L'ensemble des composants situés sous la ligne pointillée est directement raccordé au 220V secteur : DANGER !
Logiciel
Firmware PIC
Ce système s’appuie sur un firmware développé spécifiquement pour cette application. Le fichier source, très simple, est commenté ; les objectifs poursuivis sont les suivants :
- Définition d’un état d’initialisation connu (Hors-Gel)
- Retour à l’état d’initialisation en cas de défaillance du Raspberry Pi (via Watchdog)
- Protocole de communcation simple (avec le Raspberry Pi)
Le PIC se cantonnant à son rôle de pure interface (avec une touche de logique pour la sécurité en cas de panne), l’ensemble des 6 ordres du protocole GIFAM est techniquement utilisable, puisque la génération des ordres est in fine dévolue au logiciel s’exécutant sur Raspberry Pi. Ce montage, bien que simple, est donc très versatile.
Le PIC reçoit une série de 6 bits via une simple interface de type bit bang unidirectionnel, avec une ligne d’horloge et une ligne de données. Les bits 5-4 et 1-0 correspondent respectivement à l’état logique des pins GP5-GP4 et GP1-GP0 du PIC. Les bits 3-2 sont ignorés.
Si aucune transmission n’est reçue (ou si une transmission partielle a lieu) en moins d’environ 2 secondes, le Watchdog Timer se déclenche et reset le PIC à son état de départ (garantissant la mise en route du Hors-Gel en cas de problème). Aucun contrôle de l’intégrité des données transférées n’est effectué, le système fonctionne parfaitement pourvu que la vitesse de transmission reste raisonnable.
Fichiers firmware
La version actuelle est v1
- main.asm - fichier source
- main.hex - fichier binaire prêt à flasher (md5:
0360c4b20e19c55a204956324b11c912)
Logiciel côté Raspberry Pi
Côté Raspberry Pi, un démon est proposé. En effet, le rPilote doit être mis à jour constamment puisque par sécurité, en l’absence de nouvelle commande toute les 2 secondes environ, il retourne à l’état par défaut (hors-gel).
Pour simplifier l’interfaçage avec tout type de système de commande, le démon (dont le code est abondamment commenté) initialise l’interface GPIO, puis crée un thread haute priorité qui met à jour le rPilote toutes les secondes environ. Le démon se connecte au bus système du démon D-Bus du Raspberry Pi, et propose deux méthodes d’accès : l’une pour interroger l’état d’un des deux canaux de fil pilote, l’autre pour sélectionner un nouvel état pour l’un de ces canaux.
Ce choix permet de contrôler le rPilote facilement depuis pratiquement n’importe quel type de programme, de l’interface web (par exemple CGI, voir plus bas) à l’application dédiée.
Le démon proposé ici, codé en C, est à l’état de “preuve de concept” mais fonctionne correctement et gère les 6 ordres du protocole. Cependant, il n’a pas été prévu de mécanisme protégeant contre les abus (“déni de service”).
Un client web CGI très basique est également proposé, permettant de contrôler rpiloted via un simple navigateur web. Ce module est codé en Python.
Fichiers démon rpiloted
La version actuelle est 0.2
Fichiers application web
Photo d’un montage complet
Dans une boîte en plexi transparent :
