Deconz n'interprête pas les changements d'état des équipements (mais la communication fonctionne)

Bonjour à tous,
Tout d’abord, excellentes fêtes de fin d’année à tous.

01/01/2021 - edit de ce post pour être plus clair, et suppression des mes auto-reponses.

Je me permet d’ouvrir ce topic car j’ai un énorme bug sur le plugin DECONZ.

Environnement :

Jeedom V4 fraichement installé, mais j’ai eu le soucis la semaine dernière en V3.
Raspbian stretch 9.13
Jeedom v4.0.61
Plugin Deconz 2020-10-28 18:46:23 avec une clé Conbee II (firmware 26660700, version 2.07.01 / 08/12/2020)
(3 interrupteurs, 5 capteurs d’O/F, 1 ampoule et 2 capteurs T°, tout xiaomi sauf l’ampoule Tradfi)
Le tout sur un rasp 3 b+

Un soir sans prévenir, panique générale, plus rien ne fonctionne. Après maintes recherches, voici ce que j’observe :

  • Les interrupteurs ne fonctionne pas.
  • L’état des capteurs d’O/F ne change pas
  • L’ampoule est controlable, mais ne retourne pas son état.
  • Mais ! La date de dernière communication sur la page de chaque équipement est bien cohérente avec les dernières actions sur ce dernier.

Par exemple, j’ouvre la fenetre, la date de communication change (dernière communication le XX/XX/XX à « maintenant »), mais l’état reste à 0 (fermé).

Si on regarde les « infos » de chaque noeud (en XML semble-t-il), tout est bien retourné (les valeurs d’état change), mais Deconz ne les prends pas en compte (via le testeur d’expression par exemple).

Par exemple, pour un double interrupteur :

Clic gauche :
« state »: {
« buttonevent »: 1002,
« lastupdated »: « 2021-01-01T15:25:38.510 »
},

Clic droit :
« state »: {
« buttonevent »: 2002,
« lastupdated »: « 2021-01-01T15:25:53.635 »
},

Mais si je teste l’expression de la commande, ça reste à 2002.

Idem pour les capteurs d’ouverture

Je ferme le capteur :
« state »: {
« lastupdated »: « 2021-01-01T16:27:26.005 »,
« open »: false
},

Et je l’ouvre :
« state »: {
« lastupdated »: « 2021-01-01T16:27:45.055 »,
« open »: true
},

Par contre la valeur de la commande ne change pas…
Du coup la plupart de mes scenarios sont HS.

J’ai déjà tenté beaucoup de choses, en vain :

  • multiples reboot
  • cocher la case fuseaux horaires
  • Reset de la clé et réimport de la conf (fichier dat)
  • Réinstallation Deconz (pleins de fois)
  • Retrait de la rallonge USB

Auriez-vous une idée de ce qui peut provoquer cette bizarrerie ?

Merci d’avance de votre aide, pour ce problème très handicapant sur lequel je bataille depuis plusieurs jours maintenant :frowning:

A bientot !

Et en relançant le démon du plug in Deconz ?

Merci de ta réponse. Deja fait des dizaines de fois :frowning: je désespère totalement…

Dans la documentation du plugin :

J’arrive a piloter mes équipements mais je n’ai pas de retour sur les commandes d’informations

Cela vient surement d’un soucis sur les fuseaux horaires (deconz est très pointilleux la dessus). Il faut :

  • vérifier dans “Réseaux deconz” que la timezone et l’heure sont correcte si non vous pouvez soit le configurer dans deconz soit cocher la case “Fuseaux horaire” sur la gateway dans la configuration du plugin deconz (si vous faite cette derniere méthode il faut attendre 1h avant que la correction soit effective)
  • vérifier le fuseau horaire de votre OS (en particulier sur les rpi) qui doit absolument etre bon

Ca semble être une bonne hypothèse.
Sur le RPI

#date
Sat 2 Jan 16:41:37 CET 2021 (ce qui correspond donc à l’UTC+1 ou GMT +1)

J’ai donc modifié le fuseaux horaire directement sur Phoscon en en Etc/GMT+1, qui est notre fuseaux français.

L’heure affichée est

Timezone Etc/GMT+1 (2021-01-02T14:42:39)

(alors qu’en réalité il est 16h42…)

J’ai relancé le demon et redemarrer Jeedom, toujours cette heure là qui est affichée, sur Deconz et sur Phoscon…une idée ?

Edit :
J’ai tenté de mettre en GMT+2

Timezone Etc/GMT+2 (2021-01-02T13:49:21)

Donc, plus j’augmente le décalage, plus l’heure recule ? Pas logique…

Suivant cette logique, j’ai modifié le fuseau en GMT-1
J’obtiens donc

Timezone Etc/GMT-1 (2021-01-02T16:51:33)

Ce qui correspond donc à la véritable heure locale, malgré que le fuseaux ne soit pas le notre…

Et SURPRISE (enfin, pas tant que ça) !!! Tout refonctionne correctement ! :slight_smile: Le problème venait donc bien de là ! Merci la doc !

Mais ll semble bien y avoir un problème sur les fuseaux de Phoscon directement (Inversion des + et des - ??)

Est-ce qu’un développeur pourrait le confirmer ?
(j’ai fait un mail au support de Phoscon également).

De mon coté tout fonctionne correctement avec les réglages tels que prévus :
Sur le bios du NUC : horloge RTC réglée sur UTC
Sur OS Debian : timedatectl réglée sur local Europe/Paris et timedatectl RTC réglée sur UTC
Sur Jeedom : Date/Heure réglée sur Europe/Paris
Sur Phoscon Date/Time réglée sur Europe/Nrissels

Les infos remontées par le plug in Rest Api de deCONZ traite toutes ses dates/Heures en UTC (ce qui est normal et universel quel que soit l’endroit où la domotique est installée). Il est important que les Date/Heure RTC OS et matérielle soient réglées sur UTC qui est la référence universelle de base de temps (comme son nom l’indique bien).
Il appartient aux applications de haut niveau de présenter une Date/Heure convertie aux utilisateurs. C’est pour cela que chaque application dispose d’un réglage pour cette présentation (Jeedom, Phoscon, …) et il est important que ces réglages soient les mêmes sur toutes les applications.

Donc pas de problème coté Jeedom ni Deconz.

Merci de ta réponse.
Je comprends tout à fait ce que tu entends en disant que tout doit être en UTC.

Ce que je comprends pas, c’est pourquoi l’heure affichée par Deconz en GMT-1 correspond bien à notre heure locale ? Alors que ça devrait être le cas en GMT+1…
Il y a bien un problème dans Deconz du coup…puisque sans ce réglage, plus rien ne fonctionne…