Depuis une migration de ma Jeedom vers Debian 12 (installation from scratch + restauration d’une archive de sauvegarde Jeedom), le démon du plugin EIBD-KNX devient instable.
Juste avant l’arrêt du démon, je vois cette erreur dans le log eibd :
Erreur sur eibd::BusMonitor() : count(): Argument #1 ($value) must be of type Countable|array, int given
Après cette erreur, plus aucun équipement KNX ne fonctionne. Puis, sans aucune action de ma part, le démon redémarre seul environ 4 minutes plus tard (voir capture de la page Santé : dernier lancement du démon horodaté, gestion automatique active).
Informations Jeedom
Core : 4.6.1
Plugin EIB-KNX : 2026-08-29 01:00:51
OS : Debian 12
Questions
Est-ce le même bug que dans le sujet référencé (équipement mal configuré + PHP 8 plus strict sur les types) ?
Quelqu’un a-t-il une méthode plus rapide pour identifier l’équipement fautif que de les désactiver un par un ?
Le démon devrait-il gérer cette erreur sans planter complètement, plutôt que de s’arrêter puis se relancer tout seul ?
Voici les informations demandées. Les logs ne me semblent pas très utiles. A chaque fois que le démon redémarre, il me semble qu’il repart d’un fichier vide. On ne voit donc pas l’erreur qui a provoqué l’arrêt.
Core : 4.6.1 (master)
DNS Jeedom : non
Plugin : EIB - KNX
Version : 2026-08-29 01:00:51 (stable)
Statut Démon : Démarré - (2026-09-20 22:55:04)
Santé
🟢 Matériel : RPI 4 B
🟢 Système à jour : OK
🟢 Cron actif : OK
🟢 Scénario actif : OK
🟢 Démarré : OK 2026-09-17 16:59:03
🟢 Date système (dernière heure enregistrée) : OK 2026-09-21 00:38:11 (2026-09-20 23:41:02)
🟢 Droits sudo : OK
🟢 Version Jeedom : 4.6.1
🟢 Version OS : debian 12.15
🟢 Version PHP : 8.2.33
🟢 Nombre de processus Apache : 11
🟢 Version OS : Linux domo-backup 6.12.109+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.109-1+rpt1 (2026-09-11) aarch64 GNU/Linux [12.15]
🟢 Version database : 10.11.18-MariaDB-0+deb12u1
🟢 Espace disque libre : 93 %
🟢 Connexion active/max/autorisée : 13/26/151
🟢 Taille base de données : 67.3 MB
🟢 Espace disque libre tmp : 95 %
🟢 Mémoire disponible : 69 % (Total 3796 Mo)
🟢 Mémoire suffisante : 0
🟢 Erreur I/O : 0
🟢 Swap disponible : 100 % (Total 512 Mo)
🟢 Swappiness : 10 %
🟢 Charge : 0.33 - 0.34 - 0.4
🟢 Configuration réseau interne : OK
🟢 Configuration réseau externe : OK
🟢 Node : v22.23.2
Comme j’ai environ 120 éléments KNX dans le plugin et que je ne voulais pas commencer à les activer / désactivé un par un, j’ai demandé à Claude un peu d’aide et j’avoue qu’il a été bluffant d’efficacité. Il a identifié que la seule manière de provoquer ce crash est d’avoir une commande DPT 27 qui reçoit une trame courte.
Il se trouve en effet que j’avais utilisé ce type (à vrai dire, je ne me rappelle plus très bien pourquoi). Le changer en DPT 1.001, ce qui est plus logique pour mon cas, résoud ce problème.
A voir quand même dans le code s’il ne faudrait pas traiter ce cas un peu mieux try/catch pour éviter de crasher le démon.
Btw, dans le log, Claude a aussi identifié dans mes logs beaucoup d’erreurs récurrentes Type de data non pris en charge par le plugin (0.0.0 - 0/0/0) par exemple dans ce cas :
[2026-09-20 23:59:03][DEBUG] [Zen room][Zen - Thermostat][Température ambiante] : Décodage de la valeur avec le DPT : 9.001`
`[2026-09-20 23:59:03][INFO] [Zen room][Zen - Thermostat][Température ambiante] : Mise à jour de la valeur : 23°C`
`[2026-09-21 00:00:03][DEBUG] [Moniteur Bus][Erreur] Type de data non pris en charge par le plugin (0.0.0 - 0/0/0)
Cette erreur qui n’apparait qu’en debug et est lié à l’absence de trame suivante dans la minute suivant la commande précédente. Ca pourrait être une bonne idée de corriger ce problème introduit dans le commit 5af7eb43 du 02/02/2026.
Pour être honnète, je n’ai pas vérifier les affirmations de Claude et je laisse le soin aux personnes compétentes de corriger ou pas ces problèmes détectés. En tout cas, cela a résolu mon problème. J’espère que ça en aidera d’autres.
Je pensais que tous mes problèmes étaient réglés mais en fait non.
En deux jours , le 21/09 à 19h55 et le 23/09 à 00h30, le plugin s’est arrêté de fonctionner. Les scénarios n’étaient plus appelés sur l’appui d’un interrupteur. Je ne pouvais plus accéder aux logs via la console et monitoring du bus ne fonctionnait plus non plus. Dans les 2 cas, un redémarrage du démon a reglé le problème.
Pas d’erreur remontée via les notifications de Jeedom, donc plus difficile d’utiliser Claude dans ce cas là ?
