[Solved] Actions in custom widgets - update item


today I’m trying to replace a slider with two buttons in an OH3 custom widget…

The volume item is persisted and I can get the actual state, but how do I tell the item to increase/decrease without the slider?
and what would the syntax for that look like?

this is the slider item I’m trying to replace:

- component: f7-col
                - component: oh-slider-card
                    fontSize: -6
                    item: =props.prefix+items[props.selected].state+props.volume
                    action: options
                    actionItem: =props.prefix+items[props.selected].state+props.volume
                    actionFeedback: =items[props.prefix+items[props.selected].state+props.volume].state

what I got so far are these two buttons:

- component: oh-button
                    bgColor: black
                    text: "-"
                    actionitem: =props.prefix+items[props.selected].state+props.volume
                    action: command
- component: oh-button
                    bgColor: black
                    text: "+"
                    actionitem: =props.prefix+items[props.selected].state+props.volume
                    action: command

but I’ve no idea how to build that actionCommand… I don’t even know if there’s any ability for doing it this way…

I had a look at the User Interface Design Overview but this doesn’t seem to cover my question.

are there more sites to have a look at?

would be great to get this working…

It just wants to be a string suitable for commanding your Item with, like ON for a switch.

This widget has examples of indirectly providing that string

thanks rossko57,

but this is a volume item, and I dont understand how to tell the actionCommand to get the actual volume, add or subtract 1 percent, and send this command back to the item…

I think the according channel ony accepts numbers, not +1 or -1

the slider does this “automatically” but I dont know how to acchive this behavior from a button…

Your volume channel may accept INCREASE and DECREASE commands, in which case you won’t have to dynamically define anything. If the channel does not, or you want increments that are a different size than the binding defined increases and decreases, then you’ll need to use an expression to build the numerical command.

To build the command you only need to remember one important thing: the state that’s returned from the items object is a string not a number (so you can’t do math until you fix that).

As far as I understand from your code


builds a string of the actual name of the volume item, so to get the state of that item you just need


but this is still a string, so you can’t add anything to it yet. So, you use the js Number() object to convert that state string to a number. There are a couple of different ways to do this, and I don’t know the details of your item but I suspect the easiest will be to use the parseInt method:


Now you’re ready to put it all together with the actual math in the widget:

actionCommand: =Number.parseInt(items[props.prefix+items[props.selected].state+props.volume].state) + 1
1 Like

thanks a ton for your detailed info :wink:

I think I understood mostly what you wrote…

unfortunately this is not working with the squeeze binding

yes you’re right…

what I don’t get is this “js Number() object” thing…

how do I manipulate this “number” after converting?

can I do something like:

actionCommand: =(Number.parseInt(items[props.prefix+items[props.selected].state+props.volume].state)+1)

parseInt returns an object that the expression parser recognizes as a number suitable for whatever further math you wish to do. For example:

12 + 1

the parser understand as simple math and returns 13. However if one of the inputs is a string:

"12" + 1

the parses interprets it as a command to concatenate the strings and returns "121". So if you have a string that represents a number (such as from a call to items[some_item_name].state) then you have to turn that string into a number to get back to something the parser understands as a math command:

Number.parseInt("12") + 1

Now the parser first convertes "12" into 12 and now it looks just like the original form and it knows you want to do math and not concatenation and so returns 13.

Yep, your example is equivalent to the final example in my post; you just don’t need the extra (...) around the whole expression, but they don’t hurt.

1 Like

thanks again, I’ll give it a try :wink:

Ok now it gets a little weird…

I initially opened this thread because my approach to use the DECREASE INCREASE commands for the buttons was not working.

After trying @JustinG suggestions without luck I had a look at my item’s definition and it’s not a NUMBER or STRING type - no, its actually a DIMMER…

Now I tried to write a test rule which executes:


and this works unfortunately… I tried to change back to my previous approach with DECREASE INCREASE but this is still not working in yaml… I tried different things:

actionCommand: DECREASE

actionCommand: “DECREASE”

actionCommand: ‘DECREASE’

and even tried to add a props item with DECREASE and linked it with

actionCommand: =props.volumedown

but nothing changes - still not working - any ideas?

openHAB Items of type Dimmer accept commands INCREASE/DECREASE. But not all of the devices that might be linkd to a Dimmer Item actually respond or do anything with commands like that. It’s up to your binding/device whether they have any effect.

If you look in your events.log, you should be able to see commands arriving from your UI, whether they get actioned or not.

yes itemtype is DIMMER like its defined from the Binding but DSL rule does work and yaml code not that’s a little weird for me to understand

Ok opened putty to access the log…

my test rule is logged

changing the slider is logged

pushing increase or decrease button does nothing at all

I have to think about it tomorrow… its late should go to bed

Slider yaml

Button yaml

i/I ?


:see_no_evil: omg
yes you’re right - shame on me I change that and give it another try

finally it was the typo :see_no_evil: my bad

now everything is looking good - tried both and both working
but like @JustinG mentioned the DECREASE INCREASE uses bigger steps in my case …so I stick with the conversion and math approach

thanks a ton to you guys! and sorry for the typo :weary: