Best Practice for creating user friendly Widget

Development Misc
, ,
1

I have been thinking about best practice for developing a widget and the fast way to implement good code with the least amount of effort from the user.

Looking at the already awesome UI Widget: Weather

I decided to try it. I installed binding then thing… easy.
Next I went to Model / Create Equipment From Thing / Select ALL and create thing
You can get to this stage in a couple of min with every item created for you.

image

Lets take one item into consideration

image
image745×323 9.71 KB

This Item Localweatherandforecast_ApparentTemperature Current outside temp
Is not the same needed for the widget Number localCurrentApparentTemperature "[%.0f°]"

You can’t change the item name once created in mainUI.

Note: This is not a complaint

Creating items this way puts them all under a group.

image
Localweatherandforecast

If you set a widget as the default widget the item props is auto populated to this value.

uid: fancyWeather
tags:
  - weather
props:
  parameters:
    - description: "<b>Optional prefix</b> for item names.<br>More infos here: <a>https://community.openhab.org/t/ui-widget-weather/106842</a>"
      label: Item prefix
      name: itemPrefix
      required: false
      type: TEXT
      groupName: general

If the name: itemPrefix is changed to name: item then item would be Localweatherandforecast

Then you can assign each item using the auto generated item which will always have a Prefix

 =items[props.item + "_ApparentTemperature"].displayState || items[props.item + "_ApparentTemperature"].state

This is very helpful if you have multiple things of the same type.

Others have suggested the same thing and RGroll has done a fantastic job. I apologise that I encountered this on his example widget.

I think when selecting the Widget as the Default widget I can auto populate the data here.

image
image1636×832 49.3 KB

I think this may lead to less questions about how to setup widgets and more fun time for all.

Please discuss feedback is welcome as is other ideas to standardise widgets.

1 Like
2

Hey @denominator

thanks for your response and no worries about using my widgets as an example of how things could be optimized - that’s how things evolve :slight_smile:. I’ve to say that I never used the UI to create things/items, so I does not had that in mind while creating the widgets tbh.

But you brought up a totally fair point here and it should be as easy as possible, to use (and set-up) these custom widgets. So let me summarize this, to be sure that I understand your request:

  • The automatic created items (via ‘Model’ / ‘Create Equipment from thing’) follows a pattern based on the name of the thing you created (with all spaces removed) combined with a (partly localized?!) naming of what this item is about (EN: ApparentTemperature | DE: GefuhlteTemperatur) - divided by an underscore. (ThingName_LocalizedItemName)
    • So what you have in mind (if I understand everything correct) is to shorten the pre-defined naming (which currently consists of a custom namingPattern) to only the item-name part of the above mentioned model-pattern (without the thing-prefix), correct?!

For people that uses the english language in their setup your suggestion might match and they only have to define their custom thing name as a prefix in the widget and they’re good to go. (which is of course a benefit)

For everyone else, where the suggested item-naming is localized and does not match that 2nd part of the pattern, it’s still some manual work to change all the item-names to the english item-naming within the creation process (as it does not seem possible to do this later on, as you said) and have to set the thing prefix in the widget afterwards.

After digging a bit deeper in the the UI-side of things I recognized that the custom naming is even more complex (at least in the OWM-binding). The localized item-namings only get applied on things which…

  1. the system can recognize (which makes sense :stuck_out_tongue:)
  2. only on some (the first?) of the namings that it founds - it does not apply for the same value type on a different time-period.

Even the english naming seems to be different for the second case, where everything is lowercase. (which would mess up the logic that you mentioned, as this would force even people with an english setup to align the item-naming in these cases)

Additionally the item naming pattern gets an additional item parameter if there are multiple items that matches the same information but for a different time-period (which isn’t that big of a deal, as it could considered easily while developing the widget), e.g.

Number:Temperature   Wetterinformationen_GefuhlteTemperatur                   "Gefühlte Temperatur"                   <Temperature> (Wetterinformationen) ["Point"]  { channel="openweathermap:weather-and-forecast:api:WeatherID:current#apparent-temperature" } 
Number:Temperature   Wetterinformationen_forecastHours03_apparenttemperature  "Vorhergesagte Gefühlte Temperatur"     <Temperature> (Wetterinformationen) ["Point"]  { channel="openweathermap:weather-and-forecast:api:WeatherID:forecastHours03#apparent-temperature" }
Number:Temperature   Wetterinformationen_forecastToday_apparenttemperature    "Vorhergesagte Gefühlte Temperatur"     <Temperature> (Wetterinformationen) ["Point"]  { channel="openweathermap:weather-and-forecast:api:WeatherID:forecastToday#apparent-temperature" }

To summ it all up: I’m not sure if this would bring a huge benefit, with all that differencies in the naming pattern (which does not look 100% consistent to me)… :smiley:

Wouldn’t it be possible to just use the ‘Expert mode’ in the ‘Create Equipment from Thing’, where you can just paste all the items following the pattern that comes with the widget? As I understand this - it would also link all items to their respective channels then?

image
image728×225 8.39 KB

What I definitely take with me here is, that I should take the full item configuration (with its ‘tags’, ‘groups’ and ‘icons’) into consideration and attach those to the widget I publish.

3

Thankyou for taking the time to respond in such a detailed post. You bring up a lot of points I didn’t even consider.

yes this is what I have done for my Aircon Widget as I have multiple aircons. (current local time is 6:30am and 24°C outside)
I guess it is dependant on which binding and language you use.

Using OWM as example is good because most users will have weather in their setup. If the two things are created for two different locations you can quickly have hundreds of items.

This looks to be true for the OWM binding in the way that I created the items. If its not consistent it will just add complicities that are not needed.

TBH I did not click on this until I read your post. To me this method is acceptable I just didn’t know about it. Sometime it needs to be right in my face to see it.

I defiantly learned from your widget and have a couple of lines in my cheat sheet to use.

1 Like