Bonjour a tous
le daylight sensor “not reachable” C’est interne a la conbee apparemment mais je sais pas a quoi sa sert et toujours le problème de remonté vers jeedom des températures qui reste figées sauf si je bascule d’une page a l’autre
Justement c’est interne a la conbee, comment tu veux qu’il soit unreachable ?
Tu as vérifié si tu avais bien un numéro de firmware affiché dans « gateway » ?
j’ai pas de problème avec le daylight sensor interne a la conbee cest un problème de capteurs ,ils sont bien installés , avec Phoscon App je vois tous les capteurs quand je souffle du chaud ou froid (je le met dans le congélateur ) la température baisse ou monte quasiment instantané sur Phoscon App mais pas sur jeedom ,j’ai 4 pages dans jeedom accueil / température /gestion chauffage (avec le plugin thermostat) /et monotoring ,si je reste sur la page température de jeedom quand je fait baissé la température d’un capteur je la vois sur Phoscon App mais pour le voir baissé ou monté sur jeedom il faut que je zap entre les pages température et gestion chauffage et la je la vois baissé ou monté
donc je pense que les capteurs fonctionne bien que c’est peut être un problème sur le plugin Deconz voici les pages ,
J’ai ce même type de problème de rafraîchissement avec mes senseurs xiaomi (détecteurs de mouvement et d’ouverture).
Par exemple, le détecteur de mouvement retourne une valeur de détection mais celle de la température reste inchangée.
En ouvrant la page du sensor dans Phoscon, la température est actualisée et rafraîchie rapidement.
En revenant sur Jeedom, la température est toujours la même.
Comme il n’existe pas de commande refresh, comment actualiser manuellement le retour d’état ou avec le retour de détection ?
Merci 
Essayes de redémarrer le demon pour redémarrer le retour d’état. Ca ne va pas re-actualiser les valeurs.
Par contre, ça marche ou ça marche pas, pas normal que ça remonte pour un capteur et pas un autre. Tu n’as pas la même valeur pour les température sur phoscon et jeedom ?
J’ai justement un script basé sur jeelink pour forcer le redémarrage du démon chaque nuit car au bout de quelques jours les valeurs ne remontaient plus…
Je crois que la température n’ait modifiée qu’après une variation pas forcément à chaque détection par exemple. Bon après, c’est pas super fiable même en corrigeant la température de base.
Je ne sais pas si on peut faire une actualisation forcée.
Avec le Zwave y’a un refresh.
Et effectivement, les valeurs sont actualisées rapidement de l’ordre de quelques minutes sous PHOSCON.
Haaa, mais tu parles de la valeur température des capteurs de mouvement et ouverture ?
Si c’est ça, tu peux oublier, c’est pas du tout utilisable.
Bonjour a tous.
J’ai le même problème.
J’étais initialement sur Freebox delta avec 1 clé sur chaque port USB (enocean et conbee2) (je suis en V4).
Ayant ces problèmes, j’ai ressorti mon pi pour brancher la conbee 2.
Tout fonctionne, mais au bout de quelques jours / heures, le soucis réapparaît.
Je relance manuellement le démon, et c’est en général reparti.
Le problème est que je je suis obligé de monitorer tout le temps interface pour un simple thermostat.
Si vous voulez que je post des logs, aucun soucis, dites moi juste lesquels 
Merci à vous pour votre aide!
Donc pareil au bout de X jours, TOUT tes capteurs ne remontent plus rien, et ça revient quand tu relances le demon ?
Tu n’as que des capteurs ou aussi des appareils routeurs ?
Oui, pareil. J’ai 4 sondes de température aquara, une ampoule, un Switch on off et un variateur ikea
Bonjour,
Problème du même genre chez moi :
- Je suis en V4 sur Freebox Delta
- 2 capteur AQARA Temp., Hum et Pression
- Installation DeConz sans problème
- Inclusion des capteurs (soit via DeConz soit via Phoscon, les deux options fonctionnent, mais semble plus « stable » via Phoscon, depuis Deconz, j’ai eu parfois deux appareils ajoutés en même temps alors que j’en incluait un seul)
- En tout cas, une fois tout cela réalisé tout fonctionne parfaitement
Puis, je lance un redémarrage de Jeedom et la plus aucune remontée des valeurs dans Jeedom.
Le valeurs s’actualisent parfaitement dans Phoscon, dans les valeurs brutes sur Jeedom aussi, mais pas dans la commande. Donc Jeedom communique bien avec la clé, la clé communique bien avec les capteurs, mais Jeedom semble ne plus interpréter les valeurs
J’ai fait l’exercice de désinstaller, changer de clé API, relancer l’install locale, d’arrêter et relancer le Demon, rien n’y fait.
Je dois supprimer les capteurs depuis Phoscon et les réinclure. Et ca refonctionne jusqu’au prochain redémarrage de Jeedom.
Avez vous le même type de comportement sur un redémarrage Jeedom ?
En espérant qu’on trouve un fix, c’est vraiment inutilisable tel quel…
J’ai décidé d’abandonner la clef ConBee 2. Je crois que je suis sur ce problème depuis le début de l’année et j’en ai assez. J’ai meme réinstallé Jeedom sur un disque mSATA avec un hub auto alimenté pour mettre ConBee, pas de changement, le problème est revenu en quelques jours.
Est-ce que quelqu’un est passé avec succès sur une clef Zigate?
Bon, il semble que j’aie trouvé une partie du problème et un contournement.
Si ça peut servir à d’autres, ci-dessous mes constats et actions :
En fait à chaque redémarrage de Jeedom, le Démon de DeConz se relance, mais en gestion automatique, il ne se met plus à jour par la suite (la date du dernier lancement affichée dans la zone Démon est celle du redémarrage de Jeedom).
J’ai désactivé la gestion automatique du Démon et mis un scénario qui lance le démon après redémarrage Jeedom (Je suis pas sur que c’était nécessaire le scnéario mais bon…)
Je viens de relancer deux fois mon Jeedom et ça a l’air de fonctionner. En espérant que ça dure, car ça fait des jours que je me bats avec ça.
Bonjour,
Je constate le même problème lorsque je redémarre.
J’ai donc aussi depuis plusieurs mois désactivé la gestion auto du demon.
Si qui est surprenant, c’est que lorsque Jeedom j’actualise plus les valeurs, homebridge continue de fonctionner et de récupérer les états . Alors que homebridge ce base sur les donnés de Jeedom me semble t’il.
Bonjour à tous,
J’ai le même problème que vous, des informations de capteurs qui ne remontent plus au bout d’un certain temps (mais les actions fonctionnent). Seule solution = forcer le redémarrage du plugin deconz. NB: les informations sont bien à jour et en temps réel sur Phoscon.
Ma configuration : jeedom sur RPI4, Conbee2 sur RPI3 (IP:192.168.1.50) en déporté, même fuseau horaire sur les deux, même OS (raspbian buster).
Ci-dessous le dernier log où est identifiée l’erreur :
[2020-05-02 04:00:08.827][DEBUG] : Received message from gateway 192.168.1.50 : {« e »:« changed »,« id »:« 24 »,« r »:« sensors »,« state »:{« lastupdated »:« 2020-05-02T02:00:08 »,« open »:false},« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:85:8d-01-0006 »}
[2020-05-02 04:00:08.828][DEBUG] : Send to jeedom : {‹ 00212EFFFF0554B5 ›: {‹ e ›: ‹ changed ›, ‹ id ›: ‹ 24 ›, ‹ r ›: ‹ sensors ›, ‹ state ›: {‹ lastupdated ›: ‹ 2020-05-02T02:00:08 ›, ‹ open ›: False}, ‹ t ›: ‹ event ›, ‹ uniqueid ›: ‹ 00:15:8d:00:03:e7:85:8d-01-0006 ›}}
[2020-05-02 04:00:08.836][DEBUG] : Starting new HTTP connection (1): 127.0.0.1:80
[2020-05-02 04:00:08][DEBUG] : {« 00212EFFFF0554B5 »:{« config »:{« battery »:100,« on »:true,« reachable »:true,« temperature »:2100},« e »:« changed »,« id »:« 24 »,« r »:« sensors »,« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:85:8d-01-0006 »}}
[2020-05-02 04:00:08][DEBUG] : {« 00212EFFFF0554B5 »:{« e »:« changed »,« id »:« 24 »,« r »:« sensors »,« state »:{« lastupdated »:« 2020-05-02T02:00:08 »,« open »:false},« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:85:8d-01-0006 »}}
[2020-05-02 04:00:09.307][DEBUG] : http://127.0.0.1:80 « POST /plugins/deconz/core/php/jeeDeconz.php?apikey=XXXXXXXXX HTTP/1.1 » 200 0
[2020-05-02 04:00:09.587][DEBUG] : http://127.0.0.1:80 « POST /plugins/deconz/core/php/jeeDeconz.php?apikey=XXXXXXXXX HTTP/1.1 » 200 0
[2020-05-02 04:00:24][DEBUG] : 192.168.1.50:80/api/XXXXXXXXX/config type : PUT
[2020-05-02 04:04:40.368][DEBUG] : Closing Thread for 192.168.1.50 because [Errno 110] Connection timed out
[2020-05-02 04:12:14][DEBUG] : 192.168.1.50:80/api/XXXXXXXXX/config/export type : POST
[2020-05-02 05:00:24][DEBUG] : 192.168.1.50:80/api/XXXXXXXXX/config type : PUT
[2020-05-02 06:00:23][DEBUG] : 192.168.1.50:80/api/XXXXXXXXX/config type : PUT
[2020-05-02 07:00:23][DEBUG] : 192.168.1.50:80/api/XXXXXXXXX/config type : PUT
[2020-05-02 08:00:25][DEBUG] : 192.168.1.50:80/api/XXXXXXXXX/config type : PUT
[2020-05-02 09:00:25][DEBUG] : 192.168.1.50:80/api/XXXXXXXXX/config type : PUT
[2020-05-02 10:00:23][DEBUG] : 192.168.1.50:80/api/XXXXXXXXX/config type : PUT
[2020-05-02 11:00:22][DEBUG] : 192.168.1.50:80/api/XXXXXXXXX/config type : PUT
J’en avait déduit que l’erreur se produisait à ce moment là:
[2020-05-02 04:04:40.368][DEBUG] : Closing Thread for 192.168.1.50 because [Errno 110] Connection timed out
J’ai donc fouiner sur le net et est ré-installer le websocket à la fois sur RPI4 (jeedom) et sur le RPI3 (conbee déporté) en ayant pris soin de vérifier la mise à jour de pip avant.
==> problème non résolu.
Par acquis de conscience, j’ai laissait tourner un ping de RPI4 vers RPI3 toute la nuit, et n’est remarqué aucune perte de paquet …
J’ai donc mis en place pour le moment un scénario qui redémarre le plugin deconz toutes les 30mn.
J’espère que ces informations apporteront des idées à d’autres sur le moyen de régler ce problème.
J’ai le même soucis que vous avec mes capteur de mouvement aqara. Au bout de quelques heure ou jour il sactualise plus.
Vous avez trouvé une solution ? Ras dans phoqcom la remonte edt immédiate. Ça fait cher le plugin qui fonctionne pas. Aucun retour de l’équipe jeedom sur le sujet ???
La seule solution qui fonctionne à ce jour est de mettre en place un scénario qui toutes les 3h redémarre le plugin deconz.
D’après ce que j’ai pu constater le problème provient bien du plugin deconz et non de phoscon (puisque toutes les valeurs sont à jour en temps réel sur ce dernier).
Tant que le développeur du plugin n’aura pas inclus dans le programme une relance du websocket à chaque connexion « timed out », alors le problème ne sera pas résolu.
Description du scénario à créer:
Dans l’onglet « Général »:
Mode du scénario = programmé
y mettre la valeur
0 */3 * * *
Dans l’onglet « Scénario »:
Ajouter bloc « Code »
Y insérer le code suivant:
$_plugin_Id = ‹ deconz ›;
$_plugin = plugin::byId($_plugin_Id);
if (is_object($_plugin)) {
$scenario->setLog('démarrage du plugin ’ . $_plugin_Id);
$_plugin->deamon_start(true);
$scenario->setLog('status daemon du plugin : ’ . $_plugin->deamon_info()[‹ state ›]);
}
Toutes les 3h tous les jours (00h00, 03h00, 06h00, …) le plugin deconz sera redémarrer ce qui forcera la reconnexion du websocket et donc la remontée des informations dans jeedom des valeurs de phoscon.
Mais c’est quand même bizarre, vous êtes pas mal avec ce probleme, mais ce n’est pas une généralité quand même.
Et j’arrive pas a trouver un point commun entre vous, machines différentes a chaque fois. Firmware et deconz a jour le plus souvent.
Vous passez en ethernet ou wifi ?
Pas d’application ou de plugin bizarre sur vos config ?
Applications UPnP style qui se servent de alexa ou google home ?
Jeedom en ethernet, phoscon en wifi, pas d’upnp pour Google home, ni application ou plugin bizarre…
Il n’y a que ce foutu websocket qui plante aléatoirement et qui ne se résout qu’en redémarrant le plugin…