What makes you think that? Have you tried it?
(openHAB has a view of a dimmer as a “percentage thingy”)
What makes you think that? Have you tried it?
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.
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.
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.
All I wanted to know is, does the type selection drop down say “Dimmer” or “Percent”? Everywhere else it is referred to as Dimmer, but you missed it here at first, you won’t be the only one by far.
Post a screenshot and I’ll raise an issue, if you don’t want to.
It shows ‘Percentage’ in the drop-down list, I have already shared that fact in an earlier post > How to show a dimmer with a switch in PaperUI using an MQTT backend?
Yes of course it would be more obvious if it was worded to the effect of ‘Percentage (ie dimmer)’ or something to make it instantly apparent that is the one to use for a dimmer.
Whithout checking the code, It seems that the MQTT Bindings dimmer channel does not accept ON/OFF commands, therefore there is no corresponding Switch rendered in PaperUI.
According to the openHAB semantic it should accept those commands like other Bindings and therefore this is a bug that should be raised at github.
hmm, now it begins to make more sense about (mis)labelling it as percentage.
I can understand in part - on/off commands in a generic MQTT context might well have to do something rather different to 30% setting.
An approach would be to have separate on/off and percent channels, which can both be linked to one OH Dimmer Item, and have the percent channel ignore on/off commands while the on/off channel ignores numeric commands.
Just an example from the WeMo Dimmer Switch.
The dimmer channel will get an OFF command, which internally will be transformed into brightness value of 0%, on the other hand, ON command is transformed to the last known brightness.
So from Item side, you can link a Dimmer Item and a Switch item to the brightness channel, like to be seen on the WeMo docs.
Exactly what I was expecting here in this scenario from a functional perspective.
How does one go about raising this higher up the food-chain to the appropriate party?
As in I can raise a github bug yes, but can this discussion involve the appropriate devs here before raising a bug?
Not neccesarily, as I might have identified the missing part.
The channel definition for the generic MQTT things dimmer channel is missing the following in the XML file
The logic should already be in place.
But, as what has been said before, PaperUI is not meant to be an everyday control Interface, just an admin interface and will be deprecated with openHAB 3, so what exactly is your use case here ?
If deprecation is on the cards, then there is no issue, it would be pointless. However I’m glad that I wasn’t going ‘mad’ in my observation.