[MQTT/Homie] Volume Control item (Setpoint / Dimmer) in OH3 - multiple issues/questions

OpenHAB 3.2.0M5 arm64 docker on arm64 Pi4 RaspiOS Bullseye

Howdy! Still trying to get the very basics down in OH3, it’s fighting me every. step. of. the. way.

So, I have a Homie device that controls a preamp. The volume property controls a large sound system.

The homie property is defined like so:

homie/aerohome/outputs-spk-spk-main/volume/$name Volume
homie/aerohome/outputs-spk-spk-main/volume/$settable true
homie/aerohome/outputs-spk-spk-main/volume/$retained true
homie/aerohome/outputs-spk-spk-main/volume/$datatype integer
homie/aerohome/outputs-spk-spk-main/volume/$format 0:100
homie/aerohome/outputs-spk-spk-main/volume 26

In OH2.5, I would have used PaperUI to link an item to this parameter in the Thing, and then added the following statement into the sitemap:

Setpoint item=Workstation_Volume icon="soundvolume" minValue=0 maxValue=100 step=5

Now, the reason I used Setpoint instead of a Dimmer is that dimmers immediately jump to the value you click on, without warning so if you accidentally touch it near 100 you and people around you may all have to change pants. This is bad enough for a smart speaker but with a proper stereo system it is really not fit for use.

In OH3, I tried adding a “Number” item, but then when I try to interact with it, all I get is a Graph! (Analyze)

I tried making it a Dimmer item, then I get a slider, but when adjust it, the slider outputs values between 0 and 1 (decimal values get posted to the /set topic) despite the Homie property clearly stating the range is 0:100. This of course just results in the audio completely muting. Better than getting blasted out of your chair, sure, but still not really usable.

So… How do I do it? What’s a good way of representing a volume control on a Page?
I think I would prefer a setpoint item like you use for adjusting temperature – step size 5 or even 10 does the job nicely.

By the way, I found this topic about setpoints in openhab 3 but I don’t have a grasp of metadata and cards yet so I did not understand the solution.

Besides, in the spirit of “getting day-to-day users out of the business of needing to write rules for every little thing” (@rlkoshak) I would think that the Item range should follow what the Homie property dictates, without having to do textual configuration somewhere… (yes, rules are not metadata, but I think it correlates with the intent, if not with the letter). I will of course do the text configuration to get it to work as long as someone clues me in, just a possible enhancement for the future.

Now, here’s a pipe dream.
I write audio processing software for a living.
I solved the on-screen volume control problem in my own user interface ten years ago.

Here’s how I did it.


You press down anywhere on the slider. It depresses but does not change the value.
Then you move left or right while holding your finger down. The slider follows your movement in an accelerated/decelerated fashion depending on your speed of movement, and it follows you as you go outside the physical boundaries of the slider on the screen, as long as you don’t let go. This way you can set an absolutely accurate value, and it never jumps to an unintended value. It works equally well with a finger on a touch screen as it does with a mouse.

Finally, when you do let go, you’ve probably noticed how the act of letting go of a slider always ends up nudging the value up or down by one, leaving you with a value other what you intended? That is, 49 or 51, somehow never 50?

I actually solved that too. My slider has a little history buffer. When you let go, it jumps to the value it had ~100ms ago. People always pause on the value they want, before letting go, so this way you get the right value.

It works like a dream, and it has for 10 years.

In my own product, it’s not just for volume control, I use it for all sliders.

I think this type of slider would be wonderful as a volume control in openHAB. Any takers?

Setpoint is a UI widget. There is no Dimmer widget - Slider, perhaps? The point is that the widget you choose to use in the UI has no direct relation to the Item type. Item types will often have a default widget style, but you don’t have to use that.

Separate UI concerns from Item type choices. i.e. choose the Item type to suit the binding/device. Then find out how to select individual widgets for Items.

If you want to use MainUI, that is path you need to follow.
(Sitemaps and BasicUI are still available)

Sounds like this old ‘tip’ is still relevant -

but these days it would be Item metadata ‘pattern’ that needs % unit.

Okay, “widget” was a helpful keyword in your reply. Looking around the add-ons section, I found Rich Koshak’s volume control widget.
It does work, it does what it says, the range is correct for the item. Nice one!

It of course still has the problem of jumping to any value you click on, but this does give me hope – if he could write his own widget, perhaps I could too? That way I could implement the volume control of my dreams and contribute it back as a community widget.

I don’t know exactly how custom you can make a widget but I’m guessing you can write your own Javascript?

Okay, this is going to be a bigger project than I have the bandwidth for right now, but I really do need to learn CSS/JS anyway. I will definitely revisit this.

In the meantime, I wonder if it makes sense to chicken out and install BasicUI in OH3… that way I’ll be able to get things into OH3 fairly quickly, and I can dive into MainUI back when I have more time to focus in the future.

Question @rossko57 – BasicUI in OH3 does not use the Semantic Model, correct?

But… nooooo… BasicUI is a dead end. It makes no sense to start over in the same cul-de-sac i was before. I need to make MainUI work for me.

1 Like

It has no idea about that. The semantic model is a fancy view of Items and Group relationships with extra tags, Group relationships are available to sitemaps same as ever (though in practice more useful for quick’n’dirty than elegant UIs) - without the semantic tags.

Unless you have existing OH2 sitemaps easily re-used, which is what you suggested to begin with.
They co-exist - you can present a functional sitemap for family use and fiddle about with MainUI alogside.

1 Like

No guts, no glory



1 Like

They are built on the F7 framework with OH implemented customizations. You have the ability to modify how some of it works and looks using F7 parameters or even CSS and you have access to your Items and Item states that let you change how a widget looks and works based on the states of Items. But you do not have the ability to write your own custom JavaScript capabilities.

I didn’t write that volume slider, I just configured the oh-slider-item widget an save that configuration off as a custom widget. If you installed this from the Marketplace you can go to Developer Tools → Widgets → rlk-volume-setpointlist and see the “code” that went into it. It’s basically just the setting of a couple of parameters and configuring the built in widget to look how I want it.

For the most part it’s hardly worth posting to the Marketplace but I wanted to put it up there so that other widget creators can see that their widget doesn’t need to be really big and complicated to be posted to the Marketplace. Also, there might be the ability to bundle multiple widgets on the marketplace in which case I could take most of those widgets and create a sort of theme that users can install and apply.

A note about application. Once you have a custom widget you should then go to your individual Items and set the “default x widget” metadata to use the appropriate custom widget. Then where ever that Item is shown it will choose the custom widget to display it instead of the system default.

A List Item type widget (which is what this volume slider widget is) is used inside of cards (e.g. in the Location cards on the Overview Page. A stand alone widget is used on a Layout page you might define from scratch.

I cannot encourage you enough to go through the Getting Started Tutorial. It walks you through most of what’s new in OH 3 including custom widgets. At this point you might skip the Things stuff and maybe the semantic model (though lots of people think they understand it but don’t really so I’d review that too).

Correct. The semantic model offers the following and nothing more (yet):

  • a hierarchal view of some of your Items in the Model settings page in MainUI
  • will automatically build and populate the Locations, Equipment, and Properties tabs of the Overview page (see the Getting Started Tutorial for details)
  • is available in rules through some new Actions
  • is used by HABot for natural language interaction with your openHAB instance (e.g. “turn off the lights in the kitchen” type commands).

That’s it. Don’t make the model out to be more than it is. Don’t assume you must use the model or that all your Items must be in the model. Implementation wise, the mode is 100% implemented using Item Group membership and Item tags.

Given that, you could put Location and/or Group Items on your sitemap using the Group element and it will render all the members using the default sitemap widgets for the Item type in what ever random order the Items happen to be listed as members of the Group. But that almost never is satisfactory. MainUI is better in this regard since you can supply the default widget to use on an Item by Item basis.

Oh you don’t!! No way to make a custom widget at all? That would have been awesome. I really do plan to get deep into JS/CSS next year. This year I’ve dipped my feet in the water:

Simple web interface on ESP8266/ESP32 for direct control of my relay boards. These are the ones I will control from OH3 through Homie/MQTT once I get the hang of this. Mostly HTML with just enough CSS, JS and websockets sprinkled in to make it work.

It was hugely helpful for me to see it there! It was a working example of what I was looking for, just enough to point me in the right direction for making my own volume control widget based on oh-stepper-card.

Thank you! Will do.

I did!

I started.
I made it to the Semantic Model page, and I tried to follow along – it’s not an easy read because these are not easy concepts to explain in words. Once it clicks, it’ll make perfect sense to me I’m sure.
I ran 3.1.0 and got stuck when I discovered this bug but it has been fixed in 3.2.0M5! :partying_face:

Thanks for the reminder to get back to the tutorial. I kinda skipped all the way to the last page, no wonder it got so difficult! :slight_smile:

I’ll also just throw out the usual message, you don’t have to use the model.

I also wrote up a more in depth tutorial on the model that might help. A Deep Dive into the Semantic Model. This tutorial is written more with existing OH users as the target audience than brand new users. So I don’t go into “what’s an Item” and stuff like that.

See my reply on the other zwave thread too. I added a bit to my last reply while you and Jay were also posting and you may have missed it. It covers some cool things you can do now that you have the custom widget. For me the most powerful thing is to create custom List Item widgets, set my semantically tagged Items to use them as the default list Item widget and then everywhere in the semantically generated parts of the UI that Item is shown it will use my custom widget by default. And if I change the original widget, it updates everywhere automatically.

The other super powerful thing to do is create a unified widget for all the Items for a given device. Then make that the default standalone widget for the parent Equipment tagged Group Item. Then you can just plop the whole equipment on a layout page in one go.

And you don’t necessarily need to code your own widgets. There are lots posted to the Marketplace already with more being added every day. These you just install like an add-on and configure.

I did miss it! Good call.

There’s this one widget I really want to make. Can you read my original post in this thread starting at the phrase “pipe dream”? I go into it in some detail there, including an animated GIF of how my current user interface works (C++ / Win32 GDI)

I did see that thread but I am by no means an expert in Widgets. I can configure one using the reference docs and that is about it. I don’t know anything about CSS really.

What you describe over there looks largely like it won’t be possible if you are referring to how to change the way the slider behaves. Remember that MainUI is built upon layers. OH is built on F7 is built upon Vue and a good deal of the behavior and style is even implemented by the browser itself. To change how the setpoint works over all will probably require digging down through the layers and submitting a PR to the MainUI itself. It’s not going to be something you can change through config.

If being able to create a custom widget and have full control over it is important to you, you need to look at HABPanel. Or code up something yourself and use a webview widget to embed your UI page into MainUI.

Alright. Let’s call it a stretch goal. :slight_smile: