Interface graphique état connexion deconz

Il n’y a qu’une seule version de deconz, mais tu as la possibilité de la lancer en mode avec GUI ou en mode headless, je jamais lancer les deux mode en même temps.
Si tu ré-installes quelque chose, tu installe obligatoirement une deuxième application qui va utiliser une nouvelle BDD. Il n’y a pas de version différentes.

Du coup vu que c’est la même application, elle va utiliser les mêmes bases et la même config. Si ta machine a un desktop tu peux te passer de la version headless et tourner a 100% avec la version avec GUI, de cette manière tu auras l’image du réseau tout le temps, et l’accès a toutes les fonctions de deconz.

Il te faut juste configurer le plugin avec le mode « distant », c’est celui qui est utilisé si tu as deconz sur une autre machine que jeedom.

Bonjour @HugoVal11 et @Yves19 ,

je lis cet article avec attention, car j’ai aussi des bizarreries entre la vision des équipements connectés à ma clef ConBee 2 quand elle est connectée sur mon Raspberry Pi4 ou lorsque je la connecte à mon PC sous Win10 et donc que je visualise le réseau avec deconz-gui.
Comme le dit @Yves19, je vois plus d’équipements avec Deconz-gui qu’avec Phoscon ou le plug-in Jeedom.
Comme ce n’est pas pratique d’enlever régulièrement cette clef pour la changer de machine, j’aimerai comme indiqué dans ce thread pouvoir utiliser deconz-gui sur mon rpi en même temps que le plug-in deconz pour Jeedom.
J’aimerai comprendre ce que veux dire ‹ configurer le plugin avec le mode distant".
A quelle endroit dans la conf du plug-in je peux faire cela…


Cela veut-il dire repartir de zéro dans la conf du plug-in et notamment réinclure les équipements?
Sachant qu ›@Yves19 a l’air de dire que ce n’est pas faisable ou conseillé, d’autres l’ont-ils fait?
Pour être plus précis, je parlais de la procédure : désactivation du plug-in Deconz Jeedom, démarrage du service deconz-gui, puis redémarrage du plug-in Jeedom, les 2 fonctionnant en parallèle.
@Yves19 pour bien comprendre, la base de données des équipements liés à la clef Conbee2 est spécifique à chaque ‹ client › : deconz local, plug-in Jeedom, deconz-gui sur une machine Win10 par exemple?
Mais cette BDD n’est pas présente sur la clef, et n’est pas partagée entre ‹ clients ›.
Seul l’export/import via Phoscon permet de partager cette BDD (et encore quand j’ai fait cela entre la BDD Phoscon plug-in Jeedom sur mon Rpi et phocon-gui sur Win 10, tous les équipements ne semblent pas avoir été reconnus…?).
Si j’arrive à démarrer deconz-gui sur mon rpi, celui-ci va aussi démarrer un nouveau serveur pour Phoscon. Je devrai pouvoir réimporter la sauvegarde de la BDD exporté depuis le Phoscon installé par le plug-in Jeedom dans ce cas? Voire faire la même chose dans le sens inverse?
Ai-je bien compris?
Merci de vos éclaircissements

C’est indiqué dans la doc du plugin, il te suffit de ne pas installer deconz par jeedom, et de configurer les bonnes adresses IP.

Cela veut-il dire repartir de zéro dans la conf du plug-in et notamment réinclure les équipements?

Non, phoscon propose un backup/restoration, c’est ce qu’il faut utiliser si tu veux le même réseau sur toute les machines.

Sachant qu ›@Yves19 a l’air de dire que ce n’est pas faisable ou conseillé, d’autres l’ont-ils fait?

J’aimerais bien voir ou tu as vu ça ? mettre deconz sur un raspbery annexe pour faire une passerelle autonome est le plus fiable.

Pour être plus précis, je parlais de la procédure : désactivation du plug-in Deconz Jeedom, démarrage du service deconz-gui, puis redémarrage du plug-in Jeedom, les 2 fonctionnant en parallèle.

Ça par contre c’est complexe si tu n’as pas les compétences. Quelqu’un a fait un tuto en utilisant le X-fowarding, mais la ça c’est au dessus des miennes aussi.

a base de données des équipements liés à la clef Conbee2 est spécifique à chaque ‹ client › : deconz local, plug-in Jeedom, deconz-gui sur une machine Win10 par exemple?

A chaque client deconz sur la machine, pas la clé, le mode desktop/headless n’étant qu’un mode de config, pas un nouveau client.

1 « J'aime »

Si tu as besoin d’aide @BeauFort9476 sur cette partie hésites pas

2 « J'aime »

Merci pour la proposition @chris94440 , mais je vais déjà essayer avec un client VNC qui se connecte déjà au RPi.

L’application deconz-gui apparait dans les menus graphiques, mais n’est pas actif car le service sous-jacent deconz-gui est bien installé mais pas démarré.

Il faut arrêter le démon Deconz avant de lancer en ligne de commande l’appli deCONZ.

Merci @HugoVal11

Dans l’état actuel:
Le plug-in Deconz pour Jeedom a installé son implémentation du service Deconz (c’est lui qui accède actuellement à la clef Conbee2), mais en // j’ai aussi les installations locales des services deconz et deconz-gui qui sont installées sur mon rpi et qui ne demandent qu’à être démarrées.

Ce que j’ai compris de ce que disais @Yves19 dans ce thread c’est qu’il n’y avait qu’un seul service deconz qui pouvait accéder à la clef Conbee 2 à un instant donné.
J’ai vu que toi par contre tu proposais une procédure pour désactiver temporairement le plug-in, démarrer les services locaux (pas ceux installés par le plug-in Jeedom) en l’occurence ici deconz-gui (pas le headless). Et qu’ensuite je pouvais réactiver le plug-in deconz dans Jeedom.
Mais dans ce cas doit-il être dorcément en remote (i.e. connecté au service deconz qu’il n’a pas installé) ou puis-je rester avec l’instance deconz installée par le plug-in?
suis-je clair?

Merci encore

Merci @Yves19 (désolé, j’ai peut-être l’impression de me répéter, mais je veux être sûr de bien comprendre et maitriser ce que je fais plutôt que d’avoir des soucis à gérer ensuite)
Pour arrêter (et non désactiver?) le plug-in, je le fais depuis la page de configuration j’imagine? Depuis Etat ou Démon (car je n’ai pas d’icone pour Arreter, juste désactiver)


Merci

Tout juste oui

Merci @Yves19
Juste pour la documentation pour les prochains éventuels lecteurs, voilà à quoi ressemble le processus lancé par le plug-in Deconz pour Jeedom:


Ce processus disparait quand j’arrête le plug-in deconz.
Et je lance alors la ligne de commande suivant sur le RPi:
sudo systemctl start deconz-gui

Et sur mon VNC j’ai enfin d’application Deconz qui se lance!

Par contre il ne détecte semble-t-il pas ma clef Conbee2??

Voici le traces du status du service deconz-gui…

pi@raspberrypi4:~ $ sudo systemctl status deconz-gui
● deconz-gui.service - deCONZ: ZigBee gateway -- GUI/REST API
   Loaded: loaded (/lib/systemd/system/deconz-gui.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2022-01-17 18:32:59 CET; 6min ago
 Main PID: 5410 (deCONZ)
    Tasks: 106 (limit: 4915)
   CGroup: /system.slice/deconz-gui.service
           ├─5410 /usr/bin/deCONZ --http-port=80
           ├─5452 dbus-launch --autolaunch 03dc6b04a54e49a1926fd02048026d43 --binary-syntax --close-stderr
           ├─5453 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
           ├─7200 /bin/sh /usr/bin/xdg-open http://192.168.0.104:8080/pwa/login.html#host/192.168.0.104:8080
           ├─7282 /usr/lib/chromium/chromium --force-renderer-accessibility --disable-quic --enable-tcp-fast-open --show-compo
           ├─7344 /usr/lib/chromium/chromium --type=zygote --no-zygote-sandbox
           ├─7345 /usr/lib/chromium/chromium --type=zygote
           ├─7348 /usr/lib/chromium/chromium --type=zygote
           ├─7371 /usr/lib/chromium/chromium --type=gpu-process --field-trial-handle=17519123203192321958,5308490215961441769,
           ├─7375 /usr/lib/chromium/chromium --type=utility --utility-sub-type=network.mojom.NetworkService --field-trial-hand
           ├─7386 /usr/lib/chromium/chromium --type=utility --utility-sub-type=storage.mojom.StorageService --field-trial-hand
           ├─7404 /usr/lib/chromium/chromium --type=broker
           ├─7412 /usr/lib/chromium/chromium --type=renderer --file-url-path-alias=/gen=/usr/lib/chromium/gen --field-trial-ha
           ├─7413 /usr/lib/chromium/chromium --type=renderer --file-url-path-alias=/gen=/usr/lib/chromium/gen --field-trial-ha
           ├─7426 /usr/lib/chromium/chromium --type=renderer --file-url-path-alias=/gen=/usr/lib/chromium/gen --field-trial-ha
           └─7617 /usr/lib/chromium/chromium --type=renderer --file-url-path-alias=/gen=/usr/lib/chromium/gen --field-trial-ha

janv. 17 18:32:59 raspberrypi4 systemd[1]: /lib/systemd/system/deconz-gui.service:10: Unknown lvalue 'StartLimitIntervalSec' i
janv. 17 18:36:49 raspberrypi4 deCONZ[5410]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-pi'
janv. 17 18:36:56 raspberrypi4 deCONZ[5410]: [7282:7378:0117/173656.457544:ERROR:bus.cc(393)] Failed to connect to the bus: Co
janv. 17 18:36:56 raspberrypi4 deCONZ[5410]: [7282:7378:0117/173656.457698:ERROR:bus.cc(393)] Failed to connect to the bus: Co
janv. 17 18:36:56 raspberrypi4 deCONZ[5410]: [7282:7378:0117/173656.961906:ERROR:bus.cc(393)] Failed to connect to the bus: Co
janv. 17 18:36:56 raspberrypi4 deCONZ[5410]: [7282:7378:0117/173656.962000:ERROR:bus.cc(393)] Failed to connect to the bus: Co
janv. 17 18:37:09 raspberrypi4 deCONZ[5410]: [7375:7382:0117/173709.708741:ERROR:ssl_client_socket_impl.cc(924)] handshake fai
janv. 17 18:37:52 raspberrypi4 deCONZ[5410]: [7371:7371:0117/173752.930910:ERROR:gl_surface_presentation_helper.cc(259)] GetVS
janv. 17 18:38:13 raspberrypi4 deCONZ[5410]: [7371:7371:0117/173813.037749:ERROR:gl_surface_presentation_helper.cc(259)] GetVS
janv. 17 18:38:17 raspberrypi4 deCONZ[5410]: [7371:7371:0117/173817.128403:ERROR:gl_surface_presentation_helper.cc(259)] GetVS
lines 1-33/33 (END)

Une explication possible à la non détection, Deconz Gui me dit qu’un update firmware de la clef Conbee 2 est nécessaire :

Je pensais être à jour, mais peut-être une nouvelle version vient de sortir…

@Yves19 je prend un risque en faisant la mise à jour de cette manière?
Merci

Ne fais pas la mise à jour depuis deconz.

Voir ici pour l’update firmware :

Au préalable mets à jour deCONZ en version 2.13.4 (dernière stable).

Ok, merci @Yves19, j’ai bien fait de te demander avant. J’avais vu que tu disais déjà qu’il ne fallait pas le faire depuis le plug-in, mais il ne faut pas le faire non plus depuis Deconz Gui…

Par contre je ne comprend pas pourquoi il me parle d’update de firmware alors que j’ai installé la dernière version fin novembre:
deCONZ_ConBeeII_0x26720700.bin.GCF.md5 19-Aug-2021 22:23

Y-a-t-il une toute nouvelle version qui est sortie mais qui n’est pas sur la page Index of /deconz-firmware/ ?

Je pense que c’est deCONZ qui n’est pas à jour et donc croit à tort que c’est ton firmware qui n’est pas à jour.

J’ai mis à jour Deconz, mais l’interface essaie de se connecter mais ne semble pas y arriver…:

Pourtant cette fois-ci pas de traces de warning ou d’erreur au niveau du service:

pi@raspberrypi4:~ $ sudo systemctl status deconz-gui
● deconz-gui.service - deCONZ: ZigBee gateway -- GUI/REST API
   Loaded: loaded (/lib/systemd/system/deconz-gui.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2022-01-17 20:07:06 CET; 7min ago
 Main PID: 20037 (deCONZ)
    Tasks: 7 (limit: 4915)
   CGroup: /system.slice/deconz-gui.service
           ├─20037 /usr/bin/deCONZ --http-port=80
           ├─20068 dbus-launch --autolaunch 03dc6b04a54e49a1926fd02048026d43 --binary-syntax --close-stderr
           └─20069 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session

janv. 17 20:07:06 raspberrypi4 systemd[1]: Started deCONZ: ZigBee gateway -- GUI/REST API.
janv. 17 20:07:06 raspberrypi4 deCONZ[20037]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-pi'
janv. 17 20:07:06 raspberrypi4 deCONZ[20037]: libpng warning: iCCP: known incorrect sRGB profile
janv. 17 20:07:06 raspberrypi4 deCONZ[20037]: libpng warning: iCCP: known incorrect sRGB profile
janv. 17 20:07:06 raspberrypi4 systemd[1]: /lib/systemd/system/deconz-gui.service:10: Unknown lvalue 'StartLimitIntervalSec' i
janv. 17 20:11:06 raspberrypi4 systemd[1]: /lib/systemd/system/deconz-gui.service:10: Unknown lvalue 'StartLimitIntervalSec' i
lines 1-16/16 (END)

Et pas mieux dans Phoscon, même s’il a pu recharger la sauvegarde de la base de données exporté du Phoscon du plug-in

Ou alors il y a un soucis avec le port USB, mais tu as accès aux logs dans deconz maintenant, dans help, debug view.

Ou alors tu as encore 2 instances deconz qui tournent.

sudo systemctl stop deconz-gui
sudo systemctl stop deconz

Pour stopper les 2, et passes par le menu du bureau pour relancer deconz

Quand tu regardes

sudo systemctl status deconz-gui

Jetes un oeuil aussi a

sudo systemctl status deconz

Pour être sur de ne pas avoir les 2 qui tournent.

Merci @HugoVal11

Je ne connaissais pas les logs de debug de deconz-gui.
Par contre, un seul service tourne:

sudo systemctl status deconz
● deconz.service - deCONZ: ZigBee gateway -- REST API
   Loaded: loaded (/lib/systemd/system/deconz.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

Un extrait des logs

Je vois surtout un « failed open com status »

20:29:23:139 failed open com status: (-3), path: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2254887-if00
20:29:24:092 wait reconnect 5 seconds
20:29:24:141 COM: /dev/ttyACM0 : ConBee II (0x1CF1/0x0030)
20:29:24:142 COM: /dev/ttyAMA0 :  (0x0000/0x0000)
20:29:25:092 wait reconnect 4 seconds
20:29:26:092 wait reconnect 3 seconds
20:29:27:093 wait reconnect 2 seconds
20:29:28:093 Daylight now: nightStart, status: 230, daylight: 0, dark: 1
20:29:28:094 wait reconnect 1 seconds
20:29:28:179 COM: /dev/ttyACM0 : ConBee II (0x1CF1/0x0030)
20:29:28:181 COM: /dev/ttyAMA0 :  (0x0000/0x0000)
20:29:28:182 auto connect com /dev/ttyAMA0
20:29:29:608 Serial com connected
20:29:29:692 void zmMaster::handleStateStatus(zmMaster::MasterEvent) EVENT_TIMEOUT
20:29:31:456 void zmMaster::handleStateStatus(zmMaster::MasterEvent) EVENT_TIMEOUT
20:29:31:457 Serial com disconnected, reason: 1
20:29:31:458 device disconnected reason: 1, device index: 1
20:35:39:449 MASTER kill cmd 0x08 (ERROR)
20:35:39:449 Serial com disconnected, reason: 1
20:35:39:450 device disconnected reason: 1, device index: 1

Visiblement ta conbee2 est sur ttyACM0 et le démon essai de se connecter sur ttyAMA0.

Il faut

  1. redémarrer ta box domotique
  2. lancer le démon Deconz si pas déjà actif
  3. vérifier que tout fonctionne sous Jeedom/Deconz
  4. Arrêter le démon Deconz
  5. se connecter via VNC puis ouvrir uen fenêtre de commandes
  6. Lancer deconz en ligne de commande en mode admin (donc sudo deconz)
  7. attendre que la clef apparaisse dans la liste des interfaces deconz
  8. cliquer sur connecter et attendre que le réseau passe à « connecté »

Merci Yves pour ton analyse, j’avais effectivement vu les 2 ports différents, mais pourquoi le démon essai de se connecter sur ttyAMA0?
Comment puis-je le forcer à regarder sur ttyACM0?

J’ai pu faire des aller/retour avec le plug-in Jeedom qui redémarre bien et retrouve bien sa conf.

PI j’utilise bien cette ligne de commande pour démarrer le service, ce qui ouvre d’ailleurs automatiquement Deconz Gui sur VNC.
sudo systemctl status deconz-gui

A noter que la clef apparait, donc deconz la vois bien, sauf qu’il n’arrive pas à s’y connecter.

Je vais tenter le redémarrage de mon Rpi si tu penses que cela peut provenir de là…

Je redémarre tout le Rpi ou juste Jeedom?
Merci encore

Et bien il ne faut pas touchers aux services. Fais juste les étapes comme je te les ai indiquées.