I recently opened an issue on Github with a feature request. It would be nice to hear other people’s ideas around this. Like, is this something you would want as well? If you do want this, and The general way (more about this below) is implemented, what would you use it for? Are there actual problems with this that prevent it, or that need to be solved before an implementation could be made? Do you have a better idea to achieve the same thing? Any developers who would like to attempt to implement this? Anyway, I’ll just copy the github issue text below, and please chime in with any opinion or idea you might have:
It’s pretty common for home automation software to have items for e.g. dimmable lights that combine functionality into the same element in a way that openHAB does not. Both Fiabaro Home Center, Z-Way, ImperiHome and Vera have elements that combine dimmer level (e.g. a slider) with an ON/OFF switch. (I understand that WebUI has this, but that it isn’t really a ON/OFF switch, so much as a shortcut for 0 and 100 on the slider.)
In an openHAB sitemap, this has to be two separate elements, each with their own control and their own label, taking up twice the UI real estate and making the interface slightly awkward.
I see two ways of going about it if there is an interest in implementing something like this:
1: The specific way: This is probably mostly going to be used for adjustable lights (and often in this case, both controls link to the same item). Today many people have a Dimmer item for the light, and a Slider element and a Switch element referring to the same Dimmer item. The specific way, would be to create a kind of SliderSwitch element that incorporated both of these controls into the same element.
Example sitemap code:
SliderSwitch item=FF_Hallway_Light_Dimmer
Such an element could be rendered like this, in Basic UI:
2: The general way: Maybe someone wants something like a SliderSwitch element, but the Slider part and the Switch part can’t refer to the same item. Or maybe someone wants to combine other controls, like Selection and Setpoint, for example. The general way would be to create something syntactically like a block element. But instead of the element rendering as a link to a new view with the contained elements, it would incorporate the controls of the elements within the curly braces into the parent element.
Example sitemap code:
Compound label="Thermostat" icon="temperature" {
Selection item=FF_Bedroom_Thermostat_Mode
Setpoint item=FF_Bedroom_Thermostat_Setpoint
}
The general way brings a lot more possibilities to the table, but there is one thing that would need to be worked out: namely the Compound element’s stateformat, like in label="Some label [%d %%]"
. There are a few possibilities here. One is to say that stateformat isn’t supported for Compound elements. Another is to say that it is supported in unambiguous cases – like if both subelements are linking to the same item, or only one of them supports the format type selected. A third is to say that ambiguous (or all) cases need some determined qualifier to clarify which subelement’s value is being displayed, for example as a separate parameter to the Compound element.
I would personally prefer The general way, with the latter stateformat solution, but it would also be very nice with The specific way. (Also, they are not mutually exclusive, of course, so it’s quite possible to go for The specific way short term and The general way long term, if need be.)