Message d'erreur zigbee2mqtt

Du coup je ne suis pas sur que le problème de mappage de @lmilcent ne concernait uniquement les interrupteurs sans fil. Depuis le passage en v4.8.4 j’ai mes capteurs d’ouverture qui fonctionnent à l’envers et qui du coup casse mes scènes de détection d’ouverture.
Sur l’image ci dessous toutes mes fenêtres sont fermées mais j’ai l’icone représentant la fenêtre ouverte!
image

Ci dessous la valeur dans zigbee2mqtt
image

1 Like

Yep, moi aussi c’est pareil que toi @_Will_71
C’est inversé.

Tout pareil ici aussi ^^

Effectivement pour moi c’est pareil, mais je préfère cet état là, car pour moi c’est plus cohérent d’avoir l’icône barré quand la porte ou la fenêtre est fermée. quand mes capteurs d’ouverture Xiaomi étaient gérés par l’intégration Xiaomi, ils s’affichaient comme ci dessus , puis quand je suis passé dans l’intégration zigbbe ils se sont retrouvés à l’envers. je pense qu’en Zigbee2MQTT, ils étaient paramétrés à l’envers

Ahhh je vais me faire disputer !!!
Vous etes sûr de votre coup ?
J’avoue que l’icône « bouclier barré » n’est pas franchement explicite pour moi.
Mais j’ai peut-être inversé 0/1 false/true.

Cette icone ambiguë on en parle ici au cas ou

Hummm
Donc je vois que si le contact est fait, alors on a « true » comme valeur, mais Gladys ne parle pas de « contact » mais « d’ouverture ».
Les notions sont donc inversées.

Capteur de contact = vérifie que c’est fermé
Capteur d’ouverture = vérifie que c’est ouvert…

Crotte. J’ai pas vu ça.

3 Likes

bonsoir @ Alex Trovato
Au risque de me faire huer, voir l’icône barré quand la porte ou la fenêtre est fermé c’est plus parlant ( notion de barrage ) De plus, en laissant comme ça on revient dans la même logique que l’intégration Xiaomi. Effectivement de mettre ouvert ou fermé réglerait le problème. :smiley:

C’est vrai que ces icônes ne sont pas très explicites, pour moi c’était plus logique dans l’autre sens mais ca peut être un long débat je pense :slightly_smiling_face:
Après faut surtout être sur de la valeur retourné car si on laisse comme cela je doit refaire toutes mes scènes ou je prends en compte ces capteurs là

!!! :smiley:

Aha tkt ça arrive, et puis c’est l’occasion justement de changer ces icônes pas super explicite, on pourrait passer à un cadenas fermé / ouvert ?

Ouvert:

Screenshot 2022-05-06 at 08.55.39

Fermé:

Screenshot 2022-05-06 at 08.55.36

6 Likes

Je suis d’accord pour ces icônes,
En voyant un cadenas ouvert ou fermé on se pose moins de question je trouve

2 Likes

Je viens de m’en apercevoir, j’allais en faire un post. Merci pour ton retour, je confirme de mon côté le même comportement !
Ma scène de détection des intrusions quand je suis en congés dysfonctionne totalement du coup :joy:

Pour info, @AlexTrovato a fait une PR pour fixer le comportement inversé sur les capteurs d’ouvertures de porte !

Comme il ne peut pas tester, je serais preneur de retour en réel sur cette PR ! J’ai demandé à ce qu’il fasse un build Docker pour vous, qu’il postera ici.

Je sais que c’est un peu contraignant de tester des builds Zigbee2mqtt, mais bon ces développements étant fait à l’aveugle, c’est dur de faire autrement :smiley:

2 Likes

Je testerais ce soir.

Image en cours de build.
atrovato/gladys:zigbee2mqtt
Elle sera disponible ce soir :wink:

3 Likes

@pierre-gilles , @AlexTrovato
Je viens de tester et mes capteurs d’ouverture sont revenus comme avant et mes scènes refonctionnent! :grinning: :+1:

Voici une image avec mes fenêtre/porte fermées.
image

3 Likes

Je viens de merger la PR :slight_smile: Merci @AlexTrovato pour le fix et @_Will_71 pour les tests :slight_smile:

1 Like

Correctif déployé en prod ! :slight_smile:

3 Likes

Je confirme que cela refonctionne! Merci @AlexTrovato

Alors cela semble mieux mais jai encore les anciennes icônes, est ce normal ?

Je me base par rapport a ce message (jai pas ete verifier si cela faisais partit de la mr)