Oui, en cas d’erreur, tu dois les voir dans les fichiers log
Tes fichiers sont vides ou supprimés ? ça change tout, voir ce qui a été dit précédemment
Tes commandes (lumière, chauffage, prise, …) passent-elles toutes bien au bon moment ?
Tes capteurs remontent bien leurs états (porte, détecteur présence) à tous les coups ?
Content pour toi si tout fonctionne bien avec 45 modules, alors qu’elle est ta config précisément ?
Merci pour la réponse
Oui j’ai plus le log, je les supprime régulièrement
Oui la réactivité est là, parfois quelques widgets qui n’affichent pas la bonne info pour les prises électriques mais un appuis dessus les remets au bon état et j’ai un scénario qui les checks.
Je suis sur une smart avec dernière version V3
J’ai eu un soucis de réactivité mais c’était un module mal réglé qui envoyait trop souvent des infos et saturait le réseau zwave
Je viens ce soir d’avoir ( encore ) 1 changement d’état qui n’a pas fonctionné ( interruption réalisé a partir du bouton physique n’a pas été remonté dans jeedom et a laissé le level a 99 de ma lumière
Si on reboot la valeur ne change pas ( pourquoi ?!? )
Si je fais dans les options avancées du modèle forcer la mise à jour la curieusement la valeur est bien lu et passe a 0
En parallèle j’ai un scénario qui vient éteindre une prise électrique fibaro 1 h après et bim elle n’est pas éteinte ce soir ( alors oui ça marche 99% du temps … ) Mais bon sang comment il peut y avoir autant de rate ?
J’ai un maillage au top avec 23 modules soit en vert ou jaune au pire, un ping a moins de 100ms et pourtant il y a des ratés régulièrement ?!?
Comment peut-on avoir des outils pour faire une analyse complète ? ( Les logs vont être trop verbeux pour analyser LE message défaillant ) soigner un réseau n’est pas si parlant que ça sans son analyse ( il me dit toujours que tout va bien …)
Comment savoir si c’est saturé dans ce cas ?
Je tiens à dire que depuis que j’ai fait du nettoyage dans mon réseau z-wave (retrait des modules sécurisé + suppression des logs) j’ai bcp moins de soucis et améliorer drastiquement mes temps de réponses !
Bref merci pour le coup de main 
De mont côté, un peu d’analyses des fichiers log.
Pour commencer, j’ai fait le lien entre les warnings/erreurs, que je voyais régulièrement passer dans les log, et le tableau de statistiques.
Nombre de messages non-sollicités alors qu'en attente d'ACK : Warning, Node0XX, Couldn't Generate Nonce Key for Node XX
Nombre de retours inattendus : Warning, Node0XX, WARNING: Unexpected Callback ID received
Nombre de ACK retournés en erreur : Warning, Node0XX, WARNING: Device is not a sleeping node.
Nombre de messages non remis au réseau : Error, Node0XX, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
Nombre de messages jetés ou non délivrés : Error, Node0XX, ERROR: Dropping command, expected response not received after 1 attempt(s)
Ensuite, je me suis intéressé au démarrage du réseau, j’ai relancé une dizaine fois à la suite le réseau en faisant comme ceci : j’arrête le réseau Z-Wave, je choisis le niveau de log, je vide les fichiers log, je relance le réseau, j’attends le démarrage complet, j’arrête le réseau Z-Wave, je sauvegarde les fichiers log.
Au début, j’avais les 5 types d’erreurs traduis plus haut. Plus je relançais le réseau, plus il redémarrait vite, moins j’avais de soucis, et au bout d’un moment, il ne me restait qu’un nombre de messages jetés ou non délivrés pour tous les modules secteurs de façon systématique, les modules sur piles dorment, pas de message les concernant durant la phase de démarrage.
Remarque, je n’ai jamais eu d’erreur pour les messages suivants
Nombre de lectures en échec dues au timeout : 0
Nombre de messages d'échec dus au réseau occupé : 0
Nombre de messages reçus avec statut de routage occupé : 0
Donc, pas de soucis de réseau surchargé.
Voici un extrait du fichier log avec le niveau Warning, le fichier complet est ici openzwaved_demarrage_warning.log (11,0 Ko)
2020-03-12 22:47:29.194 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:47:33.666 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:47:37.668 Error, Node027, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:47:44.375 Error, Node027, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:47:52.866 Error, Node028, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:48:05.230 Error, Node029, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:48:19.099 Error, Node033, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:48:27.680 Error, Node045, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:48:31.842 Error, Node045, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:48:35.848 Error, Node045, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:48:41.135 Error, Node045, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:48:45.139 Error, Node045, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:48:49.778 Error, Node048, ERROR: Dropping command, expected response not receivtempsed after 1 attempt(s)
2020-03-12 22:48:53.934 Error, Node048, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:48:59.678 Error, Node050, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:49:04.155 Error, Node050, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:49:09.879 Error, Node054, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:49:14.352 Error, Node054, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:49:20.085 Error, Node061, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:49:24.559 Error, Node061, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:49:30.289 Error, Node062, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:49:34.767 Error, Node062, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:49:39.884 Error, Node074, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:49:44.942 Error, Node076, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:49:49.104 Error, Node076, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:49:53.678 Error, Node078, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:49:57.849 Error, Node078, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:50:03.602 Error, Node079, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:50:08.089 Error, Node079, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:50:13.231 Error, Node089, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:50:18.034 Error, Node092, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:50:22.496 Error, Node097, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:50:26.806 Error, Node109, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:50:31.041 Error, Node109, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:50:35.090 Error, Node110, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:50:39.965 Error, Node110, ERROR: Dropping command, expected response not received after 1 attempt(s)
Les noeuds correspondent exactement à TOUS les modules secteurs et les modules à piles Flirs.
Certains sont inclus en moe sécurisé avec le cadenas vert fermé ou ouvert ou sans cadenas, d’autres sont inclus en mode non sécurisé avec cadenas ouvert ou sans cadenas. Les modules sur piles non Flirs dorment, donc pas de message pour eux. Ces erreurs sont systématiques au redémarrage.
En regardant un redemarrage en mode Info cette fois, je remarque que les erreurs sont toujours liées à la commande AlarmCmd_Get donc ce n’est pas de la loterie, il y a un souci avec cette commande.
2020-03-12 23:12:13.975 Info, Node019, Sending (Send) message (Callback ID=0xa3, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): AlarmCmd_Get (Node=19): 0x01, 0x10, 0x00, 0x13, 0x13, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0xa3, 0x79
2020-03-12 23:12:14.013 Info, Node019, Request RTT 82 Average Request RTT 72
2020-03-12 23:12:17.931 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
Les fichiers complets sont ici si vous voulez regarder les erreurs pour les autres modules
openzwaved_demarrage_info.log (520,7 Ko) openzwave_demarrage_info.log (68,1 Ko)
Maintenant, si je passe en mode Debug pour une erreur du même type, je m’aperçois qu’il y a un problème de timout à chaque fois
2020-03-12 22:56:51.113 Info, Node076, Sending (Send) message (Callback ID=0xc1, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): AlarmCmd_Get (Node=76): 0x01, 0x10, 0x00, 0x13, 0x4c, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0xc1, 0x44
2020-03-12 22:56:51.122 Detail, Node076, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-03-12 22:56:51.122 Detail, Node076, ZW_SEND_DATA delivered to Z-Wave stack
2020-03-12 22:56:51.145 Detail, Node076, Received: 0x01, 0x07, 0x00, 0x13, 0xc1, 0x00, 0x00, 0x03, 0x29
2020-03-12 22:56:51.145 Detail, Node076, ZW_SEND_DATA Request with callback ID 0xc1 received (expected 0xc1)
2020-03-12 22:56:51.145 Info, Node076, Request RTT 31 Average Request RTT 30
2020-03-12 22:56:51.145 Detail, Expected callbackId was received
2020-03-12 22:56:55.117 Error, Node076, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-12 22:56:55.117 Detail, Node076, Removing current message
2020-03-12 22:56:55.117 Detail, Node076, Notification: Notification - TimeOut
Alors, qu’a-et-elle de particuliers cette commande AlarmCmd_Get pour génèrer des timout à tous les coups? Est-elle trop longue et prends trop de temps ?
En continuant mon enquête, j’ai découvert l’analyseur de fichier log sur le site OpenZWave OZW Utilities
Il analyse les lignes dans le fichier log openzwaved et rend la compréhension plus claire et avec des explications.
Pour cela, il faut enlever le fichier zwcfg_0x********.xml dans /var/www/html/plugins/openzwave/data, le sauver de préférence avant bien sûr. Perso, j’ai mis le niveau de log en Info, car trop de lignes en mode Debug et je perdais le début du fichier. Et sans les premières lignes du redémarrage du réseau, l’analyse échoue.
On peut rendre l’analyse publique, alors voici le résultat de mon redémarrage jusqu’à obtention de presque toute la matrice des voisins complète OZW Utilities
En erreur, j’obtiens le magnifique message suivant m’invitant à contacter le développeur.
A Message sent to 15 was dropped as the Controller rejected it. Please report to Developers
Traduction dans les détails : Le contrôleur a rejeté le message qu’il voulait envoyer. Génial !
Ben voilà pourquoi il ne veux pas envoyer l’ordre d’allumer ma lampe ce c*n.
Ça touche un peu tous les modules, sécurisés ou pas, sur secteur ou sur batterie.
Dans les Warnings, je retrouve principalement les problèmes avec AlarmCmd_Get
The Device did not acknowledge the message of type "AlarmCmd_Get". You should investigate if this device really supports the associated CommandClass
Pour la partie Info, je pense qu’il ne faut pas que je tienne compte des messages car j’ai un peu stressé le réseau pendant son redémarrage. J’ai réveillé à la main tous les modules sur pile afin de gagner du temps. Ceci a généré un peu plus d’erreurs que lors d’un redémarrage naturel en plusieurs heures.
Dans le premier onglet, c’est bizarre, il n’obtient pas les caractéristiques de presque tous les modules (modèles, fabricants, ID, etc). Dans Jeedom, ils apparaissent bien avec les tous les paramètres.
Je ne sais plus quoi faire… Changer de contrôleur, de box, de protocole ?
PS: Quand j’entends un « P*T**N » à l’autre bout de la maison, là je me dis : « Ah, tiens, voilà un ordre Z-Wave qui n’est pas passé ! », plus besoin de mettre des scenarii de surveillance.
J’ai également des commandes qui parfois ne passent pas alors que j’ai des modules alimentés en permanence et disposé assez régulièrement sur les étages. Je n’ai jamais pu remarquer que c’était telle zone où tel module qui posait plus régulièrement problème.
Citation
A Message sent to 15 was dropped as the Controller rejected it. Please report to Developers
Il me paraît difficile que ce soit un problème lié au code car s’il « encodait » mal le message que le contrôleur doit envoyer j’ai le sentiment que ce serait un bug permanent et donc reproductible.
Dans nos cas c’est à vue de nez un ordre sur 20 qui passe pas. Après tout ce sont peut être les contrôleurs qui ne sont pas du grande fiabilité et qui de temps en temps n’accepte pas les ordres ?
Ou bien le passage par la virtualisation puisque ça rajoute une couche ?
En détails, l’explication de l’erreur 4 http://openzwave.com/knowledge-base/senderror
Le message est rejeté par le contrôleur avant même qu’il ne soit envoyé, il ne l’envoi pas, c’est bien le problème.
Jeedom n’est pas virtualisé, il est installé sur un RPi
Quelles sont les alternatives ? Quel est le contrôleur le plus fiable ? Après avoir investi x000 € dans des modules Z-Wave, il faut trouver une solution afin que le réseau fonctionne…
Merci merci +10000 @Domatizer !!! Quel travail de fou pourquoi personne n’a communiqué ce truc d’analyseur et pourquoi il n’est pas inclus dans jeedom quand je disais qu’il y a un probleme et sur l’on avait aucun moyen d’analyse preuve que ce qui est présent dans jeedom « ne sert pas a grand chose »
Conclusion problème avec le développeur / développement ? Reste a voir si c’est côté core ou plugins …
J’avais bien compris que le message n’était pas envoyé par le contrôleur car rejeté.
Si tu as un RPi alors c’est que les problèmes ne viennent pas des systèmes de virtualisation qui ajoutent une couche à la liaison USB vers le contrôleur.
J’ai été voir sur le site openzwave pour en voir un peu plus et j’y vois personnellement plus clair.
La liste des devices compatible est indiquée, elle est impressionnante et il y a énormément de stick indiqué.
Maintenant je n’avais pas compris la remarque concernant le fait de rapporter le problème au développeurs. Il s’agit de rapporter le problème aux développeurs de OpenZwave. Partant de là comme je présume que Jeedom utilise la librairie OpenZwave (le plugin) sans modification il y a beaucoup de chance pour que le problème ne soit pas en relation avec Jeedom et son code.
Il est donc fort possible qu’il existe un problème dans le code de OpenZwave et que ce soit à cause de cela que parfois l’instruction rentre en violation du protocole lorsqu’il est demandé au contrôleur zwave d’envoyer un message.
Ce que je n’avais pas fais attention c’est qu’il existe une version 1.6 datant de fin décembre 2019 alors que Jeedom utilise une version 1.4 datant de 2016.
Il me semble clairement possible qu’entre la 1.4 et la 1.6 un certain nombre de bug de communication avec différents matériels est pu être corrigés et qu’en conséquence le passage en 1.6 puisse être en mesure de régler nos problèmes. Est-ce possible ?
De plus, les utilisateurs de Home Assistant / OpenHab qui utlisent aussi OopenZWav ont des problèmes du même genre. Donc, il y a des imperfections dans les librairies OpenZWave.
Je suis d’accord avec toi, le reverse engineering a ses limites, rien ne vaut le SDK officiel. Maintenant qu’il est passé dans le domaine publique, la situation devrait s’améliorer. C’est une question de temps. Pour l’instant, les modules Z-Wave semblent plus avancés en terme de fonctionnalités, ce qui leur donne encore l’avantage. Mais quand je vois le prix des prix des prises Wi-Fi, le choix pour de nombreuses personnes va être vite fait. Si on compare la fiabilité et la simplicité de la mise en œuvre d’un réseau Wi-Fi (ou Bluetooth), il n’y a pas photo. Le Wi-Fi sort vainqueur et pas besoin de contrôleur, tout le monde a une box internet.
La version 1.6 apporte plus de fonctionnalités pour certains modules et doit certainement corriger des défauts. Tant qu’on restera avec cette version 1.4, on va galérer. Actuellement, ce sont les fonctions de base qui posent souci, actionner une lumière, récupérer l’état d’un détecteur de mouvement. Pour gérer les scènes avancées, les alarmes générale, inondation, feu, CO, etc, en dehors de Fibaro, il ne doit pas y avoir grand monde pour gérer toutes ces subtilités.
J’ai beaucoup lu et vu cette remarque à plusieurs reprises. J’ai donc craqué et fini par ré-inclure en mode non-sécurisé tous les détecteurs de mouvements Fibaro Motion Sensor. Là, c’est le jour et la nuit. Avant, je recevais des alertes tous les jours de plusieurs capteurs qui restaient bloqués à 1 ou à 0. Mouvement continu pendant 30min sachant que la durée de maintient est fixée à 30s après le dernier passage, il faudrait soit faire du sport ou un déménagement dans la pièce pour avoir une alerte.
Depuis le passage en non sécurisé des 12 détecteurs de mouvement, je n’ai pas eu un seul raté !
Pourquoi n’est-il pas dit officiellement que certains modules ne fonctionnement pas correctement en mode sécurisé avec OpenZWave tout simplement ?
Quand je vois la promotion du mode sécurisé sur certains blogs, je me pose des questions. Ils font comment ces gens ? Juste un réseau avec 2 modules le temps de faire un article !
Je suis prêt à accepter que tout ne soit pas au point mais qu’on me dise clairement ce qui fonctionne bien et ce qui est toujours expérimental : exemple, tel module fonctionne en sécurisé s’il est seul mais ne fonctionne pas bien en présence de tel autre module inclus de tel manière.
Statistiquement, le nombre d’erreur de ce type diminue.
Error, NodeXXX, ERROR: Dropping command, expected response not received after 1 attempt(s)
Mais ces erreurs sont toujours présentes même pour les nouveaux nœuds non sécurisés.
Toujours le souci avec AlarmCmd_Get comme décrit précédememnt
Encore une question, j’ai souvent des erreurs javascript qui reviennent régulièrement.
Le mode sécurisé en effet fonctionne uniquement si l’on a quelques capteurs. Sur pile si l’on met des capteurs en sécurisé le réseau ne fonctionne plus correctement. Pourquoi exactement je n’ai pas la réponse mais en tout cas c’est le cas. Donc oui il ne faut pas utiliser la sécurité S0 alors qu’on nous vends cela comme étant utilisable, la réalité est toute autre.
Bonne question il faudrait demander à l’équipe qui gère cela mais tu dois bien comprendre pourquoi il ne communique pas sur le sujet clairement.
De toute manière tant que Jeedom n’aura pas un plugin Zwave basé sur le SDK officiel de Silicon Labs cela ne pourra pas fonctionner correctement. On aura pas de S0 et encore moins de S2, Smart Start, …
Pour ton erreur Javascript fait un ticket j’en ai aucune idée.
Hello,
Juste pour mitiger un peu cette pseudo « règle »
J’ai une cinquantaine de modules zwave, inclus en sécurisé pour ceux qui le supportent (sans défendre ou prétendre que cela était nécessaire) et mon réseau est globalement stable, tout fonctionne « normalement »…
Donc je ne sais pas d’où tu tires cette règle mais cela ressemble à de la spéculation
Heureux de l’entendre que cela fonctionne pour toi et tu as raison rien n’est écrit dans le marbre. Mais pour autant ce qui fonctionne pour une personne n’est pas le cas d’usage obligatoire pour les autres.
Par retour d’expériences de plusieurs utilisateurs ayant des problèmes sur leur réseaux zwave, cela vient souvent des modules inclus en mode sécurisé quand ils sont sur piles (détecteurs d’ouvertures, …) et de leurs ratios piles / courant. Apres il y a aussi les distances, les murs, le nombre de saut, …
En ce qui te concerne Mips, peux tu donner plus de détail sur ta configuration elle pourra peut etre d’y voir plus clair ? Tous tes modules sécurisés sont ils sur piles (sinon ratio piles/courant en mode sécurisé) ? quel est ton ratio pile sur courant au global ? Qu’utilise tu comme serveur hardware (puissance de calcul) ? Combien de saut as tu dans ton réseau ?
Bonjour,
une chose est certaine ce n’est pas le coté sécurisé qui est la cause des problèmes. Je n’ai aucun module en mode sécurisé et je ne peux pas dire que j’ai un réseau stable (fiable).
Je pense de plus en plus à un problème de performance. C’est à dire que dans certaines circonstances, si les performances (host) ne sont pas au top le système (réseau, drivers plugin, clef ?? ) part au tas.
Si par exemple il y a « beaucoup » de module en mode sécurisé la charge doit être plus importante quelque part et cela induit des délais qui à un moment ou l’autre conduis au « crash » du plugin.
Chez moi par exemple, je surveille depuis plusieurs semaines le nombre de message en attente dans la file d’attente et je n’arrive pas à expliquer pourquoi à certains moments elle augmente. J’ai mis en place quelques contres mesures pour éviter d’arriver à un crash. Par exemple pour certains modules, j’ai désactivé la mise à jour auto des états et je le fais « manuellement » par scénario. La première chose faites dans ces scénarios est de vérifier l’état de la file et si elle n’est pas vide reporter la demande de mise à jour.
Je touche du bois, mais depuis que j’ai généralisé cela je n’ai plus de crash, je vois la file monter au maximum à 10 messages puis aussitôt revenir à 0.
ken@vo
Phil
On est bien d’accord, cela « semble » (à prendre vraiment avec de pincettes ce genre de supposition) lié.
Et beaucoup de personne ont un problème sur leur installation et comme toujours, beaucoup plus n’en ont pas et ne viennent pas l’écrire ; bref tout cela ne sert pas beaucoup car on n’a juste pas la vue complète et c’est impossible de tirer des conclusions.
Concernant mon install, j’ai pris l’habitude de toute inclure en mode sécurisé, sans trop savoir pourquoi au départ, on se dit forcément que c’est mieux
J’ai très peu de route avec plus qu’un saut mais j’en ai.
Les modules sont réparti sur 3 niveaux d’en moyenne une centaine de m² chacun (moins pour le 3eme, c’est le grenier)
Béton entre le rez et le 1er et plancher avec le grenier (2 prises connectées s’y trouvent)
la plupart des murs sont très épais au rez (>40cm, ancienne construction rénovée)
j’ai beaucoup de micro-modules (fibaro, est-ce qu’il y aurait différente qualité dans les marques?) dans les interrupteurs, quasi chaque pièce, cela doit aider pour le maillage.
et quelques prises connectés réparties un peu partout dans la maison.
Parmi les modules sur piles (une petite vingtaine au total), je n’ai que deux détecteurs de porte qui ne sont pas en sécurisé (ils ne le supportaient pas); sinon y a des oeils fibaro, des détecteurs philio et des têtes de vannes thermostatiques eurotronnic (tout cela en « sécurisé »)
Donc 8 « détecteurs », 7 vannes et le reste de types interrupteurs/télécommandes
Je tournait sur une smart a début, une vm proxmox sur un nuc maintenant et effectivement j’ai eu des soucis de maillage, d’ordre qui ne passait pas au début (j’avais les remarques de la famille qui « ca ne marchait pas »), j’ai eu plusieurs fois le problème de queue qui augmentait, le démon qui ne répondait plus avec l’erreur sur le buffer (je ne me rappelle plus très bien)
Depuis que je suis sur nuc plus aucun soucis majeur, mais je ne peux pas être sur que cela soit la seule raison…
Cela arrive encore parfois qu’une lampe ne s’allume pas ou que le retour d’état ne se fasse pas (jeedom voit toujours la lampe comme allumée alors qu’elle est éteinte), genre 1 cas toutes les 2 semaines.
Si j’avais le courage (et le temps), je pense que ré-inclurait le tout en non-sécurisé pour tester si cela règlerait les derniers cas mais vu la surface à couvrir et le placement des modules je devrait monter un jeedom temporaire sur un pi que je peux déplacer pour faire les inclusions sans tout débrancher et cela sans être sur que le « sécurisé » soit la cause de ces drops
Merci pour ton retour.
Tu as mis le doigt sur plusieurs choses essentielles à mon avis sur un réseau Zwave sous jeedom et pour résumer voici mon avis :
Quand à la taille du nombre de module, elle peut être grande (sans problème avec une centaine de module) si l’on respecte les règles précédentes.
Et si vous avez du temps (merci le confinement) je vous conseil en effet pour ceux qui ont des problèmes de passer les modules sur piles en priorité en mode non sécurisé, ça permettra à votre réseau d’allez beaucoup plus vite et d’éliminer un certains nombres d’erreurs.
Mips pour le dernier cas que tu cites avec la lampe qui ne remonte pas le bon état, il faudrait regarder dans ce cas là les logs précis, et voir si a ce moment là il y eu une erreur de communication et voir si cela se produit sur les mêmes modules, et donc ensuite regarder leur route.
J’ai compléter mon poste avec le ratio pile/secteur: 17/18 modules sur piles
Je n’ai pas précisé mais c’est effectivement toujours les mêmes 2, 3 modules (surtout 1 dans le garage) qui ont ce problème et effectivement ils se trouvent chacun respectivement à une « extrémité » du bâtiment.
et donc oui, j’essaierai de regarder plus en détails, mais de nouveau, vu que c’est la lampe du garage qui reste soit disant « allumée » une fois toutes les deux semaines, c’est pas urgent pour moi.
