Depuis la maj 4.5 Le service client MQTT "Zigbee" est arrêté

rennais35000 · Décembre 4, 2025, 8:45

Bonjour,
Le log zigbee2mqtt_demon de ce matin.
Il y a l’arrêt de la nuit et qq infos peut-être mais que je ne sais pas interpréter.

0000|[2025-12-04 00:08:49] ERROR  ##### Le service zigbee2mqtt s'est arrêté #####
0001|[2025-12-04 00:10:51] INFO  ##### Démarrage du service Zigbee2MQTT #####
0002|[2025-12-04 00:10:52] INFO  ##### Le service Zigbee2MQTT démarre... #####
0003|[2025-12-04 00:11:01] INFO  ##### Le service zigbee2mqtt a démarré #####
0004|[2025-12-04 06:00:22] ERROR  [JMQTT][Zigbee vers 228 New] : ERROR dans MQTT_message, topic=zigbee2mqtt/Pompe piscine Zigbee Ph3, payload={"current":0,"device":{"applicationVersion":1,"dateCode":"20200217-586","friendlyName":"Pompe piscine Zigbee Ph3","hardwareVersion":1,"ieeeAddr":"0x0c4314fffe5bf498","manufacturerID":4727,"manufacture, message=Unsupported operand types: int - string, trace=#0 /var/www/html/core/class/scenario.class.php(432): scenario->launch()
0005|#1 /var/www/html/core/class/cmd.class.php(1922): scenario::check()
0006|#2 /var/www/html/plugins/zigbee2mqtt/core/class/zigbee2mqtt.class.php(2127): cmd->event()
0007|#3 /var/www/html/plugins/zigbee2mqtt/core/class/zigbee2mqtt.class.php(2168): zigbee2mqtt->ZL_checkAndUpdateCmd()
0008|#4 /var/www/html/plugins/zigbee2mqtt/core/class/zigbee2mqtt.class.php(2071): zigbee2mqtt->MQTT_ReceiveValues()
0009|#5 /var/www/html/plugins/zigbee2mqtt/core/class/zigbee2mqtt.class.php(1805): zigbee2mqtt->MQTT_message()
0010|#6 [internal function]: zigbee2mqtt::{closure}()
0011|#7 /var/www/html/plugins/zigbee2mqtt/core/class/zigbee2mqtt.class.php(1930): Mosquitto\Client->loop()
0012|#8 /var/www/html/core/php/jeeCron.php(85): zigbee2mqtt::deamon_client()
0013|#9 {main}

MrGreen · Décembre 4, 2025, 8:51

Généralement à cette heure ci, c’est le backup qui fait planter le client mqtt (à vérifier de ton côté) : donc ras si c’est ça

Je me suis dit l’update à réglé le soucis: Je remonte en 2.7.0: Et là NOK.

Il faut essayer de passer en nodeJs 22 (voir le post ici : Plantage Zigbee2mqtt (dans ZigbeeLinker) suite au passage en version 2.7.0 - #12 par Aurelien)

akenad · Décembre 4, 2025, 9:37

One again.

Ici probablement opération entre une chaine et un entier dans un scénario.

akenad

rennais35000 · Décembre 4, 2025, 10:27

Je les traque, mais pas évident à trouver A priori il faut que je cherche à 6h dans le scénario qui a tourné pour allumer ou éteindre la pompe de la piscine.

skillix · Décembre 4, 2025, 10:36

je vois 2 anomalies ici…

Faire tourner une piscine en hiver
une piscine en bretagne ? mais vous êtes déjà mouillé dehors vu qu’il pleut !

rennais35000 · Décembre 4, 2025, 10:49

Ah les clichés ont la vie dure
Et pour la piscine, c’est mode Hiver et hivernage actif, elle tourne en fonction de la température de l’eau.
En ce moment c’est :
Entre 2 et 3 h du matin.
Au lever du soleil avant la fin des HC (eh oui il se lève parfois ici ) entre 6 et 7 h (surement ce déclenchement avec une variable qui devait être mauvaise pour le php)
et une dernière fois entre 16 et 17 h

Donc, j’ai ça dans mon scénario qui marchait bien en php7 :

variable(DuréeFiltrationTemp)*3600 - #[SURVEILLANCE][Surveillance Pompe piscine Zigbee][Temps Actif Total]#

Du coup pour php8 je dois m’assurer que les variables c’est des entiers ? :

int(variable(DuréeFiltrationTemp))*3600 - int(#[SURVEILLANCE][Surveillance Pompe piscine Zigbee][Temps Actif Total]#)

MrGreen · Décembre 4, 2025, 11:05

@Aurelien, pourriez-vous faire remonter cela dans l’équipe svp
Il serait top que les erreurs PHP que ce soit dans un scenario ou un plugin (exemple : virtuel, ou tiers) soient remontée dans le log erreur de Jeedom (avec type d’élément : le scenario ou équipement, sont id ou nom par exemple)

Bon bien entendu quand dans le code d’un plugin il y a un try catch, pas possible de le remonter.

skillix · Décembre 4, 2025, 11:30

probablement que tu peux simplement changer le type de la commande de « autre » a « numérique »

rennais35000 · Décembre 4, 2025, 1:22

[SURVEILLANCE][Surveillance Pompe piscine Zigbee] est déjà numérique et la variable je n’ai aucune idée d’où configurer ça.
Donc on va assurer le coup pour maintenant et pour l’avenir. J’ai a peu près compris les cas d’utilisation de int et float et je vais repasser sur tous les scénarios par petit paquet car j’en ai pas mal depuis le temps.
Ce qui est ballot c’est de passer d’une situation ou c’était transparent à une situation où ça oblige l’utilisateur à être un peu plus averti. (ou moins con, oui je sais )
Que nous réserve php9

skillix · Décembre 4, 2025, 2:36

donc ca veut dire que les variable sont systématiquement en string, ce qui risque de poser problème un peut partout, moi j’en ai 198 …

Une solution serait de combiner 1 variable = un virtuel, mais bon c’est lourd.

Sylvainde · Décembre 4, 2025, 3:11

Hello,

J’ai eu le même soucis en version 4.4 site à une perte du cache, touts les status des portes/fenêtre était sans valeur, jusqu’à un changement d’état. Et de mémoire l’upgrade en 4.5 réinitialise le cache.

Pour éviter ça je fais le calcul avec intval(monequipement) + intval(monequipement) comme ça même si pas de valeur il considère la valeur à 0, au moins il ne fait plus planter zigbeelinker.

MrGreen · Décembre 4, 2025, 3:22

C’est cadeau :

rennais35000 · Décembre 4, 2025, 3:26

Patch evaluateExpression() appliqué avec succès.

PARNOULD · Décembre 4, 2025, 5:43

Bonsoir,
Ce soir j’ai laissé une version Jeedom en 4.5 et ZMQTT en version 2.6.3. Ca a l’air de tenir. C’est assez incompréhensible. A voir combien de temps ca tient. J’espère qu’une solution pérenne va être trouvée par les dev des deux modules (ZMQTT et JEEDOM). Je dois monter ma VM en Debian 11 (puisque Jeedom n’est pas compatible avec la 13). Je vais attendre un peu de voir ce qui se passe. Bon courage à tous

Sportback · Décembre 4, 2025, 5:52

Du coup:

4.5.1 + 2.7 chez moi ça marche…

sudo · Décembre 4, 2025, 6:10

Bonsoir,

Alors chez moi la box N°2 odroid c4 que j’avais passé en 4.5 ne fait pas de plantage et dans le log il n’y a plus d’arrêt du client lors de la sauvegarde a n’y rien comprendre, j’ai deux différences par rapport à l’atlas, la clé zigbee est une sonoff et zigbee2mqtt est en version 2.6.1.

Par contre sur l’atlas ou je suis revenu en 4.4.20 tous fonctionne toujours bien mais j’ais remarqué que sur l’interface Zigbee2Mqtt (6.2.3) quand je regarde journaux

[04/12/2025 18:40:33] z2m: Publish 'set' 'state' to 'ECL Hote' failed: 'Error: ZCL command 0xa4c1386a29d0197c/1 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (No ZCL response received for (141) Error: waiting for response TIMEOUT)'
[04/12/2025 18:40:34] z2m: Publish 'set' 'state' to 'ECL Hote' failed: 'Error: ZCL command 0xa4c1386a29d0197c/1 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (No ZCL response received for (142) Error: waiting for response TIMEOUT)'
[04/12/2025 18:43:43] z2m: Publish 'set' 'state' to 'ECL Hote' failed: 'Error: ZCL command 0xa4c1386a29d0197c/1 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (No ZCL response received for (123) Error: waiting for response TIMEOUT)'
[04/12/2025 18:43:44] z2m: Publish 'set' 'state' to 'ECL Hote' failed: 'Error: ZCL command 0xa4c1386a29d0197c/1 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (No ZCL response received for (124) Error: waiting for response TIMEOUT)'
[04/12/2025 18:45:18] z2m: Publish 'set' 'state' to 'ECL Hote' failed: 'Error: ZCL command 0xa4c1386a29d0197c/1 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (No ZCL response received for (245) Error: waiting for response TIMEOUT)'
[04/12/2025 18:45:19] z2m: Publish 'set' 'state' to 'ECL Hote' failed: 'Error: ZCL command 0xa4c1386a29d0197c/1 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (No ZCL response received for (246) Error: waiting for response TIMEOUT)'

Il y a des erreurs et quand j’étais en V 4.5 c’était ce module qui m’arrêtait le client.

Donc je vois des erreurs dans journaux mais dans jeedom il n’y a aucune erreur dans le log zigbee2mqtt

sudo

Richou62 · Décembre 4, 2025, 6:32

Depuis l’installation de la version beta de MRGreen, j’ai eu toujours des erreurs au niveau du demon avec arrêt MQTT. En revanche, le service MQTT redémarre qq secondes après et donc cela devient quasiment transparent. Et c’est bien la version 4.5 qui est en cause. Et j’zi pris le soin de ne pas passer en 2.7.

Enfin, j’ai supprimé un scénario et un virtuel Douteux et depuis ce matin matin, je n’ai plus erreur MQTT.

Je croise les doigts

rennais35000 · Décembre 4, 2025, 6:37

Oui la dernière beta relance mieux et sans blocage. Quand à la 2.7 elle tourne chez moi sans plus de pb qu’avant.
Et mets le scénario pour patcher qu’il a mis plus haut.
Pourquoi se faire du mal quand un log peut t’aider à faire le ménage dans les trucs douteux

skillix · Décembre 4, 2025, 6:49

Faites attention de ne pas trop mélanger les soucis si je ne dis pas de bêtises, il y a 3 soucis :

Version 2.7 de Zigbee2MQTT - Ne fonctionne qu’avec la V4.5.1 de Jeedom
Version 2.6.3 et inferieur Zigbee2MQTT en Jeedom V4.5:
2.1 PHP 8 : erreur qui provoque des erreur de calcul => plantage du client MQTT (pallié avec les dernière version de ZigbeeLinker)
2.2 PHP 7 : problème inconnu => plantage du client MQTT (pallié avec les dernière version de ZigbeeLinker)

MrGreen · Décembre 4, 2025, 7:01

La version Béta a été passé en Stable pour la stabilité du démon client MQTT.

Version 2.7 de Zigbee2MQTT - Ne fonctionne qu’avec la V4.5.1 de Jeedom

Alors c’est presque ça, je suis en 4.5 et 2.7 et nodejs 20.19.1 et ça roule.
Il doit y avoir un truc qui fait capoter mais quoi ? (dans tous les cas c’est au niveau de zigbee2mqtt)

Et les plantages du client MQTT sont + présent en PHP8 mais aussi en PHP7 (j’ai du des PHP7 dans les échanges) mais pour cela, je pense plutôt à non interprétation des erreurs php (ce que j’ai corrigé dans le plugin et via le patch posté plus haut dans Jeedom).