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

Add-ons Bindings
,
27

Is there any update on this topic?

Thanks.

28

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.

29

Fixed in master

30

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.

https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.mqtt/2.5.0-SNAPSHOT/org.openhab.binding.mqtt-2.5.0-SNAPSHOT.jar

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.

31

Exactly.

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.

32

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.

33

Any updates on this ? :slight_smile:

34

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

1 Like
35

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?

36

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" {
Channels:
    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.

37

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

38

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
39

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.

40

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

41

Thanks for taking the time to answer David. From your answer it is clear that I have missed something even though I have tried to search and read all what I could find about this topic.

My confusion was that the MQTT output had changed from the older binding and I had found no info about this. In addition I saw UP, STOP, DOWN mentioned in the MQTT docs for the rollershutter item but I cannot find exactly where just now, today I just found this from https://www.openhab.org/addons/bindings/mqtt.generic/

Channel Type “rollershutter”
•on: An optional string (like “Open”) that is recognized as UP state.
•off: An optional string (like “Close”) that is recognized as DOWN state.
•stop: An optional string (like “Stop”) that is recognized as STOP state.

I might have misunderstood from this that the commands published still were UP, DOWN, STOP but I think this was more clear from the reference I am unable to find today.

If the generally accepted output is 0, STOP, 100 and working for all I have no wish to propose any change or start a discussion about this.

42

It’s difficult to determine what is “right” here.

The Rollershutter Item type accepts commands UP/DOWN , MOVE/STOP , and numeric 0-100 (for a target position). But that’s just an abstract model.

(No, I don’t know what MOVE is for. Maybe there are mechanisms that need a direction set first and then a separate “go”)

In the real world, there are rollers with no position control. Just UP/DOWN and probably STOP are needed - in whatever form the device needs.
Likewise I would expect there are rollers that only accept numeric target positions (to include 0 and 100). Maybe there are some that scale differently, 0 -255 say.
And various combinations most likely. Certainly there are also blinds that offer more than just these controls - slat / lamella positioning - but that’s a bit outside the scope of our “standard OH model”

The conclusion I guess is that you are likely to have to tailor or translate openHAB internal commands (and maybe ignore some of them) for any given real device.
That’s okay, we can do a lot with mapped or scripted transforms, and outbound transforms have been added to MQTT binding now thanks to @David_Graeff

But if that is the correct approach, you most likely would want the OH commands passed along to the transform as they are. Converting UP to 0 for example, leaves the transform unable to distinguish between those commands if they should need different actions.

If I were starting from scratch I’d publish the standard commands just as they come, with provision for transform by MAP or JS as required.

I’m not sure if that gives an option to “ignore” any particular commands, or whether it woulld be up to the user not to send them :wink:

43

Thanks for your clarifications.

My rollershutters actually are homemade controllers for awnings. I programmed them to listen to UP, STOP, DOWN based on the v1.xx MQTT binding. They have no position control and it is easy to adopt them to anything the actual binding gives.

But instead of reprogramming controllers I selected to use a proxy item which listens to the actual commands/states and translates them to whatever is the current version. This works as well. Just for knowing how the outbound transforms work I may give them a try also.

I think the idea of publishing any commands just as they come is very good because it would most likely satisfy the requirements from a variety of brands all inventing their “own version of the wheel”.

44

I think you should raise a Github issue for this. If it is decided that a change is sensible - because the availability of outbound transform no longer requires further fudging by the binding - now is the time to change it, before a 2.5 general release. It would be a breaking change for someone.

I’m not an MQTT user.

45

I have added this as a feature request as it hardly can be labelled as error, see https://github.com/openhab/openhab2-addons/issues/6067

Many thanks for your assistance.

46

Hi Friends, mqtt items do not work when I upgrade M4 to 2.5.0. But it works if I drop it back to 2.4.0. What is the new version mqtt items do not work.