My first widget - Shelly Plug

debacher · December 7, 2021, 5:52pm

Bildschirmfoto von 2021-12-08 18-51-22

I have tinkered with the following widget for some time.

The goal was to build a widget that makes the most important values and functions of my Shelly plugs usable and is as easy to use as possible.

Here you can already see a peculiarity. The LEDs of the ShellyPlug are on when xxxLEDoff is OFF. So I had a lot of trouble setting the corresponding toggle element to green when the corresponding element is OFF and red when it is On.

(Green means always on, red means off. So the WiFi LED is off and the power LED is on, at least when the power switch is in use).

Maybe, that you have to translate the item names for other languages then german.

Possibly someone can help me with two issues I need to work on:

On Android devices, the toggle element has a small bug. The white circle (the toggle) takes the color of the background (i.e. red or green) when ON. But this is also the case with the default widgets.
I am looking for a way to iterate through all the property fields, this would avoid the many repetitions and make the widget more universal.

The usage of the Widget is simple:

Screenshots

Bildschirmfoto_von_2021-12-06_13-24-37

Changelog

Version 0.1

initial release

Version 0.5

Runtime presentation optimized
added WiFi
some cleanup

Resources

uid: ud_shellyplug_grid
tags: []
props:
  parameters:
    - description: Überschrift (wenn leer, dann wird der Name des Schalters benutzt)
      label: Überschrift
      name: ueberschrift
      required: false
      type: TEXT
    - context: item
      description: Der Schalter (Shelly Plug)
      label: Item
      name: item
      required: true
      type: TEXT
  parameterGroups: []
timestamp: Dec 8, 2021, 6:19:50 PM
component: oh-list-card
config:
  title: '="Zustand von " + ((props.ueberschrift) ? props.ueberschrift : props.item)'
slots:
  default:
    - component: oh-toggle-item
      config:
        title: = "In Betrieb"
        item: = props.item + "_Betrieb"
        color: green
        style:
          --f7-toggle-inactive-color: "#e64a19"
        badgeColor: red
    - component: oh-toggle-item
      config:
        title: ="BetriebsLED aus"
        item: = props.item + "_BetriebsLEDaus"
        style:
          --f7-toggle-active-color: "#e64a19"
          --f7-toggle-inactive-color: "#4cd964"
    - component: oh-toggle-item
      config:
        title: ="Wi-Fi LED aus"
        item: = props.item + "_StatusLEDaus"
        style:
          --f7-toggle-active-color: "#e64a19"
          --f7-toggle-inactive-color: "#4cd964"
    - component: oh-list-item
      config:
        title: "Gerätetemperatur:"
        badge: =items[props.item + "_Geratetemperatur"].state
    - component: oh-list-item
      config:
        title: "Gesamtverbrauch:"
        badge: =items[props.item + "_Gesamtverbrauch"].state
    - component: oh-list-item
      config:
        title: "Läuft seit:"
        badge: =dayjs().subtract(Number.parseInt(items[props.item + "_Laufzeit"].state), 's' ).format('D.MM.YY HH:mm')
    - component: oh-list-item
      config:
        title: "Leistung:"
        badge: =items[props.item + "_Leistung"].state
    - component: oh-list-item
      config:
        title: "Signalstärke:"
        badge: =items[props.item + "_Signalstarke"].state
        badgeColor: '=(Number.parseInt(items[props.item + "_Signalstarke"].state) < 1 ) ? "red" : ((Number.parseInt(items[props.item + "_Signalstarke"].state) > 2) ? "green" : "yellow")'

rlkoshak · December 7, 2021, 6:15pm

Thank you for posting your widget. However, it is important that all posts made to the Add-on Marketplace category follow the template that is presented to you when you first create the post. Otherwise the UI is unable to properly parse and present the widget in MainUI.

First is the screenshot, then your description.

After the “## Screenshots” section, you can include additional screenshots. This section is opional.

Then there is a changelog section which is not optional. That’s how you communicate to the users that you’ve updated the widget.

Finally there is a “## Resources” section where you post the code or a link to the code.

Unfortunately I cannot help with the issues but I do know that the post itself needs to match the required format before adding the “published” tag.

debacher · December 7, 2021, 6:38pm

Thank you for your hints, I edited the post. Hope it is ok now.

rlkoshak · December 7, 2021, 6:40pm

Looks better now, though I don’t know what will happen to the text below the code. You might consider moving that up to before Screenshots.

JustinG · December 7, 2021, 9:04pm

In widgets the mechanism for iteration is the oh-repeater and there are several different options of series for it to use. In this case the most obvious would be the array input which you can then manually define. The caveat here, is that your various property list items are so minimal and variable in form, that it actually wouldn’t gain you that much compression or code clarity.

You could do it for Gerätetemperatur, Gesamtverbrauch, and Leistung with a little more ease because the array that you would iterate over is just those three strings:

- component: oh-repeater
  config:
    for: propteryName
    sourceType: array
    in:
      -Gerätetemperatur
      -Gesamtverbrauch
      -Leistung
  slots:
    default:
      - component: oh-list-item
        config:
          badge: =items[props.item + "_" + loop.propteryName].state
          title: =propteryName + ":"

Laufzeit is different enough that it remains apart. There are plenty of examples of widgets with repeaters on the forums if you’re interested in following up on this more.

As you point out, this isn’t so much a bug as it is the default behavior for the mobile rendering. However, if you wish to manually control the color of the toggle “dot” you can use the f7 css variable --f7-toggle-handle-color the same way you have used the others.

debacher · December 8, 2021, 8:49am

Thank you for your response.

The oh-repeater with array is a better way. But I hope to find a solution without extra array, because all needed Information is in the semantic model. It would be nicer to iterate through all linked channels of a Thing.

if you wish to manually control the color of the toggle “dot” you can use the f7 css variable --f7-toggle-handle-color the same way you have used the others

This variable has on Android devices only effect on the OFF state and not for the ON state I need it for.

rlkoshak · December 8, 2021, 2:26pm

Well, typically a Thing represents one Equipment. An Equipment is a Group. And the repeater lets you iterate over the members of a Group.

Channels, Things, and Links have no role to play in MainUI Widgets.

debacher · December 8, 2021, 4:20pm

Thank you very much, I got it. I did not think about a Thing as group!

rlkoshak · December 8, 2021, 4:37pm

Just to be clear because it sounds like you might have an incomplete understanding of OH concepts which might lead you down the wrong path at some point. I’ve bolded and capitalized all the terms of art in OH.

A Device is something external to openHAB that reports sensor readings or is controllable. This is your light or switch or thermometer or what have you.

A Binding is an add-on to openHAB that knows how to communicate with Devices of a given technology (e.g. Zwave, KNX, Nest API, etc.).

A Thing is how an individual device is represented in openHAB.

Each individual sensor reading or actuator control on a Device is represented with a Channel on a Thing.

Channels are Linked to Items.

Everything else in OH, including the semantic model works with Items.

Item <-> Link <-> Channel <-> Thing <-> Binding <-> Device

The semantic model is 100% implemented at the Item level. A location is a Group Item with a location Tag applied to it. All members of that location Group are considered to be at that location. Similarly, an equipment is a Group Item with an equipment Tag applied to it. All members of the Group are considered to be a part of that Equipment. Points are any type of Item that has a point and possibly a property Tag applied to it. Points will almost always be members of an equipment or a location Group Item.

Note that not all Items will be nor should they be a part of the semantic model.

When you choose to “Create Equipment from Thing” what is happening is that a new Group Item is being created and new point Items are created for each of the selected Channels and those Items are made a member of the equipment Group Item. If a location is selected the equipment Group Item is made a member of that Location Group Item.

It’s all Items. So you shouldn’t think of a Thing as a Group. However, you should think of an equipment as a Group because that is what it is. Why does this matter? It’s because any given equipment may have Items that are linked to multiple Things. For a simple example, let’s say you have a WiFi device. Most of the point Items might come from the one Thing that represents the device. However, you also might have a Network Binding Thing that pings the device periodically to verify it’s online. The Item Linked to that Channel would also be a member of that same equipment Group. You also might have Items that are not linked to any Channels in the model.

debacher · December 8, 2021, 5:41pm

Thank you, I have not found this information so clearly anywhere before, this helps me a lot.

BTW, I used your Information to write a little widget, which can display (but only display) any Thing with its items:

uid: ud_equipment_widget
tags: []
props:
  parameters:
    - description: Überschrift
      label: Überschrift
      name: ueberschrift
      required: false
      type: TEXT
    - context: item
      description: Das Equipment für die Anzeige
      label: equipment
      name: equipment
      required: true
      type: TEXT
  parameterGroups: []
timestamp: Dec 8, 2021, 5:12:27 PM
component: oh-list-card
config:
  title: '="Zustand von " + ((props.ueberschrift) ? props.ueberschrift : props.equipment)'
  content: =items[props.equipment].displayState || items[props.equipment].state
slots:
  default:
    - component: oh-repeater
      config:
        fragment: true
        for: element
        sourceType: itemsInGroup
        groupItem: = props.equipment
      slots:
        default:
          - component: oh-list-item
            config:
              title: =loop.element.name.split('_')[1]+":"
              item: = loop.element.name
              badge: =loop.element.state

This is a solution for my issue 2 from above.

Bildschirmfoto von 2021-12-08 19-11-57

JustinG · December 8, 2021, 6:35pm

Yes, I see that now. It appears the material design theme doesn’t take --f7-toggle-handle-color into account when the toggle is checked. I guess that comes from framework7 and not the UI. If it really bothers you, you can probably override the md theme using the stylesheet property in the root component of the widget (though you may have to use !important to actually override the theme).

rlkoshak · December 8, 2021, 6:43pm

It’s all covered in the Concepts section of the docs. The Semantic Model is all covered in the Semantic Model section of the Getting Started Tutorial.

It that what it really does? =items[props.thing] is referencing an Item, not a Thing. Things cannot be accessed from the UI. The only reason this works I suspect is because your Equipment Group Item happens to have the same name as your Thing. If it didn’t then your widget would not work. If your Equipment Group Item had members that came from Items linked to other Things, those would be shown too.

You are not working with the Thing here. You are working with a Group Item that happens to have the same name as one of your Things. This will not always be the case so you should change your thing property to make that clear. I’d call it “Equipment”, not “Thing” because at this level it really has nothing to do with the Thing.

That’s sort of the whole point I was trying to get across in my previous reply. It’s Items, not Things.

debacher · December 9, 2021, 8:38am

I missed equipment in the illustration.

Item ↔ Link ↔ Channel ↔ Thing ↔ Binding ↔ Device

Would that now be a correct assignment in the following image?

Updated Image

rlkoshak · December 9, 2021, 2:48pm

Assuming that box on the left represents the Equipment Group Item (i.e. four Items are in the equipment and one is not) then yes.

But I wouldn’t necessarily represent it like that because an Equipment Group is just a Group Item. It’s not something special. So in your widget above you could choose any Group Item: equipment tagged Items, location tagged Items, or Group Items that have no semantic tags what-so-ever.

Also, if one wanted to be complete, I’d make at least one of those Equipment Items link to a Channel on a different Thing. As I explained, an Equipment can have Points that are linked to more than one Thing. Similarly a Thing can have Channels linked to Items that are members of multiple different Equipment.

Trickx · December 17, 2021, 10:39am

I would like to get this widget to work with my Shellies but struggle to understand how to configure it. Which naming conventions do I need to follow? Some configuration screenshots would be of help.

debacher · December 17, 2021, 1:02pm

You can find the configuration screenshot in my first post, just select the Shelly.
If your language is different from German you may need to use the correct label for the Points like:

_Geratetemperatur

_Gesamtverbrauch

…

JoachimS-source · January 1, 2022, 8:18pm

will this work with tasmota firmeware?

debacher · January 5, 2022, 2:38pm

I think not