After adding the alarm I wanted to reactivate my door or window opening detection scenes.
The problem is that the « Device state change » trigger works backwards for the opening sensor.
That is to say I’m forced to select the text Closed to detect opening!
If I choose Open it does the opposite and detects closing.
On the dashboard the display is correct
Here the window is closed
Here the window is open
Any possible rollback due to this bug 
?
Yes, we had talked about it recently; the problem occurred after an update of that kind.
We need to find a way to put an end to this problem 
Yes, indeed I also find it confusing to have a sensor that indicates the opposite position to the state of
If I’m not mistaken, the issue is no longer with the icon display (which seems perfectly consistent on my end) but rather concerns scene creation.
I also test the state change of my contact sensors and I have to indicate CLOSED when I want to
The problem comes from devices that return ‹ 1 › for ‹ open › and others that return ‹ 0 › for open…
A feature request to be able to ‹ invert the state ›?
A checkbox (@pierre-gilles is a fan) that would say ‹ my sensor returns inverted data › or…?
That might complicate things a bit, no?
Or if we had to do that, we’d need to write an entire text so as not to confuse the user:
This sensor indicates an OPEN state.
Verify its position.
If it still indicates OPEN when it is closed, check this box:
How is that handled? Because ultimately Gladys displays exactly what the sensor sends, 0 or 1. I think this logic needs to be inverted at that level, quite simply, so that when Gladys receives an open state from the sensor we treat it as an open window 
Totally agree, it’s the device’s logic that doesn’t seem right to me, not the Gladys (gladys) core — it seems more logical to add a feature with a checkbox in the device settings to invert the values it returns and that would be more general (in case one day devices send « open » « closed » instead of 0 and 1!) or maybe it’s in the device integration that should take this behavior into account?
Hi, it’s still the same issue, there hasn’t been a fix since 
The thread must have been forgotten; there wasn’t an associated GitHub issue.
I created a PR to invert the translations:
There will be a Gladys Plus build that I’ll post here if you want to test the inversion to confirm that it works!
Edit: The Gladys Plus build is available here: https://inverse-opening-sensor-trans.gladys-plus.pages.dev/
Can you confirm that on your end it correctly inverts in the scenes with the right value?
I’ll test when I get home at noon.
All good here!!
It’s fine here too. 
Thanks for your tests, it’s merged into master and it will be included in the next Gladys release!
Quick question:
What will it do to my sensors that were returning the correct values? I admit I haven’t tested…
The PR just swaps the translations, but it doesn’t change the values
Also, if you have a device that was good in terms of translation, that changes everything — it will be reversed for it I thought everyone agreed
Oh, I’ll see and sort it out if it breaks something. I skipped following this topic 
Edit: not even sure I’m affected.
Hello everyone,
I might say something stupid but since I don’t have a door/contact sensor to test…
Can’t we simply handle the inverted value problem in the sensor settings by inverting the values like this?
I tested on a plug it works this reverses the behavior at the UI level but if someone has a door/contact sensor to test
That still looks like a hack, not
I agree with you, the problem is that this will impact all devices, those that send a 0 for open and those that send 1 as @GBoulvin says.
Changing it directly in the integrated device resolves both cases, no?
(I only have MQTT so I can’t answer for the other cases, my idea may not be good indeed) 
PS:
It’s the behavior of the sensor that sends 0 for closed that’s not intuitive!!! 
But in the case, for example, of a relay or a detector where there is NC and NO it makes sense, Gladys just needs to be able to handle these two cases!
