Jeedom Core : 4.3.1
Version JC : 1.4.2 beta
DNS Jeedom : non
Statut Démon : Démarré - (2022-10-17 23:26:50)
Equipements :
TAB S7 Xav : v1.4.2 (1108) beta sur android [os : 32] (ws)
S21 Xav : v1.4.2 (1108) beta sur android [os : 31] (ws)
S9 : v1.4.2 (1108) beta sur android [os : 29] (ws)
TAB-murale : v1.4.2 (1108) beta sur android [os : 25] (ws)
J’ai installé le plugin beta z-wave Js, afin de migrer mes équipements sur un plugin plus récent que le vieillissant zwave.
Mais lorsque je démarre le démon z-wave Js , celui de JC s’arrete avec cette erreur :
On dirait que les 2 plugins partagent le même port d’après l’erreur
lorsque j’arrête z-wave Js , et que je redémarre l’ancien tout rentre dans l’ordre.
coté Jc a priori ,on peut le bouger ici :
comme coté z-wave Js , il n’y a aucune notion de port, est ce que je peux le changer coté JC sans tout cassé ? Est ce que vous avez déjà constaté le pb ?
merci
Est ce une vraie question ??
si on la rendu parametrable, ya de forte chance pour que ca ne soit pas uniquement pour faire joli sur la page
et en l’occurence d apres la log, ca n’est pas le port socket démon qui semble poser probleme, mais l’autre Port Websocket JC
Par contre si modif, ca veut evidemment dire que la config sur ta box & co doivent egalement evoluer dans ce sens
(Ca va sans dire, mais je prefere l ecrire…!)
pour moi c’est celui-là non ?
Le web socket est sur autre port que j’ai attribué moi-même et donc redirigé sur ma box
Mon message était plus pour alerter en fait qu’il y allait avoir collision lors de la sortie du plugin z-wave Js
(Par contre depuis la nouvelle version de JC ,la géoloc marche à merveille. Bravo pour le boulot)
Non non, je posais pas une question de mon côté, mais t indiquais bien que le soucis est sur l autre
Les collisions il peut malheureusement y en avoir tout le temps puisque le choix des ports est laissé libre au developpeur et qu il ny pas de centralisation cote jeedom pour savoir ce qui est « deja pris » par tel ou tel plugin.
Mais l info est peut etre + a remonter cote zwave puisqu ils sont tjs en beta
Pas vraiment… en attendant que le core le gère, si tu prends un port aléatoire libre au moment du démarrage du demon, tu réduis les probabilités
public static function getFreePort() {
$freePortFound = false;
while (!$freePortFound) {
$port = mt_rand(1024, 65535);
exec('sudo fuser '.$port.'/tcp',$out,$return);
if ($return==1) {
$freePortFound = true;
}
}
config::save('socketport',$port,'unifi');
return $port;
}
Je le fais depuis peu dans mes plugins, jMQTT aussi mais un peu différemment, il écoute sans préciser de port, python (dans son cas) choisit donc un port libre au hasard et puis il envoi ce port à jeedom via api pour que jeedom sache sur quel port parler avec le demon. Encore plus infaillible ! (Car réduit le temps entre la sélection du port et sa réservation)
Pas certain de comprendre le « pas vraiment » !?
Les developpeurs n ont pas le choix dans le port qu ils peuvent utiliser ? Il y a un endroit où on peut voir quel port est utilisé par quel plugin ?
En l occurence un port « aleatoire » ne nous convient pas puisqu on a besoin d ouvrir ce port a l extérieur. Donc si a chaque redémarrage du demon, le port change, ca va etre un peu compliqué de s en sortir…
Mais il est vrai que le cas pourrait aussi se produire sur le port du socket pour communication entre python et jeedom, là ca pourrait etre utile. (Pas mal la partie jmqtt !)
Oui dans le cas d’un port extérieur il faut faire une sorte de reverse proxy c’est un peu plus compliqué (qui lui doit être sur un port fixe) mais ça reste possible.
Le « pas vraiment » était pour le fait qu’il y aura « tout le temps » des collisions tant que le core le gère pas.
On va eviter de monter une usine a gaz, ca marche tres bien sans depuis 2 ans dans 99,9 % des cas
Ce que je voulais dire c est que les collisions seront possible quelque soit le plugin (et non pas uniquement avec zwave dont il est question ici) tant que le core ne gere pas l info.
Faudrait que tu m’expliques pourquoi ? car là je pige pas .L’erreur est sencé etre plus haut dans le log ? Mon websocket est sur 80xx pas sur 58090
Je vais migrer ce soir ou demain matin le plug z-wave.Je les modifierai en cas d’erreur , je te dirai
Je pensais que j’avais mis une log au démarrage du 2nd démon (qu’on ne voit pas ici, d’où le fait que je pensais que c’était l’autre qui plantait !)
mais ca n’est pas le cas → je viens de l’ajouter pour la prochaine version !
0002|[2022-10-20 10:35:30,929]DEBUG : Socket port : 58090
0003|[2022-10-20 10:35:30,929]DEBUG : PID file : /tmp/jeedom/JeedomConnect/deamon.pid
0004|[2022-10-20 10:35:30,929]DEBUG : ** Starting Jeedom daemon **
0005|[2022-10-20 10:35:30,929]INFO : Writing PID 9517 to /tmp/jeedom/JeedomConnect/deamon.pid
0006|[2022-10-20 10:35:30,930]INFO : Init request module v2.28.1
0007|[2022-10-20 10:35:30,930]INFO : ** Jeedom daemon started **
0008|[2022-10-20 10:35:30,930]DEBUG : ** Starting JC Websocket daemon **
0009|[2022-10-20 10:35:30,930]INFO : Listening on port 8090 for clients...
0010|[2022-10-20 10:35:30,931]INFO : Starting WebsocketServer on thread Thread-2.
0011|[2022-10-20 10:35:30,931]INFO : ** JC Websocket daemon started **
du coup, méaculpa, c’est bien le port 58090 qui pète et est déjà de ton côté
(bon d’un autre côté si tu avais partagé toute la log, ça aurait aussi permis de trouver plus facilement dans quel fichier l’exception était jetée et du coup avoir un indice sur lequel des 2 plantait ! je n’ai pas fait en sorte de laisser le Traceback dans les logs pour rien)
Quoiqu’il en soit la réponse à la question initiale a déjà été répondue : si le paramétrage est laissé à la main de l’utilisateur c’est pour qu’il puisse le modifier.
Sinon ca ne serait ni proposé ni affiché
ok merci. me semble en fait qu’il n’y avait que ça qui se répétait. Enfin pas grave.
Je sais qu’il est paramétrable, mais comme dit l’autre jour
je savais pas comment te présenter la chose , je te connais à force …donc je me doutais de ta réponse.
je cloture, quand je basculerai de plug ,je le modifierai.
merci pour l’ajout du log, ça aura servi à ça
Bonne journée
Moi je ne comprend pas pourquoi tu parles de zwavejs depuis le début puisqu’il n’y a aucun port ouvert en écoute par ce plugin autant que je sache… sa communication passe par mqtt
peut-être Mqtt , en tout cas mqtt, le demon est démarré et tourne.Jc aussi
L’autre jour quand j’ai installé le plugin zwavejs, j’ai démarré le démon pour voir si il démarrait et que tout était ok, j’ai eu l’erreur direct dans JC.
J’ai arrêté le démon de zwavejs, pour réactiver l’ancien plugin zwave, j’ai redémarré sans souci le démon JC qui était planté .Il tourne depuis.
D’où ma déduction
8090 c’est le port par défaut du WS sous JC
8090 c’est le port par défaut du démon sous zigbee
8091 est à présent utilisé par zwavejs (btw, je pense que zigbee utilise 8091 et suivant lorsqu’il y a des contrôleurs supplémentaires configurés => il va y avoir conflit entre ces plugins)
=> donc déjà là il y a un problème sur le 8090
le cas du 58090 je ne sais pas cmt vous avez conclu que c’était lui le coupable, je n’ai pas tout lu, je vous crois sur parole, mais JC est le seul à l’utiliser à priori donc si c’est ca, c’était juste un « problème sporadique »
mais vu ta config, je me demande quand même si c’était pas l’autre le problème…
oui c’est l’autre tu as raison c’est le 8091 du WS Je croyais que c’était moi qui avait affecté le 8091 au WS mais c’est donc celui par défaut. je vais le modifier pour qu’il ne rentre pas en conflit avec zwaveJC.Je modifierai mon fw en conséquence et reconfigurerai l’appli.
Après pourquoi dans les logs apparait l’autre, je ne sais pas
8090 c’est le port par défaut du WS sous JC
8090 c’est le port par défaut du démon sous zigbee
par contre aucun conflit chez moi entre les 2 , cela fait des mois que ça tourne comme ça
par contre sous zigbee , ça doit peut être dépendre du matos
, je te connais à force 
