Typiquement, ce sont les projets qui aboutissent bien qui se méritent un billet sur mon site. On pourrait conclure incorrectement que je réussis tout ce que j'entreprends alors que c'est loin d'être le cas. Même des projets qui me semblaient complétés avec succès ne fonctionnent pas toujours comme je voudrais. Voici une liste de problème que j'ai rencontré dernièrement.

Table des matières

1. lighttpd avec Rasbian Stretch
2. Le Sonoff hanté
3. Pannes de courant et les Sonoff
4. mDNS et TASMOTA
5. Chromecast Audio
6. DNS dynamique (2019-01-14)

lighttpd avec Raspbian Stretch

Le 4 août dernier, j'ai indiqué que je n'arrivais pas à sécuriser le flux vidéo provenant de MPJG-Streamer à l'aide d'un serveur proxy Lighttpd dans la plus récente version de Raspian Stretch. Je n'ai toujours pas trouvé la solution, mais il y a trois pistes à examiner.

1. La version de lighttpd qu'on obtient du dépôt de paquets pour Debian Stretch est 1.4.45-1 alors que celle qui était installée avec Raspian Jessie était 1.4.35-4+deb8u1. On obtient cette information soit ici, soit avec la commande apt-cache policy.
   pi@domo:~ $ apt-cache policy lighttpd lighttpd: Installed: 1.4.35-4+deb8u1 Candidate: 1.4.35-4+deb8u1 Version table: *** 1.4.35-4+deb8u1 0 500 http://mirrordirector.raspbian.org/raspbian/ jessie/main armhf Packages 100 /var/lib/dpkg/status

   Je pourrais installer la vieille version de lighttpd sur Stretch pour voir si elle fonctionne.

2. En même temps que j'installais le serveur proxy dans Lighttpd 1.4.35-4, j'ajoutais le serveur OpenVPN (version 2.3.4-5+deb8u2) sur le Raspberry Pi. Il se peut que cette installation ait inclus une bibliothèque nécessaire ou qu'elle ait modifié la configuration du système de telle sorte que Lighttpd pouvait acheminer le flux vidéo de MPJG-Streamer de façon sécurisée. Ce n'est pas très probable, mais on ne sait jamais.


3. Enfin, je pourrais recommencer mes recherches sur le Web pour trouver la façon de mettre en place un serveur proxy avec la nouvelle version de Lighttpd. Cela m'avait demandé beaucoup de recherche pour apprendre comment le faire auparavant. Avec le temps, il se peut que quelqu'un ait mis à jour l'information à ce sujet.

Rien de tout cela n'est pas une priorité actuellement. En effet, je continue d'utiliser Raspian Jessie sur le Raspberry Pi qui abrite mon système de domotique basé sur une vieille version de Domoticz comme expliqué dans le billet du 11 avril 2018 (mis à jour le 23 avril) Webcam en streaming sécurisé avec MJPG-Streamer sur un Raspberry Pi.

Le Sonoff hanté

Je voulais intitulé cette section le Fantôme dans le machin en calquant le titre du livre de Arthur Koestler, The Ghost in the Machine, que j'ai lue il y a de très nombreuses années. Or la traduction en français de l'ouvrage a un titre, Le Cheval dans la locomotive, qui s'éloigne trop du problème dont il sera question ci-dessous. Fouillant un peu plus, j'ai appris que le fantôme dans la machine est effectivement la traduction de l'expression the ghost in the machine quand elle désigne le dualisme de l'esprit et du corps chez Descartes. Elle vient d'un philosophe anglais, Gilbert Ryle, que je ne connais pas. Jamais trop tard pour s'instruire un peu.

Le spectre qui me trouble allume et éteint de façon aléatoire l'un ou l'autre de deux Sonoff qui contrôlent une paire de lampes de chevet. Ce ne devrait pas être trop surprenant, car vraisemblablement les quatre fils dans le câble de téléphone d'un mètre de longueur entre les boutons et chaque Sonoff sont en parallèle et sans blindage. Avec le câble CAT5 de plus de deux mètres qui relie les deux Sonoff, le tout constitue une bonne antenne capable de transmettre tout parasite provenant de plusieurs sources à proximité.

1. Il y a évidemment le secteur (120V à 60 Herz) qui alimente les lampes et les Sonoff. De plus, une des lampes à un très long fil conducteur que j'ai simplement enroulé plutôt que le raccourcir. De plus, il est proche d'un des Sonoff, donc des câbles mentionnés ci-dessus.
2. Il y a un réveil matin avec affichage DEL et radio AM-FM incorporé sur l'une des table de chevet. C'était le modèle le moins cher qui était disponible dans une grande surface lorsque je l'ai acheté; la protection contre les émissions radio n'est certainement pas une des qualités du de l'appareil.
3. Il y a un téléphone numérique sans fil sur l'autre table de chevet. Puisqu'il est conforme au standard DECT 6.0, il opère à la fréquence 1,9GHz ce qui ne devrait pas interférer avec le Wi-Fi, mais qui sait ?
4. À l'occasion une tablette reliée au réseau Wi-Fi 2,4GHz est utilisée près des Sonoff qui fonctionnent sur la même fréquence.

Il n'est pas facile de cerner la source précise du problème, car les deux commutateurs Wi-Fi peuvent fonctionner correctement pendant des semaines. Ce n'est qu'occasionnellement et sans raison apparente, qu'une lampe s'allume pour quelques secondes puis s'éteint et recommence ce manège deux ou trois minutes plus tard jusqu'à ce que je débranche le Sonoff.

C'est loin d'être un problème inconnu. Voici quelques situations semblables Interference on my digital input - suggested fixes? et False trigger issue using GPIO input.

J'avais rajouté une résistance de polarisation à l'alimentation (ce que l'on appelle des « pull-up resistors ») à l'entrée à la broche 14 du ESP8266 dans chacun des Sonoff comme suggéré à plusieurs endroits, dont Random input HIGH detect on GPIO .

    boutons-poussoirs                         connecteur
     (en parallèle)                  3,3K Ω    Sonoff
       _| o---------,                ____
        | o------,  |            +--|____|-->o 5V
                 |  |            |
       _| o------|--+-----//-----+---------->o GPIO14
        | o------+--------//---------------->o 0V

Ma prochaine démarche sera probablement d'ajouter un condensateur à faible capacité entre le broche 14 du ESP8266 et la masse. Il constituerait avec la résistance un filtre passe-bas qui atténuerait les hautes fréquences.

Plusieurs font référence à l'article suivant Protecting Inputs in Digital Electronics. Il s'agit d'une discussion au sujet de la protection du microcontrôleur lorsque des ... boutons [...] connectés [...] via de longs fils [peuvent] entraîner une défaillance électronique par inadvertance. Les longs fils peuvent jouer le rôle d'inducteur et lorsqu'un bouton est ouvert ou fermé, de grandes pointes de tension peuvent apparaître... Je ne pense pas que le Sonoff soit endommagé car il répond correctement aux commandes envoyées par Domoticz par l'entremise du serveur mqtt ainsi que lorsque le bouton-poussoir du Sonoff ou l'un ou l'autre des boutons à distances sont appuyés. N'empêche que l'article est intéressant.

Pannes de courant et les Sonoff

Il y a une hécatombe de Sonoff ici. J'exagère un tout petit peu, mais il y a eu deux pannes de courant majeures dernièrement, et quelques-uns des Sonoff installés dans la maison ont difficilement récupérés et deux sont tombé en panne.

Pour un, c'est évident ce que c'est l'alimentation qui est défectueuse. Il a été possible de téléverser la dernière version de TASMOTA et de vérifier qu'il est possible d'activer le relai à distance par Wi-Fi tant que dispositif est alimenté par le connecteur. Cependant, rien ne fonctionne quand le Sonoff est branché sur le secteur.

Quant à l'autre Sonoff, on dirait qu'il ne peut plus stocker l'adresse du réseau local dans la mémoire flash, car il ne peut se reconnecter au réseau local lorsque ce dernier est redémarré pour une raison quelconque.

Il y a un troisième Sonoff, installé dans la base d'une lampe, est défectueux. Son bouton-poussoir est fonctionnel mais le Sonoff ne se branche pas au réseau Wi-Fi. En revanche, le bouton connecté à la broche 14 du ESP8266 ne fonctionne pas. Pour comprendre un peu mieux ce qui se passe, il faudra récupérer le Sonoff pour téléverser le logiciel de M. Arends à nouveau.

Je ne sais pas si ces problèmes sont liés à la dernière version (6.3.0) de TASMOTA qui a été installé sur l'ensemble des 9 Sonoff du système de domotique. J'ai l'impression que la récupération après une défaillance du réseau Wi-Fi ou d'une panne d'électricité est moins solide qu'auparavant. Je voulais modifier le code source en entrant le SSID et le mot de passe du réseau pour voir si cela aurait un impact, mais je n'ai pas réussi à compiler le code source dans l'EDI Arduino.

J'avais commencé à utiliser Platform.io comme Theo Arends, mais pour une raison qui m'échappe je n'arrive pas à téléverser de nouveaux micrologiciels vers un Wemos D1 mini dans cet environnement. Pas de problème si le micro-contrôleur est un ESP866 NodeMCU V3. Il n'y a rien à comprendre. Tant que ce problème n'est pas résolu, je vais utiliser l'EDI Arduino qui fonctionne avec les trois types de dispositifs basés sur le ESP8266 que je possède.

mDNS et TASMOTA

Depuis longtemps, TASMOTA de Theo Arends utilise la bibliothèque ESP8266mDNS. Ainsi on peut atteindre le serveur Web d'un Sonoff avec une adresse telle nom-d'hôte.local plutôt qu'avec une adresse IP telle 192.168.1.185 qui, d'ailleurs, est susceptible de changé selon les aléas du serveur DHCP du routeur. Pour faciliter encore plus, j'ai modifié les noms d'hôte des Sonoff en choisissant des noms plus mémorisables tels lampe-sofa, lampe-biblio et lampe-michel pour ma lampe de chevet.

Quelle déception quand après une panne de courant, je ne pouvais retrouver que trois Sonoff à l'adresse nom-d'hôte.local. J'ai dû utiliser Zenmap sur l'ordinateur de bureau et NetX sur la tablette Android pour trouver les adresses IP dynamiques des autres Sonoff. Or ni l'un ni l'autre de ces logiciels ne fonctionne parfaitement et il a été nécessaire de plus ou moins deviner l'adresse IP dans certains cas.

Dernièrement, j'ai trouvé la source du problème. Juste avant la panne, j'avais téléversé la nouvelle version (v6.3.0) du micrologiciel de Theo Arends. Il y a plusieurs variantes de TASMOTA comme on peut le voir dans le dépôt Github. J'ai installé sonoff-classic.bin sur les trois premiers Sonoff, puis j'ai décidé d'installer sonoff-FR.bin sur les autres. Or la bibliothèque ESP8266mDNS n'est pas incluse dans la seconde variante ce qui était, sans aucun doute, clairement indiqué. Une perte de temps considérable aurait été évitée, si j'avais pris la peine de lire la documentation.

Depuis que j'ai remplacé sonoff-FR.bin avec sonoff-classic.bin sur tous les Sonoff, ils publient leur service web sans faute.

La bibliothèque avahi qui prend en charge le « réseautage sans configuration » (Zero-configuration networking ou Zeroconf) dans Linux est installée par défaut dans Ubuntu. Ainsi je peux rejoindre le serveur Web du commutateur Sonoff qui contrôle un éclairage indirect caché derrière la bibliothèque en utilisant l'adresse http://lampe-biblio.local avec le navigateur Firefox. On peut en faire autant avec Safari sur Mac OS X ou iOS où c'est la bibliothèque Bonjour qui prend en charge les protocoles Zeroconf.

Malheureusement, l'équivalent de Avahi ou Bonjour n'est pas disponible sur la plateforme Android. Cela explique peut-être pourquoi le navigateur Chromium ne peut résoudre les noms locaux de type nom-d'hôte.local. Donc, quand je veux utiliser Chromium dans Ubuntu, j'obtiens l'adresse IP explicitement avec Avahi auparavant.

J'utilise Zeroconf Browser sur mes tablettes Android pour afficher la liste des service HTTP et l'adresse IP des serveurs publiés avec le protocole mDNS. Cette application, qui n'a pas été mise à jour depuis plusieurs années, n'est plus disponible sur Google Play, mais on la retrouve encore sur Aptoide. Caveat emptor, je ne sais pas si ce site vérifie assiduement que les applications qu'on y trouve sont sécuritaires. On trouve Service Browser dans Google Play qui me semble comparable.

Il est peut-être nécessaire d'installer Bonjour dans Windows 10 pour en faire autant sur cette plateforme. Je ne peux vérifier, car j'ai déjà ajouté CUPS pour utilisé des imprimantes réseau sur ma partition Windows 10 et je crois que Bonjour est installé automatiquement avec CUPS. En revanche, je suis certain que c'est nécessaire d'ajouter Bonjourdans XP, si quelqu'un utilise encore cette version.

Il n'y a pas véritablement d'échec ici. Toutefois, j'aimerais modifier la variante française du micrologiciel de Theo Arends en y rajoutant mDNS, quitte à éliminer des fonctionnalités qui ne sont pas utiles pour les simples commutateurs Sonoff de base que j'utilise. Cependant, pour y arriver, il me faudrait résoudre les problèmes avec les EDI Arduino et Platform.io que je mentionnais dans la section précédente. TASMOTA a beaucoup changé depuis la version 5.xx et cela me demandera un certain temps pour m'y retrouver.

Chromecast Audio

À la mi-novembre, Google vendait le Home mini à rabais. Seulement 34,95 $ alors qu'il fallait dépenser au moins 35,00 $ pour la livraison gratuite. J'ai donc ajouté un Chromecast, aussi en solde, à ma commande. Je ne sais trop comment j'ai réussi, mais c'est en fait le Chromecast Audio que j'ai commandé.

Le bidule est livré avec un câble audio avec connecteurs 3,5 mm qui ne fait que 12 cm de long. Impossible de placer l'appareil à aussi courte distance de l'amplificateur. Alors j'ai utilisé un câble audio de 1 m pour faire la connexion.

Mes tests préliminaires ont montré que le dispositif remplit sa fonction qui est de transmettre un flux audio par Bluetooth vers des enceintes actives. Je peux donc faire jouer musique, baladodiffusions et la radio internet depuis ma tablette Android. Toutefois, il n'est pas possible de transmettre l'audio d'une vidéo de façon synchrone. Regarder une vidéo de YouTube sur la tablette en écoutant le son transmis vers le Chromecast Audio connecté à une chaîne stéréophonique est comme regarder un vieux Godzilla des années 50: les paroles et les lèvres sont décalés. C'est exactement le même problème que j'avais rencontré en utilisant un Raspberry Pi comme récepteur du flux audio plutôt que le Chromecast Audio. Le problème est inhérent à la technologie. Tout ceci est confirmé dans la discussion entourant la question de JeremyTM Chromecast Audio delay when watching video .

Le câble audio de 1m que j'ai utilisé pour tester l'appareil est assez long pour se rendre à ma tablette quand je suis bien confortable dans mon fauteuil. Ce gadget m'est complètement inutile.

J'ai fait une erreur. À l'inverse de moi, mes neveux et nièces utilisent couramment des téléphones intelligents. Dans quelques jour, le Chromecast Audio ira à celle ou celui dont le téléphone n'a pas de connecteur audio 3,5mm.

DNS dynamique

Il y a environ un an, j'ai créé un nom de domaine dynamique chez FreeDNS. Combiné au réacheminement des ports sur le routeur, je pouvais accéder à mon serveur domotique et au flux vidéo à partir de la webcam USB connectée au Raspberry Pi, qu'importe où j'étais pour autant que j'avais l'accès à l'Internet. Il était également nécessaire pour que Google Home Mini pour contrôler les dispositifs IdO chez moi. Tout était sécurisé en utilisant uniquement les connexions TLS (HTTPS). Tout cela est expliqué dans deux billets : Google Home Mini avec Domoticz par l'entremise de IFTTT et Webcam en streaming sécurisé avec MJPG-Streamer sur un Raspberry Pi.

Pendant les vacances du Nouvel An, nous avons été absents pendant une courte période. Juste avant notre départ, j'avais activé le Planning conditionnel dans Domoticz. J'ai été déçu, car je ne pouvais pas accéder au serveur domotique et je n'ai pas reçu de courriel lorsque des périphériques IdO étaient activés ou désactivés pour simuler notre présence à la maison. Je ne pouvais pas voir le flux vidéo de la webcam. Enfin, je ne pouvais pas non plus me connecter au serveur OpenVPN que j'avais installé il n'y avait pas si longtemps.

Ces courriels manquants s’expliquent facilement. J'étais exaspéré de tous ces messages quand j'étais à la maison, car je savais quand les dispositifs s'allumaient ou s'éteignaient. J'avais donc désactivé le service dans Domoticz.

Je devrai envisager de changer cela dans le script Away; activer la notification par courrier électronique lorsque le planning est activé et la désactiver lorsqu'il est désactivé.

Tous les autres problèmes sont clairement liés. La cause s’est présentée un peu par accident lorsque j’ai ouvert un site Web me disant que j’étais à Toronto, à 1 600 km de chez moi. Comment cela pourrait-il être alors qu'avant Moncton, à environ 20 km, était identifié comme mon emplacement ? J'ai vérifié mon adresse IP pour constater qu'elle était maintenant différente. Après au moins deux ans d’affectation de la même adresse IP, mon fournisseur d'accès à Internet (FAI) a décidé de la modifier pour des raisons inconnues. Alors pourquoi l’entrée DDNS chez FreeDNS n’était-elle pas à jour ?

Je me suis connecté à mon routeur et j'ai ressaisi les valeurs dans la configuration DDNS. Il a signalé qu'il ne réussissait à mettre à jour l'entrée DDNS. J'ai supprimé les valeurs saisies pour le nom d'utilisateur et le mot de passe pour les remplacer avec guest comme indiqué à l'étape Step 2, Router stuff dans Automatic DNS changes via your router! chez FreeDNS. Finalement, le routeur a déclaré qu'il était capable de mettre à jour l'adresse IP. Malheureusement, il n'a pas été possible de vérifier cela. J'avais manuellement mis à jour l'adresse IP dans mon entrée de sous-domaine chez FreeDNS, et mon FAI continu d'attribuer systématiquement la nouvelle adresse IP depuis le dernier changement.

Cela pourrait très bien prendre encore quelques années avant de recevoir une nouvelle adresse IP. Jusque-là, je ne saurai pas si la mise à jour DNS automatique est effectuée correctement par le routeur.