Plugin jMQTT

[meute]

C'est pas le fix #14 qui provoquerait ce problème ?

[StephC]

Je ne pense pas, la fonction execute qui est modifiée sur le fix #14 n'est pas appelée sur sauvegarde d'un équipement, je viens de vérifier.
Le problème existe aussi sur le plugin MQTT. Du coup, je ne suis pas si sûr que ça ait déjà marché.
En utilisant des ' au lieu de ", ça passe, mais la norme JSON prévoit uniquement les ". Donc palliatif pas terrible.
Je continuerai de regarder demain matin.

[meute]

Avec ' ça passe en effet mais de l'autre côté ce n'est pas bien interprété.

[meute]

J'ai regardé un peu le code mais j'y connais pas grand chose en plugin jeedom mais ça semble être plus un problème du core qui a du mal à avaler du json dans le "request" non ?

J'ai aussi essayé de mettre le json dans une variable depuis un scenario et ensuite d'utiliser cette variable comme valeur dans JMQTT mais c'est pas mieux, du côté scenario à la sauvegarde le json est remplacé par "Array" et JMQTT envoie ensuite une chaine vide à partir de cette variable.

Ce qui est étrange c'est que quand j'ouvre la page de config des commandes les champs valeurs des infos sont bien remplis avec les json dernièrement reçus et dès qu'on sauvegarde tout disparaît de l'affichage malgré que les valeurs existent toujours vu qu'elles sont visibles par le bouton test.

[meute]

T’embête pas trop je suis tombé la dessus : viewtopic.php?f=96&t=5764&hilit=json&start=500#p555348
Par contre si je mets "\{" le broker reçoit aussi "\{" ... contrairement à ce qui semble être décrit dans ce post donc peut-être que lunarok a intégré un truc pour remplacer les \{ et \} par { et } avant d'envoyer à mosquitto ... je sais pas.

Toujours est-il que mon client MQTT (ebusd) de l'autre côté accepte finalement aussi les valeurs en plain text malgré qu'il est configurer pour transmettre ses valeurs à lui en json, je ne suis donc plus obligé d'utiliser du json sur les actions, je peux mettre les valeurs en directe.

Donc pour recevoir c'est du json ce qui me permet de parser facilement les retours contenants des valeurs multiples par contre ça rend plus lourd ceux à valeur unique car il faut du coup parser "pour rien" juste pour extraire la valeur unique.
Et pour envoyer je peux le faire sans json ...donc tout va bien pour moi.

[StephC]

Bonjour meute,
merci pour toutes tes recherches.
Effectivement, dans le code de lunarok, les \ sont supprimés avant envoi à Mosquitto. Puisque tu es moins pressé, je vais prendre le temps de comprendre avant d'implanter une correction.
Je serais intéressé pour avoir ton flux MQTT pour mieux comprendre tes demandes d'améliorations auxquelles je répondrai, par exemple via:

Code : Tout sélectionner

mosquitto_sub -t "#" -v| xargs -d$'\n' -L1 bash -c 'date "+%Y-%m-%d %T.%3N $0"')

Stéphane

[meute]

Je serais intéressé pour avoir ton flux MQTT pour mieux comprendre tes demandes d'améliorations auxquelles je répondrai, par exemple via:

Tiens, dis moi si ça ta suffit, ce sont tous les échanges par pooling et broadcast de ma chaudière sur quelques minutes :

Code : Tout sélectionner

2018-01-29 03:24:06.430 jeedom/test/temp 50
2018-01-29 03:24:06.431 ebusd/global/version "ebusd 3.1.b0e20b7"
2018-01-29 03:24:06.432 ebusd/global/running true
2018-01-29 03:24:06.433 ebusd/global/updatecheck "revision v3.1-1-g60a18d1 available, broadcast.csv: different version available, memory.csv: different version available, vaillant/08.bai.csv: different version available, vaillant/15.f47.csv: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/general.csv: "
2018-01-29 03:24:06.434 JeedomJ/status online
2018-01-29 03:24:20.980 ebusd/global/uptime 94632
2018-01-29 03:24:24.987 ebusd/broadcast/vdatetime {
2018-01-29 03:24:24.989      "time": {"value": "03:24:22"},
2018-01-29 03:24:24.991      "date": {"value": "29.01.2018"}}
2018-01-29 03:24:36.998 ebusd/global/uptime 94648
2018-01-29 03:24:52.013 ebusd/global/uptime 94664
2018-01-29 03:25:01.362 ebusd/bai/WaterPressure/get (null)
2018-01-29 03:25:01.366 ebusd/f47/Hc1OPMode/get (null)
2018-01-29 03:25:01.368 ebusd/f47/Hc1DayTemp/get (null)
2018-01-29 03:25:01.371 ebusd/f47/Hc1NightTemp/get (null)
2018-01-29 03:25:01.374 ebusd/f47/HwcTempDesired/get (null)
2018-01-29 03:25:01.377 ebusd/f47/ActualRoomTempDesiredHc1/get (null)
2018-01-29 03:25:01.381 ebusd/bai/WP/get (null)
2018-01-29 03:25:01.382 ebusd/bai/WPPWMPower/get (null)
2018-01-29 03:25:01.384 ebusd/bai/CirPump/get (null)
2018-01-29 03:25:01.385 ebusd/bai/ModulationTempDesired/get (null)
2018-01-29 03:25:01.386 ebusd/bai/PositionValveSet/get (null)
2018-01-29 03:25:02.498 ebusd/bai/WaterPressure {
2018-01-29 03:25:02.500      "press": {"value": 1.869},
2018-01-29 03:25:02.501      "sensor": {"value": "ok"}}
2018-01-29 03:25:02.502 ebusd/f47/Hc1OPMode {
2018-01-29 03:25:02.503      "0": {"name": "", "value": "on"}}
2018-01-29 03:25:02.657 ebusd/f47/Hc1DayTemp {
2018-01-29 03:25:02.659      "temp1": {"value": 24.0}}
2018-01-29 03:25:02.817 ebusd/f47/Hc1NightTemp {
2018-01-29 03:25:02.818      "temp1": {"value": 21.0}}
2018-01-29 03:25:02.977 ebusd/f47/HwcTempDesired {
2018-01-29 03:25:02.978      "temp1": {"value": 55.0}}
2018-01-29 03:25:03.143 ebusd/f47/ActualRoomTempDesiredHc1 {
2018-01-29 03:25:03.144      "temp": {"value": 24.00}}
2018-01-29 03:25:03.307 ebusd/bai/WP {
2018-01-29 03:25:03.308      "onoff": {"value": "off"}}
2018-01-29 03:25:03.471 ebusd/bai/WPPWMPower {
2018-01-29 03:25:03.472      "percent0": {"value": 0}}
2018-01-29 03:25:03.642 ebusd/bai/CirPump {
2018-01-29 03:25:03.643      "onoff": {"value": "on"}}
2018-01-29 03:25:03.810 ebusd/bai/ModulationTempDesired {
2018-01-29 03:25:03.811      "0": {"name": "", "value": 17.0}}
2018-01-29 03:25:03.977 ebusd/bai/PositionValveSet {
2018-01-29 03:25:03.978      "0": {"name": "", "value": 0}}
2018-01-29 03:25:04.978 ebusd/bai/WaterPressure {
2018-01-29 03:25:04.979      "press": {"value": 1.869},
2018-01-29 03:25:04.980      "sensor": {"value": "ok"}}
2018-01-29 03:25:08.982 ebusd/global/uptime 94680
2018-01-29 03:25:14.989 ebusd/bai/Status01 {
2018-01-29 03:25:14.992      "0": {"name": "temp1", "value": 42.5},
2018-01-29 03:25:14.993      "1": {"name": "temp1", "value": 42.0},
2018-01-29 03:25:14.995      "2": {"name": "temp2", "value": null},
2018-01-29 03:25:14.997      "3": {"name": "temp1", "value": null},
2018-01-29 03:25:14.999      "4": {"name": "temp1", "value": 50.5},
2018-01-29 03:25:15.001      "5": {"name": "burnerstate", "value": "off"}}
2018-01-29 03:25:25.000 ebusd/global/uptime 94696
2018-01-29 03:25:25.001 ebusd/broadcast/vdatetime {
2018-01-29 03:25:25.003      "time": {"value": "03:25:22"},
2018-01-29 03:25:25.005      "date": {"value": "29.01.2018"}}
2018-01-29 03:25:40.015 ebusd/global/uptime 94712
2018-01-29 03:25:56.033 ebusd/global/uptime 94728
2018-01-29 03:26:01.930 ebusd/bai/WP/get (null)
2018-01-29 03:26:01.931 ebusd/bai/CirPump/get (null)
2018-01-29 03:26:01.933 ebusd/bai/WPPWMPower/get (null)
2018-01-29 03:26:01.934 ebusd/bai/ModulationTempDesired/get (null)
2018-01-29 03:26:01.935 ebusd/bai/PositionValveSet/get (null)
2018-01-29 03:26:02.242 ebusd/bai/WP {
2018-01-29 03:26:02.243      "onoff": {"value": "off"}}
2018-01-29 03:26:02.244 ebusd/bai/CirPump {
2018-01-29 03:26:02.246      "onoff": {"value": "on"}}
2018-01-29 03:26:02.406 ebusd/bai/WPPWMPower {
2018-01-29 03:26:02.408      "percent0": {"value": 0}}
2018-01-29 03:26:02.582 ebusd/bai/ModulationTempDesired {
2018-01-29 03:26:02.583      "0": {"name": "", "value": 17.0}}
2018-01-29 03:26:02.745 ebusd/bai/PositionValveSet {
2018-01-29 03:26:02.746      "0": {"name": "", "value": 0}}
2018-01-29 03:26:12.755 ebusd/global/uptime 94744
2018-01-29 03:26:24.768 ebusd/broadcast/vdatetime {
2018-01-29 03:26:24.772      "time": {"value": "03:26:22"},
2018-01-29 03:26:24.773      "date": {"value": "29.01.2018"}}
2018-01-29 03:26:24.774 ebusd/bai/Status01 {
2018-01-29 03:26:24.775      "0": {"name": "temp1", "value": 42.0},
2018-01-29 03:26:24.776      "1": {"name": "temp1", "value": 42.0},
2018-01-29 03:26:24.777      "2": {"name": "temp2", "value": null},
2018-01-29 03:26:24.778      "3": {"name": "temp1", "value": null},
2018-01-29 03:26:24.779      "4": {"name": "temp1", "value": 50.5},
2018-01-29 03:26:24.780      "5": {"name": "burnerstate", "value": "off"}}
2018-01-29 03:26:28.771 ebusd/global/uptime 94760
2018-01-29 03:26:44.790 ebusd/global/uptime 94776
2018-01-29 03:27:00.803 ebusd/global/uptime 94792
2018-01-29 03:27:02.470 ebusd/bai/CirPump/get (null)
2018-01-29 03:27:02.477 ebusd/bai/WP/get (null)
2018-01-29 03:27:02.492 ebusd/bai/WPPWMPower/get (null)
2018-01-29 03:27:02.494 ebusd/bai/ModulationTempDesired/get (null)
2018-01-29 03:27:02.496 ebusd/bai/PositionValveSet/get (null)
2018-01-29 03:27:02.759 ebusd/bai/CirPump {
2018-01-29 03:27:02.760      "onoff": {"value": "on"}}
2018-01-29 03:27:02.761 ebusd/bai/WP {
2018-01-29 03:27:02.762      "onoff": {"value": "off"}}
2018-01-29 03:27:02.924 ebusd/bai/WPPWMPower {
2018-01-29 03:27:02.925      "percent0": {"value": 0}}
2018-01-29 03:27:03.094 ebusd/bai/ModulationTempDesired {
2018-01-29 03:27:03.095      "0": {"name": "", "value": 17.0}}
2018-01-29 03:27:03.258 ebusd/bai/PositionValveSet {
2018-01-29 03:27:03.259      "0": {"name": "", "value": 0}}
2018-01-29 03:27:16.273 ebusd/global/uptime 94808
2018-01-29 03:27:24.280 ebusd/broadcast/vdatetime {
2018-01-29 03:27:24.282      "time": {"value": "03:27:21"},
2018-01-29 03:27:24.284      "date": {"value": "29.01.2018"}}
2018-01-29 03:27:32.290 ebusd/global/uptime 94824

Par contre maintenant le Daemon JMQTT est devenu le plus gros consommateur de CPU de ma VM, il apparaît toutes les 2 à 3 secondes en tête du TOP avec 7 à 14% et quelques fois des pointes à plus de 90%, mon graphique de charge sous ESXI oscille maintenant entre 5 et 15 %, avant ça dépassait pas les 7%.

C'est le "21537" :

Code : Tout sélectionner

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
21537 www-data  20   0  377840  42644  33116 S  12,0  0,5   2:33.97 php
  919 mysql     20   0  797096 225768  17320 S   3,7  2,8  84:05.24 mysqld
31235 www-data  20   0  381928  45852  33852 S   2,0  0,6   3:33.17 php
24703 www-data  39  19       0      0      0 Z   1,3  0,0   0:00.04 php
 1662 www-data  20   0  293820  32132   8616 S   0,7  0,4  17:07.56 python
 1712 www-data  20   0  520172  33232   8516 S   0,7  0,4  30:22.32 python
26542 www-data  20   0  438984  27124  17988 S   0,7  0,3   0:07.96 apache2
27102 www-data  20   0  439040  28392  19244 S   0,7  0,3   0:18.98 apache2
15266 root      20   0   44940   3824   3140 R   0,3  0,0   0:00.56 top
24227 root      20   0  416672   7036   5336 S   0,3  0,1   3:00.05 ebusd
28406 www-data  20   0  512796  29264  20048 S   0,3  0,4   0:12.75 apache2
31632 www-data  20   0  513508  28424  18180 S   0,3  0,3   0:05.85 apache2

J'ai désactivé la détection auto des topics pour voir car je me dis que ça doit consommer pas mal et en plus une fois qu'on a fini sa config on en a plus besoin tout le temps mais ça change rien.
Je sais pas si c'est une impression mais je me demande si ça n'a pas un impact aussi sur le process mysqld, je ne me souviens pas l'avoir vu précédemment aussi souvent dans le haut ... il y a beaucoup de requêtes faites vers la DB ?

Tu penses qu'il y aurait des pistes exploitables pour alléger le process ?
En plus je pool que toutes les minutes et il n'y a pas beaucoup de broadcast et sa charge CPU varie plus vite que la fréquence des échanges donc je me dis qu'il doit fair des trucs en boucle non ?

[mycev]

Bonjour,
Merci Stéphane pour la reprise du plugin et pour le travail réalisé.
Je ne suis pas à l'aise non plus avec l'absence de compatibilité ascendante...

Cela fonctionne correctement pour moi et j'ai juste une sujétion : ajouter dans l'onglet "Equipement" une case à cocher pour autoriser ou pas la création automatique des commandes (à l'instar de la découverte Automatique des topics dans la configuration du plugin).

Cela permettrait d'éviter de créer trop de commandes inutiles

[StephC]

Bonsoir meute,

désolé de ne pas avoir eu le temps de te répondre avant, suis pas mal sous la vague du boulot en ce moment...
Quelques éléments toutefois:

• Requêtes BD:
  • A chaque message: recherche des équipements jMQTT ayant souscrits à ce message, puis recherche de la commande associée et sauvegarde de la nouvelle valeur (plusieurs commandes dans le cas d'une payload JSON).
  • Je ne sais pas dire si c'est beaucoup, je n'ai pas vraiment de point de comparaisons.

• Côté plugin, je ne vois pas vraiment de pistes sauf dans le cas de payload JSON où je pourrais décoder directement jusqu'au niveau le plus bas et ne plus traiter les niveaux intermédiaires. Je ne sais pas dire si le gain est suffisant v.s. l'inconvénient que peut générer un changement de comportement du plugin.

• Je vois que tes messages arrivent en rafale (par exemple entre 03:26:01.930 et 03:26:02.746). Tu ne pourrais pas introduire un délai entre chaque message pour lisser la charge CPU?

Stéphane

[StephC]

Bonsoir mycev,
Merci
Il me semble que ça rejoint les 2 derniers points du message suivant de meute (si j'ai bien compris, il précisera au besoin) : viewtopic.php?f=96&t=32675&start=40#p578351.
Pourrais tu créer une "issue" sous GitHub pour tracer cette demande d'évolution et avoir un fil de discussion dédiée?
Stéphane

[meute]

Bonsoir meute,

désolé de ne pas avoir eu le temps de te répondre avant, suis pas mal sous la vague du boulot en ce moment...
Quelques éléments toutefois:

• Requêtes BD:
  • A chaque message: recherche des équipements jMQTT ayant souscrits à ce message, puis recherche de la commande associée et sauvegarde de la nouvelle valeur (plusieurs commandes dans le cas d'une payload JSON).
  • Je ne sais pas dire si c'est beaucoup, je n'ai pas vraiment de point de comparaisons.

• Côté plugin, je ne vois pas vraiment de pistes sauf dans le cas de payload JSON où je pourrais décoder directement jusqu'au niveau le plus bas et ne plus traiter les niveaux intermédiaires. Je ne sais pas dire si le gain est suffisant v.s. l'inconvénient que peut générer un changement de comportement du plugin.

• Je vois que tes messages arrivent en rafale (par exemple entre 03:26:01.930 et 03:26:02.746). Tu ne pourrais pas introduire un délai entre chaque message pour lisser la charge CPU?

Stéphane

Pas de soucis, ça tourne y a pas urgence.

Les raffales sont des commandes donc logiquement elles font appel a une quantité de requêtes très limitée sur la BD car pas de parsing json à faire, il faut juste transmettre un topic et sa valeur et dans le cas de mon pooling c'est une valeur vide.

Il doit vraiment y avoir un truc qui pompe anormalement car chaque minute et synchro avec mon pooling que je dois faire vers ma chaudière, la charge cpu gonfle.

Capture.PNG (60.06 Kio) Consulté 1575 fois

Sans le MQTT ma charge VM c'est une légère ondulation de moins d'1% d’amplitude autour de 5% et pourtant y en a des trucs qui tournent pendant ce temps, scenarios, des dizaines de virtuels qui regroupent des multitudes d’équipements avec des calculs et qui sont constamment rafraîchis, des dizaines d'équipements,plusieurs plugins pour divers protocoles qui communiquent constamment (Z-Wave, Hue, RFxcom, jeedouino, harmony, MiHome, Modbus ...)
Et là avec le MQTT chaque minute ça tape entre 15 et 20% en même temps que mon pooling. J'ai vérifié et ebusd passe inaperçu niveau charge et Mosquito également donc c'est bien le plugin MQTT qui provoque ça.

Comme tu peux le voir sur le graph vers la moitié les pics on baissés un peu car j'ai désactivé quelques équipements MQTT que j'avais utilisé pour des tests et qui souscrivaient de toute façon à des topic déjà souscrits par ceux de prod. Donc ça a allégé un peu la charge.

Mais bon ,ca me parait beaucoup pour simplement envoyer 5 ou 6 topics sans valeur pour faire mon pooling et recevoir donc aussi 5 ou 6 topics à parser sur maxi 3 niveaux et ce 1 fois toutes les minutes.

Je ne m'y connais pas encore assez dans l'ecosystème entre Jeedom et ses plugins pour analyser vraiment ce qu'il peut se passer, mais je vais chercher un peu quand-même dans le code, ça me permettra d'en apprendre un peu plus.

PS : Ma machine virtuelle tourne dans une VM ESXI sur un NUC I5, la machine virtuelle a 4 vcores et 8Go alloués ce qui fait qu'elle en a largement sous le pied. J'ai un benchmark jeedom à 0.70 donc cette augmentation de charge ponctuelle n'est pas anodine pour finalement si peu, c'est des pointes qui prennent 2 fois plus de charge que tout le reste pour en faire 100 fois moins.

[StephC]

Bonjour meute,
Je viens de faire un test avec un traffic continu de 10 messages par seconde: le démon jMQTT prend 7 à 8% de CPU. Et bien le double avec 20 msg/s.
Tes chiffres paraissent effectivement haut, je vais essayer de reproduire ton traffic pool/broadcast en le modélisant sur le simulateur MQTT que j'utilise pour valider le plugin.
Stéphane

[meute]

Hello,

Ne pourrais-tu pas mettre en cache mémoire dans un array la liste des topics avec leur Id jeedom et le param de parsing pour éviter de devoir scruter à chaque fois tous les eqLogic JMQTT pour retrouver a qui s'adresse chaque Topic reçu ?

Car le problème c'est qu'on a beau recevoir un seul message concernant 1 seul Topic il y a malgré tout une lecture "foreach" sur toutes les commandes de tous les équipements JMQTT qui existent pour retrouver toutes celles qui le concernent à chaque fois. Donc si on reçoit un message et qu'on a 5 équipements comprenant chacun 20 commandes ça fait mini 100 accès à la base sans compter les suivants pour le parsing et si on reçoit 5 messages à la suite l'un de l'autre c'est mini 500 accès pour juste 5 message reçus.

Je pense que le problème est là, il faudrait mettre en cache et rafraichir ce cache au démarrage du daemon et lors de l'ajout ou la suppression de commandes ou d’équipements JMQTT, le reste du temps pas besoin d'interroger la DB pour savoir quoi faire avec un Topic à la réception, l'interrogation du cache suffira à traiter le topic, le seul accès qu'il y aura c'est la ou les écritures de la valeur reçue dans les eqLogic qui lui correspondent.

Donc la charge est surtout due au nombre de commandes qui existent, car même en ne recevant qu'un message si il existe 500 commandes JMQTT c'est là que la charge apparaît.
Pour simuler il faut que tu crées un ou plusieurs équipements avec beaucoup de commandes infos dans chaque et là tu verras apparaître la charge même avec un seul message Mosquito reçu.
Le problème de charge n'est pas vraiment du à la quantité et la fréquence de message reçus, évidement au plus on en reçoit au plus la charge est impactée car ca ne fait que multiplier le problème qui existe déjà sur une seul message.

Si tu avais la possibilité de faire une requête sur la DB avec le topic comme critère ça serait différent, l'utilisation d'un cache serait utile quand même mais dans une moindre mesure.

[mycev]

Bonsoir mycev,
Merci
Il me semble que ça rejoint les 2 derniers points du message suivant de meute (si j'ai bien compris, il précisera au besoin) : viewtopic.php?f=96&t=32675&start=40#p578351.
Pourrais tu créer une "issue" sous GitHub pour tracer cette demande d'évolution et avoir un fil de discussion dédiée?
Stéphane

Bonsoir,
Ca y est, une issue est créée...

[StephC]

Bonsoir,
@mycev: parfait, la discussion continue sur GitHub

@meute, j'ai ouvert:

• une issue relative à la charge CPU et reporté nos premiers échanges, ça permettra de tout avoir sur le même fil (https://github.com/domotruc/jMQTT/issues/27).

• une issue relative au problème des comnmande action avec payload JSON https://github.com/domotruc/jMQTT/issues/28

Stéphane

[meute]

Merci, je te filerais bien un coup de main mais je ne maîtrise pas encore suffisamment ces languages pour ça.
Pour le cache j'ai son analyse dans la tête et je pourrais l'implémenter sur d'autres languages que j'utilise couramment mais pas encore dans ceux utilisés dans l’écosystème d'un plugin jeedom, j'ai trop de lacunes, surtout en PHP et Ajax, et en CSS aussi.
J'arrive à lire et comprendre le code dans les grandes lignes, a suivre une partie des interactions entre les différentes classe mais il y a encore des détails qui m'échappes, surtout car je ne comprend pas encore toutes les syntaxes et qu'il faut aussi fouiller un peu le Core jeedom pour s'y retrouver.

Faut que je m'y mette quand j'aurais un peu plus de temps.

[StephC]

Bonjour,
J'attire votre attention sur un problème gênant relatif à l'utilisation de commandes action jMQTT dans vos scénarios: les commandes ne sont pas envoyées au fil de l'au mais en rafale à la fin de l’exécution du scénario, voir https://github.com/domotruc/jMQTT/issues/30.
Je vais essayé de corriger le problème dans les plus brefs délais.
Stéphane

[StephC]

Bonjour,
Nouvelle mise à jour disponible ce jour qui corrige trois problèmes, voir change log https://github.com/domotruc/jMQTT/blob/ ... g.asciidoc.
Stéphane

[meute]

Hello,

Mise à jour faite, ça tourne toujours.

Merci,

[StephC]

Bonsoir,
Nouvelle version disponible demain matin à l'aube, ajoutant la possibilité de désactiver la création automatique de commandes information par équipement. Change log: https://github.com/domotruc/jMQTT/blob/ ... g.asciidoc.
Stéphane