Domotique épisode 1 : présentation générale

Ceux qui me connaissent un peu se sont certainement rendus compte à quel point l’électronique et l’informatique embarquée me passionnent. En plus d’être mon travail quotidien, c’est aussi mon principal loisir.

Et forcément… Électronique + informatique + nouvel appart = domotique ! La peinture n’était même pas terminée que j’avais déjà certains équipements fonctionnels.

Je me suis installé il y a deux ans et demi, j’ai déjà réalisé pas mal de choses que je vais désormais présenter dans une série de billets mais heureusement j’ai encore beaucoup d’idées !

Je vais commencer par décrire comment j’ai matériellement mis cela en place. J’ai la chance d’habiter dans un appartement récent où sont centralisés le compteur et disjoncteur EDF, le tableau électrique ainsi que les réseaux de communication (câble et fibre optique pour la connexion à l’extérieur, liaison Ethernet dans chaque pièce). Il y a largement de quoi s’amuser !

Première étape : les volets roulants

La première chose que j’ai mise en place est le contrôle des volets roulants. Chacun d’eux est piloté par une télécommande radio sur la bande des 433MHz.

J’ai dès lors deux options pour émettre les signaux : soit m’interfacer sur la télécommande existante et simuler un appui sur le bouton, soit les émettre directement.

La seconde solution me paraît a priori la plus élégante, mais est plus complexe à mettre en place : les volets utilisent évidemment un système à code tournant afin qu’une personne mal intentionnée ne puisse pas facilement écouter les signaux légitimes pour les réémettre ensuite le moment venu. Pourtant, c’est exactement ce que j’aurais besoin de faire.

De plus, si la télécommande n’était plus utilisée régulièrement pour émettre les commandes, elle risquerait de se désynchroniser (cf. ici pour avoir quelques explications sur la raison). Cela est en contradiction avec une condition essentielle pour moi à tout système domotique : à tout instant, le système d’origine doit rester fonctionnel. La domotique ne doit être qu’un confort supplémentaire dont il est possible de se passer en cas de nécessité. Il est hors de question qu’un jour je ne puisse pas bouger mes volets si le serveur tombe en panne.

Pour cette raison, j’opte pour la première solution. La télécommande est alimentée par pile et ne dispose que d’un seul bouton poussoir : à chaque pression, le volet part dans la direction opposée au dernier mouvement. En cours de déplacement, une pression sur le bouton l’arrête. Ce fonctionnement est assez intuitif pour un humain mais complique un peu la gestion logicielle : je vais devoir mémoriser quel est le dernier mouvement réalisé par le volet. Si pour une raison quelconque une trame est loupée, le fonctionnement du volet sera alors inversé. J’aurais préféré avoir deux boutons distincts afin de lever l’ambigüité sur le sens de déplacement.

Je décide d’installer toutes les télécommandes sur une planche que je fixerai au dessus du compteur. J’installe donc les supports des 7 émetteurs :

Au niveau de chaque télécommande, je perce un trou pour insérer un connecteur 2 points HE14 récupéré sur d’anciens boîtiers de PC :

De l’autre côté de la planche, j’obtiens donc ceci :

Pour simplifier la connexion de ces 7 paires de fils à ma carte d’interface, je les connecte à un câble plat (en bleu clair) terminé par un connecteur RJ45. Comme ces derniers disposent de 8 conducteurs, j’ai un fil commun et 7 fils dédiés aux 7 télécommandes. Après avoir fixé les fils avec le scotch le plus moche qui me soit tombé sous la main, voilà le résultat :

Il reste alors à modifier les télécommandes. J’installe dans chacune un optocoupleur sur un petit morceau de veroboard, avec son transistor en parallèle du bouton. J’avais préalablement pris soin de vérifier que le Vcesat du transistor était suffisamment faible pour que le circuit de l’émetteur perçoive un appui sur le bouton lorsqu’il conduit. J’ai hésité à supprimer la pile pour la remplacer par une alimentation 3V apportée via deux broches supplémentaires. J’ai cependant écarté cette solution car a priori, la pile devait être dimensionnée par le fabricant pour durer « suffisamment longtemps ». De plus, domotique ou pas, leur fréquence d’utilisation devrait être similaire. Pour terminer, cela est en contradiction avec la règle énoncée ci-haut qui affirme que le système doit rester fonctionnel dans son état d’origine : en cas de panne sur mon alimentation, mes volets seront bloqués.

La partie matérielle des télécommandes est maintenant terminée. Il me reste à faire l’interface avec le serveur.

Seconde étape : le serveur

D’ailleurs, le serveur… qui est-ce ? Et bien, tout simplement une carte Orange Pi Zero. Je n’ai pas besoin de beaucoup de ressources, son rôle sera principalement de faire tourner :

• Un serveur Web, nginx, pour ma domotique.
• Partager les fichiers d’un ou deux disques durs externes sur le réseau via Samba.
• D’héberger une instance du logiciel Seafile.

Seafile est un logiciel open-source similaire à des solutions commerciales comme Dropbox ou Google Drive. La différence est que ces deux derniers sont hébergés sur des serveurs appartenant à leurs sociétés respectives, autrement dit, nous n’avons aucune idée de ce qu’ils peuvent faire des données que nous leur fournissons. Dans l’absolu, je ne suis pas extrémiste au point qu’utiliser leurs services pour échanger avec quelques amis des documents sans importance me dérange, mais je ne leur confierai pas n’importe quels fichiers. Ce sont pourtant ceux qu’il est très pratique d’avoir accès de n’importe où lorsque l’on en a besoin (papiers d’identité…).

La tâche la plus consommatrice de ressources est certainement cette dernière, mais les 4 coeurs de l’ARM Cortex A7 épaulés par 512Mo de mémoire vive s’en sortent plutôt bien. La seule limitation de l’usage de Seafile imputable aux ressources matérielles est le téléchargement à distance d’un répertoire lourd (> 100Mo) : le répertoire est préalablement compressé en fichier Zip et cette étape est LE gros point noir avec cette machine. Mais peu importe, je n’ai que très rarement besoin de cette fonctionnalité.

A l’inverse, la relative faible puissance de calcul se fait oublier lorsque l’on considère l’énergie nécessaire pour alimenter la carte : environ 0,5A sous 5V soit 2,5W. Ceci est un critère très important pour moi : de nos jours, beaucoup trop (et de plus en plus) d’appareils ont vu leur mise hors-tension remplacée par un mode veille. C’est facile à reconnaître : le gros interrupteur on/off est remplacé par un petit bouton poussoir. C’est joli, pratique et à la mode mais l’alimentation AC/DC en amont est donc en permanence sous tension. Et même à vide, elle consomme. Au final, nos foyers dépensent inutilement beaucoup d’énergie par ce biais. Bref, tout cela pour dire que je fais attention à la consommation d’énergie du matériel branché H24 sur le secteur et le serveur n’y fait pas exception.

Lorsque j’utilise une carte de ce type, je n’utilise jamais directement ses entrées-sorties : je préfère fabriquer une interface intermédiaire qui se connecte au SBC via USB. Ainsi, pour faire évoluer le système, je ne suis pas contraint de choisir une nouvelle carte qui dispose du même nombre et types d’entrées-sorties : seul un port USB est nécessaire. De plus, les librairies pour utiliser les E/S des cartes sont souvent assez bas niveau et dépendantes du matériel. Pourtant, je ne souhaite pas avoir à modifier mon code lors d’une évolution de machine.

Comme j’envisage de mettre des transformateurs d’intensité en différents points de mon tableau électrique pour mesurer séparément l’énergie consommée par les différents usages domestiques : cuisine, prises de courant, éclairage… il me faut un microcontrôleur secondé par un FPU. En effet, il faut intégrer le produit du courant par la tension secteur plusieurs centaines de fois par seconde pour obtenir l’énergie. Je récupère donc une carte Nucleo F401RE qui communiquera avec l’Orange Pi grâce à leurs UARTs.

J’installe ces deux cartes sur un morceau de Veroboard. Je monte également un convertisseur DC/DC pour alimenter l’Orange Pi en 5V à partir du bloc d’alim 12V de ma box : en me repiquant sur une alimentation basse tension DC existante non utilisée au maximum de sa puissance, je gagne en rendement par rapport à l’usage d’un bloc secteur supplémentaire.

On voit donc en bas à droite un convertisseur DC/DC à base de LM2576. L’alimentation en 12V se fait par le bornier débrochable vert. La carte Nucléo a été séparée de sa partie ST-Link pour des raisons d’encombrement, cette dernière partie se retrouve en bas. L’Orange Pi est située au dessus de la Nucléo. Pour terminer, on trouve deux connecteurs RJ45 à droite :

• Celui dénommé « VR » permet de connecter les télécommandes des volets roulants grâce à réalisation précédente.
• Celui noté « EDF » relie la carte d’interface au tableau électrique.

J’ai utilisé pendant un peu moins d’un an l’Orange Pi, qui m’a donné entièrement satisfaction… jusqu’au jour où j’ai récupéré la carte mère X86 d’un PC de bureau tout-en-un. La consommation électrique est certes bien plus grande (environ 15W) mais la puissance de calcul est absolument incomparable. J’ai malheureusement détruit cette carte mère quelques jours plus tard à cause d’un malheureuse mauvaise manipulation, évidemment lorsqu’elle était sous tension. Trop tard, le mal est fait : les performances de l’Orange Pi me semblent désormais minables après avoir goûté au réseau Gigabit et aux disques durs connectés en USB 3. De plus, la fiabilité d’un SSD face à une carte SD est également sans pareille.

Je craque alors sur un mini-PC Zotac CI320 nano d’occasion équipé d’un SSD de 64Go et de 4Go de mémoire vive. Il s’alimente sous 19V et consomme entre 500 et 700mA suivant les ressources système demandées, en comptant ma carte d’interface et deux disques durs 2,5″. Son bloc secteur peut délivrer 2A, aussi je recycle le convertisseur DC/DC de la carte pour générer du 12V pour la box à partir de l’alim 19V du PC. Grâce au fait de ne pas avoir utilisé les GPIO de l’Orange Pi, même si le passage à une architecture X86 n’était pas du tout envisagé à l’époque, il me suffit d’utiliser un convertisseur USB/série pour communiquer avec la carte d’interface. J’utilise celui intégré dans le ST Link.

Troisième étape : l’assemblage des deux premières

Bon, ces photos sont un peu anachroniques car au moment où j’ai assemblé pour la première fois les télécommandes modifiées à la carte d’interface, le chef d’orchestre était évidemment l’Orange Pi. Je n’ai malheureusement pas pris de photos à l’époque, c’est pourquoi le Zotac apparaît :

On remarque aux côtés du mini-PC et de la carte d’interface deux disques durs 2,5″. L’un, de 4To, stocke les fichiers hébergés sur Seafile. L’autre, de 1To, contient divers documents qui n’ont pas besoin d’être disponibles de n’importe où.

Je parlerai plus tard de la petite carte en bas. Je l’ai installée que bien après. Le blindage métallique et le connecteur SMA font penser à un module radio. Mais à quoi peut-il bien servir ??? Il a l’air de porter loin !

Quatrième étape : le logiciel

Et oui, il faut bien un logiciel pour animer ces équipements. J’écris un programme en C démarré dans un screen au démarrage du système Debian. Je réalise également une interface Web servie par nginx qui fait office d’interface homme-machine. Les deux communiquent grâce à des fichiers texte déposés dans un ramdisk pour limiter le nombre de cycles d’écriture sur le SSD.

Globalement, le fonctionnement est le suivant :

• Un fichier texte par volet contient sa position d’actuelle, en pourcentage de fermeture (0% = ouvert, 100% = fermé) ainsi que le type de dernier mouvement (montée ou descente). Ces fichiers sont stockés sur le SSD car la position courante des volets doit être conservée lors d’un redémarrage.

• L’interface Web lit ces fichiers pour afficher leur état actuel. Lors d’une demande de déplacement, elle créé un fichier dans le ramdisk contenant la nouvelle position demandée.

• Le programme en C scrute en permanence l’existence de ce fichier. Lorsqu’il en détecte un, il le lit puis le supprime, ce qui signifie qu’il l’a pris en compte. Il compare alors la position demandée à la position actuelle et calcule pendant combien de temps le volets doit se déplacer (il n’y a bien sûr aucun moyen d’avoir un retour sur la position réelle des volets, la position est estimée grâce à la durée du mouvement).

• Suivant le sens de déplacement nécessaire, il faut soit appuyer une fois sur la télécommande (si le sens du dernier mouvement est opposé au sens du mouvement à réaliser), soit trois fois (dans le cas contraire).

• Lorsque le programme est en train de déplacer un volet, il créé à son tour un fichier texte dans le ramdisk indiquant que ce volet est occupé. Cela engendre la désactivation des boutons sur l’interface Web, signifiant que le volet est en mouvement et qu’il n’est plus possible de le contrôler pour l’instant.

• Si le volet ne doit pas être complètement ouvert ou complètement fermé, un autre appui sur la télécommande est généré pour l’arrêter après la durée calculée.

Un système de file d’attente est créé si plusieurs volets demandent à être pilotés simultanément (par exemple, si on demande une ouverture ou fermeture simultanée de la totalité des volets de l’appartement). En effet, une seule télécommande doit émettre à la fois, sans quoi les signaux radio seraient brouillés. Le programme vérifie donc à tout instant que cette condition est vérifiée. Si plusieurs volets demandent à être déplacés en même temps, un ordonnancement est généré afin qu’il n’y ait pas de collision non seulement pour l’émission de la commande initiale mais également pour l’envoi de la commande d’arrêt.

L’interface Web ressemble à ceci :

Pour terminer : la mesure de la consommation électrique

Comme indiqué plus haut, j’aimerais non seulement mesurer la quantité d’énergie consommée par mon appartement, mais également avoir sa répartition en fonction des différents usages. Le plus simple serait d’installer des compteurs sur rail DIN dédiés à cet usage : ils donnent une impulsion à chaque unité d’énergie consommée. Malheureusement je n’ai pas suffisamment de place dans mon tableau. De plus, je n’ai pas envie d’investir là-dedans (car soyons honnêtes : c’est fun mais ça ne sert fondamentalement pas à grand-chose).

Je vais donc certainement me tourner vers des transformateurs d’intensité, beaucoup moins onéreux et moins encombrants. L’inconvénient est que cela me demande plus de travail, matériellement (interface analogique à fabriquer) comme logiciellement (intégration mathématique de la puissance à programmer). Du coup, c’est pour plus tard.

Cependant, je peux déjà très facilement me connecter sur la sortie de télé-information client (TIC) de mon compteur, qui est à proximité. Je possède un compteur Sagem –documentation ci-dessous– qui, comme à ma connaissance tous les compteurs antérieurs au Linky, ont leur sortie TIC désactivée par défaut. Il faut faire venir un technicien sur place pour l’activer, pour ma part je lui en ai fait la demande lorsqu’il est venu mettre en service mon compteur.

Le protocole de communication de la sortie TIC est décrit à partir de la page 14 et beaucoup de sites en parlent, je ne vais donc pas m’étendre sur le sujet. En gros, c’est une liaison série asynchrone à 1200 bauds, parité paire, 7 bits de données et 1 bit de stop modulée en amplitude à 50kHz.

Dans la foulée, je m’interface donc au compteur : la sortie TIC est redressée par un pont de diode et attaque un optocoupleur lent type 4N25. Incapable de suivre la fréquence de la porteuse à 50kHz, il en ressort un signal démodulé ! Elle n’est pas belle la vie ?

Zoom sur les fronts montant et descendant du signal démodulé :

Ce signal démodulé arrive sur un UART du STM32 qui décode les trames. Malheureusement et aussi absurde que cela puisse paraître pour un compteur d’énergie, la puissance active instantanée n’est pas disponible (pourtant elle est forcément calculée par le compteur, puisque c’est elle qui est facturée pour les particuliers). Seule la puissance apparente l’est. Pourtant, c’est une information que je souhaite connaître. Heureusement, l’index de consommation est disponible sur la sortie TIC avec une résolution de 1Wh (au lieu de 1kWh sur l’écran du compteur). Les trames étant rafraîchies plusieurs fois par seconde, il suffit de compter le temps écoulé entre deux incrémentations de l’index. Il est alors aisé de remonter à la puissance absorbée.

Là-encore, l’archivage de la consommation est réalisé par le programme en C et l’affichage réalisé par l’interface Web. Voici le résultat obtenu :

Pour l’anecdote et au cas où cela puisse servir à quelqu’un, j’ai constaté lors du remplacement de mon compteur par un Linky que la sortie téléinfo était devenue muette. La sortie TIC du Linky, à la différence des compteurs antérieurs, étant active par défaut, j’ai dû chercher ailleurs le problème. Il s’avère que l’amplitude du signal du Linky est moindre que celle de mon compteur précédent. Or, j’avais mis en série avec la LED de l’optocoupleur une LED verte afin d’avoir un retour visuel sur l’émission des trames. Il fallait donc au moins 1V (Vf de la LED IR de l’opto) + 2V (Vf de la LED verte) + 2*0,6V (Vf du pont redresseur) = 4,2V crête pour faire conduire toutes ces diodes. Le Linky délivrant une tension inférieure, j’ai supprimé la LED verte. La sortie est limitée à un courant compatible avec les diodes, ce qui explique l’absence de résistance de limitation de courant.

C’est tout pour le moment ! Merci de m’avoir lu.