Comme annoncé, ce forum est passé en lecture seule au 1er janvier 2020. Désormais nous vous invitons à vous rendre sur notre nouvelle page communauté :
Image

A très bientôt !

soigner le réseau

(anciennement dénommé plugin OpenZwave)
amerton
Actif
Messages : 522
Inscription : 28 août 2016, 12:11
Localisation : Espagne

Re: soigner le réseau

Message par amerton » 29 août 2019, 23:21

@Mav3656

Merci d’avoir pris le temps d’expliquer tout ceci aussi clairement et complètement.
Ta contribution est excellente!

Ça méritait un post pour le souligner.

Anthony

arnog23
Timide
Messages : 428
Inscription : 02 mars 2016, 21:50

Re: soigner le réseau

Message par arnog23 » 30 août 2019, 00:16

Salut,

@juju31,

je suis un peu dans le meme cas que toi. Lorsque j’essaie de soigner le réseau, il me fait une exclusion/inclusion pour pas mal de modules mais sans pertes des commandes. Il y a « seulement » le nom des modules exclus/inclus qui change. Ensuite, je vois que la file d’attente augmente progressivement jusqu’à faire planté le plugin et faire redémarrer automatiquement le service. Impossible donc d’aller jusqu’au bout...

Du coup, j’ai essayé de soigner les noeuds individuellement (seulement ceux sur secteur pour commencer) et dans ce cas, il me fait une exclusion/inclusion et récré toute les commandes. Du coup, toutes les références aux anciennes commandes sont en effet perdues. Je l’ai fait seulement pour 2 modules sur secteur pour le moment pour tester mais avec presque une centaines de modules (93 pour être exact : 48 sur secteurs et 35 sur piles), ça risque d’être très long à faire.

À côté de ça, mon réseau est plutôt stable et réactif mais je souhaite le soigner car il y pas mal de module que j’ai inclus près de la box et que j’ai déplacé ensuite mais sans soigner le réseau à chaque fois (ce que j’aurai probablement du faire) et quand je regarde dans les statistiques du plugin, je vois qu’il y a des messages perdus et les voisins de certains modules me semblent incohérents. Par exemple, deux modules placés côte à côte n’ont pas les mêmes voisins ...

Un autre truc bizarre quand je demande la mise à jour des voisins, j’ai l’impression que rien ne se passe, il n’y a rien qui apparaît dans la file d’attente ... ou alors cela se fait très rapidement mais j’en doute car je ne vois pas de mise à jour des voisins. Il faudrait que je passe les logs en mode debug pour essayer de voir plus précisément ce qu’il se passe.


Juju31
Timide
Messages : 149
Inscription : 09 févr. 2016, 21:07
Localisation : Banlieue Toulousaine

Re: soigner le réseau

Message par Juju31 » 30 août 2019, 09:15

Hello Nik0,

Merci de ton feedback.
J'en déduis que normalement c'est une opération transparente.

Concernant tes 4 points, j'ai tout bon !

Bon, ben je vais donc continuer à optimiser le réseau à a main en faisant des recherches de voisins sur les quelques modules qui ne me semblent pas avoir de route optimisée.

Nik0
Timide
Messages : 104
Inscription : 12 nov. 2017, 23:07

Re: soigner le réseau

Message par Nik0 » 30 août 2019, 14:06

ok parfait !
honnêtement, à la main, je pense pas que ça marchera, tu me diras si tu y arrives,
là, j'ai fait des script de soignage des nœuds qui posent problèmes toutes les 2-3 minutes
ça fait 2 jours que ça tourne et j'ai pas trop de résultat pour tant c'est les mêmes actions qu'à la main répétées encore et encore ...
donc j'imagine même pas sans les scripts ...

Nik0
Timide
Messages : 104
Inscription : 12 nov. 2017, 23:07

Re: soigner le réseau

Message par Nik0 » 01 sept. 2019, 11:41

Bonjour à tous, j'ai pas vraiment d'évolution dans mon réseau ...
je ne sais pas si c'est pertinent, mais à chaque fois que je lance des actions de "mise a jour des noeuds voisins" soigner le noeuds, j'ai ce message dans les logs openzwaved :

Code : Tout sélectionner

2019-09-01 11:37:15.361 Error, Node064, ERROR: Dropping command, expected response not received after 1 attempt(s)
2019-09-01 11:37:15.366 Error, Node064, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
à priori les actions se font dans le vide, donc c'est pas vraiment étonnant qu'il n'y ait pas d'évolutions ...
Est ce qu'il y a quelquechose à faire pour que ça fonctionne ou est ce que je continue comme ça de lancer des actions de soins ponctuellement sur tous les noeuds ?

au niveau des deux repeteurs, j'ai pu retrouver les infos constructeurs en rafraichissant régulièrement les valeurs des noeuds :
repeteurs.PNG
repeteurs.PNG (14.63 Kio) Consulté 5032 fois
là j'ai jamais eut un état de santé aussi clean.
ma table de routage est toujours asymétrique par contre mais la communication part dans le vide donc ça me semble normale
Capture.PNG
Capture.PNG (55.62 Kio) Consulté 5032 fois
est ce qu'il faudrait pas que je ping pour réveiller le nœud avant la demande de mise à jour ou quelquechose comme ça ?

j'ai modifié mon script de mise a jour des nœuds voisins toutes les 5 minutes dans le post plus haut pour que la valeur $nodeId soit récupérée en random suivant une liste de numéros de noeuds et non pas une plage. pour éviter que ça demande la mise à jour d'un noeud qui n'existe pas.
Nik0 a écrit :
29 août 2019, 08:53

et en 3ème, je force la mise à jour des nœuds voisins à intervalle de 5 minutes entre les requêtes de heal de noeuds
sur une plage random de noeuds que j'ai définir

Code : Tout sélectionner

// Setup
// Jeedom configuration/API/Clef API Z-Wave
$apizwave = 'YourZWaveAPIKey';
// the node Id to perform the ping
$randomChoice  = function($array) {return $array[array_rand($array)];};
$input = [8, 9, 11, 12, 13, 14, 15, 16, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 33, 35, 36, 37, 38, 39, 43, 44, 45, 47, 50, 61, 64, 67, 68, 70, 71, 73, 74, 75, 76];
$nodeId = $randomChoice($input);
// End Setup

$url = 'http://127.0.0.1:8083/node?node_id=' . $nodeId . '&type=action&action=requestNodeNeighbourUpdate&apikey=' . $apizwave;
$contents = file_get_contents($url);
//$scenario->setLog('Contents :'.$contents);
$results = json_decode($contents);
$success = $results->state;
if ($success != 'ok') {
    $scenario->setLog('ZAPI TestNode return an error: ' . $results->result);
}
j’espère que ça pourra servir à d'autre

Nik0
Timide
Messages : 104
Inscription : 12 nov. 2017, 23:07

Re: soigner le réseau

Message par Nik0 » 18 sept. 2019, 17:51

pour ceux que ça pourrait intéresser, vous trouverez ci- joint le témoignage de personnes qui se sont cassées les dents sur le Zwave
http://www.knx-fr.com/showthread.php?tid=3368
je regrette vraiment de m’être lancé là-dedans ...
Je ne vois pas quoi faire d'autre sur mon réseau pour que ça fonctionne - globalement, même si je comprend le principe d'intégration, je ne comprend pas que ça marche un peu mais pas trop ...
je ne comprend pas non plus que ça ne soit pas possible de soigner le réseau de façon automatisée ...

Shakto
Timide
Messages : 112
Inscription : 07 oct. 2017, 15:31

Re: soigner le réseau

Message par Shakto » 18 sept. 2019, 20:19

Allez cadeau à mettre dans un scénario :

Code : Tout sélectionner

// Jeedom configuration/API/Clef API Z-Wave
$apizwave = 'TONCODEAPIZWAVE'; // trouvable dans configuration / api / Clef API Z-Wave 
$url_health = 'http://localhost:8083/network?type=info&info=getHealth&apikey=' . $apizwave;
$scenario->setData('monitorZwave', '');
$errEqLogics = array();

//Code
$content = (file_get_contents($url_health));
$results = json_decode($content, true);
//$scenario->setLog($content);
$success = $results["state"];

if ($success != 'ok') {
    $scenario->setLog('ZAPI network getHealth return an error: ' . $results["result"]);
} else {
    // get the full node list
    $devices = $results["result"]["devices"];
    $node_errors = array();
    foreach ($devices as $node_id => $node_values) {
      	$scenario->setLog('Test du Node '.$node_id);
        $isFailed = $node_values["data"]["isFailed"]["value"];
        // device can be disabled from jeedom
        $enabled = $node_values["data"]["is_enable"]["value"];
        if ($enabled & $isFailed) {
          
			if(pingNodeFailed($node_id, $apizwave, $scenario)){
          
                if (count($node_errors) == 0) {
                    $scenario->setLog('****** These nodes are presumed dead ******');
                }
                // get the name of the device
                $node_name = $node_values["data"]["description"]["name"];
                $errEqLogics[] = 'NodeId ' . $node_id . ' ' . $node_name;
                // add a log entry
                $scenario->setLog('NodeId ' . $node_id . ' ' . $node_name);
                // add nodeId to the node list
                $node_errors[] = $node_id;
            }
        }
    }
    if (count($node_errors) != 0) {
        $scenario->setLog('*******************************************');
    }
    // save nodes list for external processing
    $scenario->setData("ZWave_Nodes_Death", implode(',', $node_errors));
  	$scenario->setData('monitorZwave', implode(",", $errEqLogics));
}

function pingNodeFailed($nodeId, $apizwave, $scenario){
    $scenario->setLog('Do a ping nodeid ' . $nodeId);
    //try first a ping
    $url_ping = 'http://localhost:8083/node?node_id=' . $nodeId 
      . '&type=action&action=testNode&apikey=' . $apizwave;
    $content = file_get_contents($url_ping);
    $results = json_decode($content, true);
    $success = $results["state"];
    if ($success != 'ok') {
            $scenario->setLog('ZAPI node testNode return an error: ' . $results["result"]);
    } else {
      //sleep for 3 seconds
      sleep(3);
      if (getNodeFailed($nodeId, $apizwave, $scenario)) {
        $scenario->setLog('Do a hasNodeFailed nodeid ' . $nodeId);
        // use special zwave command hasNodeFailed to test
        $url_hasNodeFailed = 'http://localhost:8083/node?node_id=' . $nodeId 
          . '&type=action&action=hasNodeFailed&apikey=' . $apizwave;
        $content = file_get_contents($url_hasNodeFailed);
        $results = json_decode($content, true);
        $success = $results["state"];
        if ($success != 'ok') {
          $scenario->setLog('ZAPI node hasNodeFailed return an error: ' . $results["result"]);
        } else {
          //sleep for 3 seconds
          sleep(3);
          return getNodeFailed($nodeId, $apizwave, $scenario);
        }
      }
    }
}

function getNodeFailed($nodeId, $apizwave, $scenario){
    $url_health = 'http://localhost:8083/node?node_id=' . $nodeId 
      . '&type=info&info=getHealth&apikey=' . $apizwave;
    $content = file_get_contents($url_health);
    //$scenario->setLog($content);
    $results = json_decode($content, true);
    $success = $results["state"];
    if ($success != 'ok') {
        $scenario->setLog('ZAPI node getHealth return an error: ' . $results["result"]);
        //I can confirm anything, we assume is not failed.
        return false;
    } else {
        if ($results["result"]["data"]["isFailed"]["value"]) {
            $scenario->setLog('nodeid ' . $nodeId . ' is failed');
        }
        return $results["result"]["data"]["isFailed"]["value"];
    }
}

Avatar de l’utilisateur
Patdec
Actif
Messages : 771
Inscription : 21 janv. 2015, 15:49
Localisation : Tournai

Re: soigner le réseau

Message par Patdec » 18 sept. 2019, 20:32

Shakto a écrit :
18 sept. 2019, 20:19
Allez cadeau à mettre dans un scénario :

Ce serait pas à mettre dans les tutos ce code gentiment proposé ? :)
Débutant Jeedom.
VirtualBox 6.0.10 sur Tablette I Works 12 sous Win 10 - Debian 9.9
Jeedom 3.3.36 - Contrôleur Aeotec ZW 090 C
Modules Fibaro FGR-222

Shakto
Timide
Messages : 112
Inscription : 07 oct. 2017, 15:31

Re: soigner le réseau

Message par Shakto » 18 sept. 2019, 21:31

Et la suite pour exploiter le bout du scénario

Image

Nik0
Timide
Messages : 104
Inscription : 12 nov. 2017, 23:07

Re: soigner le réseau

Message par Nik0 » 30 sept. 2019, 08:38

Aux dernieres nouvelles, l'assistance a trouvé un défaut soit avec la clef, soit avec l'alimentation.
L'alim que j'ai là bas est en 2,5A.
J'en ai racheté une de 3A ...
Et pareil pour la clef pour info, c'est déjà la deuxieme ... avant j'avais une everspring que j'ai changé pour une aeon gen5, là j'en ai racheté une 3eme donc ...
Me reste plus que 18h00 de train pour me taper le changement et "normalement" ça devrai marcher ...

Envoyé avec mes gros doigts from the moon



Avatar de l’utilisateur
Patdec
Actif
Messages : 771
Inscription : 21 janv. 2015, 15:49
Localisation : Tournai

Re: soigner le réseau

Message par Patdec » 30 sept. 2019, 10:00

18 h de lecture de doc Jeedom, tu vas être incollable :lol:
Débutant Jeedom.
VirtualBox 6.0.10 sur Tablette I Works 12 sous Win 10 - Debian 9.9
Jeedom 3.3.36 - Contrôleur Aeotec ZW 090 C
Modules Fibaro FGR-222

Mav3656
Helper
Messages : 70
Inscription : 12 févr. 2018, 16:22
Localisation : Nantes, France

Re: soigner le réseau

Message par Mav3656 » 30 sept. 2019, 11:51

Nik0 a écrit :
30 sept. 2019, 08:38
Aux dernieres nouvelles, l'assistance a trouvé un défaut soit avec la clef, soit avec l'alimentation.
L'alim que j'ai là bas est en 2,5A.
J'en ai racheté une de 3A ...
Et pareil pour la clef pour info, c'est déjà la deuxieme ... avant j'avais une everspring que j'ai changé pour une aeon gen5, là j'en ai racheté une 3eme donc ...
Me reste plus que 18h00 de train pour me taper le changement et "normalement" ça devrai marcher ...

Envoyé avec mes gros doigts from the moon
Bonjour Nik0,

Pense a reconsidérer la solution :
- reset du contrôleur (si tu pars d'un nouveau contrôleur, pas besoin de le reset c'est comme si c'était fait il est supposé vierge)
- pour chaque équipement, procédure d'exclusion (s'il est a porté du contrôleur, et même si ce n'est pas le contrôleur avec lequel il a été inclus) - ou - procédure reset de l'équipement (pour qu'il puisse être reassocié par la suite)
- suppression des équipements dans le plugin (c'est le plus simple si tu ne conserves pas tes historiques, sinon bien supprimer le node Id dans chaque équipement avant de ré-inclure tes nouveaux équipements)

:arrow: -----------Ce qui précède est absolument nécessaire avant de faire la moindre inclusion ------------ puis :

- inclusion des noeuds secteurs du plus proche au plus éloigné (bien attendre l'état "terminé" de l'inclusion, visible dans le panneau de configuration de l'équipement)
- en dernière étape, inclusion des noeuds ne participant pas au maillage (pile, FLiRS, ...)

Tu ne t'en sortiras pas dans un temps limité autrement. Je t'ai écris des postes détaillant la marche a suivre si tu souhaites conserver tes historiques de commandes.

:idea: N'hésites pas a faire des screenshot de ta table de routage avant/après chaque inclusion si tu as besoin d'aide ou support. Il est normal de ne pas avoir que du vert. Mais tu dois avoir des communications directes entre tes modules de proximité, et toujours une route qui te permet d'atteindre le contrôleur principal. Dès que tu déroges à cette règle, tu as un problème a résoudre avant de continuer.

:idea: Un conseil également, après une inclusion (réussie ou pas), clique sur synchroniser. Vérifie que tu connais chaque modules que tu rajoutes. Parfois, si une inclusion est ratée, des modules "unknown" peuvent apparaître. Il faut alors résoudre la situation avant d'aller plus loin. Je t'ai expliqué dans un poste précédent la marche a suivre pour supprimer ces modules (onglet action et supprimer noeud en échec sur le noeud concerné).

Enfin, pour rappel, soigner ton réseau de manière automatique est techniquement réalisable mais n'ai pas une bonne solution dans un environnement qui n'est pas modifié (instabilité du réseau pendant le processus, consommation de piles excessive par exemple).

:arrow: Le zwave n'est pas compliqué, tout s'éclaircit lorsqu'on comprend ce que l'on fait. ;)
Mav3656 - Helper Officiel Jeedom

Nik0
Timide
Messages : 104
Inscription : 12 nov. 2017, 23:07

Re: soigner le réseau

Message par Nik0 » 30 sept. 2019, 11:59

Honnetement j'avais pas dans l'idée de me refaire l'inclusion des 52 controlleurs dans le we pour la 4eme fois, je pensais juste sauvegarder les données de l'ancienne clef, remettre la sauvegarde sur la nouvelle, et relancer la box ...
Et en gros, je pensais en avoir pour 2h et rentrer.
Tu penses qu'il va falloir que je me retape l'inclusion de tous les modules avec la nouvelle clef ?
Si c'est le cas, il faut plutot que je prevois 2 semaines.

Envoyé avec mes gros doigts from the moon


Nik0
Timide
Messages : 104
Inscription : 12 nov. 2017, 23:07

Re: soigner le réseau

Message par Nik0 » 01 oct. 2019, 09:58

ci-joint, l'erreur qui a été détecté dans les logs et qui a conduit a une mauvaise communication entre le Rpi et la clef Zwave et donc un défaut soit au niveau de l'alim, soit au niveau de la clef :

Code : Tout sélectionner

2019-09-19 18:43:44.631 Error, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
2019-09-19 18:43:44.633 Always,
2019-09-19 18:43:44.634 Always, Dumping queued log messages
C'est pour ça que Denis de l'assistance technique m'a orienté vers un changement de l'alim ou de la clef.

J'ai bien compris tout ce que tu m'as indiqué marv
après, je trouve vraiment laborieux d'éloigner les contrôleur petit à petit.
Et plus sérieusement on peut jamais faire une installation professionnelle avec un protocole comme celui là :
Pour un Qubino qui va a l'autre bout de la maison, si je suis bien tout ce que tu m'as expliqué,
il faut que je prenne une rallonge à laquelle je dénude les fils.
que je fasse l'inclusion à 5cm de la clef Zwave que je bouge le Qubino à 10m de celui - ci que je fasse soigné le nœud ( 36 fois parceque ça marche pas au premier coup), que je le rebouge à 10m que je resoigne le noeud, et ensuite que je le mette à son emplacement derriere la prise qui est derrière le radiateur à un endroit super inaccessible.

Franchement, c'est un bouleau de fou, et j'ai estimé qu'il fallait que je fasse ça sur environ une 20aine de Qubinos et je ne peux m'empêcher de penser que c'est quand même marrant que ça ne soit expliqué ni dans la documentation jeedom, ni dans aucun autre tutoriels d'installations. Et je suis désolé mais je pense que cette galère est délibérément occulté par tous les fabricants. Justement parceque si j'avais su que ça se passait comme ça, je n'aurai jamais envisagé cette installation.

Aujourd'hui, je me retrouve avec ce truc, qui était à un moment la solution à un problème de domotisation dans de l'existant sans tout refaire et de façon simple.
Et en fait c'est pas simple et ça marche pas. Là, je vais dans cette maison, avec la boule au ventre, essayer une ultime solution mais je suis quasiment sûr qu’après la nouvelle installation de la clef et de l'alim ça ne marchera toujours pas et l'assistance va encore me trouver une autre panne matérielle, ou un truc que j'ai mal fait...

Enfin, on verra bien.
En tous cas si ça fonctionne, et Dieu sait bien que je pris tous les jours pour et que je ne perd pas espoir d'y arriver
je vous dirai ça là.

Swatmorpheus
Actif
Messages : 919
Inscription : 23 avr. 2015, 14:38
Localisation : Haute Gironde

Re: soigner le réseau

Message par Swatmorpheus » 03 oct. 2019, 16:13

Je te rassure niko , j'ai fais une installation chez un ami (une belle config déjà dans une très grande maison ouverte de 320m² de béton armé à 5 demi niveau), je suis parti comme chez moi avec tout ce que j'ai pu en filaire avec de l'ipx etc c'est à dire 1 ipx + 4 X8R + 1 Xdimmer + 2 X4VR et y'a juste pour les fenêtres et détecteurs présence et incendie avec des fibaro ( FGMS , FGSD, etc ... en Zwave+) y'a aussi des wall plug pour faire relai un peu partout exprès bah l'oeil qui est à 1m du contrôleur reçoit bien l'ordre de passer à 1(ON/OFF sur sensor dans les valeurs) mais il reste à 1 pendant 2 ou 3h ce qui n'est pas du tout normal alors que dans la santé tout va bien , le ping idem (d'ailleurs la luminosité et la température tout est OK) , je pense que l'info ne revient pas d’ailleurs y'a le même message que tu as "ZW_SEND_DATA could not be delivered to Z-Wave stack" , soit un problème de communication entre le module et le contrôleur alors pourquoi que sur ce paramètre et pas les autres ??!! je me pose la question , là je ne pense pas à un pb d'alim vu que c'est un nuc sauf si l'usb merde et la clé GEN 5 a même pas 2 ans.
Donc oui le zwave comme tout autre techno radio est bien pour de petite installation ou petite maison sans trop de distance ou de perturbation mais dès que l'on commence à être trop gros je pense que ça commence à merder ( latence , perte d'info,etc ).
Le zwave n'est pas une installation "pro" pour moi mais "du bricolage" pour éviter de faire de gros travaux afin de passer soit du câble bus ou faire un câblage en étoile qui reste largement le plus fiable et fonctionnelle si ton serveur se casse la gueule , tout reste fonctionnelle au bouton ( sauf si t'as utilisé des micro-modules qui le permettent aussi).
Prod: jeedom V3.2.12 DIY RPI3 + Zwave (fibaro) + Zigbee (xiaomi) + IPXV4 + X4VR
AppleTV4k
PI3 : Max2play
PiZéro: PiCoreplayer
Mini+: OpenElec 7.0.1 Kodi 16.1 Jarvis
En préinstall pour migration: Nuc hystou ,ESXi6.7,jeedom V3.2.12, LMS ,Owncloud

madcow
Timide
Messages : 299
Inscription : 06 févr. 2019, 21:41

Re: soigner le réseau

Message par madcow » 03 oct. 2019, 16:41

Swatmorpheus a écrit :Je te rassure niko , j'ai fais une installation chez un ami (une belle config déjà dans une très grande maison ouverte de 320m² de béton armé à 5 demi niveau), je suis parti comme chez moi avec tout ce que j'ai pu en filaire avec de l'ipx etc c'est à dire 1 ipx + 4 X8R + 1 Xdimmer + 2 X4VR et y'a juste pour les fenêtres et détecteurs présence et incendie avec des fibaro ( FGMS , FGSD, etc ... en Zwave+) y'a aussi des wall plug pour faire relai un peu partout exprès bah l'oeil qui est à 1m du contrôleur reçoit bien l'ordre de passer à 1(ON/OFF sur sensor dans les valeurs) mais il reste à 1 pendant 2 ou 3h ce qui n'est pas du tout normal alors que dans la santé tout va bien , le ping idem (d'ailleurs la luminosité et la température tout est OK) , je pense que l'info ne revient pas d’ailleurs y'a le même message que tu as "ZW_SEND_DATA could not be delivered to Z-Wave stack" , soit un problème de communication entre le module et le contrôleur alors pourquoi que sur ce paramètre et pas les autres ??!! je me pose la question , là je ne pense pas à un pb d'alim vu que c'est un nuc sauf si l'usb merde et la clé GEN 5 a même pas 2 ans.
Donc oui le zwave comme tout autre techno radio est bien pour de petite installation ou petite maison sans trop de distance ou de perturbation mais dès que l'on commence à être trop gros je pense que ça commence à merder ( latence , perte d'info,etc ).
Le zwave n'est pas une installation "pro" pour moi mais "du bricolage" pour éviter de faire de gros travaux afin de passer soit du câble bus ou faire un câblage en étoile qui reste largement le plus fiable et fonctionnelle si ton serveur se casse la gueule , tout reste fonctionnelle au bouton ( sauf si t'as utilisé des micro-modules qui le permettent aussi).
Bonjour,

Cas extrême (et belle installation !).
N'importe quelle onde passe difficilement le béton armé. Chez moi dans une maison ossature bois tous mes modules ne voient pas le contrôleur en direct (ne pas oublier les câbles électriques non plus).
C'est pour cela que, comme pour le WiFi, il existe des répéteurs zwave dans de tels cas.
DIY Proxmox sur HP Proliant
Débutant sur Jeedom

Swatmorpheus
Actif
Messages : 919
Inscription : 23 avr. 2015, 14:38
Localisation : Haute Gironde

Re: soigner le réseau

Message par Swatmorpheus » 03 oct. 2019, 18:32

madcow a écrit :
03 oct. 2019, 16:41
Bonjour,

Cas extrême (et belle installation !).
N'importe quelle onde passe difficilement le béton armé. Chez moi dans une maison ossature bois tous mes modules ne voient pas le contrôleur en direct (ne pas oublier les câbles électriques non plus).
C'est pour cela que, comme pour le WiFi, il existe des répéteurs zwave dans de tels cas.
Oui ç j'avais vu ^^ c'est pour ça que j'ai utilisé des relai avec des wall plug et même ajouté des micro module que j'avais en rab chez moi pour faire des test et étendre le maillage via les secteur.
Mais le plus bizarre c'est pas tant la latence car même 2s de ping sur certains modules (et c'est juste un ping pas la vitesse de l'action en soit) mais quand on regarde le %ok c'est le nombre de message envoyé et reçu comme il faut si je pense bien bah on est pas tip top
Capture-zwave.PNG
Capture-zwave.PNG (164.84 Kio) Consulté 4827 fois
Je trouve que ça réagit assez bien mais c'est surtout les oeil qui me pose problème , et surtout la partie capteur PIR et certaines infos ou commande qui n'arrive pas.
Pour ex l'oeil reste déclenché pendant 2h voir plus et c'est aléatoire on le voit bien sur l'historique de la commande et il est à même pas 1m du contrôleur !!! , il n'y a pas de wifi à moins de 1,5m et le BT est sur une antenne déporté filaire donc pas de perturbation.
Capture-histo.PNG
Capture-histo.PNG (25.45 Kio) Consulté 4827 fois
Là ça pose de gros problème car dans les scénarios on peut plus tester pour allumer sur une durée de temps avec variable ou même un dans car il va se relancer à l'infini. Coté détection volumétrique pour une alarme j'en parle même pas.
Donc je trouve ça déroutant de pas pouvoir fiabiliser à 95%
Prod: jeedom V3.2.12 DIY RPI3 + Zwave (fibaro) + Zigbee (xiaomi) + IPXV4 + X4VR
AppleTV4k
PI3 : Max2play
PiZéro: PiCoreplayer
Mini+: OpenElec 7.0.1 Kodi 16.1 Jarvis
En préinstall pour migration: Nuc hystou ,ESXi6.7,jeedom V3.2.12, LMS ,Owncloud

Mav3656
Helper
Messages : 70
Inscription : 12 févr. 2018, 16:22
Localisation : Nantes, France

Re: soigner le réseau

Message par Mav3656 » 04 oct. 2019, 17:23

Swatmorpheus a écrit :
03 oct. 2019, 18:32
madcow a écrit :
03 oct. 2019, 16:41
Bonjour,

Cas extrême (et belle installation !).
N'importe quelle onde passe difficilement le béton armé. Chez moi dans une maison ossature bois tous mes modules ne voient pas le contrôleur en direct (ne pas oublier les câbles électriques non plus).
C'est pour cela que, comme pour le WiFi, il existe des répéteurs zwave dans de tels cas.
Oui ç j'avais vu ^^ c'est pour ça que j'ai utilisé des relai avec des wall plug et même ajouté des micro module que j'avais en rab chez moi pour faire des test et étendre le maillage via les secteur.
Mais le plus bizarre c'est pas tant la latence car même 2s de ping sur certains modules (et c'est juste un ping pas la vitesse de l'action en soit) mais quand on regarde le %ok c'est le nombre de message envoyé et reçu comme il faut si je pense bien bah on est pas tip top
Capture-zwave.PNG
Je trouve que ça réagit assez bien mais c'est surtout les oeil qui me pose problème , et surtout la partie capteur PIR et certaines infos ou commande qui n'arrive pas.
Pour ex l'oeil reste déclenché pendant 2h voir plus et c'est aléatoire on le voit bien sur l'historique de la commande et il est à même pas 1m du contrôleur !!! , il n'y a pas de wifi à moins de 1,5m et le BT est sur une antenne déporté filaire donc pas de perturbation.
Capture-histo.PNG
Là ça pose de gros problème car dans les scénarios on peut plus tester pour allumer sur une durée de temps avec variable ou même un dans car il va se relancer à l'infini. Coté détection volumétrique pour une alarme j'en parle même pas.
Donc je trouve ça déroutant de pas pouvoir fiabiliser à 95%
Mon oeil fibaro fonctionne très bien et fait parti de mon alarme.

Peux tu montrer la table de routage stp ?

Quelques pistes :

Ton plugin zwave est-il a jour ? As tu relancé l'installation des dépendances lorsque ça a été nécessaire sur certaines mise a jour ?

Est-il inclus en mode sécurisé ? Si oui as tu changé ta clé zwave ou utilises tu celle par défaut ? Si tu l'as changé, attention il faut la remettre apres certaines mise a jour du plugin.

Si on se penche sur le problème que tu rencontres avec ton oeil fibaro (c'est bien un fibaro ?) :
- combien de temps doit il rester au niveau haut lorsqu'une présence est détectée ? (C'est configurable via un paramètre)
- es tu certain qu'il n'a enregistré aucun mouvement pendant tout ce temps, ce qui aurait maintenue le niveau haut ? (Je pense que la réponse sera oui, mais elle vaut le coup d'être posée) une araignée, un chat, une bâche avec du vent...

Regardons ce qui se passe :
Ton détecteur de mouvement envoie une trame lorsqu'il passe au niveau bas pour indiquer qu'il n'y a plus de mouvement.

Problème : si la trame a été envoyée, elle n'a pas été reçu correctement. A t'elle été envoyée ? Première piste : l'oeil est peut-être d'effectueux. Sinon :

A qui l'a t'il envoyé ? Pour cela il faut regarder les voisins du noeud. Si l'oeil voit le contrôleur, il y a des chances pour qu'il lui envoie directement l'information. Mais si le contrôleur est occupé a ce moment là et qu'il ne répond pas, ce n'est pas évident. -- Tu dois voir apparaître dans un onglet (lié au groupe de mémoire) la route de retour vers le contrôleur. Peux tu nous donner cette information également stp ? -- continuons :

Admettons qu'il ait envoyé le message au contrôleur, alors cela pourrait être un problème du côté de la clé ou de son alimentation. C'est peu probable mais ça arrive. Cependant les problèmes de communication ne devraient pas avoir lieu qu'avec un seul module dans ce cas. Les logs peuvent aider a diagnostiquer ce problème.

Autre cause possible : le contrôleur voit il le module ? Autrement dit ta table de routage est elle symétrique ?

Si tu ne l'as pas fait depuis longtemps tu peux soigner ton reseau UNE fois (utilise le bouton depuis l'onglet "action" du panneau "réseau zwave", ça fonctionne très bien). Après avoir cliqué sur le bouton, tu attends 24h, puis tu relances le daemon zwave (dans l'écran de configuration du plugin, le bouton avec le symbole "play"). Tu peux aussi redémarrer ta box si tu préfères bien que cette action ne soit pas nécessaire.

Enfin, je te propose de nous remettre une screenshot de ta table de routage, pour comparer ensemble le avant et après (pour ça, il faut que tu ais fait une screenshot de ta table de routage avant de soigner le réseau)

Ne sois pas surpris quand tu redémarreras le demon zwave, Il faudra que tu attendes que les modules sur pile se réveillent voir leurs informations apparaîtrent.

Autre indice pour comparer la qualité de ton réseau zwave : le temps qu'il met a démarrer. Cette info est visible dans l'écran "résumé" quand tu cliques sur "réseau zwave". De la même façon, je t'invite à comparer la valeur que tu as maintenant avec la valeur que tu auras après ces manipulations.

Toutes ces pistes sont là pour aider. Il y a beaucoup d'infos, peut-être plein de choses que tu connais déjà. Dans ce cas ne le prend pas mal, tu peux choisir de les suivre, ou pas....bon courage et bonne journée.
Mav3656 - Helper Officiel Jeedom

Swatmorpheus
Actif
Messages : 919
Inscription : 23 avr. 2015, 14:38
Localisation : Haute Gironde

Re: soigner le réseau

Message par Swatmorpheus » 05 oct. 2019, 12:11

slt mav , voici quelques éléments pour te faire voir que tout est ok dans les grandes largeurs
Mav3656 a écrit :
04 oct. 2019, 17:23


Mon oeil fibaro fonctionne très bien et fait parti de mon alarme.

Peux tu montrer la table de routage stp ?

Quelques pistes :

Ton plugin zwave est-il a jour ? As tu relancé l'installation des dépendances lorsque ça a été nécessaire sur certaines mise a jour ?
la màj des dépendance est du 9/08 , le redémarrage du démon depuis le 16/09 et la dernière màj du plugin date du 23/05 donc largement à jour, pourquoi aller mettre une màj qui corrige de l'affichage et/ou qui me fait une compatibilité buster, chez moi je tourne avec une vielle version d'openzwave et aucun pb , ni avec mes oeils d'ailleurs.
Est-il inclus en mode sécurisé ? Si oui as tu changé ta clé zwave ou utilises tu celle par défaut ? Si tu l'as changé, attention il faut la remettre apres certaines mise a jour du plugin.
il y en a oui et d'autre non car ça n'a pas tous marché à l'époque mais bon idem je te dirais ce n'est pas des trames sécurisés qui passe donc on s'en fiche
Si on se penche sur le problème que tu rencontres avec ton oeil fibaro (c'est bien un fibaro ?) :
- combien de temps doit il rester au niveau haut lorsqu'une présence est détectée ? (C'est configurable via un paramètre)
- es tu certain qu'il n'a enregistré aucun mouvement pendant tout ce temps, ce qui aurait maintenue le niveau haut ? (Je pense que la réponse sera oui, mais elle vaut le coup d'être posée) une araignée, un chat, une bâche avec du vent...
Oui c'est un fibaro version 2 le zwave+, paramètres 2 et 6 donc inertie à 15 et maintient d'ouverture à 30, pas d'araignée , pas de bâche , pas de chat etc...
Regardons ce qui se passe :
Ton détecteur de mouvement envoie une trame lorsqu'il passe au niveau bas pour indiquer qu'il n'y a plus de mouvement.

Problème : si la trame a été envoyée, elle n'a pas été reçu correctement. A t'elle été envoyée ? Première piste : l'oeil est peut-être d'effectueux.
non je ne pense pas qu'il soit défectueux car ce comportement est de façon aléatoire
Sinon :
A qui l'a t'il envoyé ? Pour cela il faut regarder les voisins du noeud. Si l'oeil voit le contrôleur, il y a des chances pour qu'il lui envoie directement l'information. Mais si le contrôleur est occupé a ce moment là et qu'il ne répond pas, ce n'est pas évident. -- Tu dois voir apparaître dans un onglet (lié au groupe de mémoire) la route de retour vers le contrôleur. Peux tu nous donner cette information également stp ? -- continuons :
oui il doit y avoir une info qui n'arrive pas ça c'est sur mais je n'ai aucune trame qui attends rien dans la queue.
l'oeil est à 1m du controleur donc pourquoi il enverrait une trame ailleur qu'à lui ?? ça serait vraiment stupide dans le fonctionnement mais bon c'est possible et là y'
Admettons qu'il ait envoyé le message au contrôleur, alors cela pourrait être un problème du côté de la clé ou de son alimentation. C'est peu probable mais ça arrive. Cependant les problèmes de communication ne devraient pas avoir lieu qu'avec un seul module dans ce cas. Les logs peuvent aider a diagnostiquer ce problème.
la clé est sur un nuc donc question alimentation aucun souci, d'ailleurs javais vérifié avec un contrôleur de tension avec oscillo avec un historique pour voir si la tension était toujours bonne sur les usb car j'ai testé tout les ports usb avec la clé les usb 2 et 3 , le comportement est identique , c'est vraiment aléatoire.
Autre cause possible : le contrôleur voit il le module ? Autrement dit ta table de routage est elle symétrique ?
Oui le contrôleur voit bien l'oeil d’ailleurs comme j'ai indiqué les fonctions de température/luminosité et même le sabotage n'ont aucun soucis de remonté d'info mais juste sur ces détections.
Si tu ne l'as pas fait depuis longtemps tu peux soigner ton reseau UNE fois (utilise le bouton depuis l'onglet "action" du panneau "réseau zwave", ça fonctionne très bien). Après avoir cliqué sur le bouton, tu attends 24h, puis tu relances le daemon zwave (dans l'écran de configuration du plugin, le bouton avec le symbole "play"). Tu peux aussi redémarrer ta box si tu préfères bien que cette action ne soit pas nécessaire.
oui la santé du réseau a déjà été faites mais ça ne résous pas forcément le problème ou juste pour quelque temps mais ça revient et comme toujours c'est vraiment aléatoire.

Enfin, je te propose de nous remettre une screenshot de ta table de routage, pour comparer ensemble le avant et après (pour ça, il faut que tu ais fait une screenshot de ta table de routage avant de soigner le réseau)
Ne sois pas surpris quand tu redémarreras le demon zwave, Il faudra que tu attendes que les modules sur pile se réveillent voir leurs informations apparaîtrent.
Ne t'inquiètes pas ça fait 6 ans que j'ai du zwave chez moi , j'ai déjà exploré beaucoup de subtilité du fonctionnement avec ces surprises :).
Autre indice pour comparer la qualité de ton réseau zwave : le temps qu'il met a démarrer. Cette info est visible dans l'écran "résumé" quand tu cliques sur "réseau zwave". De la même façon, je t'invite à comparer la valeur que tu as maintenant avec la valeur que tu auras après ces manipulations.
le réseau mets environ entre 150 et 250 secondes pour démarrer

Toutes ces pistes sont là pour aider. Il y a beaucoup d'infos, peut-être plein de choses que tu connais déjà. Dans ce cas ne le prend pas mal, tu peux choisir de les suivre, ou pas....bon courage et bonne journée.


Comme tu as pu le voir j'ai déjà exploré beaucoup de piste et je ne suis pas débutant avec ce protocole mais bien-sur ce que tu dis est pertinent mais déjà vérifié (tkt je suis pas du genre à mal prendre de l'aide même si je connais déjà les choses ^^ ) . Le seul point qui doit être je pense finalisé c'est le faite que tout soit bien symétrique dans la table de routage mais bon quand c'est pas chez toi c'est compliqué de relancer un réseau et qu'il soit possible que les choses ne repartent pas bien quand t'es pas sur place.
le module qui emmerde le monde surtout c'est le 17 ( oeil escalier-chambre) et on voit bien qu'il est en direct
Capture_table_routage.PNG
Capture_table_routage.PNG (124.66 Kio) Consulté 4793 fois
Prod: jeedom V3.2.12 DIY RPI3 + Zwave (fibaro) + Zigbee (xiaomi) + IPXV4 + X4VR
AppleTV4k
PI3 : Max2play
PiZéro: PiCoreplayer
Mini+: OpenElec 7.0.1 Kodi 16.1 Jarvis
En préinstall pour migration: Nuc hystou ,ESXi6.7,jeedom V3.2.12, LMS ,Owncloud

Avatar de l’utilisateur
manuc0
Timide
Messages : 91
Inscription : 08 mars 2017, 09:36
Localisation : Belgique

Re: soigner le réseau

Message par manuc0 » 25 déc. 2019, 09:35

Nik0 a écrit :
18 sept. 2019, 17:51
pour ceux que ça pourrait intéresser, vous trouverez ci- joint le témoignage de personnes qui se sont cassées les dents sur le Zwave
http://www.knx-fr.com/showthread.php?tid=3368
je regrette vraiment de m’être lancé là-dedans ...
Je ne vois pas quoi faire d'autre sur mon réseau pour que ça fonctionne - globalement, même si je comprend le principe d'intégration, je ne comprend pas que ça marche un peu mais pas trop ...
je ne comprend pas non plus que ça ne soit pas possible de soigner le réseau de façon automatisée ...
Message de 2014 depuis beaucoup d’eau a coulé sous les ponts ..... ;)

Répondre

Revenir vers « Plugin Z-Wave »

Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 6 invités