I have a dimmer showing and working as an MQTT channel for a thing, but don’t see an option to enable an on/off switch for display? searched around here to no avail, any pointers?
You need to create and item. Once the item is created you can control it in basic ui or other ui.
1 Like
The Paper UI is only recommended for administering OH. People tend to use the Basic UI or HABPanel for operational access.
Yes, I’ve gone through the tutorials and understand where each component sits.
I should have been a little clearer in the question, I’m purely attempting to bind the right controls with a dimmer switch using an MQTT thing. I can see that a zwave thing will actually show a dimmer scrollbar with an on/off switch in PaperUI, and I’m trying to replicate that function using an MQTT driven thing, thus interested in how this can be achieved. At the moment when I set up the MQTT thing it is purely a scrollbar representation of the dimmer without a switch, though I can add another channel for the switch, it is merely my interest in how PaperUI combines the dimmer plus switch into one.
What you see in the Control is dependent on the Item type. Things are not displayed there.The channel type for the Thing should likely be Dimmer.
1 Like
That appears to be the issue, there is no channel type of ‘dimmer’ available in MQTT binding as far as I can see in the dropdown list?
<md-select-menu class="ng-scope md-overflow" style="transform-origin: 221.789px 24px 0px;"><md-content>
<!-- ngRepeat: channelType in channelTypes --><md-option ng-repeat="channelType in channelTypes" ng-value="channelType" tabindex="0" class="ng-scope md-ink-ripple" role="option" aria-selected="false" id="select_option_7" aria-checked="true" value="[object Object]" style=""><div class="md-text">
<span class="md-caption ng-binding">Text Value</span>
</div></md-option><!-- end ngRepeat: channelType in channelTypes --><md-option ng-repeat="channelType in channelTypes" ng-value="channelType" tabindex="0" class="ng-scope md-ink-ripple" role="option" aria-selected="false" id="select_option_8" aria-checked="true" value="[object Object]"><div class="md-text">
<span class="md-caption ng-binding">Number Value</span>
</div></md-option><!-- end ngRepeat: channelType in channelTypes --><md-option ng-repeat="channelType in channelTypes" ng-value="channelType" tabindex="0" class="ng-scope md-ink-ripple" role="option" aria-selected="false" id="select_option_9" aria-checked="true" value="[object Object]"><div class="md-text">
<span class="md-caption ng-binding">Percentage Value</span>
</div></md-option><!-- end ngRepeat: channelType in channelTypes --><md-option ng-repeat="channelType in channelTypes" ng-value="channelType" tabindex="0" class="ng-scope md-ink-ripple" role="option" aria-selected="false" id="select_option_10" aria-checked="true" value="[object Object]"><div class="md-text">
<span class="md-caption ng-binding">On/Off Switch</span>
</div></md-option><!-- end ngRepeat: channelType in channelTypes --><md-option ng-repeat="channelType in channelTypes" ng-value="channelType" tabindex="0" class="ng-scope md-ink-ripple" role="option" aria-selected="false" id="select_option_11" aria-checked="true" value="[object Object]"><div class="md-text">
<span class="md-caption ng-binding">Open/Close Contact</span>
</div></md-option><!-- end ngRepeat: channelType in channelTypes --><md-option ng-repeat="channelType in channelTypes" ng-value="channelType" tabindex="0" class="ng-scope md-ink-ripple" role="option" aria-selected="false" id="select_option_12" aria-checked="true" value="[object Object]"><div class="md-text">
<span class="md-caption ng-binding">Color Value (Red,Green,Blue)</span>
</div></md-option><!-- end ngRepeat: channelType in channelTypes --><md-option ng-repeat="channelType in channelTypes" ng-value="channelType" tabindex="0" class="ng-scope md-ink-ripple" role="option" aria-selected="false" id="select_option_13" aria-checked="true" value="[object Object]"><div class="md-text">
<span class="md-caption ng-binding">Color Value (Hue,Saturation,Brightness)</span>
</div></md-option><!-- end ngRepeat: channelType in channelTypes --><md-option ng-repeat="channelType in channelTypes" ng-value="channelType" tabindex="0" class="ng-scope md-ink-ripple" role="option" aria-selected="false" id="select_option_14" aria-checked="true" value="[object Object]"><div class="md-text">
<span class="md-caption ng-binding">Date/Time Value</span>
</div></md-option><!-- end ngRepeat: channelType in channelTypes --><md-option ng-repeat="channelType in channelTypes" ng-value="channelType" tabindex="0" class="ng-scope md-ink-ripple" role="option" aria-selected="false" id="select_option_15" aria-checked="true" value="[object Object]"><div class="md-text">
<span class="md-caption ng-binding">Image</span>
</div></md-option><!-- end ngRepeat: channelType in channelTypes --><md-option ng-repeat="channelType in channelTypes" ng-value="channelType" tabindex="0" class="ng-scope md-ink-ripple" role="option" aria-selected="false" id="select_option_16" aria-checked="true" value="[object Object]"><div class="md-text">
<span class="md-caption ng-binding">Location</span>
</div></md-option><!-- end ngRepeat: channelType in channelTypes --><md-option ng-repeat="channelType in channelTypes" ng-value="channelType" tabindex="0" class="ng-scope md-ink-ripple" role="option" aria-selected="false" id="select_option_17" aria-checked="true" value="[object Object]"><div class="md-text">
<span class="md-caption ng-binding">Rollershutter</span>
</div></md-option><!-- end ngRepeat: channelType in channelTypes -->
</md-content></md-select-menu>
Are you using the v1 or v2 binding?
I have one RGBW light that is dimmable but I just use a Switch item. Here are the Channels though.
Those channel types are relative to the zwave binding.
The MQTT binding doesn’t have the ‘dimmer’ type. I’m using MQTT v2.
What makes you think that? Have you tried it?
(openHAB has a view of a dimmer as a “percentage thingy”)
I should have been clearer.
Indeed I get a dimmer scrollbar in PaperUI… what I don’t get is what a zwave thing shows in paperui, that is a dimmer scrollbar PLUS an on-off switch. Which shows through on the smartphone OH app too. The MQTT channel types don’t have a ‘dimmer’ type and thus PaperUI doesn’t render the scrollbar plus the switch… this is my assessment thus far, if I am wrong, please do share a solution?
The config thus far:
The display in PaperUI:
As we can see, I had to add TWO channels in order to get both a dimmer and the ability to switch. Zwave things get representation of both facilities through just ONE channel.
Are you saying you get a Number channel if you select a Dimmer channel described in the MQTT docs?
As an aside, zwave will be able to do things that MQTT cannot - zwave is a fully discoverable technology, where devices tell the binding about their properties. MQTT is completely generic, the binding knows absolutely nothing about devices apart from what you manually configure.
I do not get a ‘dimmer’ channel type in the list to select from? I only get the list which I pasted earlier on, whence I choose number, put in a range and a delta and I then get the scrollbar in PaperUI.
I appreciate Zwave comes with inherent logic which automates a great deal… however we should be able to manually replicate the ‘automation’ with MQTT things too, no? whence raising this question… I accept more configuration is a necessity with MQTT, thus I desire to learn the ‘how-to’…
You understand that a Dimmer is a percentage device, not a number?
Comment - you’ll never be able to do manually all that discovery can do. For example, zwave is able to assign meanings to a smoke alarm switch, like “Fire!” for ON. And select languages for that.
MQQT doesn’t really understand what a switch is even, there are just payload strings to be converted to some magic state the rest of openHAB uses.
That’s fine, you do the manual conversion with MAPs and rules and transforms or whatever. It’s not the binding’s job.
This I did not understand! Ok, let me try…
Still just a scrollbar and no switch.
Configuration:
I don’t know whether you are looking at Things or Items there.
Note that a dimmer channel will behave differently to a number - you can command ON/OFF now.
In PaperUI when a dimmer ‘item’ is binded to a percentage ‘channel’ of an MQTT ‘thing’, we only see a scrollbar, no additional ON/OFF switch.
However, when doing the same with a Zwave thing, the channel-type of ‘dimmer’ is selected automatically by default according to how zwave classes function. This then binds to an item type ‘dimmer’ and accordingly shows a scrollbar and a switch representing that dimmer ‘channel’.
So my conclusion is that because we do not have a channel type of dimmer available in an MQTT thing configuration, only the type of ‘percentage’ being the valid choice as you advised out of the type collection, a binded item type of dimmer to that channel will not display a switch… is this a bug? or simply by design?
Keep in mind that in the MQTT thing channel configuration it shows ‘dimmer’ as type for that channel even though I chose only ‘percentage’ out of the available channel-type options which do not include ‘dimmer’, yet we still do not see a switch as well as the scrollbar when PaperUI renders that item.
Whether it is named percentage or dimmer, it’s the same channel type.
zwave binding can offer more channel “properties”, because of discovery. Not all of those will be available to MQTT - see previous discussions of auto-annotating an ON/OFF channel with “Fire!/ok” in the default language.
You simply cannot do that from generic MQTT and it does not matter because there are many ways to the same end.
You might find Homie discovery setups can begin to approach this.
I am surprised if zwave binding can set some property to cause PaperUI to choose a different widget. But certainly not impossible … it may for example be offering ON / OFF default annotations for dimmers, perhaps in language selections, which PaperUI can interpret.
I don’t have any zwave dimmers to look at - if you want to chase it down use REST API to compare properties of your offending channels.
I’m not sure what would happen if you find the root difference, PaperUI won’t change. MQTT binding won’t change. You might be able to use REST API to manually add extra properties to your channels, I’m not sure. It seems a bit of a pointless effort when PaperUI is an admin interface, not user facing.
I hope that you find using an MQTT Dimmer channel works better than a Number in your actual usage, that has been useful.
Does the MQTT channel editing screen in PaperUI need to be made clearer about Dimmer type?
I guess nothing ever matters if there are always workarounds… a cop out if you will, us developers have always used that to our advantage, at the expense of confusing/disgruntling end-users of our systems.
However, in this particular case, the fact that in the MQTT ‘percentage’ channel configuration a user inputs a range AND an ‘on’ and ‘off’ value, one would at least expect that to be represented accordingly in PaperUI, sure we accept PaperUI is a control/configuration facility and not an end-user customizable interface, but from a ‘control’ aspect we would at least hope it renders what the configuration implies ie. the MQTT channel has both a range and an on and off value.
I guess I’ve hit my first, ‘we dont care, nobody else is concerned’ scenario.
As the concerned party, it’s up to you to chase it down. I’ve told you where to look, I cannot do it for you, and would not in any case.
I offered a prediction about the likely response That’s a personal opinion from one responder, others might be different. And I’m not a developer. Perhaps this is something that should indeed be taken forward into consideration for OH3 for example.
But no-one knows until you identify it. With some evidence - remember not everyone has zwave dimmers and so far there hasn’t been even a screenshot of what you’re trying to achieve. I’m guessing it is still looking like this -
On the docs side, Does the MQTT channel editing screen in PaperUI need to be made clearer about Dimmer type? I can’t see what it looks like.
1 Like
Yes it should be clearer, but this is one of those RTFM moments really, the information regarding ‘percentage’ being the one to use for a dimmer should be in the docs, but at the same time it would be nice if there were hyperlinks in all areas of openhab where users can simply click and go through to the relevant docs/wiki section of openhab… Microsoft has been doing this for years, opens the doors to a much wider less-technical-research-orientated crowd. Then again, if OH is to remain a ‘geeks’ smarthome platform (no disrespect intended!), then it is fine the way it is.