Curtain command not passed to thing channel

iva-k · August 22, 2020, 9:51am

Platform information:
- Hardware: Raspberry Pi 3 B+
- OS: Linux openhab 4.19.66-v7+
- Java Runtime Environment: build 1.8.0_181-b13
- openHAB version: 2.5.4

I am using zigbee2mqtt for Xiaomi curtain motors and sending commands directly over mosquitto_pub to motor works perfect, curtains close and open as commanded. However, using the Basic or Paper UI widget it looks like the MQTT message is never sent even though looking through log I see that item state was changed.

Log when using Basic UI:

2020-08-22 11:42:13.225 [ome.event.ItemCommandEvent] - Item ‘Bedroom_Curtains’ received command UP
2020-08-22 11:42:13.230 [nt.ItemStatePredictedEvent] - Bedroom_Curtains predicted to become UP
2020-08-22 11:42:13.287 [vent.ItemStateChangedEvent] - Bedroom_Curtains changed from 20 to 0

As i’ve added this same item to Google Home, I can control it only using voice command as Google Home doesnt show any control widget, but even with Google Home i can give it command to set curtain at certain percent, and even in those cases it doesnt work always, for example:

Open curtains - Doesnt work
Close curtains - Doesnt work
Open curtains to 100% - Doesnt work
Open curtains to 0% - Doesnt work
Open curtains to 1% - Opens curtains completely
Open curtains to 2%-99% - Works ok

Log when commanding using Google Home:

==> /var/log/openhab2/events.log <==
2020-08-22 11:45:40.341 [vent.ItemStateChangedEvent] - mqtt_topic_9dc3ee63_curtains_bedroom_linkquality changed from 78 to 70
2020-08-22 11:45:40.348 [vent.ItemStateChangedEvent] - Bedroom_Curtains changed from 50 to 20

==> /var/log/openhab2/openhab.log <==
2020-08-22 11:45:43.613 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command ‘false’ not supported by type ‘OnOffValue’: No enum constant org.eclipse.smarthome.core.library.types.OnOffType.false

==> /var/log/openhab2/events.log <==
2020-08-22 11:45:43.618 [vent.ItemStateChangedEvent] - mqtt_topic_9dc3ee63_curtains_bedroom_linkquality changed from 70 to 76
2020-08-22 11:45:43.641 [vent.ItemStateChangedEvent] - Bedroom_Curtains changed from 20 to 50

Here are my item and thing configurations:

Switch   Bathroom_Mirror_Heating     "Mirror Heating"     <heating> (Bathroom, gHeating)     ["Heating"] { channel="mqtt:topic:9dc3ee63:wlan-hvac-bathroom:mirror_heater"}
Switch   LivingRoom_FCU              "Fan"       	  <heating> (LivingRoom, gHeating)   ["Heating"] { channel="mqtt:topic:9dc3ee63:wlan-hvac-livingroom:livingroom_fcu"}
Rollershutter  Bedroom_Curtains	     "Curtains"           <blinds>  (Bedroom, gCurtains)     ["Blinds"] { channel="mqtt:topic:9dc3ee63:curtains-bedroom:position", ga="Blinds" [ inverted=true,  roomHint="Bedroom"]}

Bridge mqtt:broker:9dc3ee63
{
    Thing topic curtains-bedroom "Curtains Bedroom" {
    Channels:
	Type dimmer : position "Position" [ stateTopic="zigbee2mqtt/curtains-bedroom", commandTopic="zigbee2mqtt/curtains-bedroom/set/position", transformationPattern="JSONPATH:$.position"]
	Type switch : running "Running" [ stateTopic="zigbee2mqtt/curtains-bedroom", transformationPattern="JSONPATH:$.running"]
	Type number : linkquality "Link quality" [ stateTopic="zigbee2mqtt/curtains-bedroom", transformationPattern="JSONPATH:$.linkquality"]
    }
}

This leads me to suspect that something about transform or item definition is wrong, any help is greatly appreciated. Thank you

rossko57 · August 22, 2020, 10:02am

Your events.log snippets do not show us any openHAB command.

The MQTT error is about an incoming payload (the use of the word command here is misleading). We can’t tell what channel, you might be able to work it out from the context.
It’s probably to do with a switch type channel though.

If your Bedroom_Curtains Item ever gets commands, your position channel should pass them out on the commandTopic. There is no transformation involved there.

Using an external tool like mqtt.fx can be very helpful to see the traffic.

iva-k · August 22, 2020, 12:01pm

Thanks for replying!

Unless I am mistaken these state change logs indicate a command was issued, no?

Item ‘Bedroom_Curtains’ received command UP

However I do not understand where they are coming from, item type is Rollershutter, so i assume from there, and I would need to transform that before sending mqtt message.

But this is obviously not happening, looking at mqtt messages none are being sent, and it doesnt make sense why 0 or 100% wouldnt work but 2-99% commanded via google does work.

rossko57 · August 22, 2020, 12:31pm

Please review openHAB basics. Item states and Item commands are very different uhh things.
For example you can command a roller shutter Item UP but it can only have state like 55%.

In general, a linked binding will listen for commands to an Item and pass outwards to real device.
Likewise, a binding receives data from external device and passes to linked Item state.

I repeat I see no command in your Google related events.log extract, so there’s nothing to be sent out.

I do see your command UP from clicking UI.
MQTT binding should take that, not do any transform (because you haven’t asked for one), and publish payload “UP” to topic zigbee2mqtt/curtains-bedroom/set/position

It probably does need transforming, but you haven’t asked for any outbound transform in your config, nor could anyone else guess what you wanted it transformed to.

If you cannot see that published “UP”, your MQTT openHAB config has some fundamental problem. How are you examining MQTT messages, to find that none are sent?
I think your basic broker connection is okay, because you get the error log on received payload.

H102 · August 22, 2020, 2:30pm

Adding to what rossko57 mentioned about your MQTT OH config, check in PaperUI and see if you have two brokers. I made this mistake once and if you did the same then simply make sure you are using the correct broker. I only mention this b/c the broker bridge in config above ends in 9dc3ee63. Most will give it a name but if you did not then ignore this post but make sure you don’t have more than one broker.

iva-k · August 22, 2020, 11:41pm

Just to make things clearer, curtain motor expects a number from 0 to 100 for curtain position.

I expected the same, but that doesn’t occur. Like I mentioned previously any command given via Paper UI or Google Home doesn’t result in ANY MQTT messages being published. The only time anything is published when I tell google home “Open curtains to x(any number between 2 and 99)”

I’m using Wireshark to analyze all traffic and mosquitto message logs. And there is definitely no messages being published other than what I already mentioned.

I did some additional tests in openhab console, and I was actually able to replicate issues I am seeing when using Google Home to control the curtains.

For command:
smarthome:send Bedroom_Curtains x

any number from 2 to 99 works.
0 and 100 don’t work, and no MQTT message is published.
1 is published as 100 in the MQTT message.

I am not sure how to interpret this. I see only 2 possibilities:

Rollershutter item doesn’t handle 0,1 and 100 correctly causing some assert or some other issue before MQTT message can be even published
Rollershutter item does handle them correctly but passes some other values to the dimmer item channel which causes an assert there.

I’ve tried to add a transform to item channel to handle ON, OFF, UP, DOWN, pretty much anything I can think of and i dont see any transformation being done, which leads me to believe that no data is actually reaching out transform script.

Thanks for your suggestion. I’ve left the default name for no particular reason, but I did doublecheck now and that is the only broker I have. All other devices using MQTT via WiFi or Zigbee work just great, its only the curtains that are causing me grief.

rossko57 · August 23, 2020, 12:23am

Well, let’s analyze that.
What gets published when you tell google home “blah”?
Where do you suppose that comes from? Remember we did not see any commands in your events.log when you showed us the google activity.
Look closely, are those commands ending up at some other Item?

On looking closer, I’ll retract what I said about UP getting published!
You’ve got a RollerShutter Item type, but it’s linked to a dimmer type MQTT channel.
I think your Item will happily accept an UP command, but dimmer channel ignore that.
You’d have to use a rule to translate UP/DOWN/STOP to something numerically digestible for the dimmer channel I suspect.

Meantime, the channel should work with numeric commands. Have you tried this, its not clear?

iva-k · August 23, 2020, 6:33pm

Well, nothing as I said before. But this isnt important bit, as i’ve mentioned in my last message i was able to replicate this problem even when issuing commands via openhab console.

Yes, i’ve mentioned it before:

Thats a fair point, and i’ve tried changing the channel type to number, and what i am getting now is slightly different, 1 now doesn’t result in curtain being opened fully. Seems like a step in right direction finally.

RiotMode · January 7, 2021, 3:16am

which version of the motor are your running ?
left or right ?

iva-k · January 19, 2021, 4:38pm

Hi Phillip, its the older one on the right.