Plugin jMQTT

[StephC]

Bonjour GV,
Non, ce n'est pas lié au fait que que c'est une réinstallation.
J'ai mis un commentaire sous GitHub pour expliquer ce qu'il se passe: https://github.com/domotruc/jMQTT/issues/9.
Suis en train de tester plusieurs manières de le corriger.
Stéphane

[StephC]

Bonjour,
J'envisage d'ajouter une fonctionnalité permettant de publier vers le broker MQTT toutes informations jeedom modifiées, voir https://github.com/domotruc/jMQTT/issues/21.
Avant de me lancer, suis preneur de connaître votre intérêt pour une telle fonctionnalité, vos attentes, vos idées, ...
Plutôt sur le fil GitHub.
Merci d'avance,
Stéphane

[StephC]

Bonsoir,
Nouvelle mise à jour disponible demain matin qui implémente la possibilité de désactiver l'installation de Mosquitto en local (si votre broker est installé sur une machine distante).
Stéphane

[meute]

Hello,

Top ta version, je découvre mais j'ai testé les deux et dans mon cas il n'y a que JMQTT qui puisse convenir vu que je dois parser pas mal de json en provenance du daemon ebusd pour ma chaudière ... que du bonheur pour l'instant mais suis pas au bout de l'intégration.

Par contre quand j'ai désactivé le plugin MQTT original ça a fait perdre la connexion vers Mosquito pour JMQTT, son daemon ne démarrait plus, je suppose que Mosquito était à l'arrêt , j'ai relancé l'install des dépendances depuis JMQTT et c'est reparti.

[marmoul]

Bonjour,

J'ai souvent cette erreur qui remonte.
Genre plusieurs fois par jour.
mais je ne sais pas top ou chercher du coup.
Sa peut expliquer que tout mes volets sur jmqtt on bouger sans déclenchement ou sa n'a rien a voir?
Merci

Code : Tout sélectionner

	Erreur sur jMQTT::daemon() : Mosquitto\Exception Object ( [message:protected] => The connection was lost. [string:Exception:private] => [code:protected] => 0 [file:protected] => /var/www/html/plugins/jMQTT/core/class/jMQTT.class.php [line:protected] => 320 [trace:Exception:private] => Array ( [0] => Array ( [file] => /var/www/html/plugins/jMQTT/core/class/jMQTT.class.php [line] => 320 [function] => loopForever [class] => Mosquitto\Client [type] => -> [args] => Array ( ) ) [1] => Array ( [file] => /var/www/html/core/php/jeeCron.php [line] => 73 [function] => daemon [class] => jMQTT [type] => :: [args] => Array ( ) ) ) [previous:Exception:private] => Mosquitto\Exception Object ( [message:protected] => The client is not currently connected. [string:Exception:private] => [code:protected] => 0 [file:protected] => /var/www/html/plugins/jMQTT/core/class/jMQTT.class.php [line:protected] => 340 [trace:Exception:private] => Array ( [0] => Array ( [file] => /var/www/html/plugins/jMQTT/core/class/jMQTT.class.php [line] => 340 [function] => publish [class] => Mosquitto\Client [type] => -> [args] => Array ( [0] => jeedom/status [1] => offline [2] => 1 [3] => 1 ) ) [1] => Array ( [function] => mosquittoDisconnect [class] => jMQTT [type] => :: [args] => Array ( [0] => 1 ) ) [2] => Array ( [file] => /var/www/html/plugins/jMQTT/core/class/jMQTT.class.php [line] => 320 [function] => loopForever [class] => Mosquitto\Client [type] => -> [args] => Array ( ) ) [3] => Array ( [file] => /var/www/html/core/php/jeeCron.php [line] => 73 [function] => daemon [class] => jMQTT [type] => :: [args] => Array ( ) ) ) [previous:Exception:private] => ) )

PS je te met les log mon deamon s'arrete et redémarre

[StephC]

Bonsoir marmoul,
Je n'ai pas vraiment d'idée, désolé.
L'erreur indique que la connexion à Mosquitto est perdue. Dans quelle fichier est logué cette erreur? Sais-tu la synchroniser avec le log jMQTT.txt?
Par hasard, tu n'aurais pas un 2ème jeedom avec lequel tu fais des tests en parallèle?
Stéphane

[StephC]

Bonsoir meute,
J'ai regardé et effectivement MQTT supprime l'extension php mosquitto du serveur Apache à la désinstallation, d'où le problème que tu as eu. Réinstaller les dépendances côté jMQTT étaient la bonne chose à faire.
Stéphane

[meute]

Hello

J'ai un truc bizarre, j'envoie via un scenario 6 commandes l'une dernière l'autre pour faire un polling du style "ebusd/bai/WaterPressure/get".
et il est très rares qu'elles arrivent toutes au broker.
Le client de l'autre côté reçoit des fois les 6 commandes, parfois 2 ou 3 et le plus souvent qu'une seule qui est souvent la dernière mais pas toujours.
En mettant MQTTFX sur le coup il voit la même chose, je peux le constater au niveau des compteurs de réception pour chaque souscription au 6 topics qui ne s'incrémentent pas ensembles, la majorité des commandes n'arrivent pas, ça pool toutes les minutes et il y en a toujours au moins 1 qui passe mais rarement les 6.

Les logs JMQTT ne dise rien de spécial, à chaque coup je vois bien les traces des 6 commandes :

Code : Tout sélectionner

[2018-01-25 02:45:01][INFO] : <- ebusd_bai|ebusd/bai/CirPump/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/bai/CirPump/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié
[2018-01-25 02:45:01][INFO] : <- ebusd_bai|ebusd/bai/WP/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/bai/WP/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié
[2018-01-25 02:45:01][INFO] : <- ebusd_bai|ebusd/bai/PartloadHcKW/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/bai/PartloadHcKW/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié
[2018-01-25 02:45:01][INFO] : <- ebusd_bai|ebusd/bai/WPPWMPower/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/bai/WPPWMPower/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié
[2018-01-25 02:45:01][INFO] : <- ebusd_bai|ebusd/bai/ModulationTempDesired/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/bai/ModulationTempDesired/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié
[2018-01-25 02:45:01][INFO] : <- ebusd_bai|ebusd/bai/WaterPressure/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/bai/WaterPressure/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié
[2018-01-25 02:45:01][INFO] : <- ebusd_f47|ebusd/f47/OpModeEffect/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/f47/OpModeEffect/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié

- J'ai mis le Qos de l'équipement à 1 > Idem
- J'ai mis le Qos de chaque commande aussi à 1 > Idem
- J'ai mis un sleep d'une seconde entre chaque commande > Idem

Et chose étrange dans MQTTFX je peux voir que les commandes sont à première vue transmises depuis JMQTT avec un Qos à 0 malgré tout. LE Qos est quand même implémenté dans le plugin ?

Une piste ?

[marmoul]

Bonsoir marmoul,
Je n'ai pas vraiment d'idée, désolé.
L'erreur indique que la connexion à Mosquitto est perdue. Dans quelle fichier est logué cette erreur? Sais-tu la synchroniser avec le log jMQTT.txt?
Par hasard, tu n'aurais pas un 2ème jeedom avec lequel tu fais des tests en parallèle?
Stéphane

Bonjour Stephane
Je reçois cette erreur de Jeedom dans le centre de notification.
La dernière erreur date du 24/01 à 15h38 je ne sais pas si le log remonte jusqu’à la :/
J’ai bien un autre Jeedom mais pas actif tout est éteint.
L’instal Est propre j’ai refait ma vm mardi matin.

J’ai désactivé le pluging et réactivé et depuis hier j’ai plus cette erreur.
Si sa revient je te fais signe.
Merci

[marmoul]

Hello

J'ai un truc bizarre, j'envoie via un scenario 6 commandes l'une dernière l'autre pour faire un polling du style "ebusd/bai/WaterPressure/get".
et il est très rares qu'elles arrivent toutes au broker.
Le client de l'autre côté reçoit des fois les 6 commandes, parfois 2 ou 3 et le plus souvent qu'une seule qui est souvent la dernière mais pas toujours.
En mettant MQTTFX sur le coup il voit la même chose, je peux le constater au niveau des compteurs de réception pour chaque souscription au 6 topics qui ne s'incrémentent pas ensembles, la majorité des commandes n'arrivent pas, ça pool toutes les minutes et il y en a toujours au moins 1 qui passe mais rarement les 6.

Les logs JMQTT ne dise rien de spécial, à chaque coup je vois bien les traces des 6 commandes :

Code : Tout sélectionner

[2018-01-25 02:45:01][INFO] : <- ebusd_bai|ebusd/bai/CirPump/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/bai/CirPump/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié
[2018-01-25 02:45:01][INFO] : <- ebusd_bai|ebusd/bai/WP/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/bai/WP/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié
[2018-01-25 02:45:01][INFO] : <- ebusd_bai|ebusd/bai/PartloadHcKW/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/bai/PartloadHcKW/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié
[2018-01-25 02:45:01][INFO] : <- ebusd_bai|ebusd/bai/WPPWMPower/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/bai/WPPWMPower/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié
[2018-01-25 02:45:01][INFO] : <- ebusd_bai|ebusd/bai/ModulationTempDesired/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/bai/ModulationTempDesired/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié
[2018-01-25 02:45:01][INFO] : <- ebusd_bai|ebusd/bai/WaterPressure/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/bai/WaterPressure/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié
[2018-01-25 02:45:01][INFO] : <- ebusd_f47|ebusd/f47/OpModeEffect/get (null) (retain=0)
[2018-01-25 02:45:01][DEBUG] : Publication du message ebusd/f47/OpModeEffect/get  (pid=15305)
[2018-01-25 02:45:01][DEBUG] : Message publié

- J'ai mis le Qos de l'équipement à 1 > Idem
- J'ai mis le Qos de chaque commande aussi à 1 > Idem
- J'ai mis un sleep d'une seconde entre chaque commande > Idem

Et chose étrange dans MQTTFX je peux voir que les commandes sont à première vue transmises depuis JMQTT avec un Qos à 0 malgré tout. LE Qos est quand même implémenté dans le plugin ?

Une piste ?

Alors je sais pas si c’est similaire mais j’ai un scénario qui envoie plusieurs commandes à mes modules volet roulant j’ai que la dernière qui passe également
Je précise que au début sa passait bien.
Est ce un bug?

[StephC]

Bonjour,
Pas de piste à priori.
Le Qos est bien implémenté ; dans ton exemple, c'est celui au niveau de chaque commande qui joue. Je n'ai pas fait de test par contre mais je ne vois pas de problème à la lecture du code.
Je testerai, ce soir, si possible (suis bien chargé côté boulot en ce moment...).
Stéphane

[StephC]

Bonsoir,
Je reproduis bien le problème: lorsqu'une série de commande est envoyée de façon trop rapprochée, seule la dernière passe.
J'ai ouvert le problème https://github.com/domotruc/jMQTT/issues/23 pour le corriger.
Stéphane

[marmoul]

Bonsoir,
Je reproduis bien le problème: lorsqu'une série de commande est envoyée de façon trop rapprochée, seule la dernière passe.
J'ai ouvert le problème https://github.com/domotruc/jMQTT/issues/23 pour le corriger.
Stéphane

Ok sa marche.
Tu estime à quand la correction du pluging?
Juste une estimation car c’est vrai que c’est pas hyper waf pour mes volets
On s’habitue vite au automatisme lol
Merci

[StephC]

Bonjour,
C'est corrigé et disponible sur le market: maintenant toutes les commandes passent sur une rafale de commande.
@marmoul: tiens moi au courant si ça arrange tes problèmes.
Stéphane

[marmoul]

Bonjour,
C'est corrigé et disponible sur le market: maintenant toutes les commandes passent sur une rafale de commande.
@marmoul: tiens moi au courant si ça arrange tes problèmes.
Stéphane

Sa marche je fais la maj aujourd’hui.
En tous j’ai plus ces messages de déconnexion depuis le reboot
Merci

[meute]

Merci Stephane, les commandes burst c'est effectivement corrigé, il en rate plus une.

Le Qos vu par MQTTFX par contre est toujours à 0 lui, faudrait que j'aille faire un tour dans les log de Mosquito pour confirmer ou pas.

[meute]

5 petits trucs :

- Élargir la colonne des noms des commandes car dans le cas d'une commande action la case est tellement petite qu'on ne voit que 5 caractères à la fois

- Lorsqu'une info json est parsée, les niveaux supérieurs restent des commandes infos mais les valeurs avant parsing au niveau suivant ne sont plus visibles, seul le dernier niveau de parsing s'update, et les précédents se vident, ça serait possible d'actualiser quand même les niveaux précédents ?

- Lorsqu'on décide de parser une info il faut attendre que le topic soit updaté à nouveau sur le broker pour voir apparaître la ou les nouvelles info résultantes de ce parsing, ça serait pas possible lors du click sur "parsejson" de parser et créer la nouvelle info directement ?

- Pouvoir activer et désactiver la création automatique des commandes sur chaque équipement en plus du global pour qu'une fois q'un équipement est créé avec les commandes qu'on a besoin il ne se modifie plus tout seul si un topic inconnu arrive tout en conservant la création auto des nouveaux équipements et l'ajout de commandes dans les équipement existant pour lesquels le scan est activé.

- Pouvoir activer ou désactiver la création auto d'un nouvel équipement tout en pouvant continuer à ajouter automatiquement les commandes dans les équipements existants.

Rien de bien handicapant à l'usage mais c'est des améliorations qui seraient utiles à mon sens.

[StephC]

Le Qos vu par MQTTFX par contre est toujours à 0 lui, faudrait que j'aille faire un tour dans les log de Mosquito pour confirmer ou pas.

Bonjour,
J'ai regardé la problématique des Qos. Pour Qos 0 et 1, pas de problème ca marche, voici les log Mosquitto:

Qos=0:

Code : Tout sélectionner

1517072127: New client connected from 192.168.1.235 as jeedom/580/c316793f (c1, k60).
1517072127: Sending CONNACK to jeedom/580/c316793f (0, 0)
1517072127: Received PUBLISH from jeedom/580/c316793f (d0, q0, r0, m0, 'hw/temp/set', ... (2 bytes))
1517072127: Received DISCONNECT from jeedom/580/c316793f
1517072127: Client jeedom/580/c316793f disconnected.

Qos=1:

Code : Tout sélectionner

1517072320: New client connected from 192.168.1.235 as jeedom/580/9a00aaa5 (c1, k60).
1517072320: Sending CONNACK to jeedom/580/9a00aaa5 (0, 0)
1517072320: Received PUBLISH from jeedom/580/9a00aaa5 (d0, q1, r0, m1, 'hw/temp/set', ... (2 bytes))
1517072320: Sending PUBACK to jeedom/580/9a00aaa5 (Mid: 1)
1517072320: Received DISCONNECT from jeedom/580/9a00aaa5
1517072320: Client jeedom/580/9a00aaa5 disconnected.

On voit bien le broker qui acquitte la réception de la commande par un PUBACK.

Par contre, avec Qos=2:

Code : Tout sélectionner

1517072652: New client connected from 192.168.1.235 as jeedom/580/699518f0 (c1, k60).
1517072652: Sending CONNACK to jeedom/580/699518f0 (0, 0)
1517072652: Received PUBLISH from jeedom/580/699518f0 (d0, q2, r0, m1, 'hw/temp/set', ... (2 bytes))
1517072652: Sending PUBREC to jeedom/580/699518f0 (Mid: 1)
1517072652: Received DISCONNECT from jeedom/580/699518f0
1517072652: Client jeedom/580/699518f0 disconnected.

La communication s'interrompt après PUBREC, il manque les 2 derniers échanges (PUBREL et PUBCOMP) comme expliqué ici: https://www.hivemq.com/blog/mqtt-essent ... ice-levels.
Un client écoutant le topic ne reçoit pas la commande, j'ai ouvert l'anomalie https://github.com/domotruc/jMQTT/issues/25.

Stéphane

[meute]

Merci pour les tests,

J'ai un autre problème plus embêtant, impossible de mettre du json dans le champ valeur d'une action sur un topic, à la sauvegarde de l’équipement le champ se vide et lorsque j'envoie la commande le json n'est pas là, c'est vide aussi.
Ca expliquerais pourquoi des fois je vois apparaître le json dans le champ valeur des info et que parfois le champ valeur reste vide alors que via le bouton test je retrouve bien la valeur en json.
Si je mets le json entre "" il reste mais évidement ça marche pas vu que c'est transmis comme une chaine ...

Ca m’empêche de transmettre des commandes vers ma chaudière car je suis obligé de le faire en json.

Tu as une idée ?

[StephC]

Effectivement, je reproduis. Suis sûr que ça marchait... je regarde.