Une fable au sujet d'échecs après échecs, certains d'entre eux de ma faute, d'autres non, qui ont fait tomber le système domotique et ont ensuite rendu difficile sa remise en ligne.

Table des matières

Comment le système domotique s'est retrouvé sur un Orange PI PC 2

Il y a environ 16 mois, j'ai tenté de convertir une boîtier Android TV en serveur Linux dans l'espoir d'y installer mon système domotique. Malheureusement, ce fut un échec partiel, car la découverte de dispositifs par Alexa en conjonction avec ha-bridge par bwssystems n'a pas fonctionné. Incapable de déterminer l'origine du problème, j'ai mis de côté le boîtier TV converti même si Linux fonctionnait plutôt bien. Il aurait été possible de continuer à fonctionner avec ha-bridge sur le petit Orange Pi Zero comme avant. Cependant, je voulais vraiment que tous les serveurs du système domotique soient sur un seul appareil avec une connexion Ethernet au réseau local de un gigabit/seconde. La solution a été d'utiliser l' Orange Pi PC 2 à la place d'un Raspberry PI 3B assez similaire hormis sa connexion Ethernet de 1 Gb/s.

Le système domotique fonctionne sur un Orange Pi PC 2 (OPiPC2) avec un système d'exploitation Armbian 22.05.3 non pris en charge. Cette version de Armbian était basée sur Ubuntu 22.04.1 Jammy. Sans surprise, l'ordinateur monocarte n'a eu aucun problème à gérer Domoticz, ha-bridge, WireGuard et nginx sans arrêt. De plus, Alexa collabore bien avec le système. Il s'agissait d'une solution temporaire jusqu'à ce que le problème avec le box TV converti en serveur Linux soit résolu ou que le tout soit déplacé vers un serveur X86_64 plus costaud que je mets des mois à construire. Or tout cela était en veilleuse, car tout fonctionnait sans problème. C'est drôle comme les correctifs temporaires se transforment en éléments permanents.

Défaillance catastrophique du système

Le système est tombé en panne il y a quelques jours. Domoticz envoyait des courriels toutes les 10 minutes pour avertir que l'OPiPC2 était en surchauffe, mais je ne m'en rendais pas compte puisqu'aucun ordinateur n’était en marche cet après-midi. Ensuite, j'ai remarqué qu'un commutateur WiFi (construit avec un W600-PICO) ne fonctionnait pas correctement. De plus, l'interface Web Domoticz n'a pas pu être utilisée pour allumer ou éteindre les lumières de manière fiable. J'ai regardé les messages MQTT vers et depuis Domoticz et j'ai vu que le contrôleur de porte de garage inondait le serveur de messages « porte de garage ouverte » et « porte de garage fermée » en succession très rapide. Pire, la porte du garage avait été ouverte. Après la fermeture manuelle de celle-ci, les messages « porte ouverte », « porte fermée » continuaient d'être transmis. Le débranchement de l’appareil IdO a coupé ce flux de messages. Ensuite, j'ai redémarré l'OPiPC2 en espérant que le système domotique fonctionnerait correctement comme avant, sans le contrôleur WiFi de la porte de garage évidemment. Bien sûr, ce n’était pas le cas, sinon ce billet n’aurait pas été nécessaire !

Après un examen du système, surtout des entrées du journal, il est devenu évident que la carte µSD sur laquelle étaient enregistrés le système d'exploitation et la base de données domotique était défectueuse. Il existe de nombreux avertissements sur le manque de fiabilité de ces périphériques de stockage, mais franchement, je n'avais pas eu de pannes significatives avec les cartes SD utilisée sur un Raspberry Pi hébergeant le système domotique depuis des années auparavant. C’est vrai même si j’utilise souvent des cartes anonymes provenant de fournisseurs inconnus.

Rétrospectivement, l’échec était explicable. Chaque message annonçant un (faux) changement de l'état de la porte de garage nécessitait une mise à jour de la base de données puisqu'elle contient un journal de l'état de chaque dispositif. Domoticz tentait donc de réécrire un fichier de base de données d'environ 2,5 Mo (domoticz.db) des dizaines, voire des centaines de fois par seconde. Selon toute probabilité, le fichier souvent beaucoup plus volumineux domoticz.db-wal (référence SQLite au sujet de ce journal d'écriture anticipée) était mis à jour encore plus fréquemment. Pas étonnant que la puce chauffe. On ne peut que deviner le nombre de cycles de lecture et d'écriture qui ont été imposés à la pauvre petite carte µSD de 8 Go de la machine. L'enregistrement du courrier électronique montre que cela durait depuis environ trois heures avant que je débranche le contrôleur de la porte de garage.

Échec sur échec

J'avais eu la brillante idée de créer une carte µSD de sauvegarde que j'ai insérée dans l'OPiPC2. Ensuite, j'ai copié ma dernière sauvegarde de la base de données vers l'OPiPC2 et j'ai redémarré le système domotique. Il a fonctionné avec presque exactement la même configuration qu'avant, à l'exception des codes IR modifiés pour un blaster IR. Ce n’est pas grave, on les obtient facilement. D’ailleurs, j’avais effectivement enregistré les nouveaux codes dans mon document de configuration Tasmota. Ainsi, après ces petites mises à jour après une vérification que le système fonctionnait, la prochaine étape était de créer une carte SD de sauvegarde de la carte SD de sauvegarde mise à jour qui était maintenant la carte principale. Le vénérable programme dd utilisé pour faire des copies de cartes SD a échoué en raison d'erreurs de lecture. Puisqu'il s'agissait d'une carte micro SD dans un lecteur de carte SD, j'ai essayé avec différents adaptateurs, car ceux-ci sont connus pour s'user. Pas de chance.

The Solution - Start Over

Ne voyant aucun moyen sur et facile pour ce problème, j'ai réinstallé Armbian 23.8 Bookworm CLI, 31 août 2023 sur une nouvelle carte SanDisk Ultra A1 de 16 Go. L'opération s'est très bien déroulée, tous les services ont fonctionné comme prévu et systemctl a signalé qu'il n'y avait eu aucun service défaillant. Pas mal du tout si l'on considère qu'il s'agit d'un système d'exploitation pour un ordinateur monocarte orphelin avec prise en charge communautaire uniquement.

___ ____ _ ____ ____ ____ / _ \| _ \(_) | _ \ / ___|___ \ | | | | |_) | | | |_) | | __) | | |_| | __/| | | __/| |___ / __/ \___/|_| |_| |_| \____|_____| Welcome to Armbian 23.8.1 Bookworm with Linux 6.1.53-current-sunxi64 No end-user support: community creations System load: 2% Up time: 6 min Memory usage: 11% of 984M IP: 192.168.1.22 CPU temp: 39°C Usage of /: 12% of 15G RX today: 159.2 MiB [ General system configuration (beta): armbian-config ]

Il n’a pas fallu longtemps pour installer le minimum de paquets pour redémarrer la domotique.

avahi-daemon - configuration locale du réseau avec mDNS
mosquitto - serveur MQTT
Environnements virtuels Python 3 - pour certains scripts Python
OpenJDK (jre) - environnement d'exécution Java
ha-bridge - Émulateur Philips Huer
domoticz - serveur domotique

L'une des raisons pour lesquelles cela a été facile est que je suivais mes propres instructions à propos de la domotique sur un Raspberry Pi. Il y avait de petits problèmes à résoudre tels une bibliothèque manquante et la recherche de la dernière version d'un paquet, mais rien de majeur qui demandait beaucoup de temps. Cependant, le plus gros gain de temps est le fait que j'avais des sauvegardes des bases de données de domoticz et de ha-bridge ainsi que du fichier de configuration de ce dernier de tous mes scripts. Il n’était même pas nécessaire de mettre à jour Alexa avec la redoutable procédure de découverte d’appareils ; ha-bridge fonctionnait comme avant.

Pour être honnête, il manquait quelques éléments. Même si j'avais les scripts, il n'y avait aucune sauvegarde de crontab pour la prise en charge de leur exécution. Heureusement, la carte µSD de sauvegarde défectueuse a pu être lue et j'ai pu récupérer presque tout ce dont j'avais besoin.

Certaines choses doivent être ajoutées, mais le système domotique fonctionnait le jour même de sa panne, ce qui réduisait les désagréments pour les autres membres de la maison. Bien entendu, juste avant de remettre officiellement le système en ligne, j'ai copié la carte µSD sur une autre carte SanDisk et j'ai conservé la carte originale nouvellement créée en guise de sauvegarde.

Après cela, quelques heures ont été consacrées à l'élaboration d'une meilleure stratégie de sauvegarde basée sur certaines des leçons apprises. J'espère mettre à jour un ancien billet sur ce sujet dans quelques semaines.

Encore plus de problèmes de carte SD

Ce n'est pas la fin de cette histoire. Pourquoi ne pas tenter à nouveau d'utiliser le boîtier TV S92 d'Alfawise comme appareil Linux pour faire fonctionner le système domotique ? J'ai fait une mauvaise manœuvrée qui m'a amené à réinstaller Android sur la machine. Rétrospectivement, cela n'était pas nécessaire et il était en fait assez simple d'obtenir une version très récente d'Armbian sur la machine.

_ _ ____ ___ _ ____ / \ _ __ ___ | | / ___|/ _ \/ |___ \ / _ \ | '_ ` _ \| |____\___ \ (_) | | __) | / ___ \| | | | | | |_____|__) \__, | |/ __/ /_/ \_\_| |_| |_|_| |____/ /_/|_|_____| Welcome to Armbian 23.11.0-trunk Lunar with Linux 6.1.60-ophub No end-user support: unsupported (lunar) userspace! System load: 3% Up time: 18:14 Memory usage: 18% of 1.88G IP: 192.168.1.22 CPU temp: 45°C Usage of /: 16% of 15G storage/: 1% of 29G RX today: 363.6 MiB [ General system configuration (beta): armbian-config ]

Selon, systemctl il n'y a eu qu'un seul service défaillant. Il a suffi de le désactiver, car il se plaignait de ne pas trouver de lecteur doté de la technologie SMART, sans grande surprise d'ailleurs. Malheureusement, lors de l'installation des paquets nécessaires comme sur l'OPiPC2 un peu plus tôt, l'erreur suivante s'est produite

[ 1000.028355] mmc1: Card stuck being busy! __mmc_poll_for_busy [ 1001.272246] mmc1: card never left busy state [ 1001.275371] mmc1: tried to HW reset card, got error -110 [ 1001.279241] mmcblk1: recovery failed! [ 1001.282875] I/O error, dev mmcblk1, sector 1294288 op 0x0:(READ) flags 0x3000 phys_seg 1 prio class 2 [ 1001.292677] EXT4-fs error (device mmcblk1p2): __ext4_find_entry:1682: inode #40076: comm deb-systemd-hel: reading directory lblock 0 [ 1001.293623] mmc_erase: group start error -110, status 0x0 [ 1001.295895] Aborting journal on device mmcblk1p2-8. [ 1001.298754] I/O error, dev mmcblk1, sector 888832 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 2 [ 1001.300065] mmc_erase: group start error -110, status 0x0 [ 1001.337648] I/O error, dev mmcblk1, sector 1413160 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 2 [ 1001.353364] mmc_erase: group start error -123, status 0x0 [ 1001.355056] I/O error, dev mmcblk1, sector 3039128 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 2 [ 1001.364049] mmc1: card 0007 removed [ 1001.364067] JBD2: I/O error when updating journal superblock for mmcblk1p2-8. [ 1001.374833] EXT4-fs (mmcblk1p2): I/O error while writing superblock [ 1001.381007] EXT4-fs (mmcblk1p2): Remounting filesystem read-only

Dès lors, le système était engagé dans une boucle d’erreurs de lecture de la carte SD et est devenu inutilisable.

[ 1008.292448] EXT4-fs error (device mmcblk1p2): __ext4_find_entry:1682: inode #40183: comm vnstatd: reading directory lblock 0 ... [ 1008.988527] EXT4-fs error (device mmcblk1p2): __ext4_get_inode_loc_noinmem:4605: inode #21: block 354: comm gmain: unable to read itable block ...

Le dispositif mmcblk1 était la carte µSD sur laquelle le système d'exploitation était stocké. C'était une carte Verbatim de 16 Go. J'ai réessayé avec un autre carte Verbatim dite Premium. Étonnamment, la même chose s’est produite, quoiqu’à un moment différent, lors de la lecture d’un secteur différent. Quelles sont les chances que deux cartes µSD soient endommagées ? J'ai fait une recherche rapide dans le GitHub amlogic-s9xxx d'ophub en pensant que l'arborescence des périphériques aurait pu être modifiée. Le problème a été soulevé dans ext4-fs error #889. D'après ce que j'ai compris de la discussion entre ophub et ermac500, ce dernier a tenté d'analyser et de réparer la carte SD (avec badblocks et fsck sur Linux ou chkdsk sous Windows), mais cela a gâché l'image. Ne voulant pas perdre de temps, j'ai essayé une troisième carte µSD, un autre SanDisk du même type utilisé avec succès sur l'OPiPC2. Cette troisième tentative a fonctionné et le système domotique fonctionne sur le boîtier TV converti depuis quelques jours sans problème.

Leçons apprises

Il ne faut pas négligé la qualité du support de stockage sur lequel le système d’exploitation est installé.
Le guide de démarrage de Armbian est très clair à ce sujet. Le forum regorge de réponses qui commencent en conseillant de vérifier la carte SD.
La qualité des cartes SD n’est pas facile à vérifier à l’avance.
La carte SD BINFUL "sans nom" achetée chez Aliexpress et qui a fonctionné sur l'OPiPC2 pendant 16 mois et, peut-être, pendant plusieurs mois auparavant sur un Raspberry Pi a très bien fonctionné. Je ne peux pas en dire autant des cartes SD Verbatim achetées localement dans un magasin d'une chaîne nord-américaine bien connue.
Achetez des cartes SD de classe A1 ou A2.
Ceci est abordé dans Mise en route - Comment préparer une carte SD. Lisez les entrées les plus récentes dans le message du forum sur les performances de la carte SD, nottamment la conclusion, si vous êtes pressé.
Testez n'importe quelle carte µSD dès son achat et également avant sa mise en service.
Si la carte a été utilisée auparavant, restaurez les paramètres d'usine par défaut, puis effectuez tous les tests. Encore une fois, cela est abordé dans le guide de démarrage d'Arbian. Malheureusement, il ne contient pas de conseils pour ceux d'entre nous qui utilisent Linux. ux.
Évitez les erreurs de programmation.
La cause immédiate de cette série de pannes était mon code sur le module ESP8266 surveillant l'état de la porte de garage. Le code doit être réécrit pour supposer que le capteur (c'est-à-dire un interrupteur à contact) est défectueux si l'état de la porte de garage alterne très rapidement. Il est facile d’écrire du code qui fonctionne lorsque le matériel fonctionne comme prévu, c’est une autre affaire d’anticiper et de gérer correctement les éventuelles erreur et pannes matérielles.
La redondance peut être une bonne chose.
Il y a environ un mois, le moniteur du garage s'est déchaîné comme décrit ci-dessus. À l'époque, j'avais réparé la source du problème : une mauvaise soudure pour la résistance de rappel sur la ligne de signal provenant du commutateur de contact. Une réparation qui n'a pas été bien exécutée, clairement. Ces échecs mettent en évidence que l'ESP8286 n'avait aucun autre moyen de déterminer l'état de la porte, ce qui explique pourquoi il a ouvert une porte fermée. Cela ne se produirait pas si l’ouvre-porte de garage avait une connexion d’ouverture et de fermeture séparée, mais qu’il n’avait qu’une connexion à bascule. Il existe un besoin évident d'un deuxième capteur pour confirmer que la porte est ouverte avant d'actionner l'interrupteur de fermeture/ouverture de la porte de garage dans l'espoir que la porte se ferme plutôt qu'elle ne s'ouvre.