Tentative fonctionnement premier équipement Jeedom

Tags: #<Tag:0x00007f3861b76880>

Envoie une copie d’écran de la page configuration?
Et mets ton plugin en mode debug pour que les logs soient plus détaillés



openzwave.txt (22,6 Ko)
openzwaved.txt (18,0 Ko)

Le numéro de port Z-wave est bizarre.
Quels sont les périphériques branchés sur ton RPI4?

J’ai configuré le port à la main, il fait référence à la clé usb USB SIGMA DESIGNS Contrôleur Z-Wave Plus
Ça permet d’attribuer un nom + référence de port fixe à un équipement connecté sur le Raspberry

Plus d’infos ici : https://www.raspberrypi.org/forums/viewtopic.php?t=217511

Sur le Raspberry j’ai uniquement le disque SSD + la clé Sigma de connectés

J’ai fait pas mal de personnalisation de l’OS avant d’installer Jeedom (OS sur SSD, Clé de sécurité zwave changée, ports usb personnalisés, https, …) , je ré-essaye sur une autre SDCard avec les configs par défaut. Ça me permettra de de savoir si c’est une des confs spécifiques qui bloque.

Je n’ai pas dit qu’il y avait une erreur sur le numéro de port, c’est sa syntaxe qui est bizarre., je n’en ai jamais vu des comme ça.
Je serais toi, j’essaierais de brancher tout’les périphériques usb sur un hub autoalimenté.
Il peut y avoir un problème d’alimentation entre le RPI4, la SSD et la clé z-zwave.

Alors pour le moment je n’ai pas de hub usb sous la main.

J’ai refais complétement l’installation du Raspberry en laissant toutes les options par défaut (uniquement la SDCard, pas de config spécifique de ports, …) et je n’ai pas rechargé la sauvegarde de Jeedom.
Je me retrouve donc avec uniquement la clé Sigma Designs ZWave Plus de connectée sur une installation toute neuve.

Ca ne marche pas mieux. Et l’erreur est je pense au niveau de la détection de la clé, puisque je n’ai même pas essayé de connecter le Qubino.
D’ailleurs on voit bien que le périphérique inconnu est de marque Sigma Designs

Le port de la clé usb est celui standard

Au niveau OS la clé est vue :
pi@jeedom:// $ sudo lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

pi@jeedom:// $ sudo lsusb -v | grep ‘idVendor|idProduct|iProduct|iSerial’
can’t get debug descriptor: Resource temporarily unavailable
idVendor 0x1d6b Linux Foundation
idProduct 0x0003 3.0 root hub
iProduct 2 xHCI Host Controller
iSerial 1 0000:01:00.0
idVendor 0x0658 Sigma Designs, Inc.
idProduct 0x0200 Aeotec Z-Stick Gen5 (ZW090) - UZB
iProduct 0
iSerial 1 E3040A02-4A02-0115-201B-041600CC95C0
can’t get device qualifier: Resource temporarily unavailable
can’t get debug descriptor: Resource temporarily unavailable
idVendor 0x2109 VIA Labs, Inc.
can’t get debug descriptor: Resource temporarily unavailable
idProduct 0x3431 Hub
iProduct 1 USB2.0 Hub
iSerial 0
can’t get device qualifier: Resource temporarily unavailable
can’t get debug descriptor: Resource temporarily unavailable
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
iProduct 2 xHCI Host Controller
iSerial 1 0000:01:00.0
pi@jeedom:// $

La clé est celle ci exactement : https://www.amazon.fr/gp/product/B01NCSPFEO/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1

Et pour les logs :
openzwave.txt (9,8 Ko)
openzwaved.txt (15,4 Ko)

Je ne connais pas cette clé, mais c’est normal qu’elle soit vue comme une Aeotec (qui a la même puce zwave que le clé sigma design car toutes les puces zwave pour le moment sont des sigma design)?

idProduct 0x0200 Aeotec Z-Stick Gen5 (ZW090) - UZB

De plus même si je ne connais pas grand chose en Linux ton lsusb montre qu’elle n’est pas reconnue par l’os non ?

Pourtant dans lsusb je vois bien la clé Sigma Designs, ça ne suffit pas ?

pi@jeedom:/ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Quand j’enlève la clé j’ai ceci :
pi@jeedom:/ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Elle voit une clé Aeotec. C’est peut être normal car c’est la même puce (mais pas le même firmware).

Il faudrait quelqu’un qui a la même clé que toi pour vérifier.

Ah zut alors car cette clé Aotec est connue pour ne pas fonctionner avec le Rasp 4.
C’est bien pour ça que j’ai pris la Sigma, c’est con ça :frowning:
La parade étant à priori de passer par un hub usb.
Je viens de le commander, reste plus qu’à attendre alors …

Je n’ai pas dit de prendre une Aeotec forcément. J’ai dit que ta clé ne semblait pas reconnue comme une sigma design mais que c’était peut être normal (même puce).

La Aeotec consomme pas mal d’où la nécessité (enfin ça règle souvent des problèmes) d’un hub autoalimenté du fait des petites alims des PI.

Bonjour @Vax69,

J’ai moi même un Pi4 SSD Rasbian Buster et Jeedom V4
(plus de détails ici : https://community.jeedom.com/t/2512)

Je dispose par ailleurs à la fois des clés USB :

  • SIGMA DESIGNS Z-Wave Static Controller Z-Wave PLUS UZB
    et
  • AEOTEC Z-Stick Gen5 ZW090-C

AEOTEC-Z-Stick-Gen5-et-SIGMA-DESIGNS-UZB

Ces 2 clés embarquent le même chipset Z-Wave de chez SIGMA DESIGNS.
Pour fonctionner correctement sur un Pi4, autrement dit pour apparaitre dans lsusb,
la clé AEOTEC nécessite d’être connectée sur un Hub USB2 avec sa propre alimentation alors que ce n’est pas nécessaire pour la clé SIGMA DESIGNS.

Et enfin je dispose d’un module,Qubino ZMNHJD1 Fil pilote.

Pour la SIGMA DESIGNS ou l’AEOTEC, lsusb donne :
ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
ou
ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090)

Dans ton contexte (clé USB SIGMA DESIGNS Z-Wave Static Controller) :

  • les dépendances sont OK
  • le port Z-wave est OK
  • le démon est OK
  • le réseau zwave est OK (Etat Network ready)

Le module Qubino ZMNHJD1 Fil pilote est compatible avec le plugin Z-Wave : https://jeedom.github.io/documentation/zwave/fr_FR/equipement.compatible

Dans les équipements Z-Wave, ne pas confondre le controleur et les autres équipements.
Tu dis que tu as réussi à inclure le module Qubino mais rien de ce que tu as fournis pour l’instant comme images ne le montre.

Pour inclure le module, dans le plugin Jeedom, activer le mode inclusion en mode non sécurisé,
brancher le module sur l’alimentation (N sur Neutre et L sur Ligne/Phase) à moins d’un mètre du contrôleur.
Le module est reconnu et inclut automatiquement au bout de quelques secondes.
Un nouvel équipement et les commandes apparaissent :

Qubino-ZMNHJD1-Fil-pilote-Equipement

Qubino-ZMNHJD1-Fil-pilote-Commandes

akenad :slight_smile:

2 J'aimes

Merci. Au moins c’est pas la clé :blush:
Du coup c’est subtil la différence de dénomination :wink:

Merci pour vos réponses, cela fonctionne (presque) maintenant.
Il y avait bien un soucis d’association du module Qubino, maintenant cela fonctionne. Je récupère la valeur de la sonde de température.
J’ai pu tout configurer notamment avec le disque SSD en support d’OS externe et j’ai mis la clé sur le hub usb que j’ai reçu ce matin.

Je posterai dans un message dédié toutes les étapes de configuration, cela pourra aider certains. Je me suis fait une note avec un résumé de toutes les commandes Linux de passées.

Et je dis presque car le radiateur ne réagit pas aux ordres du fil pilote, mais bon j’essaierai sur un autre radiateur car je suis pas sur qu’il soit en mode programmation, l’afficheur déconne, c’est un Thomson Theco 1000, le problème est récurrent sur cette gamme.

Salut,

J’arrive après la bataille et j’avoue que j’ai pas lu tout le fil mais j’en profite pour faire un retour rapide sur des difficultés rencontrées avec les récents révisions des ZMNHJD1:

Déjà @Vax69 pour tes problèmes as-tu bien inclus le module à proximité immédiate du contrôleur pour ensuite le mettre à sa position finale ?
Concernant le pi4 il me semble avoir lu qu’il était presque indispensable d’utiliser un hub Usb auto alimenté pour faire fonctionner un contrôleur Usb zwave.

sinon J’en ai déjà 3 dont la révision finissait par le chiffre 2 (je crois) qui fonctionnent parfaitement dont 1 à l’étage à l’autre bout de la maison un des plus éloignés de mes modules.
J’ai récemment ajouté un autre ZMHJD1 (révision finissant par 5) à l’étage plutôt proche du contrôleur qui est en hauteur de surcroît.

Bref je vous passe les détails: manque de paramètres dans le module dont la température, perte des paquets de remontée de température, oblige de mettre à jour la route de retour quotidiennement… j’en suis arrivé à ajouter un range extender qui n’a eu strictement aucun effet sur le réseau zwave (voire pire).

Même à 5 mètres du contrôleur à la fin, le module se déconnectait du zwave. Du coup retour du module qubino (et du range extender au passage) et achat d’un nouveau ZMNHJD1 (révision 5 aussi) chez pl***te-domotique qui faisait -25% en plus! Et aucun problème juste perte de 3/4 paquet de température par jour.

Tout fonctionne désormais.
Que ce soit le module ZWave Qubino ZMHJD1 que mes volets Somfy + Sondes de température Oregon via RFX433.
J’ai juste depuis le début un équipement zwave inconnu que je n’arrive pas à virer, il revient à chaque fois.
36

As-tu essayé Supprimer le noeud en échec sur ce module ?

Ah non j’avais pas essayé, je viens de le faire, il n’apparait plus.
Merci.

Merci d’avoir remonté ce point, j’avais de gros probleme de stabilité de zwave avec un pi3, je viens de mettre un vieux hub usb avec alimentation, tout est passé au vert, plus de node dead, et tout est plus rapide.
Merci @Salvialf :ok_hand: je viens de passer de l’enfer au paradis :wink:

1 J'aime