[mqtt.homeassistant] Add support for Button component

[ccutrer]

No description provided.

[antroids]

Probably org.openhab.binding.mqtt.generic.values.TextValue is a better option for stateless channel with a single command.

[ccutrer]

I don't have a strong preference either way. There is definitely an impact to it. For the following items:

Switch NorthGate_Restart "Restart North Gate" { channel="mqtt:homeassistant_083af268005c:mosquitto:083af268005c:083af268005c_2Dbutton_2Dba0e8e32#button" }
String HeatPUmp_ClearErrors "Clear Errors" { channel="mqtt:homie300:mosquitto:aurora-180501914:faults#clear_2Dhistory" }

Both of them have a command description reflecting a single viable choice. The former is a Switch from a Home Assistant Button, with this PR. The latter is a String, coming from a Homie property of Enum type with a single option.

With the following sitemap:

sitemap test label="Test" {
  Switch item=NorthGate_Restart
  Switch item=HeatPUmp_ClearErrors
}

They show up in the iOS app like this:

And in a Web Browser like this:

If I change the widget type to Default, they show up the same in both places. I'm a little surprised the iOS app doesn't do better. My ideal for both would be a single push button that's already labeled with no extra work.

From MainUI, when going to look at the Item, they look like this:

Notice that the Switch item is immediately operable, but the String item is not. I don't use pages built from MainUI, so can't compare a basic usage from there. So at this point, a String item is slightly preferred when using BasicUI in a browser, and Switch item is slightly preferred for viewing the item directly in MainUI. My one pushback to a string item is that when using it from rules, you have to actually go figure out what value it is you're supposed to send, instead of implicitly knowing it's ON. I do agree that semantically a String item makes more sense, since there's no expectation that its possible states/commands will be ON and OFF (the latter not making sense), whereas a String you're aware it could be anything, so aren't surprised with it being limited to a single value. One thing I need to work on (and plan to do as a separate PR) is to set an auto update policy of VETO so that the item doesn't actually change states, and UIs won't reflect it's in that state. Buttons are intended to be able to be pressed multiple times, and are stateless. And regardless of all this, it's possible for the UIs to improve and better handle when an item has a command description with a single option, as well as MainUI displaying command descriptions. So I lean towards your argument that a String item is better, since its a better fit for the model semantically.

@jlaur, @lolodomo: do you guys want to weigh in?

[antroids]

LGTM, thanks!
Now we have the both versions 👍

[lolodomo]

LGTM, thank you