Je pilote un radiateur électrique avec un Quibino ZMNHJD. Ca fonctionne bien mais parfois il passe en statut Dead. Et ensuite terminé. Plus moyen de le piloter.
Solution que j’ai trouvée pour le redémarrer : depuis l’équipement, dans ‹ Noeud › / Actions → Rafraichir les valeurs du noeud. Ca le fait repasser en Live et tout repart.
Du coup j’ai essayé de lancer cette commande en automatique tous les matins.
Pour cela j’ai créé une commande dans l’équipement (car la commande Rafraichir noeud n’existe pas, il n’y a que Pinger noeud , Soigner noeud et Statut noeud ):
et je lance cette commande dans un scénario programmé.
Malheuresement cela ne fonctionne pas.
D’ailleurs, si j’appuis sur le bouton ‹ Tester › de la commande il ne se passe rien (l’équipement reste en Dead).
J’ai creusé un peu et j’ai aussi essayé de passer par un bloc de code dans un scénario - en piochant dans d’autres post.
Par exemple (extrait)
// Setup
// Jeedom configuration/API/Clef API Z-Wave
$apizwave = ‹ ma clé API ZWAVE ›;
// list of nodes to perform a check
$nodeIds = array(66);
// End Setup
foreach ($nodeIds as $nodeId) {
$scenario->setLog('Foreach Node: ’ . $nodeId);
if (getNodeFailed($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);
…
dans la commande que j’ai créée avec la propriété refreshNodeCC → est-ce que cela est correct . j’ai trouvé cette valeur dans un post
concernant l’utilisation de l’url dans un bloc de code qui ne fonctionne pas. Ai-je oublié quelque chose ?
Mon contexte :
Jeedom version 4.5.2
RPI 4B - 2 Go
Santé → tout est au vert
Plugin Z-wave JS avec MQTT
Clé Z-Wave : Everspring Gen5 - Formware 4.36 - SDK 6.51.7
Vous mélangez les plugins. L’étiquette manquait d’ailleurs.
Il ne fallait pas activer la clé api, elle ne sert pas.
Et le bout de code trouvé est pour un autre plugin qui est obsolète.
Le code et le log sont à mettre dans un bloc Texte préformaté.
Revenez sur la description de votre problème d’origine en fournissant page santé, config plugin et log et pas sur les problèmes que vous rencontrez à mettre en place une solution inadaptée.
Bonjour à tous,
Ah tiens j’ai un problème similaire sur un ZMNHJD qui est un peu en bout de portée zwave dans ma config : il a fonctionné nickel pendant 4-5 ans, mais depuis 3 mois me fait le même sketch.
Je ne me suis pas encore penché sur la question (détail du pb quand il passe en dead), car pour l’instant le radiateur s’allume toujours dans la SdB à la bonne heure, et madame n’a pas encore râlé.
Mais effectivement, ça corrobore le commentaire de @Madcow, ça semble mal vieillir… (rien n’a changé autour, à part évidemment les versions de Jeedom et le passage zwaveJS, mais qui n’a à mon avis rien à voir).
Je sais, ça ne fait pas trop avancer le schmilblick, mais bon
Merci pour vos retours.
Désolé pour les petites erreurs de présentation.
J’ai repassé la clé API en désactivé - comme c’était avant.
Pour le code en bloc formatté (même si celui-çi ne sert pas du coup) :
// Setup
// Jeedom configuration/API/Clef API Z-Wave
$apizwave = 'ma clé API';
// list of nodes to perform a check
$nodeIds = array(66);
// End Setup
foreach ($nodeIds as $nodeId) {
$scenario->setLog('Foreach Node: ' . $nodeId);
if (getNodeFailed($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 {
$scenario->setLog('ZAPI node testNode return OK: ' . $results["result"]);
//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 {
$scenario->setLog('ZAPI node hasNodeFailed return OK: ' . $results["result"]);
//sleep for 3 seconds
sleep(3);
getNodeFailed($nodeId, $apizwave, $scenario);
}
}
}
}
}
function getNodeFailed($nodeId, $apizwave, $scenario){
$url_health = 'http://localhost:8083/node?node_id=' . $nodeId . '&type=info&info=getHealth&apikey=' . $apizwave;
$scenario->setLog('ZAPI node getHealth url: ' . $url_health);
$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"];
}
}
Le fait est qu’il est assez loin du contrôleur, et en tout cas pas en ligne directe.
J’ai acheté une clé ZWave ZOOZ 800, mais pas encore installée. J’ai regardé comment migrer et ca me semble délicat (notamment pour avoir le nouveau contrôleur en ID n° 1). Maintenant vu la complexité de mon installation, je peux aussi supprimer l’inclusion de tous les modules, mettre la nouvelle clé et réinclure. Puis repasser sur les scénarios pour adapter avec les nouveaux Id.
Merci d’avance pour vos nouvelles réponses. J’aimerais bien savoir comment utiliser des url dans les blocs codes - même si ce n’est plus sujet maintenant.
Et aussi si j’ai raté quelque chose avec la commande que j’ai créée (propriété refreshNodeCC).
A noter : j’avais tenté le ping du noeud mais ca n’avait pas fait repasser en ‹ Alive › l’équipement.
Précisions supplémentaire : j’ai un scénario qui reboot le raspberry à 3h00 du matin - j’avais mis ça en place suite à des pb de plantage aléatoire.
c’est complétement inutile, ca fait des années que mon controleur a l’ID 58
et je doute que la nouvelle clé aide avec la portée, il faut plutot privilégié le maillage et donc ajouter un module sur secteur à mi-chemin ou dans la pièce de ce module récalcitrant
sachez aussi que debian 13 n’a pas encore été validé… c’est ambitieux d’avoir installé cette version
Pour Debian 13. Je ne me souviens plus exactement de ce que j’avais fait. Mais j’ai dû repartir d’une image d’install de Raspberry, puis j’ai installé Jeedom avec la procédure d’install de Jeedom. Donc l’image disque du Raspberry devait être une Debian 13. En tout cas pas eu de pb de ce côté.
Je vais me lancer dans l’install de la nouvelle clé. Même si pas de rapport avec la portée, ca me permettra de changer le raspberry de place. Aujourd’hui si je le rapproche du Quibino j’ai d’autres capteurs qui sont hors portée…
on est d’accord mais ici le module est déjà hors portée du contrôleur et relié via 2 prises donc changer le contrôleur va améliorer le signal entre celui-ci et les noeuds directs mais ne va rien changer sur le signal qui arrive au Quibino depuis les sauts intermédiaires, d’où ma réponse
ou alors je n’ai rien compris
Bonjour.
Quelques nouvelles.
J’ai basculer la clé Z-Wave vers le Zooz800. Pas eu de pb. J’avais exclus tous les modules, puis réinclus. Voilà les nouvelles routes du réseau :
Certains équipements ne sont pas connectés. Je ne sais pas pourquoi, en tout cas ils fonctionnenet correctement.
L’équipement qui posait pb est maintenant en ligne directe avec le contrôleur.
Maintenant il n’y a plus qu’a attendre et voir s’il repasse en Dead. Pour le moment je n’ai pas changé le raspberry de place.
