Réseau Zwave tombe après quelques heures

Tags: #<Tag:0x00007fcb9c8a2f68>

Bonjour à tous,

Je me tourne vers vous car j’ai un soucis avec mon réseau Zwave que je ne parviens pas à résoudre malgré avoir passé des heures sur le forum à essayer différentes choses.

Tout d’abord mon config: RPI4 + SSD, Jeedom 4.0.61 + clé Aeotec stick Gen 5
image
Tout est au vert dans la page santé.

Depuis quelques semaines, mon réseau Zwave s’arrête de fonctionner après quelques heures après avoir relancé le démon. Par exemple, hier je l’ai relancé vers 12h, il a fonctionné tout l’après-midi et j’ai vu dans les logs qu’il y avait des messages d’erreur timeout à partir de 21h22. A partir de là, plus de comms sur le réseau, plus rien n’est envoyé et plus rien ne remonte.
Ce comportement pourrait être consécutif à une mise à jour de l’OS avec « sudo apt update & & sudo apt upgrade ». Ce n’est qu’une hypothèse.
J’ai également inclu à peu près à cette période un nouveau module Qubino fil pilote rail din pour lequel j’ai vraiment galéré. Un noeud était bien détecté mais les infos constructeur/modèle etc ne remontaient pas et les commandes n’étaient pas créées. Bref après de multiples inclusions/exclusions et alors que j’étais sur le point de renvoyer le module, ça a finit par fonctionner. Probablement pas lié à mon problème de réseau.
Voici les logs d’hier soir quand le réseau s’est arrêté:

[2020-12-27 19:35:22][INFO] : Received Meter report from node 38: Exporting=False
[2020-12-27 19:35:22][INFO] : Received Meter report from node 38: Current=0.0A
[2020-12-27 19:35:22][INFO] : Received Meter report from node 38: Previous Reading=0.0A
[2020-12-27 19:35:22][INFO] : Received Meter report from node 38: Interval=301seconds
[2020-12-27 19:35:23][INFO] : Received Meter report from node 38: Exporting=False
[2020-12-27 19:35:23][INFO] : Received Meter report from node 38: Current=0.0A
[2020-12-27 19:35:23][INFO] : Received Meter report from node 38: Previous Reading=0.0A
[2020-12-27 19:35:23][INFO] : Received Meter report from node 38: Interval=301seconds
[2020-12-27 21:22:50][INFO] : Send command to node 31 on class 37 instance 1 index 0 value 255
[2020-12-27 21:22:50][INFO] : 200 GET /node?node_id=31&instance_id=1&cc_id=37&index=0&type=setvalue&value=255&apikey=********************************(127.0.0.1) 2.52ms
[2020-12-27 21:22:51][INFO] : NodeId 31 send a notification: Timeout
[2020-12-27 21:22:52][INFO] : NodeId 31 send a notification: Timeout
[2020-12-27 21:25:09][INFO] : Send command to node 16 on class 38 instance 1 index 0 value 0
[2020-12-27 21:25:09][INFO] : 200 GET /node?node_id=16&instance_id=1&cc_id=38&index=0&type=setvalue&value=0&apikey=********************************(127.0.0.1) 4.34ms
[2020-12-27 21:25:10][INFO] : NodeId 16 send a notification: Timeout
[2020-12-27 21:25:11][INFO] : NodeId 16 send a notification: Timeout
[2020-12-28 01:16:24][ERROR] : Critical error on  send_changes_async threads can only be started once
Unhandled exception in thread started by <bound method _Timer.__bootstrap of <_Timer(Thread-399531, stopped daemon -1356860320)>>
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 774, in __bootstrap
    self.__bootstrap_inner()
  File "/usr/lib/python2.7/threading.py", line 789, in __bootstrap_inner
    del _limbo[self]
KeyError: <_Timer(Thread-399531, stopped daemon -1356860320)>

On voit qu’à partir de 19h35, il n’y a plus de logs alors qu’auparavant il n’y a pas une minute sans un log.

J’ai vu qu’il pouvait y avoir des soucis de compatibilité des packages Python, voici ce que j’ai actuellement:

 pip --version
pip 20.3.1 from /home/pi/.local/lib/python2.7/site-packages/pip (python 2.7)
 python --version
Python 2.7.16
pip3 --version
pip 18.1 from /usr/lib/python3/dist-packages/pip (python 3.7)
 python3 --version
Python 3.7.3

Là je sèche, si quelqu’un a une idée, d’avance merci

Bonjour

Il est souvent conseillé de passer cette clé en mode SUC à la place du mode SIC qui est le mode par défaut.
Cela se réalise avec l’application officielle de votre clé, depuis Windows.
Tout est indiqué ici :

Pouvez-vous testez cela et nous faire un retour ?

Notez aussi, que sur un Rapsberry Pi4, si vous avez l’ancienne génération de dongle Z-wave, il faut que celui-ci soit sur un hub USB2 et pas connecté directement sur le Pi.

Bonjour Fabrice,

Effectivement depuis mon passage sur PI4, ma clé est connectée à travers un hub USB2.
Je vais regarder pour le mode SUC vs SIC et je reviens vers vous.

Je remarque aussi, avec étonnement, que la charge de votre Pi est élevée.
A titre d’exemple voici ce que j’ai en ce moment sur un Pi3B+ : 0.2 - 0.23 - 0.24
- La charge va très rarement au delà de 1 chez moi.

J’ai regardé à plusieurs reprises et la charge est toujours au dessus de 1.5
Comment savoir ce qui consomme le plus de CPU ? Je désactive des plugins les uns après les autres et je regarde si ça améliore les choses ?

bonjour,
Juste pour ma culture quel est la différence entre mode SUC et SIC j’ai pas trouvé sur le net ou pas compris.

Bonjour

Alors je suis très septique sur le fait qu’il faut faire cette modification aussi, mais certains indique ne plus avoir eu de problème après. C’est pour cela que je souhaite un retour de l’utilisateur.

Pour les différences, j’ai trouvé cela :

Moi je comprends surtout que sic est l’évolution de suc.

Chez moi je suis en sic, c’est le réglage ar défaut du constructeur, j’imagine que c’est donc le meilleur choix.

Si tu maitrise l’anglais, je veux bien un retour :mask:

Sui vous le voulez je vous fait une trad de cet excellent article .

1 J'aime

Oui je suis preneur je m’endormais moins bête ce soir :smile:
Moi aussi je suis en mode SIC par défaut, jamais eus trop de soucis.

Bonjour Yves,

Une traduction totale, non, ce n’est pas utile je pense. Car c’est relativement bien traduit avec les outils comme Bing Translator.
C’est plus un résumer en Français qu’il faut, avec des points clés qui serait utile.

=> En fin de compte, savoir s’il faut le faire ou pas et si oui pourquoi et dans quelle condition.

Moi je comprend que ce n’est pas nécessaire avec 1 seul contrôleur.

Merci.

J’ai effectué la manip pour passer le dongle zwave en mode SUC. Il me semble qu’il était déjà dans ce mode avant que je ne le change mais je ne suis pas sûr d’avoir compris les infos remonté par le tool.
J’ai relancé le démon zwave et on va laisser tourner jusqu’à ce soir pour voir si ça tient davantage ou pas.
Je vous tiens au courant

JC

Static Update Controller (SUC) et SUC ID Server (SIS)

S’il y a un contrôleur primaire dans le réseau, il va fournir sa table de routage à tous les contrôleurs secondaires inclus dans le réseau. Cependant après que le contrôleur primaire aura inclus ou exclus un équipement sur le réseau les tables de routage de tous les contrôleurs secondaires deviendront invalides

Afin d’assurer qu’il n’y ait qu’une seule table de routage valide et à jour, le contrôleur primaire est le seul équipement autorisé à inclure/exclure des équipements. Les contrôleurs secondaires demandent alors périodiquement une mise à jour de la table de routage.

Cependant, pour un usage plus agréable d’un réseau Z-Wave nous serions en droit d’attendre que

  • Toutes les contrôleurs téléopérés soit capables d’inclure des équipements et de faire du routage
  • Les tables de routage de tous les contrôleurs du réseau soient maintenues en cohérence et qu’une mise à jour continue de permettre à chaque contrôleur de contrôler tous les équipements du réseau.

La meilleure façon de faire cela est de configurer un contrôleur SUC/SIS dans le réseau.

Static Update-Controller (SUC)

Le contrôleur Static Update Contrôler (SUC) est une capacité particulière d’un contrôleur statique. La plupart des contrôleurs statiques (contrôleurs à un emplacement fixe et alimentés par le réseau de puissance) peuvent remplir le rôle de SUC. Cependant, cette fonctionnalité requiert en général d’être activée.

Le SUC reçoit la table de routage mise à jour depuis le contrôleur primaire et met cette table de routage à disposition de tous les autres contrôleurs du réseau. Comme le SUC est un contrôleur statique et donc toujours actif dans le réseau, tous les autres contrôleurs peuvent à tout moment lui demander la table de routage à jour.

Afin de s’assurer que tous les autres nœuds, en particulier les contrôleurs, sont avertis de l’existence d’un SUC dans le réseau, l’ID du Nœud du SUC actif est périodiquement communiqué au sein du réseau.

image
SUC dans un réseau Z-Wave

L’existence d’un SUC permet à un contrôleur « nomade » de jouer le rôle de contrôleur primaire. Tout changement dans le réseau dû à une inclusion ou une exclusion d’un nœud par le contrôleur primaire est communiqué au SUC ; ceci persiste vers tous les autres contrôleurs même lorsque le contrôleur primaire n’est pas actif.

image
Mise à jour de la Table de Routage du SUC Routing

Puisque la plupart des contrôleurs nomades fonctionnent sur batterie et ne sont pas actifs en permanence par définition, ces contrôleurs doivent périodiquement demander la table de routage à jour ou à minima lors de leur réveil, en général par appui sur un bouton.

Si le contrôleur primaire nomade est perdu ou endommagé, le SUC peut attribuer le privilège de contrôleur primaire à un nouveau contrôleur nomade, évitant ainsi à l’usager de devoir refaire une installation complète du réseau avec un tout nouveau contrôleur primaire et de devoir changer son Home ID.

Static ID Server (SIS)

Même la présence d’un SUC dans le système ne résout pas le problème de l’unicité du contrôleur qui a le privilège de contrôleur primaire, seul contrôleur donc autorisé à inclure de nouveaux équipements. Cette limitation est contournée par ajout d’une autre fonctionnalité au SUC appelée SIS‘ = Static ID Server .

La SIS agit comme un magasin à IDs de Nœuds qui peuvent être attribués par les contrôleurs nomades. La présence du SIS dans le réseau permet à tous les contrôleurs du réseau d’inclure des équipements. Le contrôleur à juste besoin de demander au SIS un nouvel ID de Nœud et d’attribuer ce nouvel ID au serveur. Le SIS garantit que les IDs de Nœuds sont attribués de manière univoque à chaque nœud pour éviter les conflits. La seule obligation est que le contrôleur nomade ait une connexion avec le serveur SIS pour lui permettre de récupérer les ID de Nœuds.

image
Serveur SIS Server dans un réseau Z-Wave

L’utilisation du SIS dans votre réseau a quelques avantages et inconvénients :

Avantages

  • La topologie du réseau et les informations sur les nœuds sont sauvegardées dans un contrôleur statique de manière plus performante que sur un équipement nomade alimenté sur batterie
  • Tous les contrôleurs du réseau peuvent inclure de nouveaux équipements
  • La configuration et la gestion du réseau deviennent très flexibles

Inconvénients

  • La fonctionnalité n’est disponible qu’a partir de la version 3.4 du firmware Z-Wave – les équipements réseau avec un firmware plus ancien ne supporteront pas cette configuration
  • Le contrôleur d’Inclusion ne peut inclure des équipements que s’il est en liaison radio avec le SIS
  • Le SIS représente un point de faiblesse singulier. Un SIS endommagé peut conduire à une réinstallation complète du réseau à partir de zéro.

Comme la capacité de SUC/SIS est déjà incluse dans le firmware de la plupart des contôleurs statiques modernes, ou des dongle USB, la plupart des réseaux Z-Wave peuvent profiter de ces fonctions dès qu’un contrôleur statique est présent (dans la mesure où l’usager l’active).

Un contrôleur statique peut être utilisé comme contrôleur primaire et aussi avoir la fonction de SUC/SIS. Cette configuration est courante dans les réseaux réels.

image
Règles de contrôleur dans l’interface utilisateur d’une Gateway

Réseaux avec des Nomades Esclaves (Portable Slaves)

Lorsqu’un contrôleur SUC est présent dans le réseau, il est apte à déterminer une nouvelle position pour un esclave et mettre à jour la table de routage du réseau en conséquence. La procédure qui permet ceci s’appelle “ Algorithme de Recherche des Egarés ” (“ Get Lost –Algorithm ”) et ne fonctionne que sur des esclaves de routage (esclaves qui ont une connaissance partielle des informations de routage du réseau)

Un nœud esclave normal n’est pas autorisé à envoyer des messages non sollicités et par conséquence ne peut jamais déterminer ni les changements ni sa position au sein du réseau. Cependant, les nœuds Esclaves de Routage ont l’autorisation eux de le faire.

Si un nœud Esclave de Routage envoie un message non sollicité qui échoue, sa table de routage sera présumée invalide.

Comme première action ce nœud va envoyer un message broadcast “Appel à l’aide” dans le réseau. Un nœud qui reçoit un tel message sait que son émetteur s’est retrouvé à un nouvel emplacement. Ce nœud par contre ne peut pas fournir au “nœud en détresse” une table de routage à jour. Si ce nœud est un nœud de routage esclave il va acheminer le message “Appel à l’aide” au SUC.

Le SUC peut mettre à jour sa propre table de routage et affecter de nouvelles routes au nœud en détresse en déroulant les mêmes étapes qu’il déroulerait lors de l’inclusion d’un équipement. Le message “Appel à l’aide” est capable de d’autoréparer un réseau lorsqu’un nœud a été déplacé.

Afin de disposer d’une fonction effective d’autoréparation au sein d’un réseau, les conditions suivantes doivent être remplies :

  • Un SUC doit exister au sein du réseau
  • Les nœuds déplacés doivent être des nœuds de routage esclaves, pas des nœuds esclaves standard (pour autoriser le principe de message non sollicité)
  • Sur la nouvelle position il doit y avoir au moins un esclave routeur à portée de communication
  • Le nœud déplacé doit pouvoir détecter qu’il a été déplacé. Ceci n’est possible que si ce nœud envoie un message non sollicité
2 J'aimes

Bonjour,

Merci à Yves pour la traduction.

En ce qui concerne mon problème, le réseau Zwave a de nouveau planté hier.
Il y a des logs jusqu’à 14h10 puis plus rien jusqu’aux messages d’erreur vers 21h50.
Je vais relancer les dépendances au cas où mais je l’ai déjà fait plusieurs fois et le problème revient quand même.

Des idées ?

2020-12-28 14:08:34.838 Info, Node031, Received Meter report from node 31: Power=0.00W
2020-12-28 14:08:34.838 Info, Node031,     Previous value was 0.00W, received 301 seconds ago.
2020-12-28 14:08:35.837 Info, Node031, Received Meter report from node 31: Voltage=238.69V
2020-12-28 14:08:35.837 Info, Node031,     Previous value was 239.33V, received 301 seconds ago.
2020-12-28 14:08:36.837 Info, Node031, Received Meter report from node 31: Current=0.00A
2020-12-28 14:08:36.837 Info, Node031,     Previous value was 0.00A, received 301 seconds ago.
2020-12-28 14:10:14.647 Info, Node038, Received Meter report from node 38: Energy=77.36kWh
2020-12-28 14:10:14.647 Info, Node038,     Previous value was 77.36kWh, received 301 seconds ago.
2020-12-28 14:10:14.818 Info, Node038, Received Meter report from node 38: Energy=77.36kWh
2020-12-28 14:10:14.818 Info, Node038,     Previous value was 77.36kWh, received 301 seconds ago.
2020-12-28 14:10:15.458 Info, Node038, Received Meter report from node 38: Power=0.00W
2020-12-28 14:10:15.458 Info, Node038,     Previous value was 0.00W, received 301 seconds ago.
2020-12-28 14:10:15.629 Info, Node038, Received Meter report from node 38: Power=0.00W
2020-12-28 14:10:15.629 Info, Node038,     Previous value was 0.00W, received 301 seconds ago.
2020-12-28 14:10:16.448 Info, Node038, Received Meter report from node 38: Voltage=234.68V
2020-12-28 14:10:16.448 Info, Node038,     Previous value was 233.63V, received 301 seconds ago.
2020-12-28 14:10:16.615 Info, Node038, Received Meter report from node 38: Voltage=234.68V
2020-12-28 14:10:16.616 Info, Node038,     Previous value was 233.63V, received 301 seconds ago.
2020-12-28 14:10:17.448 Info, Node038, Received Meter report from node 38: Current=0.00A
2020-12-28 14:10:17.448 Info, Node038,     Previous value was 0.00A, received 301 seconds ago.
2020-12-28 14:10:17.616 Info, Node038, Received Meter report from node 38: Current=0.00A
2020-12-28 14:10:17.616 Info, Node038,     Previous value was 0.00A, received 301 seconds ago.
2020-12-28 21:50:07.915 Info, Node016, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 -
2020-12-28 21:50:07.915 Info, Node016, SwitchMultilevel::Set - Setting to level 0
2020-12-28 21:50:07.915 Info, Node016,   Duration: Default
2020-12-28 21:50:07.915 Info, Node016, Sending (Send) message (Callback ID=0xbf, Expected Reply=0x13) - MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Set (Node=16): 0x01, 0x0f, 0x00, 0x13, 0x10, 0x08, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x01, 0x00, 0xff, 0x25, 0xbf, 0xd4
2020-12-28 21:50:08.916 Error, Node016, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-12-28 21:50:08.917 Info, Node016, Sending (Refresh) message (Callback ID=0xc0, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Get (Node=16): 0x01, 0x0d, 0x00, 0x13, 0x10, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x02, 0x25, 0xc0, 0x5b
2020-12-28 21:50:09.917 Error, Node016, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-12-28 21:58:40.283 Info, Node036, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 - W
2020-12-28 21:58:40.283 Info, Node036, SwitchMultilevel::Set - Setting to level 87
2020-12-28 21:58:40.283 Info, Node036,   Duration: Default
2020-12-28 21:58:40.283 Info, Node036, Sending (Send) message (Callback ID=0xc1, Expected Reply=0x13) - SwitchMultilevelCmd_Set (Node=36): 0x01, 0x0b, 0x00, 0x13, 0x24, 0x04, 0x26, 0x01, 0x57, 0xff, 0x25, 0xc1, 0xac
2020-12-28 21:58:41.283 Error, Node036, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-12-28 21:58:41.284 Info, Node036, Sending (Refresh) message (Callback ID=0xc2, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=36): 0x01, 0x09, 0x00, 0x13, 0x24, 0x02, 0x26, 0x02, 0x25, 0xc2, 0x00
2020-12-28 21:58:42.284 Error, Node036, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-12-28 21:58:53.674 Info, Node036, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 -
2020-12-28 21:58:53.674 Info, Node036, SwitchMultilevel::Set - Setting to level 12
2020-12-28 21:58:53.674 Info, Node036,   Duration: Default

Bonjour,

Cette histoire de charge CPU m’a mis la puce à l’oreille.
Quand je regarde ce qui consomme du CPU sur mon PI4 avec htop, je vois que ce sont 2 process python 2220 et 2232 qui prennent 100% du CPU avec openzwaved.
image

que se passe t-il ?

Merci @Yves19 pour le partage « en français » de l’explication du mode SUC. Je ne comprends toujours pas vraiment l’intérêt de ce SUC. La plupart d’entre nous sont dans une configuration simple avec un seul contrôleur Z-Wave. Je suis resté dans le mode par défaut, donc pas de SUC chez moi.

Les problèmes de réseau Z-Wave ne sont pas là !

Non, le problème n’est pas là. Si tu n’a pas pas de mise à jour, il n’y a pas de raison de les relancer.

Oui

Est-ce que tu as fixé en dur le port USB de ta clé Z-Wave si tu as d’autres clés branchée sur ta box Jeedom ? Si elle se déconnecte de temps en temps à cause d’une autre clé, c’est mort pour la stabilité. J’ai mis plus d’un mois pour comprendre ce problème de merde. Lire ici Changement inopiné port USB clé ZWave Sur ce point, ce serait vraiment mieux si le(s) plugin(s) demandai(en)t directement le path unique de la clé dans /dev/serial/by-id/usb-0658_0200-if00, il n’y aurait plus ce problème d’identification de clé.

Tes modules 16 et 36 ont un souci avec la classe COMMAND_CLASS_SWITCH_MULTILEVEL
Quels sont tes modules ?

Perso, je n’ai pas rencontré de problème avec cette classe. Mais, j’ai rencontré des problèmes similaires avec d’autres classes mal supportées par openzwave. J’ai supprimé tout ce qui n’était pas utilisé. Je te laisse tout le fil.

Depuis 8 mois que j’ai effectué ce nettoyage drastique, je n’ai plus eu d’emmerdes avec le réseau Z-Wave. Aucun soin du réseau depuis ! Il reste encore quelque petits trucs, mais j’en ai vraiment marre…

Quelle est la durée de ton timeout ? On dirait qu’il est de 1 seconde dans les logs ! C’est trop court, il faut mettre au minium à 4 secondes (valeur par défaut). Il y a plein de Dropping command par manque de temps sinon.

Si tu mets un timeout trop long, ça peut bloquer la queue trop longtemps et engendrer d’autres problèmes qui n’auraient eu lieu si la queue n’avait pas été bloquée à ce moment là. Pa exemple, les modules sur pile n’ont plus le temps de se réveiller, il faudra plusieurs réveil pour que tout soit complet.

@Domatizer merci pour la piste du port USB.

ça pourrait bien expliquer mon problème.
J’ai mis en place le fichier avec les liens comme décrit dans le fil que tu as mis en référence. J’ai relancé, on va voir si ça tient.

Concernant ta question sur le noeud 16, il s’agit d’un Fibaro FGD-212 Dimmer 2. Il pilote l’éclairage d’une partie du jardin. Pour le noeud 36, il s’agit également d’un dimmer Fibaro mais au format rail din qui pilote l’éclairage de mon garage. Je les utilise en switch on/off pas comme dimmers.

Tu parles du timeout, ou est-ce que je peux voir cette valeur ?

merci pour ton aide

Si tu poses la question, tu n’as pas du modifier cette valeur :innocent:

Dans ce fichier
/var/www/html/plugins/openzwave/resources/openzwaved/config/option.xml
à la ligne
<Option name="RetryTimeout" value="8000" />
(valeur en millisecondes)

Pour le module Fibaro FGD-212 Dimmer 2, tu peux effectuer les mêmes modifs que moi. Tout est dans le lien.

Effectivement, je n’avais pas touché à cette valeur. Je viens de la passer à 8000 dans le fichier indiqué.

Par contre, je crains que mon réseau zwave ne soit à nouveau planté. Après avoir redémarré le RPI4, tout a fonctionné correctement, j’ai sélectionné les ports USB par leurs noms symboliques créés dans le fichier 99-usb-serial.rules comme indiqué et j’ai relancé les démons (Openzwave, Conbee et RFXtrx433).
Tout s’est bien lancé, j’ai vérifié dans les logs et la charge CPU dans la page santé est resté en dessous de 1 (0.5/0.6).
Au bout de qq temps, la charge CPU a augmenté (> 1.2). Dans les logs Openzwaved plus de messages, silence radio (c’est le cas de le dire :slight_smile: )
En allant voir le PI en ssh, top me remonte 100% d’utilisation du cpu par python openzwaved alors qu’après le redémarrage du RPI, le process qui consommait le plus était Apache avec 20/30%.

Je vais passer les logs Openzwave en Debug pour voir si j’obtiens plus de détails avant que tout ne s’arrête.

Le compromis est entre 4 et 8s. Si tu mets plus, tu va avoir d’autres problèmes avec les modules sur piles. Idéalement, il faudrait tout nettoyer les commandes mal supportées dans les fichiers config comme j’ai commencé à faire pour ne plus avoir de pénalités de timeout inutile. Mais, bon…

Pour moi, la charge CPU du RPi4 est à comparer avec la valeur 4, le nombre de CPU.
Donc 1.2 sur 4, ça va !

Bonjour,

Nouveau plantage d’Openzwave hier soir à 22h05 (toujours la même heure tous les soirs, ça doit correspondre à une action particulière, mais je ne vois pas laquelle.
Sinon, le plantage est consécutif à une commande sur un de mes dimmer 2 Fibaro avec COMMAND_CLASS_SWITCH_MULTILEVEL.
Ce qui est étrange c’est qu’à partir de 20h03 il n’y a plus aucun logs jusqu’à 22h05.
Le plantage doit donc avoir lieu à 20h03 et il y a un sursaut à 22h05.
Pour info le node 15 est un oeil Fibaro et le node 16 est un Fibaro Dimmer 2. Les deux sont installés et fonctionnent depuis plusieurs années sans soucis.

@Domatizer, j’ai regardé ton post sur les commnand class non supportés et il va falloir qui je m’y mette, mon reseau zwave démarre en 475 secs :frowning:

2020-12-29 20:02:33.780 Info, Node015, Received Basic set from node 15: level=255. Treating it as a Basic report.
2020-12-29 20:02:33.780 Detail, Node015, Refreshed Value: old value=true, new value=true, type=bool
2020-12-29 20:02:33.780 Detail, Node015, Changes to this value are not verified
2020-12-29 20:02:33.781 Info, Node015, SensorBinary::Set by basic report - Setting node 15 to On on instance 1
2020-12-29 20:02:33.781 Detail, Node015, Notification: ValueChanged
2020-12-29 20:03:19.734 Detail, Node015,   Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x0f, 0x03, 0x30, 0x03, 0x00, 0xcd
2020-12-29 20:03:19.734 Detail,
2020-12-29 20:03:19.734 Info, Node015, Received SensorBinary report: Sensor:205 State=Off
2020-12-29 20:03:19.734 Detail, Node015, Refreshed Value: old value=true, new value=false, type=bool
2020-12-29 20:03:19.734 Detail, Node015, Changes to this value are not verified
2020-12-29 20:03:19.735 Detail, Node015, Notification: ValueChanged
2020-12-29 20:03:19.788 Detail, Node015,   Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x0f, 0x03, 0x20, 0x01, 0x00, 0xdf
2020-12-29 20:03:19.788 Detail,
2020-12-29 20:03:19.788 Info, Node015, Received Basic set from node 15: level=0. Treating it as a Basic report.
2020-12-29 20:03:19.789 Detail, Node015, Refreshed Value: old value=false, new value=false, type=bool
2020-12-29 20:03:19.789 Detail, Node015, Changes to this value are not verified
2020-12-29 20:03:19.789 Info, Node015, SensorBinary::Set by basic report - Setting node 15 to Off on instance 1
2020-12-29 20:03:19.789 Detail, Node015, Notification: ValueChanged
2020-12-29 22:05:13.279 Info, Node016, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 -
2020-12-29 22:05:13.279 Info, Node016, SwitchMultilevel::Set - Setting to level 0
2020-12-29 22:05:13.279 Info, Node016,   Duration: Default
2020-12-29 22:05:13.279 Detail, Node016, Queuing (Send) MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Set (Node=16): 0x01, 0x0f, 0x00, 0x13, 0x10, 0x08, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x01, 0x00, 0xff, 0x25, 0xe3, 0x88
2020-12-29 22:05:13.279 Detail, Node016, Queuing (Refresh) MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Get (Node=16): 0x01, 0x0d, 0x00, 0x13, 0x10, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x02, 0x25, 0xe4, 0x7f
2020-12-29 22:05:13.280 Detail,
2020-12-29 22:05:13.280 Info, Node016, Sending (Send) message (Callback ID=0xe3, Expected Reply=0x13) - MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Set (Node=16): 0x01, 0x0f, 0x00, 0x13, 0x10, 0x08, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x01, 0x00, 0xff, 0x25, 0xe3, 0x88
2020-12-29 22:05:14.282 Error, Node016, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-12-29 22:05:14.282 Detail, Node016, Removing current message
2020-12-29 22:05:14.282 Detail, Node016, Notification: Notification - TimeOut
2020-12-29 22:05:14.285 Detail,
2020-12-29 22:05:14.285 Info, Node016, Sending (Refresh) message (Callback ID=0xe4, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Get (Node=16): 0x01, 0x0d, 0x00, 0x13, 0x10, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x02, 0x25, 0xe4, 0x7f
2020-12-29 22:05:15.285 Error, Node016, ERROR: Dropping command, expected response not received after 1 attempt(s)