[Main UI] Widgets to include in the standard library

[ghys]

Let's discuss some ideas of additional built-in (standalone) widgets to include in the UI for layout pages. The library will also include some "list item" widgets, to discuss separately.

As a reminder it's not in the plans currently to let users inject their own Javascript code (including libraries) so we have to take into account what we want to offer. Webpack's code splitting allows to split heavy dependencies into separate chunks loaded on-demand so we should leverage that as much as possible - but still consider the impact of these libs in the UI bundle size. Also remember that the whole app is prefetched when on HTTPS for caching purposes (once it's completely cached a PWA "add to home screen/desktop" button appears).

Gauges

• [ ] Framework7 has a gauge component which may be enough in most cases. https://framework7.io/vue/gauge.html - note that it can already be used in a custom widget without a dedicated widget, using expressions.

Other alternatives:

• [ ] Canvas-Gauges: https://canvas-gauges.com/documentation/examples/ Bundle size: 42.4kB minified, 12.9kB minified+gzipped (source)

• [ ] Steel series: https://nicolas-van.github.io/steelseries/ Bundle size: 733kB minified, 100.8kB minified+gzipped (!) (source) (big, but this is the whole library, we can include only the components we need)

None of these are interactive but they cover a lot of potential usage - thermometers, compasses (for wind direction?), general-purpose gauges. Note that ECharts, the library used for charting in the app, also has a decent gauge chart type (https://echarts.apache.org/examples/en/index.html#chart-type-gauge) but the gauge chart type is not included at the moment. Also worth mentioning is https://github.com/ecomfe/echarts-liquidfill which can be included to nicely visualize tank fill levels etc.

Thermostat

• [ ] Nest thermostat clone: https://www.svidget.io/examples/nestthermostat (Maybe a little too blatant. Obviously we would change it a little and drop the Nest logo) I haven't found any other good alternatives to this one yet.

Image

• [ ] We could use this lazy load feature to load images on demand, then open one of more images in a nice looking photo browser. There's still a long-standing problem of how to proxy images when accessing openHAB remotely (the current proxy servlet is tailored for sitemaps, and allowing it to proxy any item is a security vulnerability). We should also consider a proxy for video feeds. The photo browser could maybe also be opened as a widget action ?

IFrame (Web view)

• [ ] Pretty self-explanatory.

Buttons

• [x] The "label" widget can already act as a button, when an action is configured. It should perhaps be made easier to change the colors/icon/label based on the state of an item.

• [ ] easy-to-configure segmented buttons and other types of regular buttons (https://framework7.io/docs/button.html#examples)

Numpad

• [ ] can be used to enter PIN codes to unlock alarms and locks, especially useful on mobile.

Color picker

• [ ] the current color picker control should be extended to only display the current color and open the color picker in a popup.

Those are the ones I can think of at the moment, other more esoteric types may be developed as custom widgets by the community. Eventually there would be a gallery or another easy sharing mechanism like in HABPanel.

[digitaldan]

@ghys, good discussion for sure. I was hoping you would bring this up soon :-)

To be clear , this would be all the widgets listed in the "standard library" on the page designer?

Gauges

I'm kinda ok with the f7 ones. It matches the look and feel of the app and if it can be interactive, that would be awesome. I also found https://hellocomet.github.io/vue-svg-gauge/ , not sure what advantage this has over standard f7 gauges.

Also, what does Habpanel use ?

Thermostat

While i know we have stayed away from modeling specific 'things' in the gui previously, i feel like having a thermostat widget is really useful, so i am very much in favor of this. To your point, not a lot of options out there. Maybe we create our own based on the Gauge library we choose, the nest example seems not be really more than just a dressed up gauge anyways.

Image

For starters, having a simple widget type with refresh (ala habpanel or sitemaps) i think is enough. I think the main use case are web cam snapshots.

Buttons

The more we can add options here the better, i feel like this is probably the most used widget type. So i am very ok going wild here and giving the user a dedicated button type with lots of options.

Numpad

Personally i use a custom widget in HABPanel, so i would get a lot of use using a built in one.

Color picker

Yep, its an important one I think as our previous UI's have had specific color widgets.

As a reminder it's not in the plans currently to let users inject their own Javascript code (including libraries)

How do custom widgets work then? I have not tried using that yet in the UI. is this similar to habpanel? And is this a security issue primarily?

As soon as https://github.com/openhab/openhab-core/pull/1451 gets meregd, i will probably start looking at using OH3 as my primary server, once this happens I'm sure changes to the widget library will come up frequently.

[ghys]

How do custom widgets work then? I have not tried using that yet in the UI. is this similar to habpanel? And is this a security issue primarily?

It has similarities with HABPanel (hierarchical structure + config properties a.k.a "props") except instead of a HTML template you have to define it in YAML, expressions are allowed in most if not all config parameters making dynamic things possible. You can use f7 components, like f7-card, or components from the "system" library (controls not wrapped in a card, like oh-slider, but they are not documented). You can also use the standard Vue attributes like class and style and also visible/visibleTo to hide things based on the user's role or an item state. You can still do a lot, on https://tiny.cc/ohdemo you have a few examples of custom widgets, like the gauge expanding to a slider in a translucent card, the weather forecast or a popover gauge. Their YAML "code" is accessible in the developer tools if you login (demo:demo). You also get a minimal example when you create a new widget.

I know writing these YAML structures is not going to be appealing to everybody, compiling Vue templates at runtime is possible was considered as an alternative but you have to include the full build (https://vuejs.org/v2/guide/installation.html#Runtime-Compiler-vs-Runtime-only) which is 30% heavier, not sure I want to do that. Besides serializing HTML it in JSON is ugly - see HABpanel's widgets.

And is this a security issue primarily?

It's a factor but the problem of caching/bundling assets into a self-sufficient app e.g. Cordova was an even bigger one (and I admit I don't know how to inject code at runtime in an app bundled with webpack).

[digitaldan]

Makes sense, there does not seem to be an easy solution (there never is !).

What is your opinion on the state of current widget set? I'm not sure if its at a state where you want feedback, requests, PRs, etc..? I don't want to start flooding you with github issues if it's not what you want to focus on right now. For the record , the current widget set looks great, i probably only have a few requests, and of course there's work on getting everything wired up i think to the rest api.

Should we/I start opening issues up for these types of things?

Also , do you have a TODO list or roadmap of work you are planning on doing overall? Was thinking it might help others know what's considered fished and what still is being planned to work on.

[digitaldan]

Also i was going back through your list, and i think i have mixed up buttons vs toggles vs labels as a switch.

Labels as a switch is what i was thinking about as a button ( but not what f7 thinks as a button, or toggle) .

Label as a widget type is probably a little confusing to users as it does more then display text, but i'm not sure how you message that different.

[ghys]

Also , do you have a TODO list or roadmap of work you are planning on doing overall?

Yes, it's slowly clearing up but I still have a clear short-to-mid-term path in my mind, mostly focused on expanding the widget infrastructure itself first.

First you may have noticed there's a notion of a default "standalone" representation for an item - it's used on the model page, item details page and others - which you can alter on a per-item basis using metadata. You should be able to easily add it to a page, just by selecting the item, it's often more natural than selecting the type of widget first then configuring it with your item(s). It would only make a "copy" of the item's default widget so you would be able to further customize it after it's been added.

I also intend to introduce the same but for items when presented as part of a list. You would also have options to influence the position in the list and whether or not the item should be displayed or not when encountered. This will unlock several interesting use cases, that would probably be implemented in the process: generated detail pages/popups/cards/whatever about a group and its members, HABot answer cards, semantics cards on the home page, and so on.

When all that's done, the focus would be to improve the library itself (having a consistent nomenclature, sharing more code, adding new widgets and options). But of course we can still discuss these improvements in the meantime, in fact that was the point of opening this very issue early on.

Labels as a switch is what i was thinking about as a button ( but not what f7 thinks as a button, or toggle). Label as a widget type is probably a little confusing to users as it does more then display text,

Yes buttons would look like

or maybe also like this:

It would be useful to have colored easy identifiable buttons to launch scenes etc.

Right now I use labels for that which just happen to be clickable (not the final design though!).

You can have a combination of all these and choose what works best for you.

[digitaldan]

When all that's done, the focus would be to improve the library itself

Super impressive, let me know if i can do anything to help.

The colored buttons look very nice for things like scenes, very cool. Regarding the last image, what widgets are those, are they actually displaying charted data, or is that a static background image? Was curious about how to represent a chart in a widget.

[ghys]

The label widgets can display the trend of the last 24 hours, that's an undocumented option :) (trendItem). They also display by default on item pages and the model for number items with a dimension set.

component: oh-label-card
config:
  title: Power
  item: ElectricityMeter_Power
  trendItem: ElectricityMeter_Power
  action: analyzer
  actionAnalyzerItems:
    - ElectricityMeter_Power
    - Computer_Power
  actionAnalyzerChartType: month
  actionAnalyzerCoordSystem: time

[digitaldan]

that's an undocumented option :)

very nice!

[bobadair]

Hi. Maybe I’m missing something, but I don’t see any examples of sliders. Horizontal and vertical sliders, with and without labels, tick marks, raise/lower buttons, value display, etc. are obviously important for items like dimmers, volume controls, shade/blind positions, awning positions, etc.

[digitaldan]

@bobadair are you running your own 3.0 dev build of openHAB ?

[bobadair]

Not yet. I'm running 2.5.4 in production and still have my dev environment set up for 2.5.x for binding development. I just meant that I didn't see any mention of slider widgets in the discussion in this issue.

[digitaldan]

Gotcha, sliders are already part of the 3.0 UI, so i assumed they were mostly covered, but you are right , it's probably worth discussing if there are any needs beyond what is there. For reference , here is an example of what we have today:

and options that can be set:

[ghys]

Hi. Maybe I’m missing something, but I don’t see any examples of sliders.

Yes this thread was originally about widgets that are completely missing or lacking in functionality, sliders are already there so I didn't mention them.

and options that can be set:

Note that if you configure the widget in YAML you're be able to pass most options accepted by the Framework7 range slider component. As a general principle it's mostly true for any widget based on a Framework7 component. You only have to convert the option from "kebab-case" to "camelCase". For example you can add scaleSteps: 10, color: "=(+items.Item1.state > 60) ? 'red' : 'blue'" or limitKnobPosition: "=device.iphone || device.ipad" under config: even if it's not a documented option. Some options will not work out-of-the-box of course because they require some custom wiring, for instance dual expects value to be a 2-element array, it's not supported so it won't work; neither will formatLabel because it expects a JS function.

[bobadair]

Ah, that makes sense. Thanks for the info, @ghys and @digitaldan! It looks really good so far. I'm looking forward to getting a version of 3.0 running on a dev system soon. I'm by no means a UI design or usability person, but to me the slider options, while basic, look pretty decent already.

[digitaldan]

@ghys I also found this interactive f7 gauge/knob, might be useful for a thermostat widget https://github.com/kramer99/vue-knob-control

[ghys]

Interesting, thanks! It seems to integrate nicely visually with the general look & feel and in fact looks very similar to https://framework7.io/docs/gauge.html with additional options (the interactivity is the killer feature). I plan to change the widget description API a little bit before adding new ones, but it looks like a good candidate for inclusion.

[ghys]

Added the knob as a system control (#288), no card wrapper for it yet, and it's definitely a keeper.

I like the style of the grid of buttons in the new Android 11 power menu - in the "Home" section here:

.

Could definitely be a good thing to have something like this too.

[digitaldan]

288 looks great! Thats a very nice feature for sure, i will use them quite a bit in my UI's

I like the grid layout as well in Android 11, very clean and modern.

[ghys]

In fact it would actually be quite cool to have the grid layout on par with the list layout, that is:

• a series of grid widgets (oh-*-grid) for different cases (basic button, switch, dimmer, media player, color, rollershutter...)
• a "default grid representation" logic for an item
• a way to override that logic with metadata (gridWidget namespace)
• an ability to display group members in a grid instead of a list - would look a little bit like Apple Home:

[digitaldan]

That would be awesome for sure! Fwiw ,from a stylistic pov, i like the Android grid with rectangular widgets over Apple's squares, i feel like they just copied their home screen layout and always felt dated to me, which is why i never use it.

Besides a default presentation, how would users add a "grid" to a view? would it be a new page type? New grid/layout widget (like a list widget)? Layout option in a page (like block, masonry, grid) ?

[ghys]

i like the Android grid with rectangular widgets over Apple's squares

yes I think it' good to mimic things when they're good but openHAB should have its own style as well ;)

Besides a default presentation, how would users add a "grid" to a view? would it be a new page type? New grid/layout widget (like a list widget)? Layout option in a page (like block, masonry, grid) ?

Definitely not a new page type - a "grid container" would do nicely I think, to add on an existing block column or masonry. It's true that adding a full-width column to a block involves too many clicks/taps currently, we ougtha change that.

[andrewfg]

For the thermostat, have a look at the HeatMiser App; a thermostat needs four elements:

• Actual temperature (on the dial)
• Target temperature (both on the dial and numerically in the middle)
• Icon showing heating, cooling, or off (underneath the dial)
• Up/Down roller or buttons to change the Target temperature

[andrewfg]

[dacchio]

Hello, I don't know if it's the right place to ask...or if it's been already implemented (I did not find it in my OH3 test environment) Do you think could be possible/useful to provide an "input" widget, in order to set a string item (maybe with different types: string, date or time ).

I give you an example of my use case: I have (in OH 2.5) several string items I use to store the time a specific action should run, this way we (ie my wife) can easely change those actions time schedule via basic UI or habpanel.
In habpanel I have a custom widget with a form with an input element and a save button sending the value to the string item. In basicUI I have a Webview with a similar form.

Example in habpanel - Rollershutters auto open time:

Thank you

[rgrollfitz]

The label widgets can display the trend of the last 24 hours, that's an undocumented option :) (trendItem). They also display by default on item pages and the model for number items with a dimension set.

Would be nice to have this custom trend-component without any elements around it (something like oh-trend?!) - so it would be easier implementing this into custom widgets.

IMHO it would be overall a valueable thing, if there would exist custom oh-components without any elements around it. Theres no easy way (without a lot css-fiddling) to integrate some of the list elements or most of the standard oh-components into custom made widgets with mostly f7 base-components. But don´t get me wrong here - its also valueable to have these ready-to-use components for a quick-start and new users.

The oh-image is a good example (just a plain image which is accepting styles and could be integrated almost everywhere) - sadly this component doesnt support actionCommands atm, as far as I know.

Further more I definitely +1 the integration of an oh-input element (The scope of the standard f7-input-component looks allready sufficent to me)

[ghys]

@rgrollfitz I made oh-trend and oh-icon available yesterday as part of #317, also you can now use expressions inside objects like style (at last!). I'll try coming up with solutions for some of your other points soon, including having a basic variable system so components like oh-input can exist.

[rgrollfitz]

@rgrollfitz I made oh-trend and oh-icon available yesterday as part of #317, also you can now use expressions inside objects like style (at last!). I'll try coming up with solutions for some of your other points soon, including having a basic variable system so components like oh-input can exist.

Awesome, thank you! Played around with oh-icon and oh-trend last night and tried to understand the code you pushed and extracting the respective options for the widgets.

This is my non-techy understanding of what the options and limitations are - please correct me, if Im wrong.

• oh-icon is the answer to the f7-icon component, which allows to access the pre-existing as well as the own iconset - excluding the f7 ones obviously. Current available options are width & height - the component itself dont accept styles and actions atm, correct? So if you want to use an icon as a clickable link, this isnt possible out-of-the-box besides positioning e.g. an oh-button component over it (positioning icons inside of buttons is not possible right now due to missing slots)

• oh-trend and the respective options are (mostly) sufficent IMHO -- so you can even fiddling around to get the strokeOpacity from the documentation with rgba gradient-values. But there seems to be a limitation implementing it as a (custom made) card-background due to its restriction, accepting css-styles like absolute-positioning (there might be some css/svg limitations that I´m not aware of)

Thanks a lot for your hard work!

[ghys]

@rgrollfitz thanks for the feedback, it helps.

I addressed it and included the fixes in #356.

Here's a oh-icon with styling and action (which you can now take from a prop parameter group with an action context -- just set actionPropsParameterGroup to the name of the parameter group which will host the action props):

and here's a oh-trend with styling, if you put it at the same level and before f7-card-content below f7-card it seems to cover the whole card:

[LukasA83]

Is there currently any way to get a MJPEG stream by using a standard widget or a custom for a camera? I'm struggling to get it set up. In basicui we had "video" as an element which did the job.

[yfre]

i would vote for QR code widget, client/browser based generated. use cases:

• QR code to pair Homekit (could be place in Homekit settting screen)
• QR codes with direct URLs to pages

[mstormi]

I believe we need time and date input widgets. There's no such thing in OH to the best of my knowledge, and a quick scan of open issues didn't reveal any development activity either so I thought this is the right place to ask.

There's quite some people trying to compensate for the lack of such a widget in one way or another with rules or YAML-JS, I've also seen you @ghys post some example to trigger the Android built-in clock and calendar input widgets, but it's all far from being plug'n'play, and I keep seeing requests for this every some days.

I'd think we should have some time input first that users can directly map to a Number:Time item/channel and a date input widget to map to a DateTime item (optional to include time of the day, too).

[Some day maybe a timeline picker, too but yes I see the complexity in this one as it would need to allow for a varying number of "on" and "off" intervals (or even more than 2 states). But that would be pretty useful for all sorts of time based activities such as heating plans. ] EDIT: See https://community.openhab.org/t/timeline-picker-to-setup-heating-light-and-so-on/55564/555 some JS based work there

That'll also avoid a lot of work and mistakes on user side to happen with parsing and converting.

[florian-h05]

@ghys Can we close this?