Zigbee plugin, pont deCONZ (passelle universelle Zigbee)

[mercusot]

Bon ben en mettant ce que je t'ai proposé ... il semble s'en ficher complètement, je n'ai pas de nouvel attribut qui se pointe. Ni dans l'interface Deconz (même en rechargeant le DDF ou redémarrant), ni au travers de l'API Que cela soit en majuscule ou minuscule.

Code : Tout sélectionner

{
  "config": {
    "heatsetpoint": 2200,
    "mode": null,
    "offset": 0,
    "on": true,
    "reachable": true,
    "schedule": {},
    "schedule_on": false
  },
  "ep": 1,
  "etag": "7783c90310e7a546aa288a68f3fe2f1f",
  "lastannounced": null,
  "lastseen": "2022-04-03T14:33Z",
  "manufacturername": "Sinope",
  "modelid": "TH1124ZB",
  "name": "Thermostat Salon",
  "state": {
    "lastupdated": "2022-04-03T14:36:54.418",
    "on": true,
    "temperature": 2212
  },
  "swversion": "2007",
  "type": "ZHAThermostat",
  "uniqueid": "50:0b:91:40:00:02:ca:1c-01-0201"

[Thorgal]

Oui c'est pour ca que je te parlais d'utiliser "duration", pour le moment on ne pas pas creer de "custom" parametre, et comme "backlight" n'existe pas encore, le code l'ignore, tandis que "duration" existe, c'est une valeur numerique (on aurait pu en trouver un qui soit enum) donc ca aurait pu etre compatible pour tester. Au lieu de s'en servir pur lire le timer on aurait regardé l'etat du backlight.

Mais laisse en stand-by pour le moment, tu pourras lire la valeur mais pas la modifier, je suis en train de faire des essais sur une vanne Tuya et je viens de comprendre ce que voulais dire "Cependant, pour les exploiter, des changements d'état doivent être déclenchés.". Ca commence a se mettre en place pour les commandes thermostats, je regarde pour faire ca globalement.

[mercusot]

Mais laisse en stand-by pour le moment, tu pourras lire la valeur mais pas la modifier

En effet c'est à moitié intéressant !

Vivement que cela se débloque un peu du côté de la flexibilité des fichiers DDF

[frtoto]

Bonjour,

j'ai remarqué hier (mais je ne sais pas depuis combien de temps) que mes capteurs de température qui n'ont plus de batterie, passaient bien en "Non Reachable" sous Phoscon mais pas sous domoticz. Ils restent comme s'ils fonctionnaient normalement (l'entête de l'icone ne devient pas rouge) mais la température est fixe. Résultat, mes scripts de chauffage continuent à faire tourner les radiateurs car la T° était toujours à 17.2... J'ai eu le cas sur 2 capteurs différents de xiaomi (1 rond et 1 carré).

Cela vient du plugin ou de Dz ?

Merci

Edit : je viens de voir sur github.com qu'un autre utilisateur a le même pb


Dz 2022.1 (4251)
Plugin 1.0.23

[Thorgal]

Je dirais que ca viens du plugin domoticz, si dans phoscon tu les vois bien en unreachable.
J'ai pas vu le lien de l'issue sur github, c'est quoi l'adresse ?

Tu aurais le json d'une des sondes HS (si elles le sont encore) ?

[mercusot]

Je dirais que ca viens du plugin domoticz, si dans phoscon tu les vois bien en unreachable

Où de la façon dont le script gère l'information de température, ou les deux
J'ai déjà eu un cas où le capteur n'était plus joignable et la valeur restait la même, juste la date de mise à jour faisait en sorte qu'au bout de x temps (x étant déterminé par le paramètre "Temps d'expiration" de Domoticz) le bandeau passait au rouge.

Dans l'exemple donné dans git (https://github.com/Smanar/Domoticz-deCO ... 1191871171) il reste à savoir comment se comporte le plugin. Est-ce qu'il met à jour le device de Domoticz même si la sonde est "unreacheable" ? Mais même dans le cas où la sonde ne serait pas mise à jour et viendrait à "expirer", si le script ne gère pas cette info alors la température restera à la dernière lue.

C'est pour cela que de mon côté je ne mets jamais un chauffage en route/arrêt en fonction d'une sonde de température mais en fonction d'un évènement autre (présence, heure, etc ...) en lui fournissant une température (setpoint) et je compte sur le thermostat du chauffage pour savoir s'il a besoin ou non de chauffer.

[Thorgal]

Le lien a raté ^^.
Je suis en train de faire deco un capteur pour le resultat, mais il va falloir 24h

Le plugin fait par rapport a la valeur de config/reachable (ou state/reachable pour les lights), cette valeur passe a false au bout de 24h sans la moindre reaction du capteur (pas sur pour la durée, mais si besoin j'ai trouvé le code qui gere ca y a pas une semaine)
Et ca passe le widget en rouge, mais ca ne change pas la temperature, car la je vois pas quoi faire, la passer a 0 ou 100 ? Selon les script ca pourrait etre pire.
Donc actuellement la temperature reste bloqué, par contre le widget DOIT passer en rouge pour prevenir d'un probleme.

[mercusot]

J'ai corrigé le lien ... désolé

Normalement je crois que les capteurs de mesure ne sont pas mis à jour lorsque non joignables, tout simplement, comme tu l'évoques, parce qu'on ne saurait pas quoi mettre comme valeur d'une part, mais surtout parce que ce changement pourrait déclencher des scripts alors que justement il n'y a pas de changement de valeur cohérent.

Ces capteurs passent automatiquement en rouge après le délai paramétré dans Domoticz. Et cela ne représente pas nécessairement un problème. J'ai des capteurs de température ou de luminosité qui ne reportent que si la valeur bouge de plus ou moins x%, et donc ils peuvent rester plusieurs heures sans reporter.

Domoticz les met en rouge mais cela n'est pas nécessairement un problème, juste une indication qu'ils n'ont pas été mis à jour depuis plus de x minutes (paramétrable dans Domoticz).

Un capteur de mesure n'est pas un capteur d'état de mon point de vue.

[frtoto]

Donc actuellement la temperature reste bloqué, par contre le widget DOIT passer en rouge pour prevenir d'un probleme.

C'est ce que je voudrais mais d'après les logs de Dz cela faisait au moins 5 jours que la T° ne changeait pas, donc qu'ils ne sont pas passés en rouge au bout de 5 jours

[mercusot]

Ce qui laisserait supposer que le plugin continue de le mettre à jour même s'il est "unreachable" et donc le délai de dernière mise à jour dans Domoticz n'excède jamais le paramètre "Temps d'expiration".