Status badge "Summary of openings"

Feature requests
1

Could we add to the status badge « Summary of openings »:

  • the ability to choose what you want to see appear: the open or closed elements.
    Indeed, when you leave the house, you want to know that everything is well closed, but if I’m too hot in the summer, I might want to check that everything is open ^^
  • an option to display the list of elements in question by clicking on the badge!
    image
    image262×184 21.7 KB

    At my place, I see that something is open… but I don’t know what :wink:
2

I think there is a problem because I still have a discrepancy between my sensors and the result of this tablet.

I checked, I currently have 4 open detectors and the tablet tells me 5.
image

3

I have the same problem on my end where I have nothing open but it still shows 1 open.

4

I confirm :slight_smile: it would be great to be able to see at a glance which element is still open.
In the meantime, I’ve created a page that lists all my openings to quickly check which one is open :sweat_smile:

5

Hello,

I’ve dug into it: the chip count is correct, but the stored value is inconsistent across integrations.

Gladys 5 introduced the convention OPENING_SENSOR_STATE = { OPEN: 0, CLOSE: 1 }, which is used by the chip counter. This constant did not exist in Gladys 4, and three integrations store the opposite (open = 1):

(Zigbee2MQTT, Matter, and MQTT/Home Assistant, on the other hand, are compliant.)

Result: an opening from these integrations and closed is worth 0, so it is counted as always open. The most discreet case is Netatmo, which creates an “open window detection” feature by thermostat/thermostat head, invisible on dashboards and reset to 0 continuously → a “ghost” open. This matches your two cases (4 + 1 = 5, and 0 + 1 = 1).

Note, it’s not always “+1”: conversely, a Z-Wave/Xiaomi sensor actually open is worth 1 and is not counted. A simple -1 would therefore not fix anything.

To confirm on your end: look on your devices’ page for an opening displayed as “Open” when it is physically closed.

I think the fix is to align these three integrations with the constant… it remains to decide the fate of the values already in the database: without migration, the display remains false until the next state change, with migration, the conditions of scenes of the type “sensor = 1” change meaning.