Bonjour a tous,
En pleine interrogation entre Jeedom et HA, j’ai une Luna et HA sur une VMs dans ma freebox.
Mes équipements Zigbee sont a travers une clé SLZB-06Mg24.
J’ai fait le pont sous HA pour accéder au JeeZigbeeMqtt herbégé sous Jeedom, ainsi j’ai fait des scénario sous HA équivalent a Jeedom pour voir les différences mais force de constater une différence nette de temps de réaction a iso scénario assez basique de détecter un mouvement et allumer une lumière.
Je suis d’autant surpris que les informations Zigbee passent par Jeedom.
Auriez vous constaté également une différence de réactivité entre Jeedom et HA ?
Coche déjà synchrone dans tes scénarios, ça augmente sensiblement le temps de réponse. A ne pas faire pour les scénarios trops complexes, mais idéal sur un scénario type détecteur/actionneur
Norbert
Bonjour,
Ça le diminue plutôt… non ? 
Au profit de quel système ? HA ou Jeedom ?
HA plus rapide
Du coup pour ceux qui ont essayés les 2 systèmes et surement largement plus expert que moi, avez vous fait ce constat ?
1 « J'aime »
Ah oui ! !! !
du mal a vous suivre 
@ngrataloup a raison, le mode synchrone permet de gagner du temps de latence.
La doc dit :
Mode synchrone : Lance le scénario dans le thread courant au lieu d’un thread dédié. Permet d’augmenter la vitesse de lancement du scénario, mais peut rendre le système instable. Attention a ne surtout pas mettre de scénario complexe ou avec des pauses (sleep) ou wait en synchrone, cela engendre un comportement instable de jeedom et ne pourra être couvert par le support.
Donc a utiliser avec précaution, mais globalement ça fonctionne plutôt bien (ou en tout cas c’est l’impression que j’ai avec mes scénarios des gestion des luminaires associés aux capteurs de présence/mouvement…).
Après je ne peux pas aller plus loin et comparer objectivement la réactivité entre HA et Jeedom sur la même installation, n’utilisant pas HA… (mais je vois très bien le principe utilisé du pont HA > Jeedom qui utilise le même matériel et reçoit les mêmes infos au même moment).
1 « J'aime »
Pour avoir les deux en production sur la même machine virtuelle (via Docker), je confirme que les remontées d’infos sont (nettement) plus rapides sous HA, y compris pour l’affichage des états sur l’interface graphique : j’ai des appareils - gérés par un démon indépendant - qui remontent sur les deux (via l’intégration native MQTT sous HA et via jMQTT sous Jeedom), et si le changement d’état est instantané sous HA, je constate un délai d’environ 1 seconde sous Jeedom (en version 4.5 alpha depuis plusieurs mois).
pour le mode synchrone, ça aide à bien diminuer la latence pour les scénarios.
Après, à voir si c’est rédhibitoire pour ton usage ou non 
Bonjour,
Heu si je prends un exemple dans mes logs :
[2025-09-06 21:01:49][INFO] : Evènement sur la commande [Chambre][Sensor][Présence] valeur : 1
[2025-09-06 21:01:50][INFO] : Exécution du scénario [Eclairage][Chambre][GestionEclairage] déclenché par : [Chambre][Sensor][Présence]
[2025-09-06 21:01:50][INFO] : Exécution du scénario [Eclairage][Salle de bains][GestionEclairage] déclenché par : [Chambre][Sensor][Présence]
[2025-09-06 21:01:50][INFO] : Exécution de la commande [Chambre][Plafonnier Chambre][On] avec les paramètres {"background":"0"}
Il faut donc 1s (de 21:01:49 à 21:01:50) pour qu’entre la détection de mouvement, le scénario de gestion de l’éclairage se lance et allume la lumière.
Franchement si vous trouvez qu’une seconde c’est trop long, faites du temps réel pas de la domotique
Peut être que HA est plus rapide je n’en sais rien mais bon franchement la est-ce vraiment un critère à prendre en compte pas sur enfin ce n’est que mon avis.
3 « J'aime »
Quand je suis passé sous HA, je me souviens aussi de l’avoir trouvé plus réactif. C’est peut être subjectif, j’ai jamais cherché à mesurer le temps de réponse, et celui de Jeedom ne ma jamais paru trop long.
Cependant, j’ai l’impression que HA ne vérifie pas la bonne exécution de la commande, alors que Jeedom si (ou je me trompe)
J’ai dans la cuisine une ampoule RGB en wifi qui m’indique la couleur Tempo du jour. Vu son emplacement elle est un peu juste en réception wifi.
Sous Jeedom je me souviens que j’avais de temps en temps un avertissement qui me disait que la commande n’était pas passée (timeout ou 3 [?] essais consécutifs sans succès) signe qu’il fallait « rebooter » l’ampoule pour qu’elle retrouve le wifi, mais en dehors de ces cas, elle réagissait toujours (plus ou moins vite).
Sous HA elle s’allume plus vite (enfin j’ai l’impression) mais il y a plus régulièrement des ratés (ne s’allume pas / ne s’éteint pas quand il faudrait et il faut alors « répéter » l’action qui provoque la commande de l’ampoule) et quand elle plante pour de bon rien ne l’indique.
J’ai pas creusé plus que ça, vu que c’est pas vital et que la raison des ratés est connue (mauvaise réception du wifi).
Bonjour,
On est dans le subjectif.
Il faudrait du factuel, peux tu montrer les logs dans les 2 cas?
Bonjour,
La tolérance de la maille de la seconde sur les logs est probablement trompeuse, dans ce cas, ça pourrait aller entre 1/10s (réactif) de seconde á presque 2 secondes (moins réactif)
Bonjour,
Les LOGs indique un temps de traitement dans la seconde coté Jeedom et HA.
Cependant, pour faire mon test, j’ai créer le même scenario pour allumer une lumière sur mouvement, sauf que HA a une commande en %luminosité différente que Jeedom. Ainsi, je constate que la lumière s’allume systématiquement au % de HA avant que Jeedom la pilote. Certes ce temps de latence est réduit mais toujours bien présent avec le mode Synchrone sous Jeedom
Bonjour,
Tu peux augmenter la vitesse en zigbee en changeant dans la configuration du plugin (mettre 0 au lieu de 0.3). Mais attention cela a un impact sur la charge jeedom donc a vos risques et perils.
Bonjour
Ok merci pour l’information, ou ce situe ce paramètre stp ?
ok merci, je cherchais dans Z2M 
J’ai mis en synchro mes scénarios et scindé en 2 pour allumer/éteindre de manière séparée.
J’ai une clé : SMLIGHT SLZB 06Mg24, mon réseau est stable sans perte d’équipement, ni de commande aléatoire
J’ai changé également le Cycle sous Mqq manager a 0sec
… j’ai toujours une latence importante sur les retours capteurs pour allumer alors que la commande direct est instantanée
Auriez vous d’autres idées ?
Je ne comprends pas ce que ça veut dire.
je me suis mal esprimé, le temps de latence entre le moment ou je suis dans le champ du capteur et que la lumière s’allume, alors que j’ai basiquement, scénario, détection == 1, allumer