Mon problème
Bonjour à tous !
Je suis en train de passer toutes mes automatisations HA sur Node Red. Auparavant j’avais ce chemin : Z2M, HA, Z2M. Maintenant j’ai celui la : Z2M, HA, NR, HA, Z2M. J’ai essayé également après l’installation de la palette Z2M dans Node Red : Z2M, NR, Z2M. Je constate une légère latence de l’ordre de la demi seconde avec Node Red que je n’avais pas avec les automatisations HA.
Cette latence est elle normale ou il y à un réglage pour l’éviter ?
Ma configuration
System Information
| version |
core-2023.8.2 |
| installation_type |
Home Assistant OS |
| dev |
false |
| hassio |
true |
| docker |
true |
| user |
root |
| virtualenv |
false |
| python_version |
3.11.4 |
| os_name |
Linux |
| os_version |
6.1.39 |
| arch |
x86_64 |
| timezone |
Europe/Paris |
| config_dir |
/config |
Home Assistant Community Store
| GitHub API |
ok |
| GitHub Content |
ok |
| GitHub Web |
ok |
| GitHub API Calls Remaining |
5000 |
| Installed Version |
1.32.1 |
| Stage |
running |
| Available Repositories |
1285 |
| Downloaded Repositories |
2 |
Home Assistant Cloud
| logged_in |
true |
| subscription_expiration |
6 juillet 2024 à 02:00 |
| relayer_connected |
true |
| relayer_region |
eu-central-1 |
| remote_enabled |
true |
| remote_connected |
true |
| alexa_enabled |
false |
| google_enabled |
false |
| remote_server |
eu-central-1-3.ui.nabu.casa |
| certificate_status |
ready |
| can_reach_cert_server |
ok |
| can_reach_cloud_auth |
ok |
| can_reach_cloud |
ok |
Home Assistant Supervisor
| host_os |
Home Assistant OS 10.4 |
| update_channel |
stable |
| supervisor_version |
supervisor-2023.09.2 |
| agent_version |
1.5.1 |
| docker_version |
23.0.6 |
| disk_total |
30.8 GB |
| disk_used |
15.7 GB |
| healthy |
true |
| supported |
true |
| board |
ova |
| supervisor_api |
ok |
| version_api |
ok |
| installed_addons |
File editor (5.6.0), Mosquitto broker (6.2.1), Zigbee2MQTT (1.32.1-1), Samba Backup (5.2.0), Node-RED (14.4.5) |
Dashboards
| dashboards |
2 |
| resources |
1 |
| views |
14 |
| mode |
storage |
Recorder
| oldest_recorder_run |
11 septembre 2023 à 15:09 |
| current_recorder_run |
18 septembre 2023 à 23:58 |
| estimated_db_size |
5617.31 MiB |
| database_engine |
sqlite |
| database_version |
3.41.2 |
___
Salut,
il est assez facile de comprendre que plus il y a d’intermédiaire dans la ‹ chaine › plus c’est long à aboutir…
Après j’aurais tendance à dire : si ça marche mieux avec HA, rester avec HA
Salut,
J’avais fait pas mal de tests de comparaison et je n’ai jamais eu différence significative.
Il est possible que la machine sur laquelle ça tourne et ses ressources jouent un rôle là dedans…
1 « J'aime »
Il faut voir l’architecture et les ressources allouée à chaque élément effectivement.
Est ce que tu passes vraiment de Z2M vers HA puis vers NR puis HA puis Z2M !!
l’important sont les liaisons vers le brocker auquel tu vas te connnecter.
La messagerie MQTT est plus que rapide et c’est rarement là que cela freine !
Donc il faut limiter les intermédiaires pour aller au brocker
Apres il faut se poser la question : Pourquoi quand je suis dans NR je passe par HA pour aller sur brocker ? Peut être que depuis NR autant aller directement sur le brocker cela fait un étage de moins. et cela dispose de l’avantage c’est que si HA est coupé cela fonctionne encore mais c’est un autre sujet et débat.
Regarde pour ton cas si tu peux pas faire un chemin plus direct sans passer en permanence par la case départ !
Avec ma conf je remarque pas vraiment de latence enfin rien de pénalisant quand tu descends à la cave par exemple 
C’est ce que je me suis dit aussi, mais c’est tellement plus simple avec le visuel de NR !
HA tourne sur Synology DS220+ sur une VM, aucun conteneurs installé dessus.
J’ai pensé à éviter la case HA en surveillant et publiant directement dans le broker, mais je conserve toujours ce petit lag que je n’ai pas avec HA malheureusement