Pour rajouter une précision, screenshot de chez moi à l’instant.
La porte est fermée:
Avec une valeur de 1:
Je comprend donc que côté dev, il faut modifier la data qui arrive pour l’adapter à l’usage front dans Gladys ?
[DEVICE_FEATURE_CATEGORIES.OPENING_SENSOR]: {
0: 'unlock',
1: 'lock'
},
Actuellement le code nous dit que les capteurs d’ouverture sont à 1 lorsque « sécurisé » alors qu’on capte une ouverture … ‹ OPENING_SENSOR ›
Oui c’est bien ce que je souligne, c’est donc un capteur fermeture => Je peux comprendre le fait de n’avoir qu’un type de capteur, mais là on voit le souci, tesla envoi une data ‹ portes ouverte › = ‹ capteur ouverture › a 1 lorsque ouverte. Idem pour les fenêtres …
Exact !
Il n’y a pas vraiment de débat, c’est simplement une convention dans Gladys : “1 = fermé” 
Les constructeurs sont d’ailleurs partagés à ce sujet. Certains, avec une approche issue du monde de l’électronique, considèrent qu’un circuit fermé (contact établi) = 1, ce qui correspond logiquement à une porte fermée.
D’autres, avec une vision plus “informatique”, interprètent “1 = true”, donc porte ouverte = oui 
Il faut faire la conversion pour matcher avec la convention Gladys 
On le fait dans pas mal d’intégrations par exemple pour harmoniser les couleurs.
1 Like
Hello,
je ne sais pas si côté dev ça peut aider mais les capteurs d’ouverture que j’ai chez moi sont en fait des capteurs de fermetures :
On en perd presque notre latin (expression de vieux
)
Zigbee2mqtt a la même convention que Gladys.
Après, pour le terme « Door Opening Sensor » c’est juste que c’est comme ça en anglais qu’on désigne ces capteurs, il n’y a pas de logique à chercher
1 Like
Les premiers développements sont live dans Gladys Assistant 4.60 :
2 Likes
5 messages ont été scindés en un nouveau sujet : Impossible de mettre des chiffres à virgules dans la condition sur variables