Binding-mqtt - 2.5.0.SNAPSHOT; rollershutter command is sent wrong

Tags: #<Tag:0x00007f7454c37218> #<Tag:0x00007f7454c37150>

This should work. The mentioned PR is already merged since a while. You need 2.5M1 at least. If it still not work you need to issue another bug report stating your configuration etc.

But just FYI: MQTT development is on hold at the moment until the ESH reintegration has been completed.

I’m migrating an OH2.0 to OH2.5M1 as a docker container but run into the same issue.

old default.items:
Rollershutter r12 (gRoll_boven_all) { mqtt=">[xxx:/rolluik/r/12/u:command:UP:30],>[primus:/rolluik/r/12/d:command:DOWN:30],>[xxx:/rolluik/r/12/s:command:STOP:0],<[xxx:/rolluik/h/12:state:default]", autoupdate=“false” } /* gang */

I wrote my own rollershutter interface with arduino & pubsubclient (16 devices). As you can see, it expects /rolluik/r/12/u, d or s and the amount of seconds. The arduino publishes the state in percent on /rolluik/h/12 on a regular interval.

new default.things:
Bridge mqtt:broker:mosquitto “bridge: mosquitto” [ host=“xxx”, secure=false ]
Thing topic rollershutters “thing: rolluiken” {
Type rollershutter : r12 “Rolluik gang” [ stateTopic="/rolluik/h/12", commandTopic="/rolluik/r/12/u" ]

new default.items:
Rollershutter r12 { channel=“mqtt:topic:mosquitto:rollershutters:r12” }

events.log when clicking each button:
[ome.event.ItemCommandEvent] - Item ‘r12’ received command DOWN
[nt.ItemStatePredictedEvent] - r12 predicted to become DOWN
[vent.ItemStateChangedEvent] - r12 changed from 0 to 100
[ome.event.ItemCommandEvent] - Item ‘r12’ received command STOP
[ome.event.ItemCommandEvent] - Item ‘r12’ received command UP
[nt.ItemStatePredictedEvent] - r12 predicted to become UP
[vent.ItemStateChangedEvent] - r12 changed from 100 to 0

I only see the values change in the Paper UI (d: 100, s: no change, u: 0) there is nothing published on mqtt itself. This is probably related to the error below, I might need to change my code above

openhab.log when clicking a button:
[ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method ‘ThingHandler.handleCommand()’ on ‘org.eclipse.smarthome.binding.mqtt.generic.internal.handler.GenericThingHandler@2168d4’: Cannot call update() with custom stop/move/up/down
java.lang.IllegalStateException: Cannot call update() with custom stop/move/up/down

What do I have to change in my new code to at least already publish something in mqtt? Can I get some example code? If the above should work, I can create a PR.

And what’s the best next step here?

  • wait for transformations to work on outgoing messages?
  • try to make it work via buttons and rules? like:
val mqttActions = getActions("mqtt", "mqtt:broker:mosquitto")
mqttActions.publishMQTT("topic", "payload") 
  • rewrite my rollershutter arduino code? (really? nah. Perhaps in the future to comply to homie v3)
  • stick with the mqtt 1 binding for the rollershutters for now?

I’m using 2.5M1 but same error :

14:49:49.074 [ERROR] [rnal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()'
on'org.eclipse.smarthome.binding.mqtt.generic.internal.handler.GenericThingHandler@7fa565a7': Cannot call update() with custom stop/move/up/down

@David_Graeff, can you confirm it works with 2.5M1 ?

I haven’t tried it myself, I have only added a test case that tested for the STOP command and if a percentage value is accepted. I will start MQTT development end of the week again and fix all the accumulated problems.

Just make sure to open an Issue on Github, describing exactly which commands work and which don’t.

Cheers, David

For github issue, on which repo ? Smarthome ? openhab-addons ? openhab-core ? Thank you

Good question, thanks for asking. Eclipse Smarthome is not longer part of this project. The mqtt bindings are in the openhab-addons repository now.


Is there any update on this topic?


Hey! I Have the same problem.
Is there still any solution?
I migrated OH to 2.5M1 to try if there is a new “stop”-state for the rollershutter-item. But it seams like it is not working basically.

By the way, great job, David. Thank you.

Fixed in master

Thanks a lot. So I am a little bit confused now. What do I have to do to get it working with your changes?
I downloaded this file and put it into the openhab2-addons directory.

It seem to install the MQTT binding from this location, but the embedded broker did not work. In my Generic MQTT Thing I am not able to select any broker.
I also tried the latest build of OH, but it has to many bugs right now for daily use.


The tl;dr: The issue is fixed but cannot be used at the moment, until the buildsystem migration has finished, openhab-core is repaired and the remaining buildsystem related problems with the mqtt binding are resolved.

Thank you David. Okay, I will wait until the migration has finished. I adapted my scripts, so the roller shutter switches will basically work for now.

Any updates on this ? :slight_smile:

There is nothing more to say. The functionality is implemented and you need to wait for OH 2.5m2

1 Like

hey guys,

I just ran into the same issue, great to see that this will be fixed in M2 (praying this will be released shortly).

bit of offtopic question: my rollershutter integration floods my events.log with entries like:

2019-04-27 17:11:19.838 [ome.event.ItemCommandEvent] - Item 'Rollo_WZ_01_Command' received command STOP
2019-04-27 17:11:27.471 [ome.event.ItemCommandEvent] - Item 'Rollo_WZ_02_Command' received command STOP
2019-04-27 17:11:49.849 [ome.event.ItemCommandEvent] - Item 'Rollo_WZ_01_Command' received command STOP
2019-04-27 17:11:57.479 [ome.event.ItemCommandEvent] - Item 'Rollo_WZ_02_Command' received command STOP
2019-04-27 17:12:19.857 [ome.event.ItemCommandEvent] - Item 'Rollo_WZ_01_Command' received command STOP
2019-04-27 17:12:27.484 [ome.event.ItemCommandEvent] - Item 'Rollo_WZ_02_Command' received command STOP

Is this something I can configure/ignore?

I would like to join in here. @David_Graeff

I have the same problem like the other guys above me. Im new in OpenHab and did not understand it right. In the actual Snapshot it was fixed and the mqtt send up down stop ?

For example what i need. I have create a Thing like this ::

Thing topic wzlinks "Wohnzimmer li"  @ "Wohnzimmer" {
    Type rollershutter : WZ_Jalousie_links     "Wohnzimmer li"      [stateTopic="/JaroFB/LastAction_Channel_01", commandTopic="/JaroFB/set", UP="up 1", DOWN="down 1", STOP="stop 1"]

my items look like this

Rollershutter       WZ_Jalousie_links        "Wohnzimmer li [%d %%]"            <blinds>    (Jalousien, WZ_Jalousien)           {channel="mqtt:topic:embedded-mqtt-broker:wzlinks:WZ_Jalousie_links"}

My commandTopic i need for the blinds is

/JaroFB/set up 1, for example. When the Dongle read this the blind will move.

1 is my blind channel, so blind 2, 3 and so on.
So what the mqtt is sending you know 0, 0, 100 with this the blind can do nothing.
When the new Build is out 2.5.0 M2 it works like i need it ? Did he send then

Or is there a way i can do this on another way ? What i have is a rule file they worked with astro binding and move my blinds random everyday. I use groups for each room.

@NikM did you manage to solve this issue by replacing / updating some files? If so, can you provide instructions?

Hi Stefan. I use rollershutter-switches with the mqtt-tuya script. I adapted the script for now. But with this solution I only can use Up and Down Switch not the Stop Switch of my rollershutter-switches. Thats a little bit pitty. I am still waiting for 2.5M2 with the upgraded rollerhutter profile.
Sorry for the late answer.

1 Like

I have installed the 2.5m2 version hoping the rollershutter now would work as it did for the 1.x binding but that is not the case. I have a switch commanding the shutter and the MQTT messages coming out via the binding now is 0, STOP, 100 (was earlier UP, STOP, DOWN).

Will this be changed back to UP,STOP,DOWN in a coming release or are the new messages the correct output?

With the exception of the rollershutter the new MQTT binding is working well for me so many thanks for a great job.

Actually different people demand for different outputs and I do not know what the idiomatic openhab-like way is. Could you maybe create a github issue for discussion and express your thoughts and why you think that your idea could be beneficial?

Thanks, David