Mqtt 2.4 binding dimmer on/off


What should happen when I send ON/OFF commands to dimmer channel of the generic mqtt thing ?
What I get is an error in the log:

2019-01-13 13:43:23.305 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.eclipse.smarthome.binding.mqtt.generic.internal.handler.GenericThingHandler@e2a897': null
java.lang.NumberFormatException: null
	at java.math.BigDecimal.<init>( ~[?:?]
	at java.math.BigDecimal.<init>( ~[?:?]
	at java.math.BigDecimal.<init>( ~[?:?]
	at org.eclipse.smarthome.core.library.types.DecimalType.<init>( ~[102:org.eclipse.smarthome.core:0.10.0.oh240]
	at org.eclipse.smarthome.core.library.types.PercentType.<init>( ~[102:org.eclipse.smarthome.core:0.10.0.oh240]
	at org.eclipse.smarthome.core.library.types.PercentType.valueOf( ~[102:org.eclipse.smarthome.core:0.10.0.oh240]
	at org.eclipse.smarthome.binding.mqtt.generic.internal.values.PercentageValue.update( ~[?:?]
	at org.eclipse.smarthome.binding.mqtt.generic.internal.generic.ChannelState.publishValue( ~[?:?]
	at org.eclipse.smarthome.binding.mqtt.generic.internal.handler.AbstractMQTTThingHandler.handleCommand( ~[?:?]
	at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke( ~[?:?]
	at java.lang.reflect.Method.invoke( ~[?:?]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect( [102:org.eclipse.smarthome.core:0.10.0.oh240]
	at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke( [102:org.eclipse.smarthome.core:0.10.0.oh240]
	at com.sun.proxy.$Proxy203.handleCommand(Unknown Source) [207:org.eclipse.smarthome.binding.mqtt.generic:0.10.0.oh240]
	at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand( [109:org.eclipse.smarthome.core.thing:0.10.0.oh240]
	at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem( [109:org.eclipse.smarthome.core.thing:0.10.0.oh240]
	at sun.reflect.GeneratedMethodAccessor100.invoke(Unknown Source) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke( ~[?:?]
	at java.lang.reflect.Method.invoke( ~[?:?]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect( [102:org.eclipse.smarthome.core:0.10.0.oh240]
	at [102:org.eclipse.smarthome.core:0.10.0.oh240]
	at [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:?]
	at java.util.concurrent.ThreadPoolExecutor$ [?:?]
	at [?:?]

And the second question is how can I translate ON/OFF commands to 255/0 valuest sent to the mqtt broker ? With mqtt1 binding I used map transformation, and in new binding I do not see such option.

You can’t not yet. Outgoing transformations are coming in 2.5

Your thing, item and rule, please

no rules, just thing, and item.

    Thing topic livingroomDimmer "Dimmer" @ "Livingroom" {
            Type dimmer : ledDimmer "Led strip dimmer" [stateTopic="mySensorsout/6/0/1/0/3", commandTopic="mySensorsin/6/0/1/0/3", min=0, max=100, step=1]

Dimmer mysensors_livingroom_led_dimmer “Livingroom led strip [%d %%]” (gLivingroomLights,group_floor_lights_dependency) {channel=“mqtt:topic:openhabian:livingroomDimmer:ledDimmer”, autoupdate=“false”}

You can send a command to the item not the thing
An OFF command to a Dimmer item should be translated to a value of 0 and ON to 100

But this translation should be done in the binding, not the item ?
when I look at the mqtt binding code ( in the update method, the OnOffType is not handled. Yet other types are, such as IncreaseDecreaseType.

Then file a bug…
@David_Graeff ??

is it possible to use mqtt1 binding under openhab 2.4 ?

Yes of course.
You need to enable legacy binding in the paperUI and install MQTT1

well, to use mqtt1 I had to place mqtt1 jars into /usr/share/openhab2/addons/ because adding mqtt1 to addons.cfg didn’t worked and the binding was not listed in the extension list in habmin.

Because you need to:

OMG, I thought that You are talking about been able to use any OH 1 bindings … which I did before so I thought that I already have this setting … my bad

thanks :slight_smile:

What does “on” / “off” mean semantically to a percentage? :slight_smile: That is the reason why on/off was not handled.

I’m saying was, because in the latest pull-request I actually added an on/off interpretation as well.

1 Like

If Dimmer item accepts ON/OFF then the binding also should handle it. switch channel has on/off parameters that maps ON/OFF commands to values, so could the dimmer channel.

1 Like

The expected and documented behavior is that Dimmers can be commended with ON/OFF commands. It is also supposed to respond to INCREASE and DECREASE commands.

Type Name Description Command Types
Dimmer Percentage value for dimmers OnOff, IncreaseDecrease, Percent

Similarly, Color. Rollershutter, and Player Items also accept multiple command types.

DIMMERS… This is talking about DIMMERS.
I only offer a percentage channel in MQTT, that can be linked to a dimmer. But the API contract doesn’t require me to accept On/Off.

The expected behavior of Dimmer is that it can receive an ON/OFF.

If you do not support ON/OFF, you shouldn’t allow linking to a Dimmer Item type. Otherwise we have “Dimmers can accept ON OFF except for bindings 1, 2, and 3 because they work differently.” There is nothing documented anywhere that I can find that would indicate that linking a Percentage Channel to a Dimmer would break the documented behavior of the Dimmer Item type.

1 Like

Support for on/off got added in my last PR (which is not merged). I’m just saying that while I initially developed the binding, I did not violate any API contract, so technically it is not a bug, but a feature. But I don’t have any objections of not adding it.

Agreed, and I’m happy that the feature was added. I’d review the other Item types too if they are relevant to make sure Color, Player, and Rollershutter are also not similarly breaking expectations.

And I do understand that there may not be an API contract here, but there is a contract of sorts with the end user in the documented way that the Item types need to work. Perhaps there does need to be an API contract on this topic?

The official documentation is where I go when dealing with Item issues in my rules. The documentation clearly states that a Dimmer Item will accept an OnOff command type:

Actually, when the documentation is unclear, which in this case it is not, I consult the relevant source code from OH and/or ESH, but this would seem to be an unequivocal statement regarding the fundamental behavior of a Dimmer Item.

1 Like