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.