Je viens solliciter votre aide à cause d’un problème de latence dans le déclenchement de mes scénarios.
J’ai des boutons Xiaomi et j’utilise zigbee2mqtt.
Sur le dashboard de zigbee2mqtt les actions des différents composants zigbee sont quasi instantanées (détection mouvement, bouton, allumage/eteignage ruban led)
Jeedom reçoit assez rapidement l’information, mais tarde à déclencher les scénarios. Ci-dessous une capture où on voit que jeedom à récupérer l’info d’un bouton à 08:50:25 mais le scénario lié s’est déclenché presque 20 secondes plus tard.
Petite précision sur la capture c’est bien l’heure de son déclenchement par l’action sur le bouton Xiaomi. Quand je dis qu’en manuel il se lance tout de suite c’est que j’ai testé pour savoir si un déclenchement manuel faisait monter mes volet roulant en 20 secondes aussi ou pas (et c e n’est pas le cas, c’est quasi instantané)
Petit suggestion, son ton déclencheur si il prend une une ex: bouton 1 click == ‘single’ met la valeur souhaitée directement dans ton déclencheur sans passer par si dans le scénario et a la fin de ton scénario fait un event sur cette valeur pour la vider
event > bouton1 click > valeur > et tu laisse vide
Si vous voulez de l’aide efficace, fournissez toute l’info demandée sinon on perd notre temps. Si vous venez demander de l’aide c’est que vous n’avez pas trouvé seul et dans 99% des cas c’est parce que la personne n’a pas cherché au bon endroit.
On voit bien que le scénario met 12s d’exécution au lieu de 2/3s en manu donc on a bien 10s perdue sur « ce qu’il fait », il est donc intéressant d’avoir cette info.
Ce n’est pas le scénario qui correspond au log ci-dessus dans lequel il y a un bloc SI.
Si vous avez modifié le scénario, donnez les nouveaux logs et pas dans un capture d’écran cette fois (difficile à lire) mais copier/coller le contenu dans un Texte préformaté Comme ceci
saisissez ou collez du code ici
Il faudrait fournir une capture d’écran de la page santé jeedom aussi
Sur les conseils de Maxcrouz, j’ai « déplacé » la condition « SI » qui était dans le scénario directement dans le déclencheur donc en effet le log du tout début ne correspond plus au scénario
[2022-08-06 09:47:53]INFO : Evènement sur la commande [Aucun][zigbee2mqtt][bridge:logging] valeur : {"level":"debug","message":"Received Zigbee message from 'switch_1', type 'attributeReport', cluster 'genOnOff', data '{\"onOff\":0}' from endpoint 1 with groupID 0"}
[2022-08-06 09:47:54]INFO : Evènement sur la commande [Aucun][zigbee2mqtt][bridge:logging] valeur : {"level":"debug","message":"Received Zigbee message from 'switch_1', type 'attributeReport', cluster 'genOnOff', data '{\"onOff\":1}' from endpoint 1 with groupID 0"}
[2022-08-06 09:47:54]INFO : Evènement sur la commande [Aucun][zigbee2mqtt][bridge:logging] valeur : {"level":"info","message":"MQTT publish: topic 'zigbee2mqtt/switch_1', payload '{\"action\":\"single\",\"battery\":100,\"linkquality\":73,\"voltage\":3032}'"}
[2022-08-06 09:47:55]INFO : Evènement sur la commande [Cuisine][switch_1][click] valeur : single
[2022-08-06 09:48:08]INFO : Exécution du scénario [Volets Roulants][Aucun][Ouvre VR Cuisine] déclenché par : [Cuisine][switch_1][click]
[2022-08-06 09:48:08]INFO : Exécution du scénario [Volets Roulants][Aucun][Ferme VR Cuisine] déclenché par : [Cuisine][switch_1][click]
Une machine virtuelle sous Proxmox. La machine est HP ProDesk 400 G1 USFF- Core i3-4160T@3.10GHz - 8Go RAM - 240Go SSD
C’est pas un foudre de guerre mais malgré tout ca marche plutôt bien le seul souci que j’ai c’est la latence dans le déclenchement des scénarios depuis des evenement zigbee2mqtt
j’ai aussi des scénarios qui se déclenche sur du RFLINK et je n’ai pas cette latence
Je réveille ce sujet car, malgré pas mal de tests, j’en arrive à la conclusion que sur une VM sous Proxmox les performances ne sont pas du tout à la hauteur (en tout cas sur mon HP ProDesk 400 G1 USFF- Core i3-4160T@3.10GHz - 8Go RAM - 240Go SSD).
S’en traduit des lenteurs, la plus flagrante pour moi étant l’exécution d’actions des scénarios
Par exemple un appui sur un bouton Zigbee, récupéré par jMqtt pour déclencher le scénario d’ouverture des volets met 3 secondes parfois plus pour se déclencher
Autre exemple, l’allumage de bandeau de led (zigbee) sur détection de présence (zigbee), la c’est carrément 20 secondes, quand par l’interface web de zigbeetomqtt c’est instantané ou quasi
J’ai donc fini par investir dans un NUC i3 7eme génération et c’est le jour et la nuit :
La charge est bien en dessous de 1 (0.19 - 0.12 - 0.1)
Le benchmark ressemble à
Nom
Temps
cache_write_5000
0.21669507026672
cache_read_5000
0.054435014724731
database_write_delete_1000
0.24995589256287
database_update_1000
0.13020777702332
database_replace_1000
0.1251380443573
database_read_50000
0.014703035354614
subprocess_200
0.35522699356079
total
1.1463618278503
quand sous la VM le total atteint entre 38 et 54
J’ai gardé la VM sous le coude pour d’autre test mais meme si le NUC est overkill je suis content de retrouver un Jeedom fonctionnel.
Je suis un assez ancien utilisateur de Jeedom, d’abord sur des raspberry 3 et 4, avec carte SD puis SSD, jusqu’à présent j’avais principalement du zwave et rflink, c’est le zigbee et peut etre le fait d’avoir une plus grande maison car j’ai déménagé qui m’a mis le dos au mur au niveau des performances
Le dernier test que j’ai fait c’est un VM sous Proxmox mais en partant de l’ISO Jeedom pas de 0 sur Buster et le résultat du benchmark alors que je n’ai pas encore restauré la sauvegarde est
