Stabilité du zwave: c'était mieux avant ! (maj 2019-04-10 15:50:21)

[BLRPERES]

bonjour a tous

j'ai eu la mésaventure d'avoir ce probleme dernièrement...
et pour l'intant n'étant pas sur place je n'arrive pas à forcer la mise à jour.

auriez vous une "autre" idée de quoi faire?

ma conf: PI3B+ avec cle ZWAVE GEN5
plugin et jeedom last update
j'ai essayé aussi avec le plugin en beta ==> pas mieux
toujours pas d'information constructeur

mais je pense que mon probleme est encore plus grand car les modules ne réagissent pas quand je lance la commande
comme si le controleur etait indéfiniment indisponible alors que queue sortant est bien à 0

j'ai redémarré
cliqué sur générer les neud
synchroniser

pour l'instant les modules,essentiellement de FGD-212 avec neutre ou FGS-212 ne répondent pas malgré qu'ils sont vue comme ok.

[asarus]

Sans être sur place, ça va être plus difficile...

Pour te donner quelques pistes, après pas mal d'échanges avec Nechry et d'investigations j'ai en grande partie réglé mon problème (et ça fera l'objet d'un petit reportage)

Mon souci venait d'un réseau zwave saturé en nombre de messages (en moyenne pas loin de 9 messages / seconde sur cette fréquence), et du coup tout se met à mal fonctionner. Lors d'un update ou d'une coupure de courant, il n'arrive plus à faire le tour du réseau pour interroger les modules, il doit certainement essayer plusieurs fois, les modules doivent aussi tenter de remonter leurs infos et ça n'arrange rien...

Je ne sais pas pourquoi ni quand ça a commencé mais finalement j'ai utilisé une clé SDR pour mesurer l'activité sur le 868 mhz puis j'ai pris les statistiques (sur chacun des modules, un par un) du nombre de messages reçus et envoyés. Et j'ai refait pareil quelques heures après pour voir lesquels envoyaient le plus de messages.

Ensuite il a fallu les éteindre pour laisser un peu de bande passante pour les autres. Stabiliser le réseau en faisant redétecter les infos constructeur pour ceux qui ne les avaient plus. Très souvent j'ai du faire "regénérer la détection du noeud" mais c'est long car ça relance le réseau et ça nécessite qu'il soit stable sinon ça repart en vrille...

Et une fois le réseau, allégé de quelques modules, à peu près stable, j'ai remis les autres au fur et à mesure et vérifier leur config pour qu'ils communiquent de manière raisonnable sans saturer complètement la fréquence.

A distance, la seule chose que tu devrais pouvoir faire c'est prendre un module défaillant, faire "regénérer la détection du noeud" (ça relance le réseau), puis ensuite regarder si c'est bon. Si nécessaire tu enchaines ensuite sur "redétecter les infos du noeud"... et si tout est bon tu fais "synchroniser" pour que ça apparaisse bien. Et si ça marche, tu fais de même pour le module suivant, etc...

[BLRPERES]

Je sens que ça va être long
Surtout que je commence à avoir des modules morts (soit à pile soit parce qu’il y a un problème majeur)

Je continuerai à tester
Puis sinon allez retour sur place pour débrancher la clé et faire reposer tout ça


Envoyé de mon iPhone en utilisant Tapatalk

[dJuL]

Alors que ça marche pour "pas mal" de personnes le z-wave quand même

Je suis d'accord avec toi, mais il y a quelques cas comme asarus et moi sur le forum.

Ça fait bazarder des modules, en racheter, rebrancher, reconfigurer, etc.

Oui, c'est pour ça que je n'ai pas opté pour cette solution radicale sur un coup de tête, mais en cherchant sur le forum ce qui pouvait être amélioré.

Pour tes retours d'état, si ça se trouve c'était juste un souci avec les Widgets (et c'est même sûr en fait).

Pour les retours d'état, je ne me suis pas contenté de vérifier sur les widgets mais aussi à la source, dans la configuration du module, onglet Valeurs.
J'avais aussi ajouté des commandes action de refresh pour arriver à faire remonter l'état des relais.
Le plus risible, c'était d'avoir une puissance non nulle avec une lampe éteinte ou l'inverse, une lampe allumée avec une puissance à zéro.

Salut,

J'ai un appart tout neuf, une smart toute neuve, et j'ai passé toutes mes lampes en z-wave (fibaro dimmer ou relais)
Tout marche au poil avec les boutons physiques, heureusement...

Je viens de commencer mes scénarios et là c'est le drame.
J'ai remarqué que le problème se pose souvent lorsqu'il y a plusieurs commandes enchaînées...
Prenant l'exemple d'un OFF sur plusieurs modules :
Parfois certains commandes ne passent pas : il m'arrive également d'avoir l'état qui change (il passe bien sur 'off') mais pas la puissance consommée (et effectivement dans ce cas la lampe est bien resté allumée), parfois je vois l'état faire 'off' puis 'on' très rapidement sur le dashboard, ou parfois juste rien ne bouge...
Mon maillage est parfait, tout le monde atteint le contrôleur en direct, et il n' y a aucune erreur dans les logs zwave.
De ce que je voie les commandes semblent bien être toutes envoyées (pas très digeste les logs zwave)
Si je teste sur 5 ou 20 modules en même temps, parfois ça marche, parfois un ou deux modules ne prennent pas la commande, mais jamais les mêmes...
Bref c'est pas fiable
Pourtant je teste les états avant de lancer les commandes (je suis obligé d'ailleurs pour certains relais paramétrés en impulsion)
Quand à la rapidité de réaction c'est aléatoire aussi, parfois c'est instantané partout, parfois c'est bien plus long, et pareil, jamais sur les même modules.

Avant j'étais en X10, un vieux trucs, pas de retour d'état... Mais au moins les commandes passaient à 100%, même sur 20 modules.
Le temps de réaction était toujours sensiblement le même.
Et ce pendant plus de 10 ans.
Là il y a des ratés, alors que tout est neuf et à jour, et ça m’agace...
SI il y avait juste des problèmes de retour d'état, je m'en contenterais, mais des commandes qui ne s’exécutent pas là je trouve ça vraiment plus dramatique.

Tout mes modules sont inclus en mode sécurisé, je ne sais pas si ça peut jouer, mais compliquer de tout démonter pour tester en mode non sécurisé.

Je songe a tester avec un délais entre les commandes, pour voir si c'est mieux.

J'ai pris des modules neufs et une SMART pour ne pas me prendre la tête , pensant que ce serait fiable...
Pour le moment je suis déçus.

[dJuL]

Voila j'ai filtré les logs et j'ai le même type d'erreurs qu'en début de thread.

Ci-joint également l’exemple d'un état incohérent que j'ai réussi à reproduire.

[romanais]

Tu as quels modules pour gérer tes éclairages ?
Inclusion sécurisée ou classique ?
Je n'ai jamais eu ce genre de soucis.

[Jeandhom]

J'en étais arrivé à passer plusieurs fois la commande avec ce code pour arriver à mes fins. Mais c'est le manque aussi de fiabilité sur les retours d'état qui m'a fait lâcher ce protocole.
D'ailleurs, est-ce vraiment un problème de protocole ou de la librairie openzwave ?

Code : Tout sélectionner

/*	Récupération des tags sous la forme
    IDCMD="#[Cave][Prise][onduleur Off]#" ITERA=20
    IDCMD="#[Cave][Prise][onduleur On]#" ITERA=20
    Le troisième argument du tag IDCMD doit inclure la chaine (case sensitive ou sensible à la casse) On ou Off mais pas les deux à la fois
    [onduleur Off] fonctionne : 0xOn 1xOff
    [onduleur On] fonctionne : 1xOn 0xOff
    [Onduleur Off] ne fonctionne pas : 1xOn 1xOff
    [Onduleur On] fonctionne : 2xOn OxOff
    Le tag ITERA est optionnel, il écrase la valeur par défaut, ci dessous, qui peut être modifiée
    Si ITERA est égal à zéro ou $itera est égal à zéro alors les itérations pourront être illimitées (DANGEREUX)
*/
$itera = 25;
$tags = $scenario->getTags();
$iteratag = $tags['#ITERA#'];
$scenario->setLog("ItérationTAG : $iteratag");
if ($iteratag == NULL) {
  $iteramax = $itera;
} else {
  $iteramax = $iteratag;
}
$scenario->setLog("ItérationMAX : $iteramax");
$idcmd = $tags['#IDCMD#'];
$idcmd = str_replace("#", "", $idcmd);
$idcmd = str_replace("\"", "", $idcmd);
$scenario->setLog("idCMD : $idcmd");
$idetat = cmd::byString($idcmd)->getValue();
$scenario->setLog("idEtat : $idetat");
$namecmd = cmd::byId($idcmd)->getName();
$scenario->setLog("NameCMD : $namecmd");
$on = substr_count($namecmd,'On');
$off = substr_count($namecmd,'Off');
$scenario->setLog("Nb de On : $on");
$scenario->setLog("Nb de Off : $off");
if (($on == 0 and  $off > 0) or ($on > 0 and  $off == 0)) {
  $onoff = 0;
  if ($off == 0) {
    $onoff = 1;
  }
  $scenario->setLog("OnOff : $onoff");
  $i = 0;
  do {
    $i++;
    $cmd = cmd::byId($idcmd);
    $cmd->execCmd();
    do {
      sleep(1);
      $networkState = openzwave::callOpenzwave('/network?type=info&info=getStatus');
      $queueSize=$networkState['result']['outgoingSendQueue'];
    } while ($queueSize > 2);
    $cmd = cmd::byId($idetat);
    $valetat = $cmd->execCmd();
    $scenario->setLog("itération n°$i : $valetat");
  } while (($valetat != $onoff) and ($iteramax == 0 or $i < $iteramax));
  if ($valetat != $onoff) {
    $scenario->setLog("Commande non exécutée : Pas assez d'itération");
  }
} else {
  $scenario->setLog("Commande On ou Off : Indéfini");
}

[romanais]

On peut considérer tout de même que le zwave est stable.
Il y a un paquet de paramètres à voir. Ton matos, box et modules. Type d'inclusion. Charge de la machine, les versions installées etc.
Je gère quelques installations pour des amis et heureusement que je n'ai pas tous ces soucis

[dJuL]

Tu as quels modules pour gérer tes éclairages ?
Inclusion sécurisée ou classique ?
Je n'ai jamais eu ce genre de soucis.

Que du fibaro (sauf 1 qubino) : FGD-212 majoritairement, 1*FGS-222 et 2*FGS-223
Tout en sécurisé (sauf le 222 qui ne le supporte pas)

On peut considérer tout de même que le zwave est stable.
Il y a un paquet de paramètres à voir. Ton matos, box et modules. Type d'inclusion. Charge de la machine, les versions installées etc.
Je gère quelques installations pour des amis et heureusement que je n'ai pas tous ces soucis

Jeedom smart neuve avec dernière version stable et clef z-wave fournie avec.
Charge quasi nulle, aucun plugin installé

[romanais]

Ah sécurisé ! Figure toi que si je demandais ce qu'il en était pour toi c'est parce que les seules fois où j'ai vu vraiment des soucis sur les réseaux, c'était sur des inclusions sécurisées.
Aucune de mes installations ne l'est.
Ça alourdit considérablement les communications entre la clé zwave et les modules.
Il faudrait que je retrouve des infos là dessus.
Je sais que c'est censé tout fonctionner mais dans les faits...

[romanais]

Si t'as l'occasion de tout reprendre en non sécurisé (relou je sais), ça te permettrait d'éliminer tous les paramètres liés à ton matos, configuration et environnement.

[dJuL]

J'en étais arrivé à passer plusieurs fois la commande avec ce code pour arriver à mes fins. Mais c'est le manque aussi de fiabilité sur les retours d'état qui m'a fait lâcher ce protocole.
D'ailleurs, est-ce vraiment un problème de protocole ou de la librairie openzwave ?

Code : Tout sélectionner

/*	Récupération des tags sous la forme
    IDCMD="#[Cave][Prise][onduleur Off]#" ITERA=20
    IDCMD="#[Cave][Prise][onduleur On]#" ITERA=20
    Le troisième argument du tag IDCMD doit inclure la chaine (case sensitive ou sensible à la casse) On ou Off mais pas les deux à la fois
    [onduleur Off] fonctionne : 0xOn 1xOff
    [onduleur On] fonctionne : 1xOn 0xOff
    [Onduleur Off] ne fonctionne pas : 1xOn 1xOff
    [Onduleur On] fonctionne : 2xOn OxOff
    Le tag ITERA est optionnel, il écrase la valeur par défaut, ci dessous, qui peut être modifiée
    Si ITERA est égal à zéro ou $itera est égal à zéro alors les itérations pourront être illimitées (DANGEREUX)
*/
$itera = 25;
$tags = $scenario->getTags();
$iteratag = $tags['#ITERA#'];
$scenario->setLog("ItérationTAG : $iteratag");
if ($iteratag == NULL) {
  $iteramax = $itera;
} else {
  $iteramax = $iteratag;
}
$scenario->setLog("ItérationMAX : $iteramax");
$idcmd = $tags['#IDCMD#'];
$idcmd = str_replace("#", "", $idcmd);
$idcmd = str_replace("\"", "", $idcmd);
$scenario->setLog("idCMD : $idcmd");
$idetat = cmd::byString($idcmd)->getValue();
$scenario->setLog("idEtat : $idetat");
$namecmd = cmd::byId($idcmd)->getName();
$scenario->setLog("NameCMD : $namecmd");
$on = substr_count($namecmd,'On');
$off = substr_count($namecmd,'Off');
$scenario->setLog("Nb de On : $on");
$scenario->setLog("Nb de Off : $off");
if (($on == 0 and  $off > 0) or ($on > 0 and  $off == 0)) {
  $onoff = 0;
  if ($off == 0) {
    $onoff = 1;
  }
  $scenario->setLog("OnOff : $onoff");
  $i = 0;
  do {
    $i++;
    $cmd = cmd::byId($idcmd);
    $cmd->execCmd();
    do {
      sleep(1);
      $networkState = openzwave::callOpenzwave('/network?type=info&info=getStatus');
      $queueSize=$networkState['result']['outgoingSendQueue'];
    } while ($queueSize > 2);
    $cmd = cmd::byId($idetat);
    $valetat = $cmd->execCmd();
    $scenario->setLog("itération n°$i : $valetat");
  } while (($valetat != $onoff) and ($iteramax == 0 or $i < $iteramax));
  if ($valetat != $onoff) {
    $scenario->setLog("Commande non exécutée : Pas assez d'itération");
  }
} else {
  $scenario->setLog("Commande On ou Off : Indéfini");
}

Oui c'est justement ce que je cherche à éviter de faire, surtout avec un sleep de 1s entre les tests, ce qui va encore ralentir l’exécution...
Mais si pas le choix je vais passer par un truc du genre mais exécuté en background (car mes scénarios répondent).

[BLRPERES]

On peut considérer tout de même que le zwave est stable.
Il y a un paquet de paramètres à voir. Ton matos, box et modules. Type d'inclusion. Charge de la machine, les versions installées etc.
Je gère quelques installations pour des amis et heureusement que je n'ai pas tous ces soucis

Pour ma part j’avais une expérience semblable à la tienne sauf pour un projet qui a toujours été un peu récalcitrant
Jusqu’au plantage sévère

La conf est un pi3b+ avec ssd et cle gen5


Envoyé de mon iPhone en utilisant Tapatalk

[dJuL]

Si t'as l'occasion de tout reprendre en non sécurisé (relou je sais), ça te permettrait d'éliminer tous les paramètres liés à ton matos, configuration et environnement.

Oui j'y ait pensé, mais cela veut dire tout démonter... Bien relou...
Mais si il y a une chance que ça améliore les choses je tenterai peut-être

[dJuL]

Je vais la tenter en laissant tout dans les murs, je vois que ça marche même avec le bouton principal... Juste on est parfois un peu plus loin du contrôleur... Je vais faire ça on va voir...

Edit: tous les paramètres du module sont perdus lors de l'exclusion grrr...

Parfois aussi Jeedom bug et me ré-inclus le module dans le même equipement ID, en pétant son nom et ses réglages, et du coup en restant en mode sécurisé alors que j'ai inclus en mode non sécurisé... Obligé du coup de redémarrer le z-wave entre chaque exclusion/inclusion, c'est long...

[dJuL]

OK, mis à part ces soucis d'inclusion / exclusion (cf ci-dessus) je viens de finir l'étage.
Effectivement ça marche bien mieux et surtout c'est beaucoup plus réactif.
Le ping est d'ailleurs beaucoup plus faible dans la santé.
Pour l'instant 0 bug sur des commandes en simultanés sur 6 lampes.

Je vais faire toute la maison et garder que les capteurs d'ouverture en sécurisés (car eux remontent juste l'info et ça semble marcher) et je préfère pour les utiliser dans ma future alarme les avoir en sécurisé.

Je vous tiendrais au jus, mais si le mode sécurisé est foireux il serait peut être bon de l'indiquer un peu plus (j'ai même lu ici ou sur des blogs que c'était recommandé d'inclure en sécurisé)
Quand je vois la galère en plus pour avoir le cadenas fermé (forcer rafraîchissement du noeud... redémarrage de démon...), tout ça pour un truc qui marche pas bien.

[romanais]

Bon déjà si tu arrives à avoir un truc qui tourne et te redonne la foi c'est un bon début
Je crois que j'avais lu un truc intéressant de sarakha à ce sujet.
Si je retrouve des infos je reviendrai poster ça.

[dJuL]

Bon déjà si tu arrives à avoir un truc qui tourne et te redonne la foi c'est un bon début
Je crois que j'avais lu un truc intéressant de sarakha à ce sujet.
Si je retrouve des infos je reviendrai poster ça.

Ahah je suis pragmatique, je n'ai pas la foi...
Depuis même mes modules encore inclus en sécurisés semblent à nouveau mieux fonctionner.
Peut être qu'il y a une limite max de modules en sécurisés pour pas que ça bug...
Ou peut-être que c'est juste un hasard, à suivre... Je vais de toutes façons continuer à tout re-inclure.

Oui ça m'intéresse si tu retrouves le lien

[dJuL]

Après avoir tout essayé (vider le cache, redémarrer le démon...), j'avais toujours parfois le module ré-inclus sous le même nodeId et en mode sécurisé malgré mon choix, ce qui effaçait automatiquement l'équipement existant (pas cool pour mes scénarios).

Pour ceux que ça intéressent je pense avoir trouvé, il faut exclure le module plusieurs fois (au moins 2 fois pour les fibaros) pour qu'ils soit totalement exclu.

[dJuL]

Bon j'ai fini, mis à part 3 capteurs d'ouverture tout est maintenant en mode non sécurisé.
une fois lancé je voulais finir ça car c'est relou à faire...
Pour l'instant bonne nouvelle, tout semble marcher, aucune commande perdue, même en exécutant 20 commandes, et c'est instantané, plus de lag pourri comme j'avais avant.
Beaucoup moins d'erreur dans le log, quasi plus.
Plus de latence non plus, pourtant mon maillage est bien moins bon (normal vu que j'ai tout re-inclus)
A voir dans le temps ce que ça donne donc.
Si ça tient, c'est que c'était bien le mode sécurisé qui chie quand on exécute des actions sur un certain nombre de modules...