Hello everyone,
Does anyone know how to create a scene based on the return of a push button?
The interface displays the correct values, but in the scenes I don’t know how to do it.
I have tried:
Nothing works! In the Gladys logs, it is indicated conditionVerified = false. It’s explicit!
This scene works for me with a Xiaomi button:
However, on the dashboard, I don’t have the same as you, the value of my button is an integer:
What is the model of your button?
Can it perform long, single, or double presses?
Mine is a WXKG06LM.
Yes, I can!
It’s the Xiaomi Aqara switch
@lmilcent which integration button is this?
If it’s the Zigbee2mqtt integration, once again it all depends on what was changed in this PR…
It is indeed Zigbee, with a button feature.
Actually, it would be helpful to describe how Gladys reacts with the different features to avoid asking the question each time (maybe it’s already done?).
For example, of type switch - an On/Off button is offered, and it is detected as a socket.
In my case, it is of type button and the returned values are consistent. But in a scene, I don’t see how to use it.
In the Xiaomi service, the literal values of the buttons are translated into numerical values.
const SWITCH_STATUS = {
NO_CLICK: 0,
CLICK: 1,
DOUBLE_CLICK: 2,
LONG_CLICK_PRESS: 3,
LONG_CLICK_RELEASE: 4,
};
Maybe I should do the same in the Zigbee service 
However, there are many types of buttons…
Oh, I thought Gladys Core handled this based on the features.
Isn’t that more logical?
Most importantly, I think this will prevent a service from interpreting a button differently from another, to maintain consistency and therefore a certain simplicity regardless of the protocol.
In my case, there are:
What I don’t understand is that these devices emit events and not values.
For a thermometer, the value is updated every time it changes.
For a button, if you press it (for example, a single click), we could update the value to 1, but right after, it should go back to 0 (to reflect the button’s state)?
That’s indeed Gladys Core that defines the format of the features.
That’s the goal in theory 
We try to have feature formats shared between services as much as possible (On/Off, color, brightness, temperature, etc…)
However, in practice, unfortunately sometimes it is difficult to generalize from devices that have very exotic specificities. In the example cited (Xiaomi), for now it was the only button peripheral with several types of presses (short, long, double, etc…), and therefore indeed it is the only one to implement this kind of operation.
Now that we have the case in 2 services, we can think about seeing what overlaps/does not overlap
You indeed need to do the same on the Zigbee side (it’s the same button, right?)
I think that in the case of a button, you should see the value more as an event rather than a state. It’s an event « the button has been pressed ».
I see little interest in doubling each event with an event that resets the state to 0 (« The button has not been pressed ») … Do you see any?
Edit: By the way, the NO_CLICK: 0, was added at the beginning but not used, I don’t see the point. It should have been removed in the PR.
I don’t know if this is currently the case, but on the dashboard, my button is displayed « single » and then a few seconds later « no event » (if I reload the page)
It will be complicated to manage all the cases.
For devices like this one Aqara WS-USC02 control via MQTT | Zigbee2MQTT or this one Aqara WXKG02LM_rev2 control via MQTT | Zigbee2MQTT, we have:
@lmilcent Have you tried with the « single » value in the scenes?
Yes, I tried with « 1 » and a single short press on my button.
@cicoub13 In my opinion, we need to revisit this, this type of button should be handled natively and work out of the box in scenes
Just like we adapt the UI when it’s a binary button for example:
We need the same for these buttons.
I would see a dropdown with the different values:
The user should not have to guess how it works, it’s hell otherwise ^^
The same goes for presence/contact detectors, right?
Shouldn’t we display « closed/open » and « motion/no motion » instead?
Indeed the same! Except for numerical comparison values (temperature > XX), the user should not have to type anything, it doesn’t make sense
@cicoub13 I saw that you proposed the zigbee2mqtt PR, so how does it work for button-type devices with multiple types of presses? What is sent by the service? Is it the same format as the Xiaomi service?
I haven’t done anything yet.
I can integrate the same values as the Xiaomi service. But it would be good to standardize this for all services (in the constants) and to add a button (like the On/Off) in another PR.
And as I mentioned, there are devices that have many more cases: left/middle/right buttons that can all have short/double/long presses. Should we handle these as different features (this is going to be tricky for Zigbee 
)?
I would see:
short, double, long type pressesThis way it’s simpler
I agree, we need to standardize. The same constants as the Xiaomi service seem good to me! We can put that in the project constants indeed.
I think we need to handle exotic devices on a case-by-case basis, not everything is factorizable and in my opinion it’s not desirable to do « hyper generalization »
So yes, it doesn’t bother me if we have some exotic devices defined as a separate « feature » as long as it remains consistent with Gladys in general, we need to think about the usage. For example, if it’s to control a light, the on/off, the brightness, and the color, it’s vital that these are « native/general » features of Gladys so that Gladys can control these devices in the chat, scenes, and others.
When it’s very very exotic buttons specific to a single integration and that will never be used elsewhere, we need to think from start to finish how it will be useful in Gladys and do the best, without necessarily trying to fit it into a mold and make it unusable.