Standard Native Buttons

[psychuk]

I would very much appreciate the inclusion of standard buttons as a type of item in both the OH web interface and the iOs and Android sitemaps.
As of now this type of interaction is best achieved using switches, but switches are not buttons, there is no button-down, button-up, click, or double click event availability (at the very least the first two events should be supported, other behaviours could be simulated in code).
Native buttons would do much to not only beautify sitemaps but to greatly improve functionality where a user simply wants OH to 'do this', instead of having to choose a state implicitly.

[lolodomo]

As I understand it, you would like to retrieve in an item state the user actions done in UI on buttons? Is that correct?

We defined recently the Buttongrid element for sitemap UIs but without this feature but I believe it can be enhanced.
#3441

[psychuk]

I would like to have a new item type added... Button.
At the very least for those buttons to have 'press' and 'release' state change events (a state change to ON and OFF, for example).
For those buttons to be available in paper UI and standard sitemaps as graphical buttons, having a depressed look when pressed and returning to normal when released, as with any other UI.
If you'd like to be fancy, you could always add a 'toggleable' modifier to make them behave like switches (ie. they stay pressed until pressed again) as an alternative to native switches. I would prefer this to switches, but that is only my personal preference.
If the Buttongrid you mentioned achieves this I would happily use that, I would simply only have 1 Button per item, assuming I could align text on the same line of course.

[ThaDaVos]

Maybe the button from this Binding does what you want?
https://community.openhab.org/t/magic-binding-4-0-0-0-4-2-0-0/144790

[psychuk]

Maybe the button from this Binding does what you want? https://community.openhab.org/t/magic-binding-4-0-0-0-4-2-0-0/144790

Interesting set of tools there, it doesn't state that those buttons are visible in standard sitemaps though. It's more likely they are widgets.

[ThaDaVos]

The binding is about things which simulate real life devices - to make testing easier or use as dummy things - I have it installed but not used yet - but thought, as you were asking about events, that it may be useful - as it simulates a button

[rkoshak]

I would like to have a new item type added... Button.
At the very least for those buttons to have 'press' and 'release' state change events (a state change to ON and OFF, for example).

I believe there is no Button Item type by design so this will be a hard sell (any changes to Item types is a hard sell because it impacts all the repos, not just this one).

A Button doesn't really have a state, it has events. An Item's entire reason for being is to store state so when you have events and do not have state, a Thing's Event Channel is to be used.

In MainUI, when one wants to generate an event like that, it has the ability to call a rule as an action when activated. That mimics how an event Channel would trigger a rule. Maybe something similar could be worked up for sitemaps?

I would imagine it would be an extension to the behavior of the Switch element with mappings.

Am I completely off base @lolodomo?

[psychuk]

I would imagine it would be an extension to the behavior of the Switch element with mappings.

If you could get a switch to look like a button with some styling magic that would work, that would essentially be a toggle button.
Add the ability to somehow get the underlying switch to revert back to OFF when released and you have the best of both worlds.

[ThaDaVos]

Reverting of the switch would be possible already - think it's one of those meta things you can add - I know I did it before

[rkoshak]

If you could get a switch to look like a button with some styling magic that would work, that would essentially be a toggle button.

It's been a long time since I messed with sitemaps. I think you can set up a mapping on the Switch (which gives you the button UI element) and have it send TOGGLE which will flip the switch (i.e. command ON when OFF, OFF when ON).

Reverting of the switch would be possible already - think it's one of those meta things you can add - I know I did it before

The expire Item metadata.

There is also the rawbutton_on_off_profile which might be useful here. https://www.openhab.org/docs/configuration/items.html#profiles

[psychuk]

The expire Item metadata

Just looked at that, good idea in principle, but that simply reverts to a state after a period of time, there is no way to 'press and hold'.
I'm basically looking for some kind of 'press' for as long as you want and then 'release' workaround.

I believe there is no Button Item type by design so this will be a hard sell (any changes to Item types is a hard sell because it impacts all the repos, not just this one)

I agree it may well constitute a level of change that others may find uncomfortable undertaking, however I would suggest adding things is easier than removing things (from a backwardly compatibility point of view) and furthermore I would respectfully hope the team are still willing to evolve the existing toolset rather than having a view that 'this is what you have, make do'. I actually asked for buttons way back in OH2, I was genuinely surprised they wasn't included in the item types.

[rkoshak]

I'm basically looking for some kind of 'press' for as long as you want and then 'release' workaround.

That's what the rawrocker-to-dimmer profile does. There might be something you can use there.

I actually asked for buttons way back in OH2, I was genuinely surprised they wasn't included in the item types.

Well, like I said, an Item that doesn't represent a state violates the architecture and defined meaning of an Item. It's not just adding a new Item, it's changing the entire meaning of what an Item is. And, like I said, even merely adding a new Item impacts openhab-core, openhab-addons, openhab-webui, openhab-android, and openhab-ios at a minimum. It's a pretty big deal. Someone would have to be pretty dedicated to volunteer to take that on.

[psychuk]

Well, like I said, an Item that doesn't represent a state violates the architecture and defined meaning of an Item

Why would it not have an item state? Surely if it's pressed it's ON, and released it's OFF, the end user simply maps these to PRESSED and UNPRESSED respectively. This is the behaviour I would expect it to adopt (ie. Button gets ON state change event, rule executes, maybe runs a timer if jogging is required, Button gets OFF state change event, which is either ignored or cancels the timer is automation is jogging). I mean, there would be nothing stopping a person from binding this to a light and using the button to send morse code to their neighbours.

[rkoshak]

Why would it not have an item state? Surely if it's pressed it's ON, and released it's OFF, the end user simply maps these to PRESSED and UNPRESSED respectively.

Then this isn't the right repo for this. You don't need a new Item type, you need new UI elements/widgets to send ON/OFF when pressed/released. The Switch Item would still be appropriate.

[lolodomo]

What is requested is not a new item type but a new UI stateless element having specific commands on a switch item. When the UI button is pressed, the UI sends command ON and the button is released, the UI sends command OFF.
If I consider only sitemap UIs, this would require to define a new sitemap element and then to implement it in all sitemap UIs (Basic UI, android app and iOS app). Or instead of a new sitemap element, it could be an extension of the existing Switch element.
Not very difficult but very very specific usage.

[lolodomo]

For sitemap UIs, what do you think about a new Switch element parameter named button ?
If this parameter is there, the UI shows a simple button, ignoring the item state but sending ON when the button is first pushed and OFF when the button is released. The value of this parameter would be the text to display inside the button.
In case the item is of type String (and not Switch), we could even send other button events as text commands.

It should not be too much difficult to implement that in Basic UI.

@openhab/android-maintainers
@openhab/ios-maintainers
Any interest to implement this feature in Android and iOS apps ?
Or have you a better proposal ?

[psychuk]

I am still hoping this will be adopted in some fashion, It still baffles me we have a toolset for almost everything you can touch in your home, apart from buttons.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/button-on-when-pressed/153062/5

[CrysK]

Yes, it would be great to have a button that works like a button in real life :)

[jimtng]

For sitemap UIs, what do you think about a new Switch element parameter named button ?

+1

If this parameter is there, the UI shows a simple button, ignoring the item state but sending ON when the button is first pushed and OFF when the button is released.

If the item is currently OFF, it shows as "not pressed down" and when the user touches and holds (press and hold), it sends an ON command, and when the user releases the widget, it sends OFF command.

Another alternative is that it can show the current state of the item. So if the item is currently ON, it shows as being depressed (pressed down). If the user touches it, and holds it, it does nothing but when the user releases the button, it becomes "not pressed down", and it would send an OFF command.

Also similar to https://community.openhab.org/t/confirm-button/146490 we could add a buttondelay=3s (or debounce, or similar) option, to only send the ON command when the widget is pressed for longer than 3s. This would be very handy to avoid inadvertent activations.

Multi-clicks

However, this doesn't support "double click, triple click, (N-clicks), hold". To do this, it needs to be linked to a string or number item, and then it would need the ability to specify the intervals between clicks to be considered double clicks vs two single clicks, etc.

Maybe add another parameter multiclicks to activate this behaviour (perhaps a separate enhancement, different to button?). I know this makes it much more complex than just ON/OFF so it could be for another topic / separate feature?

[lolodomo]

In that case (so many different options), it is better to create a new sitemap element named "button" with its own dedicated parameters.
As updating or adding a new sitemap element requires changes in the sitemap syntax, the sitemap generator in Main UI and to be then supported in all sitemap UIs, I would like to be sure first there is an interest to develop this new feature by the usual Android and iOS app contributors.
IMHO, we are not at the same value for users compared to the introduction of the input and buttongrid elements. I hope we will not do that for only 2 users all over the world... I would have expected a more "sexy" new element for next OH version ;)

[lolodomo]

@openhab/core-maintainers : it would cool to tag this feature request with the tag "sitemap".

[mueller-ma]

What the use case of these new buttons? I read rollershutters somewhere, but the Android app already has a "press and hold" feature for the rollersutter buttons.

[kaikreuzer]

I'd just like to mention that we have buttons in sitemaps since openHAB 0.6 or earlier already... They are part of the Switch widget, if a mapping is added to them. The nice thing about this feature is that you can even have several buttons on the same line (all with different/custom commands and label texts). If the underlying item does not have an auto-update configured, the buttons should always be shown as "not active" (it feels that we currently have a bug in the Basic UI, because this somehow does not seem to work as expected).

So imho the feature request here is mainly about adding support for different kinds of events like "released" or "double-press". Events do not really fit to the concept of sitemaps, though, which are about interacting with items. Not sure if we have any example of events in the UI so far and how those could be best incorporated. I would want to avoid blowing up the logic for all our UIs to implement, such as defining 4 different items for 1, 2, 3 and 4th press within a certain timeframe etc. Only sending press/release events and then processing those on the runtime (similar to processing thing channel events through different profiles) is probably the much better choice.

[psychuk]

What the use case of these new buttons? I read rollershutters somewhere, but the Android app already has a "press and hold" feature for the rollersutter buttons.

Any item really where 'jogging' would be useful. Scene selection is another benefit. Or simply as a trigger to perform multiple actions from rules.
Speaking personally I have many switches, etc in my home setup, and the device I use most often is my Z-Wave Keyfob... with 4 buttons. Moreover a button seems at least to me to be a standard type of control element.

[kaikreuzer]

@psychuk It really sounds as if you do not know the button feature yet. Check out https://demo.openhab.org/basicui/app?w=0202&sitemap=demo, where you can see a demo button. It is exactly made for switching scenes and such stuff.

[psychuk]

@psychuk It really sounds as if you do not know the button feature yet. Check out https://demo.openhab.org/basicui/app?w=0202&sitemap=demo, where you can see a demo button. It is exactly made for switching scenes and such stuff.

Interesting, I like the idea of having many buttons on one line, however do those buttons have a press and release action?

[kaikreuzer]

No, see my comment above.

[rkoshak]

Only sending press/release events and then processing those on the runtime (similar to processing thing channel events through different profiles) is probably the much better choice.

If this approach is taken (I've no opinion either way) please don't add yet another custom subsystem to handle events from UIs to the Item. If it is at all possible, please try to come up with a way to use the already existing Profiles (note there are already some button press profiles which might be applicable here). As an added bonus, providing a way to add profiles to an Item without a Channel would be awesome! I think it would be a boon if profiles could be made generic like that.

[psychuk]

So imho the feature request here is mainly about adding support for different kinds of events like "released" or "double-press".

I think double click events or press and hold events could be implemented quite easily via client side scripting, IMHO, if the team thought native functionality of these states were too much to implement.
Limiting the item state to 'ON / PRESSED' and 'OFF / RELEASED' would suffice in most cases.

It's also worth mentioning that this kind of enhancement (or addition) would not break anyone's current setup or configuration.

[jimtng]

I think double click events or press and hold events could be implemented quite easily via client side scripting

If by that, you meant using rules (rulesdsl/jsscripting/ruby, etc), keeping track of precise timing for multi-clicks will be difficult because of the latency between front end UI -> REST -> event bus -> rule. This is one thing that needs to be done on the front end.

[psychuk]

This is one thing that needs to be done on the front end.

I agree it would be better, to have such things handled in the GUI, however if this becomes a reason not to implement any changes I would rather have some button functionality, than none whatsoever.

[lolodomo]

Only sending press/release events and then processing those on the runtime (similar to processing thing channel events through different profiles) is probably the much better choice.

You mean a new concept to implement in core framework: events attached to item that will be handled by rule engines ?

[lolodomo]

If the underlying item does not have an auto-update configured, the buttons should always be shown as "not active" (it feels that we currently have a bug in the Basic UI, because this somehow does not seem to work as expected).

I believe it was already discussed few years ago, I even proposed a fix but you did not like my solution. Then no other solution was proposed.
Trying to find this discussion...

[CrysK]

... or press and hold events ...

This is like the regular Switch is currently working

Limiting the item state to 'ON / PRESSED' and 'OFF / RELEASED' would suffice in most cases.

Yes, this would be great. Just no hold after a push would be wonderful.

[lolodomo]

Only sending press/release events and then processing those on the runtime (similar to processing thing channel events through different profiles) is probably the much better choice.

You mean a new concept to implement in core framework: events attached to item that will be handled by rule engines ?

@kaikreuzer : can you please develop your thoughts, I am not sure to understand the solution you would prefer.

[CrysK]

Is there any progress in the development of the button?

[lolodomo]

No progress on my side, I simply did not understand what was the preferred implementation solution.

[CrysK]

From my point of view, an addition or change to the current "Switch" element would suffice.
If pressed: "ON", if not pressed: "OFF".
Unfortunately, I can't help you with how to implement this.

[lolodomo]

Maybe the proposed solution by @kaikreuzer was to define a new kind of events on the bus, a special UI event that would be sent by UIs when the button is pressed or released for example. The core framework should then be updated to handle these new events and in particular to add a new trigger in all rule engines. Not something trivial I believe.

[psychuk]

Maybe the proposed solution by @kaikreuzer was to define a new kind of events on the bus, a special UI event that would be sent by UIs when the button is pressed or released for example. The core framework should then be updated to handle these new events and in particular to add a new trigger in all rule engines. Not something trivial I believe.

If you are assuming you have to implement various button states, then it gets more complicated, having a button element that reports 'ON' when pressed and 'OFF' when released is far easier, in my opinion, those events already exist (state change event). This was my original 'bare minimum' functionality when creating this feature request.

[lolodomo]

Let's restart all of this.

First, Kai has right, we have buttons in sitemap UIs since many many years.

With the following items:

Switch DemoSwitch
String DemoString

and the following sitemap elements:

Switch item=DemoSwitch mappings=[ ON="ON" ]
Switch item=DemoString mappings=[ UP="UP", DOWN="DOWN" ]

The result is:

These buttons are click buttons, the command is sent to the item when clicking the button.
The request is press & release buttons. For that, we need two different commands, the command when pressing the button and the command when releasing the button. So my proposal is to extend the current syntax of buttons mappings to embed one or two commands. If only one command, this is a click button. If two commands, this is a press & release button, the first command is used when pressing the button and the second command is used when releasing the button.
Here is the proposal of new syntax:

Switch item=DemoSwitch mappings=[ ON:OFF="ON" ]

This could be used even with several buttons:

Switch item=DemoString mappings=[ UP:STOP="UP", DOWN:STOP="DOWN" ]

This extended syntax is fully backward compatible.

This is an easy solution to implement, first in the core framework with a small change in the sitemap syntax and finally in Basic UI to support the two different modes.

Edit: use ":" rather than "-" as separator as a command can be a negative number.

[lolodomo]

The feature is now available in Basic UI.
I will update the sitemap documentation.

@openhab/ios-maintainers @openhab/android-maintainers : any plan to add this feature in iOS and Android apps ?

[lolodomo]

I believe this feature request can now be closed.