Pour faire court : si des problèmes sont rencontrés lors de la compilation du code source de mochad ou si la passerelle ne s'exécute pas à cause d'une erreur de type usb_claim_interface failed -6, alors essayez d'installer ma version qui est dans un référentiel GitHub : https://github.com/sigmdel/mochad. Si vous souhaitez simplement obtenir une installation fonctionnelle de mochad, le référentiel contient toutes les informations pertinentes et il n'est pas nécessaire de lire ce qui suit. Toutefois, si l'on désire les instructions d'installation en français on peut lire les deux dernières sections ci-dessous.

Table des matières

1. Le contexte
2. Des mises à jour qui cassent les choses
3. C'est un peu le bazar
4. Installation de sigmdel/mochad
5. Verification du fonctionnement de mochad

Le contexte

Mochad est une passerelle entre un contrôleur X10 (modèles CM15A, CM15A Pro ou CM19A) et des ordinateurs du réseau local utilisant le protocole TCP. Écrit en C, il a été téléversé sur SourceForge le 8 décembre 2010 par mmauka, qui pourrait être le sobriquet de Brian Uechi.

J'ai utilisé mochad depuis 2016 (voir Domespic [3] Gateways) jusqu'à il y a environ trois semaines, lorsque mon système domotique a été déplacé vers un nouveau serveur et que tout le matériel X10 a été supprimé. Parce que la combinaison d'un émetteur-récepteur PC USB CM19A et d'une télécommande PalmPad HR12A est un moyen simple et direct de contrôler les appareils IdO que tous maîtrisent intuitivement, je voulais le transmettre à quelqu'un sur le point de mettre en place un système domotique. Cela nécessitait une installation de mochad sur un ordinateur monocarte exécutant une distribution récente de Linux basée sur Ubuntu 22.04 pour ARM 64 bits d'Armbian. J'ai été déconcerté lorsque l'installation a échoué pour la première fois au cours des six dernières années pendant lesquelles mocha a été utilisé avec de nombreuses images Linux sur au moins quatre ordinateurs monocartes différents.

Un certain nombre de problèmes ont été rencontrés. Tout d'abord, le script de configuration a démarré avec un message inquiétant.

Ensuite, la construction a échoué avec les messages suivants, qui ont été répétés plusieurs fois.

Pensant, à tort s'est-il avéré, que le script configure obsolète était peut-être à l'origine de cette erreur, j'ai recherché une version mise à jour de mochad. Cela a donné un référentiel sur GitHub par Boris Jonica (bjonica) qui a commencé comme une fourche de la version 0.1.12 de mochad sur SourceForge. Quelques mois plus tard, Nicholas Humfrey (njh) a apporté une contribution significative qui a supprimé le script configure et l'a remplacé par un script autogen qui génère un script configure. Cette modification n'a pas été incorporée par mmauka dans le référentiel SourceForge. En revanche, les modifications apportées par mmauka jusqu'à la version 0.1.17 ont été pour la plupart intégrées au référentiel GitHub, mais pas tous comme on le verra. Parmi les fourches du référentiel bjonica, il y en a une de Neil Cherry (linuxha) bien connu pour son site Linux Home Automation. Il a ajouté la prise en charge facultative d'IPV6 et a fait passer le numéro de version à 0.1.18. J'ai décidé d'essayer cette version qu'on trouve ici : https://github.com/linuxha/mochad.

Cette fois-ci, la configuration s'est déroulée sans faille, mais les erreurs de l'éditeur de liens sont restées. Heureusement, cela a été facile à résoudre, car j'avais rencontré ce type de problème à plusieurs reprises dans mes petits projets pour microcontrôleurs. Déclarer les variables définies plusieurs fois comme étant de type extern dans global.h et définir PollTimeOut dans global.c était tout ce qu'il fallait faire. Avec ce changement, le binaire mochad a été créé sans erreur et il a fonctionné comme prévu lorsqu'il a été lancé manuellement. Cependant, lorsque le démon était lancé par la règle udev ajoutée lors du processus d'installation, il s'arrêtait presque immédiatement avec le message d'erreur suivant.

C'était du déjà vu, car ce problème avait été la motivation pour utiliser la version 0.1.17 en 2016. Une petite enquête a montré que tous les changements apportés à la version 0.1.17 par mmauka n'avaient pas été ajoutés dans les fourches sur GitHub. C'était surprenant, car le journal des modifications était explicite sur ce que la nouvelle version avait ajouté.

Par conséquent, il était logique d'ajouter ces corrections introduites dans la version 0.1.17, car je soupçonne que mochad est le plus souvent installaé dans des système Linux avec systemd comme programme d'initialisation. Cela a également nécessité une légère modification du fichier Makefile.am. En fin de compte, la version de mochad.service utilisée provient du message d'Andreas datant de 2021-09-07 et intitulé mochad gets usb_claim_interface failed - udev rule au motif que le fichier d'unité me semble plus sophistiqué... mais après tout, qu'est-ce que j'en sais?

Par souci d'exactitude historique, ajoutons que la source du problème usb_claim_interface failed -6 sous systemd a été identifiée par Vicente en 2016-04-07. Patrick Kuijvenhoven (petski) a fourni un fichier mochad.service fonctionnel en 2016-04-15 dans une fourche sur GitHub du code sur SourceForge. Le référentiel de petski est indépendant de la hiérarchie bjonica. Il n'y avait pas de règles udev, d'ailleurs le message de petski SourceForge daté de 2016-04-15 contient la suppression de la règle udev précédente. Vraisemblablement, petski envisageait que le fichier de service devait être lancé manuellement ou activé pour charger le démon automatiquement au démarrage.

Des mises à jour qui cassent les choses

Pourquoi l'éditeur de liens signalait-il des erreurs dans la version 0.1.17 lors de la compilation du projet quand le système d'exploitation était Armbian ou la plus récente version de Raspberry Pi OS, mais pas sous Mint 20.1 qui est relativement récent ? Pourquoi personne n'avait-il signalé ce problème ? Pour ce qui est des erreurs de construction, cela a à voir avec la version du paquet build-essential et plus précisément avec la version de l'éditeur de liens, ld qu'il contient et peut-être la version du compilateur gcc.

J'avais tort de dire que l'erreur de compilation n'était mentionnée nulle part. Non seulement Steve Porter a signalé le problème le 5 février 2022 sur le forum de discussion mochad dans un article intitulé Rasberry PI compile errors, mais il a également fourni une solution basée sur la version originale 0.1.17. Sa solution est différente de la mienne et une preuve qu'il y a toujours plus d'une façon de faire quoi que ce soit.

C'est un peu le bazar

Après toutes ces années, SourceForge présente toujours la version 0.1.16 de mochad comme étant la plus récente. Cette vieille version n'est pas compatible avec systemd laquelle est probablement utilisée sur la majorité des ordinateurs Linux sur lesquels mochad sera exécutée. C'était aux utilisateurs de trouver la version 0.1.17, ce qui est dommage, car je pense que la version 0.1.17 est aussi compatible avec les distributions de Linux qui n'utilisent pas systemd. Mais maintenant, même si la version 0.1.17 est utilisée, elle ne se compilera plus sur les distributions plus récentes.

Comme moi, certains chercheront probablement sur GitHub une version mise à jour du code. Ils trouveront de nombreuses fourches "uniques" dont aucune ne fonctionnera avec les derniers outils de construction. Voici quelques-unes que j'ai trouvées.

• enishoca/mochad : clone de 0.1.17
• ermshiperete/mochad : clone de 0.1.17 avec fichier mochad.service amélioré
• alilloig/mochad : clone de 0.1.16
• amuelson/mochad : clone de 0.1.16
• mochad-0.1.16 : clone 0.1.16

Comme déjà mentionné, Patrick Kuijvenhoven a crée une fourche (petski/mochad) basée sur la version 0.1.16 et y a ajouté un fichier mochad.service et les règles udev correspondantes avant que la version 0.1.17 ne soit mise en place par mmauka. Patrick a également contribué un fichier docker-compose.yml. Il existe deux fourches de cette version de mochad, mais elles n'apportent rien de nouveau.

Également mentionné précédemment, il existe le référentiel bjonica/mochad dans GitHub et ses nombreuses fourches. Comme indiqué, aucun de celles-ci (sauf la mienne) ne fonctionnera avec systemd, mais en revanche elles ont un système de configuration plus récent. Après un examen rapide de ces fourches, la plus intéressante est celle de Neil Cherry, linuxha/mochad, qui ajoute la prise en charge facultative d'IPV6. Il s'agit de la version 0.1.18 de mochad et c'est cette version que j'ai modifiée.

Steve Porter laisse entendre qu'il existe peut-être une version 0.1.19, mais je ne l'ai pas trouvée. Il n'y a même pas un murmure d'une version 0.1.20.

Cette profusion de fourches serait probablement déroutante pour quiconque voulant utiliser mochad pour la première fois. La conclusion de tout cela semble donc être que pour la plupart des utilisateurs, soit

• Version 0.1.21 de mochad par Steve Porter

• ma version of mochad

est le meilleur choix.

Si le support IPV6 et la compatibilité avec systemd sont nécessaires, ma version est actuellement le seul choix. Notez que par défaut, IPV6 n'est pas activé tant que la valeur de la macro IPV6 au tout début de mochad.c n'est pas modifiée de 0 à 1.

Je n'utilise pas IPV6 et je n'ai pas du tout testé ce code. Toute question concernant cette fonctionnalité doit être adressée à son auteur, Neil Cherry.

Installation de sigmdel/mochad

Cette section est une traduction de la section Installation of mochad du référentiel.

Puisque mochad utilise la bibliothèque libusb-1.0, il faut ajouter le paquet de développement pour celle-ci.

Avec la plus récente version serveur de Raspberry Pi OS Lite il était nécessaire d'installer un outil de configuration.

Ceci n'était pas nécessaire pour les deux autres images de Linux testées, mais cette commande n'entraîne aucune conséquence négative quand autoconf est déjà installé.

Sans être strictement nécessaire, netcat est utile pour tester mochad. Ce logiciel était en place sur les deux autres plates-formes, mais il a fallu l'ajouter dans le Raspberry Pi.

On peut obtenir la source du référentiel sur GitHub de plusieurs façon dont le clonage.

Si git n'est pas disponible, on peut simplement télécharger une archive de la plus récente version.

Si le support IPV6 doit être utilisé la valeur de la macro IPV6 au tout début de mochad.c doit être modifiée.

La configuration puis la compilation sont lancées depuis le répertoire contenant la source (d'où les commandes cd ci-dessus. Avant il faut s'assurer que autogen.sh est un script exécutable, ce qui devrait être le cas. De toute façon la première commande est inoffensive.

Enfin, on peut procéder à l'installation.

Encore une fois, cette commande doit être lancée depuis le répertoire source.

Voici les fichiers installés.

Si systemd est en place alors le fichier de service est aussi ajouté.

Il ne faut pas activer ce fichier; les règles udev s'en chargeront si un contrôleur X10 est branché.

Maintenant que l'installation est complète, tous les fichiers téléchargés ainsi que le répertoire source peuvent être éliminés.

Verification du fonctionnement de mochad

On peut essayer sudo udevadm control --reload, mais je préfère redémarrer le système pour être certain que les règles udev soient mise à jour. C'est instructif de faire cela avant de brancher l'adaptateur X10 au Pi.

Le service est inactif, car aucun contrôleur radio de X10 n'a été trouvé. Branchez soit le CM15A ou le CM19A, puis examinez à nouveau le statut du service mochad.

Le service est correctement activé, et l'on peut alors tester avec netcat si ce programme a été installé. Il affichera des messages identifiant la touche activée du PalmPilot.

Il se peut que le test montre que mochad ne fonctionne pas. Si systemctl affiche l'erreur suivante,

alors l'erreur peut provenir d'un conflit avec le module ati_remote. Ce dernier prend en charge la télécommande Lola pour la carte vidéo ATI All-In-Wonder. Cette télécommande et le CM19A ont le même numéro d'identité USB: 0x0bc7:0x002. Il s'ensuit que le module ati_remote est chargé et prend contrôle du port USB auquel le CM19A est branché avant que mochad puisse obtenir accès au même port. On peut facilement vérifier si ati_remote est activé.

Ajouter le module à la liste noire bloque son chargement et règle le problème.

Essayer de décharger le module avec la commande sudo modprobe -r ati_remote ne fonctionne pas. Je n'ai pas essayé en rajoutant le paramètre -f pour forcer le déchargement. De toute façon, il s'agit là de mesures temporaires et si l'on veut se servir de mochad, il faut une solution permanente qu'on obtient avec l'inscription du module à la liste noire.