Capteurs xiaomi (via deconz) reçu par jeedom mais pas mis à jour (encore...)

Plugins Protocole domotique
41

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.

42

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.

43

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.

44

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 ???

45

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.

46

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.

47

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 ?

48

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…

49

Donc pour toi, jeedom et phoscon sur 2 machines, connectée entre elles en wifi et que du standard (ni VM, ni docker)

PS:
Je viens de voir un truc, il y a des plugins pour navigateur web qui permettent de se connecter en websocket. Si l’un d’entre vous est assez calé pour se connecter en meme temps que jeedom sur le websocket, pour essayer de localiser le soucis ? Je viens de tester avec Browser WebSocket Client avec l’adresse ws://IP:PORT (port websocket pas le port « tout court »)

50

Jeedom tourne sur un rpi4 sous buster et phoscon sur un rpi3. Aucune VM ni docker en effet.
RPI3 <–> wifi <–> livebox4 <–> RPI4

PS: je test le websocket et te dis ça.

51

Aucun soucis pour me connecter au websocket sur phoscon en même temps que jeedom.

Sur le websocket j’ai ça:

{« config »:{« battery »:100,« on »:true,« reachable »:true,« temperature »:2600},« e »:« changed »,« id »:« 7 »,« r »:« sensors »,« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:46:f5-01-0006 »}

{« e »:« changed »,« id »:« 7 »,« r »:« sensors »,« state »:{« lastupdated »:« 2020-05-12T19:32:22 »,« open »:false},« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:46:f5-01-0006 »}

{« config »:{« battery »:100,« on »:true,« reachable »:true,« temperature »:2600},« e »:« changed »,« id »:« 14 »,« r »:« sensors »,« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:83:f6-01-0006 »}

{« e »:« changed »,« id »:« 14 »,« r »:« sensors »,« state »:{« lastupdated »:« 2020-05-12T19:33:27 »,« open »:false},« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:83:f6-01-0006 »}

Dans les log de jeedom j’ai ça:

[2020-05-12 21:32:22.632][DEBUG] : Received message from gateway 192.168.1.50 : {« config »:{« battery »:100,« on »:true,« reachable »:true,« temperature »:2600},« e »:« changed »,« id »:« 7 »,« r »:« sensors »,« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:46:f5-01-0006 »}
[2020-05-12 21:32:22.633][DEBUG] : Send to jeedom : {‹ 00212EFFFF0554B5 ›: {‹ config ›: {‹ battery ›: 100, ‹ on ›: True, ‹ reachable ›: True, ‹ temperature ›: 2600}, ‹ e ›: ‹ changed ›, ‹ id ›: ‹ 7 ›, ‹ r ›: ‹ sensors ›, ‹ t ›: ‹ event ›, ‹ uniqueid ›: ‹ 00:15:8d:00:03:e7:46:f5-01-0006 ›}}
[2020-05-12 21:32:22.638][DEBUG] : Starting new HTTP connection (1): 127.0.0.1:80
[2020-05-12 21:32:22.655][DEBUG] : Received message from gateway 192.168.1.50 : {« e »:« changed »,« id »:« 7 »,« r »:« sensors »,« state »:{« lastupdated »:« 2020-05-12T19:32:22 »,« open »:false},« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:46:f5-01-0006 »}
[2020-05-12 21:32:22.656][DEBUG] : Send to jeedom : {‹ 00212EFFFF0554B5 ›: {‹ e ›: ‹ changed ›, ‹ id ›: ‹ 7 ›, ‹ r ›: ‹ sensors ›, ‹ state ›: {‹ lastupdated ›: ‹ 2020-05-12T19:32:22 ›, ‹ open ›: False}, ‹ t ›: ‹ event ›, ‹ uniqueid ›: ‹ 00:15:8d:00:03:e7:46:f5-01-0006 ›}}
[2020-05-12 21:32:22][DEBUG] : {« 00212EFFFF0554B5 »:{« config »:{« battery »:100,« on »:true,« reachable »:true,« temperature »:2600},« e »:« changed »,« id »:« 7 »,« r »:« sensors »,« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:46:f5-01-0006 »}}
[2020-05-12 21:32:22.662][DEBUG] : Starting new HTTP connection (1): 127.0.0.1:80
[2020-05-12 21:32:22][DEBUG] : {« 00212EFFFF0554B5 »:{« e »:« changed »,« id »:« 7 »,« r »:« sensors »,« state »:{« lastupdated »:« 2020-05-12T19:32:22 »,« open »:false},« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:46:f5-01-0006 »}}
[2020-05-12 21:32:22.690][DEBUG] : http://127.0.0.1:80 « POST /plugins/deconz/core/php/jeeDeconz.php?apikey=XXXXXXXX HTTP/1.1 » 200 0
[2020-05-12 21:32:22.878][DEBUG] : http://127.0.0.1:80 « POST /plugins/deconz/core/php/jeeDeconz.php?apikey=XXXXXXXX HTTP/1.1 » 200 0
[2020-05-12 21:33:27.452][DEBUG] : Received message from gateway 192.168.1.50 : {« config »:{« battery »:100,« on »:true,« reachable »:true,« temperature »:2600},« e »:« changed »,« id »:« 14 »,« r »:« sensors »,« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:83:f6-01-0006 »}
[2020-05-12 21:33:27.453][DEBUG] : Send to jeedom : {‹ 00212EFFFF0554B5 ›: {‹ config ›: {‹ battery ›: 100, ‹ on ›: True, ‹ reachable ›: True, ‹ temperature ›: 2600}, ‹ e ›: ‹ changed ›, ‹ id ›: ‹ 14 ›, ‹ r ›: ‹ sensors ›, ‹ t ›: ‹ event ›, ‹ uniqueid ›: ‹ 00:15:8d:00:03:e7:83:f6-01-0006 ›}}
[2020-05-12 21:33:27.458][DEBUG] : Starting new HTTP connection (1): 127.0.0.1:80
[2020-05-12 21:33:27][DEBUG] : {« 00212EFFFF0554B5 »:{« config »:{« battery »:100,« on »:true,« reachable »:true,« temperature »:2600},« e »:« changed »,« id »:« 14 »,« r »:« sensors »,« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:83:f6-01-0006 »}}
[2020-05-12 21:33:27.474][DEBUG] : Received message from gateway 192.168.1.50 : {« e »:« changed »,« id »:« 14 »,« r »:« sensors »,« state »:{« lastupdated »:« 2020-05-12T19:33:27 »,« open »:false},« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:83:f6-01-0006 »}
[2020-05-12 21:33:27.475][DEBUG] : Send to jeedom : {‹ 00212EFFFF0554B5 ›: {‹ e ›: ‹ changed ›, ‹ id ›: ‹ 14 ›, ‹ r ›: ‹ sensors ›, ‹ state ›: {‹ lastupdated ›: ‹ 2020-05-12T19:33:27 ›, ‹ open ›: False}, ‹ t ›: ‹ event ›, ‹ uniqueid ›: ‹ 00:15:8d:00:03:e7:83:f6-01-0006 ›}}
[2020-05-12 21:33:27.480][DEBUG] : Starting new HTTP connection (1): 127.0.0.1:80
[2020-05-12 21:33:27][DEBUG] : {« 00212EFFFF0554B5 »:{« e »:« changed »,« id »:« 14 »,« r »:« sensors »,« state »:{« lastupdated »:« 2020-05-12T19:33:27 »,« open »:false},« t »:« event »,« uniqueid »:« 00:15:8d:00:03:e7:83:f6-01-0006 »}}
[2020-05-12 21:33:27.503][DEBUG] : http://127.0.0.1:80 « POST /plugins/deconz/core/php/jeeDeconz.php?apikey=XXXXXXXX HTTP/1.1 » 200 0
[2020-05-12 21:33:27.684][DEBUG] : http://127.0.0.1:80 « POST /plugins/deconz/core/php/jeeDeconz.php?apikey=XXXXXXXX HTTP/1.1 » 200 0

Apparemment les infos remontent de la même façon sur jeedom que mon pc…
Je me répète peut être mais dans les log du plugin deconz il y a un timed out au bout d’un certain temps et l’écoute du websocket s’arrête mais ne se relance jamais.
Il n’y a pas un moyen de configurer le plugin pour qu’il relance l’écoute websocket dès lors qu’il est timed out ?

52

Ça je sais pas, je suis pas dev.
Mais le truc a faire si de voir si ça deco en même temps sur jeedom et sur une autre appli (je sais pas ce que tu utilises pour te connecter au websocket) c’est pour ca que je proposais de les faire tourner en meme temps, pour voir si la connexion se perd des 2 coté a la fois.

Comme ça, ça permettrait de voir de quel coté se pencher, si le prb vient de jeedom, de deconz, ou du systeme de websocket mit en place.

Parce que j’ai pu voir quelques issues a un moment sur une application qui avait le meme probleme, puis plus rien qui ressemble a ça sur leur github depuis plusieurs mois.

Y a eu ça comme réaction coté Jeedom, puis plus de news Le démon se coupe tout seul

53

Ok j’avais pas compris.
J’ai vu qu’une mise à jour a été poussée aujourd’hui et qui relancerai la connexion WebSocket en cas de perte (ce que je suggérais). Je viens de l’installer, je désactive mon scénario de relance pour voir si ça fonctionne et je vous tiens au jus.

54

Avec un peu de retard: ça semble stable pour ma part pour le moment.
Merci aux développeurs pour leur modifications.

55

Bonjour à tous depuis quelques temps déjà, je me réveille et surprise… La couche jeedom ne fonctionne plus sur tous les devices. Sur phoscom adresse IP:8484 tout est opérationnel.
Si je relance le démon tout repart la normale. Pendant quelques jours.
J’ai découvert ce fil. J’étais prêt à laisser tomber combee. J’ai mis en place le scénario il y a quelques jours. Et ce matin rebelote. Mes ouvrants sur jeedom sont figés. Je clique sur un device pour l’allumer. Il s’allume mais aucun retour d’état… Bref , je consulte le.log deconz :
Connection Times out… (Errno 110)
Punaise. 3 mois de galère. J’en peux plus.

56

Bonjour à tous,
Je viens de voir ce fil par hasard et comme beaucoup, j’ai le même problème du websocket qui lâche au bout d’un moment (en général plusieurs jours voir plusieurs semaines) mais difficile à détecter.

57

@neiler09 et @remidetoulon.
Pour ma part, le problème semble résolu, mais je ne me fais pas de doute qu’il est probable que le websocket relâche aléatoirement.
Une solution temporaire consiste à créer un scénario qui va relancer le plugin toutes les x heures afin de palier ce problème de websocket.
Cette solution fonctionne pour moi:

Ayant remarqué que le websocket lâche au minimum au bout d’environ 4-5h, c’est la raison pour laquelle j’ai mis à exécuter mon scénario toutes les 3h.
A vous de voir s’il est nécessaire de raccourcir ou rallonger cet intervalle.

2 « J'aime »
58

Bonjour Altoinou,
Aurais tu une petite idée ? Aujourd’hui la couche deconz m’a lâché après 6 jours de bon et loyaux services.
J’ai regardé les log de ton scénario :
[2020-06-01 15:00:02][SCENARIO] Start : Scenario execute automatiquement sur programmation.
[2020-06-01 15:00:02][SCENARIO] Exécution du sous-élément de type [action] : code
[2020-06-01 15:00:02][SCENARIO] Exécution d’un bloc code
[2020-06-01 15:00:02][SCENARIO] syntax error, unexpected ‹ deconz › (T_STRING)
[2020-06-01 15:00:02][SCENARIO] Fin correcte du scénario

Je n’ai pas l’impression qu’il relance correctement le demon.
J’ai exécuté ton scénario manuellement et visiblement, le demon n’a pas été relancé.
J’ai du le faire manuellement.
As tu une idée ?
Cordialement

59

Slt @remidetoulon.
En effet je viens de me rendre compte en relisant ton message que dans le script mon copier-coller a mal fonctionné et a mis des caractères invalides…
Je te mets ci après le script exacte à insérer dans la partie code :

// id du plugin
$_plugin_Id = 'deconz';

// charger le plugin 
$_plugin = plugin::byId($_plugin_Id);
if (is_object($_plugin)) {
  
    	// start daemon ...
		$scenario->setLog('démarrage du plugin ' . $_plugin_Id);    
		$_plugin->deamon_start(true);    
		$scenario->setLog('status daemon du plugin : ' . $_plugin->deamon_info()['state']);
}
60

Je vais tester, je te tiens au courant. Merci