Throwing in my twopenneth -
You can command ON to a Dimmer Item
The Item will pass this ON along to any and all bindings
It’s up to the binding to handle that into terms suitable for the device (or ignore)
Don’t get confused about actions of autoupdate muddying the water with it’s best guess prediction of likely outcome (such as 100%).
No thats not what I said. I said they (Google Assistant/Aleax and probably also Siri) is using terms which the users understand from the device it handles. As mentioned a few times… It´s confusing to use terms like “turn on/off the window” or “turn on/off the garagedoor”. Or like OP mentioned previously, “open/close the oven”. Terms like this makes it quite confusing. You´ll probably never see GA/Aleax or Siri doing the same.
But I can still send ON as a command to the Dimmer.
[/quote]
Hmm just made a fast test…And you´re right…
Test switch (virtual switch) and Dimmer item.
Switch DimTestSw "Dummy switch for testing dimmer on/off" <switch>
Dimmer spise_halo_styrke "Spotlys ved spiseplads [%s %%]" <cu_spot> (vLys) ["Lighting"] { channel="ihc:controller:elko:spisespot_dimmer", autoupdate="false" }
Small rule to send the ON/OFF to one of my dimmer…
rule "Test dimmer switch"
when
Item DimTestSw changed
then
if(DimTestSw.state == ON) {
spise_halo_styrke.sendCommand(ON)
logInfo("info", "Dimmer test switch ON")
}
else
if(DimTestSw.state == OFF) {
spise_halo_styrke.sendCommand(OFF)
logInfo("info", "Dimmer test switch OFF")
}
end
This is what happens turning ON:
2019-05-30 00:02:36.355 [ome.event.ItemCommandEvent] - Item 'DimTestSw' received command ON
2019-05-30 00:02:36.370 [vent.ItemStateChangedEvent] - DimTestSw changed from OFF to ON
2019-05-30 00:02:37.732 [INFO ] [.eclipse.smarthome.model.script.info] - Dimmer test switch ON
2019-05-30 00:02:37.734 [ome.event.ItemCommandEvent] - Item 'spise_halo_styrke' received command ON
2019-05-30 00:02:38.971 [vent.ItemStateChangedEvent] - spise_halo_styrke changed from 0 to 25
And this happens when OFF:
2019-05-30 00:07:20.187 [ome.event.ItemCommandEvent] - Item 'DimTestSw' received command OFF
2019-05-30 00:07:20.203 [INFO ] [.eclipse.smarthome.model.script.info] - Dimmer test switch OFF
2019-05-30 00:07:20.208 [vent.ItemStateChangedEvent] - DimTestSw changed from ON to OFF
2019-05-30 00:07:20.217 [ome.event.ItemCommandEvent] - Item 'spise_halo_styrke' received command OFF
2019-05-30 00:07:20.393 [vent.ItemStateChangedEvent] - spise_halo_styrke changed from 25 to 0
The Dimmer item receives ON/OFF fine, but it sends a value to the dimmer through the binding. (I have the Dimmer item pre-configure to 25 by default… an extra nice feature in the IHC binding. Wihtout it would have send the value of 100).
This explains why it didnt work when I tried for my garagedoor, cause if the binding “tranform” ON to a value, the switch wont be able to handle this…
But you´re right, the dimmer receives ON/OFF just fine. But the binding sends a value/number. And it wont work when the device is a switch, ofcouse.
Reminder: binding (technology) dependent.
Perhaps. But if the dimmer cant receive an ON/OFF, why should the binding pass it on?
Exactly. I don’t know how else to put this; one more try. It is the job of the binding to match up openHAB’s idealized model world to real devices with nasty variant technical interfaces.
openHAB’s model Dimmer supports percentage setting and on/off. That’s a design decision.
Any real device may require a “hey you, wake up!” followed by “here’s a command, x0AFB” followed by “here’s a parameter x0FC0”. That’s 1,999 design decisions by manufacturers past and present.
The whole point of the model is to insulate openHAB from this stuff.
In openHAB, all dimmers look alike. All can do on/off, all have a 0-100% range.
The bindings hide that this dimmer can’t do on/off and that that dimmer has 0-255 steps. The binding author (should) make sure that ON gets translated into something close or that 98% gets translated to step 250.
Can you think of a dimmer where the (a) binding will pass on on/off?
Yes, KNX, MQTT, Zwave, and I would think DMX amongst others.
Modbus would be an example of a low level protocol where the user can configure bahaviour e.g. send number% to this register and binary on/off to that register.
HTTP bindings are likewise simplistic and do what they are told.
I don’t understand the problem here? You want a Dimmer type without on/off, Number type would be closest.
Thinks - is the difficulty that you believe there no real dimmer devices that accept on/off?
I think a lot of rules can be avoided if more complex item types are available. Of course everything can be done with primitives. The idea of having more elaborated item types is to avoid additional rules.
And because we are changing the UI anyway now with much better newer frontend toolkits it’s easier to present more complex types.
A working group should develop some guidelines, looking at Homeassistent, iobroker and Mozilla web things to determine a new better set of item types.
The “problem” isn´t a serious problem. The debate is mainly about how dimmers works because I prevoius stated dimmers cant take on/off signal. I honestly dont recall how we got from contact/switches to speak about dimmers and how they work.
Well, probably because I cant express myself good enough in english, or you dont understand what I mean.
I´ll rest my case… But, while you mentioned it. I´ve got a Fibaro z-wave dimmer. If you know this dimmer, you´ll know if has switch channels as well as dimmer channel. The swicthes do accept on/off, ofcouse, but the dimmer channel dont. At least not from openhab, which ofcouse could be a binding design. But I honestly dont see why it should. I makes no sense…
Understood. That’s all good, Items need not map one-to-one with device parameters. A binding can match up on/off from an Item to device parameter xx and nn% from the same Item to device parameter zz.
Wait till we consider the Color Item type 
Sorry to chime in, but: which one? I checked them all, they only have switch_dimmer channels.
Of course they do, otherwise you would not be able to dim or switch them from openHAB 
FGD212
So you can send an on/off to the dimmer channel? (remember, the question is wether it takes number values or on/off).
Yes, Sir.
Switch FibFGD212_1_Sw (gRestore) { channel="zwave:device:uzb:node37:switch_dimmer1", autoupdate="false" }
2019-05-31 11:26:45.269 [vent.ItemStateChangedEvent] - FibFGD212_1_Sw changed from OFF to ON
2019-05-31 11:26:48.060 [vent.ItemStateChangedEvent] - FibFGD212_1_Sw changed from ON to OFF
31-Mai-2019 11:26:44.170 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 37: Command received zwave:device:uzb:node37:switch_dimmer1 --> ON [OnOffType]
31-Mai-2019 11:26:46.978 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 37: Command received zwave:device:uzb:node37:switch_dimmer1 --> OFF [OnOffType]
Hmm… I just made the test myself…
It does receive ON, and it change the dimmers state in number values.
But… Look at the last line:
2019-05-31 11:52:21.628 [ome.event.ItemCommandEvent] - Item 'DimTestSw' received command OFF
2019-05-31 11:52:21.639 [vent.ItemStateChangedEvent] - DimTestSw changed from ON to OFF
2019-05-31 11:52:21.654 [ome.event.ItemCommandEvent] - Item 'Dimmer1DimmerSwitch1' received command OFF
2019-05-31 11:52:21.653 [INFO ] [.eclipse.smarthome.model.script.info] - Dimmer test switch OFF
2019-05-31 11:52:21.664 [nt.ItemStatePredictedEvent] - Dimmer1DimmerSwitch1 predicted to become OFF
2019-05-31 11:52:21.684 [vent.ItemStateChangedEvent] - Dimmer1DimmerSwitch1 changed from 40 to 0
The dimming goes from 40 to 0 (zero). Not from 40 to off.
The very same happens when you turn it on:
2019-05-31 11:51:56.114 [ome.event.ItemCommandEvent] - Item 'DimTestSw' received command ON
2019-05-31 11:51:56.129 [vent.ItemStateChangedEvent] - DimTestSw changed from OFF to ON
2019-05-31 11:51:56.148 [ome.event.ItemCommandEvent] - Item 'Dimmer1DimmerSwitch1' received command ON
2019-05-31 11:51:56.148 [INFO ] [.eclipse.smarthome.model.script.info] - Dimmer test switch ON
2019-05-31 11:51:56.156 [nt.ItemStatePredictedEvent] - Dimmer1DimmerSwitch1 predicted to become ON
2019-05-31 11:51:56.176 [vent.ItemStateChangedEvent] - Dimmer1DimmerSwitch1 changed from 0 to 100
Again, the dimming goes from 0 (zero) to 100. Not from off to 100.
This is what I think I tried explain somewhere in the debate.
This dimmer actually has a switch option, like two products in one. But the actual dimmer is only working on value numbers. Thats why you dont see the dimmer change from 40 to off, but from 40 to 0 (zero). And again when you turn it on, the dimmer doesnt go from off to 100, it goes from 0 (zero) to 100.
This specific product do require a switch option though, otherweise it wouldn´t be able to remember that last value, or it wouldn´t make any sense to remember it. So it´s a required design choice from Fibaro.
There is nothing wrong in this. Several dimmers works the same. But in my opinion it´s wrong to say, that dimmers work on on/off. They dont, not unless there is a switch involved somewhere. In this particular product, if you removed the memory of the previous state, there really isn´t a need to support on/off anymore, except from a general design, that command ON will change the dimmer to 100, and command OFF will change it to 0 (zero). It´s still a switch though, not the actual dimmeing itself.
Do not confuse Item states with commands.
In this case, the only state a Dimmer type can take up is 0-100. (Well, and NULL or UNDEF).
By the by, bindings can also do the job of “translating” an incoming device status of ‘off’ into an OH standardized state 0.
Have you seen the allowed Dimmer type commands INCREASE/DECREASE? Rarely used, but they exist in the OH model.
We would not want sending a Dimmer INCREASE to result in a state of “INCREASED A BIT”, and it doesn’t.
Another example, you can send a RollerShutter type the command STOP. The resulting state isn’t going to be “stopped”, it’s going to be the position the mechanism stopped at, like 75%.
It’s not really clear - have we accepted that it is valid to send a real dimmer some kind of “turn on” instruction? And that different dimmer models could behave differently, i.e. either do the memory thing or instead go full tilt?
And if that is accepted, can we also accept that “turn on” is therefore different from “go to 100%”? Because in (some) cases it really does produce a different result.
Given that behaviour in the real world, why would we not want to model it in our idealized internal Dimmer type Item? Why would we disable the ‘memory’ of any linked device? I’m lost here.
It might be helpful to describe the life of a command to a Dimmer Item.
First, as rossko57 says, it’s important to understand the distinction between a State and a Command (I like to use proper nouns when talking about OH concepts to avoid confusion). I think I already said this above, but I’ll repeat it here in case I have my threads mixed up.
Items store a State. All Items can store the special states of UNDEF and NULL. Beyond that, each Item type has it’s one singular way to store it’s state. This is documented in the table here. The middle column describes how the Item stores the State (note to self, that table should be updated to show the specific type the Item stores, not just a description of it). In Dimmers case we have
Item carrying a percentage value for dimmers
That translates to PercentType which is an integer number between 0 and 100.
You will only ever see an Item updating to or changing to a PercentType because that is how it stores it’s state.
But, each Item can also receive Commands and the possible Commands it can receive can differ from the State. Looking at that same table above we see that the Dimmer Item can receive:
OnOff, IncreaseDecrease, Percent
This means we can sendCommand(ON), for example, to a Dimmer Item.
So what happens when I sendCommand(ON) to a Dimmer Item which doesn’t store it’s state as an OnOffType? The process is as follows. Let’s assume that the ON command is coming from BasicUI.
The Dimmer Item has been put on the sitemap as a Switch. The user clicks on the toggle to turn ON the Dimmer.
BasicUI creates an ON Command Event on the Event Bus. The Dimmer Item has not changed state at this point.
Interested parts of OH pick up the command from the Event Bus. These may be:
The Binding sees that the Item has received an ON Command. The Binding determines what ON means for this given device and issues the messages to the device necessary for it to “turn ON”. The binding also interprets what the ON Command means in terms of the Dimmer’s State. (I’m skipping the whole issue of autoupdate here for clarity). Because a Dimmer Item can only store State as a PercentType, the binding Updates the Item with a PercentType. Since we are dealing with Dimmers, usually that Update will either be the last value the device was set to before it was last turned off, or 100. So in the logs you will see the Dimmer Item updating and changing to 100.
You will never see the Dimmer changing from OFF to 100 because OFF is not a State that a Dimmer can store. But you will see that a Dimmer can receive a Command. And it is possible to get the Dimmer’s state as if it were a Switch. In a Rule you can do this using MyDimmer.getStateAs(OnOffType). Somehow the sitemap also understands how to interpret the state of a Dimmer to an OnOffType so it knows how to properly set the toggle. It does not work with icons though because icons only work directly with the actual stored State.
As you can see, we’ve NOT said that Dimmers “work on on/off.” Dimmer can be Commanded with ON/OFF and INCREASE/DECREASE. It is the job of the Binding to interpret those Commands to the new Dimmer State.
I wonder what would happen if you tried MyDimmer.getStateAs(IncreaseDecreaseType)? Probably a null or an exception. I don’t have any Dimmers right now so can’t quickly test, maybe something to try this evening. 
Hopefully between rossko57’s description and my description this is all a bit more clear. Note also, this is why when you have a Rule triggered by received command, you cannot rely on the state of the Item in the Rule. It hasn’t necessarily changed state yet in response to the command.
This is what I have been trying to say all the time.
What you say is, that the binding changes on/off, to something the dimmer can understand. Agree?
Then I agree with both you and Rossko57.
That is ALWAYS the case - no matter what the binding receives it MUST convert it to something the device can understand. If it receives a percentage, or an ON - it does a conversion, and sends it to the device - always.
And some dimmers do understand on/off. I am the author of a specific binding supporting dimmers (nikohomecontrol). The dimmer can be commanded with on/off or a percentage value. However, it will always report its state as a percentage value. Sending on will return the dimmer to its previous state or 100%, depending on a configuration setting in the Niko Home Control system (not in openHAB).
Every dimmer system is different, so some may not support on/off commands directly. It is then the binding’s responsability to send the appropriate value, and interpret the state received from the dimmer to represent a percentage value state. As an example, the Niko Home Control dimmers do not support increase/decrease (at least not through the API). The binding therefore interprets increase/decrease commands to send a percentage value calculated from the current state +/- a step value (which is a configurable option in my binding).
So the binding is responsible to translate the commands received from an item (percentage, on/off, increase/decrease) to something meaningful for the physical device, and to translate the status response from the physical device to a percentage value visible in the item.
In openHAB, all dimmers should support percentage, on/off and increase/decrease commands. All dimmers will report their state as percentage. If you link a dimmer item to a switch in a sitemap, that percentage will be interpreted as on/off by the sitemap, but the underlying status is still a percentage.
And of course, the converse; a given device may report it’s status as “I am off and setting is 57%”. Binding’s job to sort that into openHAB model status.