J’ai vu des topics similaire cependant je n’ai pas réussi à trouver la solution à la fin de la lecture.
Le problème que je constate : Il y a un décalage horaire entre Jeedom et deconz faisant que mes capteurs ne fonctionnent pas.
Details : Jeedom v4.0.62 + deconz dans un container (2.09.00 / 23/12/2020 + Firmware : 26580700 )
Pour mes tests j’utilise un capteur d’inondation aqara.
Sur deconz : RAS ; dès qu’il y a de l’eau le capteur change de statut, idem quand plus d’eau.
Sur Jeedom ; L’objet ne se met pas à jour, il reste encore et toujours dans le meme statut ( qui était soit eau détecté soit pas d’eau) mais ne se met pas à jour.
Pourtant ! je vois bien Jeedom et deconz se parler comme il faut, en allant dans le device (aqara inondation sensor) et en cliquant sur configuration et tab informations brutes :
« lastupdated »: « 2021-01-12T16:06:15.795 »,
« lowbattery »: false,
« tampered »: false,
« water »: false
Le statut water se met bien à jour comme il faut en même temps que deconz. Donc tout le monde se parle bien comme il faut.
Et là le problème saute aux yeux : « lastupdated »: « 2021-01-12T16:06:15.795 »,
Il y a encore et toujours une heure de décalage horaire pourtant :
mon linux portant jeedom est sur la bonne timezone et à l’heure
L’interface de Jeedom est bien elle aussi sur Europe/Paris et à l’heure
Sur la page web de deconz je suis bien sur Europe/Paris et l’heure affichée et à l’heure (ie ; même que jeedom et les serveurs linux)
Dans le conteneur deconz je suis en timezone UTC (qui ne change jamais) :
root@srvint:~# docker exec -it deconz bash
root@srvint:/# cat /etc/timezone
Etc/UTC
Voyez-vous comment résoudre ce problème de décalage horaire alors que tout le monde est sur la bonne timezone ? Sauf le conteneur mais en lisant le readme j’ai l’impression que c’est déjà ok (et la commande date retourne l’heure correcte)
Merci à vous
Edit ; je viens de faire un upgrade firmware dans la dernière version au cas où (26680700)
L’ensemble des données gérées par deconz se fait en référentiel UTM (ce qui est une bonne chose).
Donc les infos que tu lis dans infos brutes sont bien exprimées dans ce référentiel.
Il appartient aux applications de haut niveau de présenter à chaque utilisateur (donc selon sa localisation) les infos date/heure dans son fuseau horaire. C’est ce que fait Jeedom en allant puiser les infos de localisation dans sa configuration…
De quelle niveau de Linux parles tu ? Le noyaux ou une couche de présentation. Le noyau doit rester en UTC. Les couches de présentations doivent s’aligner sur la localisation. Donc la notion de bonne timezone et heure est à géométrie variable sur une machine. Pour régler le groupe date/heure il faut bien comprendre quel référentiel est utilisé par chaque niveau (et je ne t’ai pas parlé de la RTC de ta machine qui a tout intérêt à rester en UTC avec Linux comme avec Win10)
C’est exactement cela. tu as très bien synthétisé ta configuration
Le fonctionnement des capteurs n’est probablement pas lié (pour rester politiquement prudent) à la gestion du groupe date/heure sur ta configuration.
Maintenant tout ce qui est capteurs Xiaomi … je te laisse faire un peu de lecture sur ce forum pour te forger ta propre conviction.
Si il y avait un problème de communication websocket entre Deconz et le REST API deCONZ ce devrait être général. As tu d’autres équipements qui eux fonctionnent/ne fonctionnent pas (en terme de remontée d’informations vers Jeedom) ?
As tu essayé de nettoyer le cache Jeedom puis redémarrer le démon Deconz ?
Ok, merci de ton retour.
Le point sur les capteurs Xiaomi est en utilisation conjointe avec Deconz ou en général tu veux dire que les capteurs aqara zigbee sont pas top ?
J’ai quelques prises connectées Ikea Tradfri qui fonctionnent bien depuis plusieurs semaines (après une inclusion compliquée) et RAS c’est pour ça que je suis confiant sur la communication entre Jeedom/Deconz. Hier en farfouillant un peu partout j’ai cliqué sur nettoyer le cache mais je n’ai vu aucun changement.
C’est plutôt cela. Pas coté performances intrinsèques mais coté implémentation Zigbee. Ils sont assez aléatoires. Tant que leur routeur est ON on va dire que ça peut tenir. Mais dès qu’ils perdent leur routeur ou qu’ils passent en mode veille profonde alors là c’est retour case manip manuelle.
Par contre pour le problème que tu as soulevé , pas sur que ce soient les capteurs qui sont en cause puisque tu as des routeurs qui fonctionnent et que les infos capteurs arrivent bien jusque sur la box domotique.Un fonctionnement erratique de l’interface Deconz semble plus probable. Il faudrait redémarrer le démon voire la box pour relancer depuis zéro la communication.
D’accord, si c’est aussi valable avec la GW xiaomi ça peut expliquer que parfois je sois obligé de rappuyer sur le bouton du capteur zigbee pour que ça reparte direct… (c’est rare mais ça suffit pour perdre en fiabilité…)
Pour Deconz je vais essayer de relancer tout ça (reboot jeedom + conteneur deconz) ca fera pas de mal de rebooter j’ai un uptime assez respectable sur la VM Jeedom…
En parcourant le topic j’ai vu qu’il y avait pas mal de topic sur le websocket ou des comportements étranges faisant que la communication ne se fait plus à un instant.
Maintenant il y a peu-être énormément de setup où ça marche parfaitement bien mais pour le moment je ne trouve pas ça très smooth Deconz+Jeedom. (J’ai vu que le conbee II était en experimental zigbee2mqtt)
