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.