Interface graphique état connexion deconz

Slt all
Comment faites vous pour avoir la vue graphique des noeuds du reseau zigbee deconz


Pour info je suis sur une vm debian sans interface graphique…

Ben perso moi j’installerais l’interface graphique car j’ai pas le niveau pour m’en passer, mais sinon tu as 2 solutions ici Access deCONZ GUI in headless setups · dresden-elektronik/deconz-rest-plugin Wiki · GitHub

Super merci j’y avais pas pensé
Merci HugoVal11 t’es au top comme toujours.
Christophe

Si ton jeedom est installé sur un debian tu peux suivre : util:xming [LinuxPedia]
Après tu tappes : deCONZ
image
Puis une fenetre X-Forwarding s’ouvre … normalement


Sauf que moi j’ai un pti soucis il n’est pas connecté … :frowning: … certainement lié à cette remarque du lien de HugoVal11
« One remark though in case a SSH connection is established with a different user than the one designated for running deCONZ. Copy the .Xauthority file in the user home dir establishing the SSH connection over to the deconz’ user home (e.g. sudo cp /home/pi/.Xauthority /home/deconz/.Xauthority ) and ensure you can ‹ su › to the deconz user to have it run. »

J’ai plus qu’à trouver ce fichier … :slight_smile:

Je pense que mon user n’a pas le droit d’accéder a la clef usb pourtant je l’ai rajouté au groupe dialout et www-data … peut etre faut il redémarrer la vm… hummm
@HugoVal11 y a quoi d’inscrits dans « Connect to device » ??

Et tout fonctionne pour toi @trollix?

A priori le deCONZ-GUI est executé par root


Quand je regarde si les services sont up … ils sont tous inactifs alors qu’il fonctionne …

Y doit y avoir un truc que je fais mal … mais quoi … une idée ??
J’ai copié le fichier .Xauthority dans le home du root (/root) … mais pas mieux au niveau de deCONZ … not connected
image
Any ideas ?

Il nous faut juste savoir quel user lance le ou les service deconz et deconz-gui…a votre bon coeur…:hugs:

C’est parce que tu as pas copie le .Xauthority de ton home dans le home de root (/root) enfin je pense

Exact!!!
Merci @trollix

Yep super collaboration @trollix:wink:
Je pense que le sujet peut etre clos.

Lol, y a du niveau quand même, respect.
Perso j’ai rien compris, mais par contre je ne vois pas pourquoi il ne serait pas possible de faire tourner la version que vous faites tourner avec le plugin jeedom. Il n’est pas possible de faire tourner 2 version de deconz, mais une seule suffit pour tout faire.

Si vous faites tourner « la version spéciale », essayez de configurer le plugin jeedom comme si vous aviez une version distante (utilisé dans le cas des rpis deportés)
Y a pas de raison pour que le plugin ne tourne pas avec.
Si vous arrivez a faire tourner une version de deconz, n’importe laquelle, il y a obligatoirement un webserveur qui tourne quelque part avec une API dispo pour jeedom (et un phoscon independant du reste), par contre pour trouver l’ip, le port et régler le websocket …

Sérieux, tu arrives a avoir 2 instances de deconz sur la meme VM ? C’est impossible normalement.
Tu dis avoir 2 phoscons, tu aurais les ip et les port de ces 2 applications (fais attention d’avoir une ip locale sur les deux) ?

Donc je comprend encore moins ce qui se passe.
Tu aurais une capture des 2 phoscons avec l’url visible (url locale) stp.

Car ça m’a l’air louche, deconz est conçu pour ne marcher que pour une seule instance, même avec des droits différent (normal car il se connecte, et bloque la clé USB, du coup impossible pour une seconde instance de faire pareil)

Bonjour à tous,
J’ai suivi avec un grand intérêt votre discussion et j’ai réussi à faire fonctionner deCONZ grâce à vous.

Par contre lorsque je me connecte sur deCONZ avec la GUI :

  • je ne retrouve pas les noms de mes devices zigbee (ils apparaissent identifiés par leur adresse IEEE)
  • tous mes devices zigbee n’apparaissent pas dans le graphique, j’en vois 5 sur 12 environ.

Voyez vous bien les noms des devices ?
Avez vous eu des problèmes similaires ?

Ce qui est curieux est que je dois redémarrer ma VM pour passer de Jeedom à deCONZ (si je désactive simplement le plugin, ca ne marche pas, il faut redémarrer). Et dès que je suis passé sur deCONZ, dans phoscon mes lumières disparaissent.
Merci pour votre aide

Bonjour.
Premier point important : tu ne peux pas voir deux sessions de deCONZ qui tournent en même temps sur une même machine (virtuelle ou pas). Une seule peut accéder à un instant donné à al clef ConBee2 sinon gare aux conflits.

Second point : il ne doit y avoir à un instant donné qu’un seule base de données Zigbee à laquelle deCONZ GUI ou Jeedom ou Phoscon qui sont des applications de haut niveau vont accéder. C’est le seul moyen de garder l’homogénéité entre la configuration connue de l’application et la réalité. A défaut l’application deCONZ GUI va prendre un peu plus de temps pour redécouvrir le réseau entier et perdre au passage des informations issues de Phoscon (nom des équipements en premier lieu).

Ces deux préalables étant rappelés il est fort probable que tu as juste fait un changement d’application entre ta machine virtuelle et une autre sans faire « suivre » la base de données Zigbee à chaque fois. Donc sur chacune des machines ce qui est affiché correspond à la une base et pas forcément la base up to date. Tu as donc perdu des noms (cf plus haut) et des équipements qui sont certainement en mode veille (capteurs par exemple) mais qui devraient finir par apparaître au bout d’un moment (avec la bonne base tu les aurais vus affichés avec des liens rouges ou pas de lien du tout avec leurs voisins).
Pour les équipements visibles sous deCONZ et pas dans Phoscon c’est probablement parce que le Phoscon que tu utilises à un instant t n’est pas celui qui est connecté à la base de données où à la clef Conbee2 (càd correspondant ou process deconz actif et valide sur la machine).

Pour ne travailler à chaque fois que sur une seule et même base de données entre différentes machines il faut, à chaque changement de machine :

  • sous Phoscon courant sauvegarder la configuration (mode advanced)
  • puis télécharger cette sauvegarde et la mettre sur un support amovible par exemple (la BDD est de taille très réduite avec Zigbee)
  • changer de machine (passer la clef ConBee2 sur une autre machine ou passer d’une machine physique à une VM par exemple)
  • sous Phoscon de cette nouvelle machine, importer la configuration préalablement sauvegardée (ce qui va resetter la GW au passage)
  • ensuite travailler avec un deCONZ GUI ou autre application sur cette machine.

Je pense que la manip est surtout a faire lors d’une modification du réseau.
Si tu ne rajoutes aucun appareil, je ne pense pas qu’il y ait besoin de copier la BDD.

Sinon utiliser un OS avec desktop, tu tournes tout le temps avec le GUI, ou tu peux le réactiver/désactiver en 2 lignes de commandes.

Sinon, je pense comme lui, la base de données ne doit pas être la même.

Edit:
Encore désolé Yves, je prend « répondre » a chaque fois, et ce putain de site me fait répondre au dernier qui a parlé, le gros « répondre » en vert est pas assez visible, faudrait qu’il clignote.

:rofl:pas de soucis.

Merci à tous les deux pour ces précisions qui sont très importantes.

Par contre je ne comprends pas très bien si je dois sauvegarder une base de données dans mon cas particulier car contrairement à l’exemple que tu donnes, je n’utilise qu’une machine. Je m’explique :

Contrairement à abeille, le plugin deconz de jeedom ne permet pas de visualiser les liens entre les devices zigbee et les routes qui se modifient avec certains appareils qui passent en coordinateur. J’ai vu que la GUI permettait de visualiser ces graphes et je l’ai installée dans ce but. Donc pas de problème si je dois désactiver le plugin jeedom pendant cette opération.
Concernant phoscon je ne l’utilise que pour gérer les groupes de lampes

J’ai une seule machine et une seule installation de deconz avec 3 interfaces :

  • jeedom / plugin deconz
  • phoscon (requette http sur localhost)
  • la GUI de deconz via un Xterm

En principe, je n’ai qu’une seule installation de deconz, il s’agit de celle qui a été faite par jeedom. La clef reste branchée sur cette machine qui est la seule à y accéder (c’est une VM mais elle accède en direct au port usb et aucune autre VM n’utilise la clef, ni aucune autre installation d’un software comme deconz).

J’ai bien compris qu’il fallait stoper le service du plugin jeedom avant de lancer la GUI.
Par contre je pensais que phoscon pouvait être lancé en même temps que les autres car je l’ai toujours utilisé en meme temps que le plugin jeedom sans constater de problème.
→ dois je me déloguer sur phoscon avant de lancer la GUI de deconz ? / Penses tu que ce soit phoscon qui perturbe ?

J’avais compris que jeedom avait installé deconz et communiquait avec lui via l’API. Du coup je m’attendais à ce que ces 3 interfaces que j’utilise me donnent accès à la même BD. Mais ce n’est visiblement pas le cas.
Ce qui est curieux c’est que Jeedom et phoscon ont toujours été parfaitement synchro.

Par contre deconz affiche des données incomplètes, comme s’il accédait à une autre BD. Je ne comprends pas…

Jeedom installe bien une instance de deCONZ et de Phoscon par la même occasion. Jeedom installe aussi un service qui démarre deCONZ lors du démarrage mais aussi en dynamique lorsque le service détecte que deCONZ est arrêté.
Donc pour utiliser decONZ GUI en stand alone il faut non seulement arrêter le plug-in Deconz de Jeedom mais aussi tous les services et process afférents (autrement dit pas simple surtout avec la relance dynamique).

L’application deCONZ stand alone si elle est lancée sur la même machine et dans le même environnement logiciel accèdera à la même base de données Zigbee (et donc Phoscon aussi). Jeedom et Phoscon s’interfacent bien avec deCONZ au travers du plug in deCONZ de deCONZ). La difficulté est d’arrêter sur cette machine l’instance de deCONZ qui y tourne déjà.
Ensuite il faut lancer Phoscon depuis l’application deCONZ GUI pour être sur qu’elle accède à la même base de données.

Les écarts de présentation entre Jeedom, Phoscon et deCONZ GUI viennent du fait que les bases accédées ne sont pas les mêmes (sur Zigbee, toute la topologie réseau est dans la basse de données pas en dur sur la clef ConBee2).

Par ailleurs sous Jeedom les équipements qui sont absents apparaissent comme tels. Il faut faire une synchro Jeedom pour retirer les noeuds qui auraient ont été désappariés du réseau depuis une autre interface que Jeedom ce qui permet à ce dernier de balayer la base de données et de mettre à jour sa configuration.

De plus seuls les équipements reconnus par Phoscon et traités par l’API sont présentés sous Phoscon. Il se peut que des équipements non encore intégrés dans l’API ne soient pas sous Phoscon alors qu’ils le sont dans deCONZ GUI. Le Github deCONZ RESTAPI est là pour faire nos requêtes de mise à jour par les développeurs de cette interface.