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…
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 »)
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.
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 ?
Ç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
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.
Avec un peu de retard: ça semble stable pour ma part pour le moment.
Merci aux développeurs pour leur modifications.
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.
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.
@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 »
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
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']);
}Je vais tester, je te tiens au courant. Merci
Petite question aux utilisateurs de deconz.
A chaque fois que je redémarre le demon, j’ai remarqué que j’avais 3 prises xiaomi sur 5 que je dois réactiver manuellement pour que celle ci soit prise en compte?
Ça vous le fait à vous ?
c’est a dire pas « prise en compte » ? Elle ne répondent plus ou ne sont pas marquée en utilisable ?
Je viens d’abandonner la zigate parce que je perdais des capteurs Aqara que je n’arrivais pas à réinclure.
Sur Conbee 2 depuis 3 jours, tout fonctionne pour l’instant mais je vois que vous rencontrez aussi des problèmes 
Bonjour à tous.
J’ai un peu plus identifié le problème évoqué au-dessus.
Le problème ne vient pas de la couche jeedom, mais de phoscom. Et j’explique (prise en compte):
Tout les matins quand je me réveille, j’ai 3 prises Xiaomi sur 5 (version juste avant celle avec la prise USB) qui ne répondent plus.
Je pensais que le problème venait de la couche jeedom (deconz) mais visiblement quand je vais sur l’interface phoscom,.les prises réagissent parfaitement sur l’interface graphique, MAIS DANS LE RÉEL… Rien ne se passe…
Si je vais sur la prise (qui ne répond plus) et que je l’active manuellement. Tout reviens à la normale.
Hier j’ai reçu une nouvelle prise Xiaomi (la nouvelle version européenne). Pour le test , je l’ai mise a la place d’une de mes prises qui ne fonctionne plus.au bout de 24h env. Et surprise. Ce matin… Elle ne répond plus elle aussi !!! Je l’active manuellement et tout repart à la normale.
Avez vous une petite idée ?
Je dirais un probleme de connexion, mais chez Xiaomi, en cas de problemes de connexion, les appareils se barrent.
Tu ne peux pas regarder le maillage ?
Ce ne serait pas les plus éloignées qui déconnent ? Tu as essayé de mettre une rallonge USB ?
Tu n’as pas installé la derniere version de deconz (ne le fais pas si tu n’en as pas besoin)
Pour regarder le maillage il faudrait que je déplugue la clé et que je regarde ça sur mon pc. 1/Pourquoi pas 
2/Alors non, ce ne sont pas les plus éloignés qui se déconnectent !!! j’en ai deux à 5m du contrôleur et sans mur qui ont ce problème.
3/Oui j’utilise un hub alimenté (car pi4 avec clé zwave) et celui-ci est au beau milieu de la maison (petite maison) le capteur le plus éloigné étant à 8m max avec deux cloisons placo max entre.
4/Version deconz 264A0700
Pour info, la configuration de la maison étant adapté pour me passer de routeurs, j’ai appairé les prises après avoir appairé les capteurs volontairement.
Ça passe nickel. Ce qui à l’avantage dans mon problème (prise xiaomi qui se déconnectent) de ne rien bloquer.
En revanche lorsque j’appaire une de ces prise (défectueuses) c’est au tac au tac… que je sois au bout de la maison, deconz la reconnais en moins d’une seconde.