[Tuto] jMQTT + Mosquitto + ZWave-JS-UI (anciennement ZWaveJS2MQTT)

Ouvrez votre propre sujet svp.

Antoine

Bonsoir,

Merci !

Il me semble préférable de garder un seul Mosquito et :

  • soit installer zigbee2mqtt sur une VM à part
  • soit installer zigbee2mqtt sur la même VM que zwavejs2mqtt/Mosquito

Pour le problème, préférable d’ouvrir un sujet dédié avec des captures d’écrans et quelques logs de jMQTT par exemple.

Bonjour,

j’ai poster ici car il me semblait important de signaler d’un éventuel blocage dans le tuto.
j’ai résolu le prob, pour info, j’avais déporter le broker et zwavejs sur un nuc et le broker ne validait que les connexions internes. J’ai résolu mon problème avec un simple fichier de conf a ajouter pour lui indiquer d’écouter le websocket.

merci à Bison pour son avis :slight_smile:

Ok donc rien à corriger spécialement sur le tuto ?

peut être une invit a rechercher des infos sur le websocket en cas de déport sur une autre machine mais en soit si on se renseigne ca me parait très bien !

la je galère un peu plus sur jmqtt mais c’est une autre histoire :slight_smile:
faut le temps de la prise en main!

Bonsoir,

Petite galère ce soir à partir de 21h00, plus de réponse de zwavejs2mqtt. VM avec grosse consommation vCPU et impossible d’accéder à l’interface de gestion web de l’outil.

Je vous passe les essais pour trouver l’origine et pour le moment il s’agit chez moi d’un délire lors du passage automatique à la version v6.7.4 de zwavejs2mqtt.

Je vous laisse donc ici ce qu’il faut faire si vous êtes planté également :

  • connexion en ssh sur la VM
  • snap revert zwavejs2mqtt

Vous remarquerez alors avec un snap list --all que la version précédente aura été restaurée et la nouvelle désactivée :
image

Dans le même ordre d’idée, la MàJ auto provoque toujours des plantages ou des dysfonctionnement chez moi,

Il suffit de faire un « sudo snap restart zwavejs2mqtt » en SSH pour que cela reparte (avec souvent un « Re-interview Nodes » à la clef qui prends facilement 6-10 heures …

J’ai aussi eu comme toi un soucis au passage à la 6.7.4, et la je viens de m’apercevoir que je suis en 6.8.0 (sans l’avoir vu passer !!!)
image

J’ai l’impression qu’il y a une zone d’ombre entre les versions github et les versions snap …

Sous docker, je n’ai pas eu ce soucis…
Il y a eu effectivement comme l’indique @m.georgein une montée rapide entre deux versions…
Je suis en Zwavejs2Mqqt 6.8.0 (maj 2022-04-28 15:12:16, maintainer robertsLando)

J’ai pas eu de soucis sur la 6.7.4, :thinking: :thinking: sinon le wife aurait gueulé, le zawe gérant pas mal de chose dans la maison (mais plus l’eau chaude :joy_cat: :joy_cat:)

Salut,

Ton plantage régulier au changement de version et ce que tu dis sur l’interview à refaire fait penser que ça provoque une perte de visibilité de la clef lors du changement de version non ?

J’avais tenté un passage en version 6.8.0 qui était la « candidate » chez moi hier mais sans succès.

Je ne pense pas que cela vienne du port, mais plutôt d’un problème soft au changement de version,
par exemple voila ce que me dit snap :
image

DEUX changement de version hier d’après snap c’est étrange

installé 6.8.0 - last stable 6.7.4 - last candidate 6.8.0

En fait on dirais qu’il ne redémarre pas correctement après une MàJ, ce qui pourrait expliquer qu’hier avec deux MàJ successive cela soit passé sans soucis

Pour l’interview, si le référentiel ‹ Z-Wave JS › à changé il le refait peut être d’office au restart ??

Je suis aussi sur Docker, et je n’ai aucune maj automatique, tu a fais quelque chose manuellement pour mettre à jour ? ou bien tu a installé un service de monitoring ?
image
j’ai un train de retard…

hello,
oui j’ai juste le container watchtower qui tourne et vérifie régulièrement si il y a de nouvelle image.

1 « J'aime »

Merci pour ce coup de main Bison, je me suis retrouvé dans la même situation au même moment et ton message m’a bien aidé :slight_smile:
Sinon j’ai également le même soucis que vous : au moment des màj, j’ai remarqué que je devais redémarrer la VM Zwave pour que tout rentre dans l’ordre
A suivre

1 « J'aime »

Moi je n’ai pas ce soucis lié aux maj (sauf cette fois car elle a un bug).en principe ça passe sans problème. En revanche @m.georgein rencontre régulièrement ce soucis et on a beau réfléchir on ne voit pas bien pourquoi :thinking:.

Vous aviez installé quoi sur cette VM ? Mosquito et zwavejs2mqtt ou bien autre chose ? On y trouvera peut être ce qui explique le problème.

@Bison , @m.georgein
Pour ma part j’ai tout sous docker, je ne sais pas si ça peut vous aider :thinking:

J’ai de temps en temps quelque soucis avec zwavejs2mqtt, perte de la clé usb uniquement dans le container (je pensais que cela venait au départ de mon autre container zigbee2mqtt mais après l’avoir arrêté et laissé quelque temps à l’arrêt, j’ai toujours eu ce soucis de remonté de clé lors des mises à jour…

Ça m’avait souler un moment que j’en étais parti pour tout scinder sur des PI différent. :man_facepalming:

Depuis j’ai remis zigbee2mqtt en route et ça fait deux mises à jour qui passe sans soucis, je ne sais pas pourquoi, une histoire d’ampérage sur les ports du PI, une erreur entre nos amis …

La solution que j’ai trouvé pour régler ce problème, il fauit que je supprime deux fichiers xxxx.xxxx.lock dans la config de zwavejs2mqtt

ça ressemble à des problèmes de permissions quelque part tout ça.
@chris_77 tu pourras regarder les permission des fichiers .lock quand tu es planté avant de les supprimer ?

Chez moi les process snap s’éxécutent en root et ce sont bien tous des droits root qui sont sur le répertoire /var/snap

Entre temps pour notre affaire d’update qui a planté Caelion et moi-même j’ai vu ça sur le github : https://github.com/zwave-js/zwavejs2mqtt/issues/2398

Apparemment lors de cet update le « deviceConfigPriorityDir » pointait vers un répertoire non existant et ça plantait donc l’exécution.

Vous avez quoi dans le fichier /var/snap/zwavejs2mqtt/current/settings.json à la ligne « deviceConfigPriorityDir » ? Moi "deviceConfigPriorityDir": "null"

@bison pour le moment, il veut pas planté :grin: :grin: :sweat_smile: mais j’ai retrouvé les fichiers en question ;

drwxr-xr-x 2 root root   4096 May  2 19:34 d6e32509.jsonl.lock
drwxr-xr-x 2 root root   4096 May  2 19:34 d6e32509.metadata.jsonl.lock

Et un ps -aux | grep snap pour voir comment tourne snapd et les autres services ?

pirate 24385 0.0 0.0 7264 468 pts/0 S+ 21:01 0:00 grep snap

le pirate je suis sous HypriotOS

Ah mais oui pardon tu es sous docker du coup je ne sais même pas comment ça marche et sous quel utilisateur tourne snapd.

Et pour toi @m.georgein ?