When I add a Homie device Thing and bind a channel (defined as integer) to a Dimmer, the value is set to the proper topic (/set). If I bind the same channel to a Rollershutter item, the value is not sent to the topic.
As far as I understand, both are PercentTypes, so they should work, but for some reason the Rollershutter does not. Any ideas? What can I check to determine the root cause?
openHAB commands get sent to topics. Can you clarify what you do?
I am linking the channel to a Rolleshutter item:
I am monitoring the MQTT traffic. When I try to control the rollershutter (click up or down - sending 0 or 100), nothing is sent to the appropriate command topic (homie/deviceid/nodeid/property/set). If I bind the same channel to a Dimmer item, I can see the updates to the command topic.
What does your events.log show as the commands to your Item? It can’t be both UP and 0
You can command UP to a Rollershuter type Item, but that isn’t going to do much to a number type binding channel without some transformation.
The commands are UP/DOWN/STOP. I did try to change the channel to String, but that did not change the behavior. The command is visible in the events.log, but not posted to MQTT.
That’s what I figured. It is expected that you cannot send an UP command over a number channel. Just because you’ve hooked a number channel to an openHAB Roller type Item makes no difference, it’s still only a number channel.
Does Homie define any rollershutter type that should cause the defining of a more appropriate channel type by the binding? I don’t know.
If the Homie device is expecting a number in that topic, it wouldn’t help.
Thanks for all the input. String should work in this case, right? But it does not.
You can only successfully link an Item of the specified type to a Channel. In your screen shot from above, a Number Item is the only valid Item you can link to the Blinds (1) State Channel. Is there perhaps some other Channel that shows String or Rollershutter as the Item Type you can link to?
Why would it? You cannot send strings over a number channel.
Go back a step here … what do you want to send to your device, how do you want to send it?
Clearly, it is saying “here’s a number topic representing my position”.
Are you supposed to send numbers on the same topic to command a new position? I don’t know your device.
Should you send numbers on some other topic?
Should you send text commands like UP on some other topic?
Are text/number instruction either-or, or both allowed?
If you don’t know how your device works, random efforts are not going to work.
First of all, thanks for your support, I should have been clearer. I have implemented my own device to control the rollershutters over MQTT protocol, so I have an ability to change the type of my homie property (thus changing the channel data type).
I have tried to send the property value as number (in this case I can see the value updated on the command topic via dimmer, but not via rolleshutter item). Even when I change the item type to string, nothing is sent to the command topic from the rollershutter item.
Forget changing the Item type. If you want to use a number, use a number.
What do you want to happen? I’ll take a guess that you want command UP to your openHAB Item to send a value 0 over the MQTT command topic? You use a outbound transformation on the MQTT channel for that.
You do understand that from openHABs view you would normally receive status updates on one topic, and send commands on a different topic, otherwise you get in a loop?
To reiterate. You cannot just change the Item Type. The Channel requires a Number Item. You have to use a Number Item with that Channel. And that Channel will only and can only ever receive Numbers as commands. No Strings. No INCREASE or ON or STOP commands. Just Numbers.
So, as rossko57 indicates, you either need to Link the Channel to a Number Item or you need to add a transformation (probably using the transform Profile since Homie Things are automatically discovered) to translate the Strings and non-numeric commands to a number. Or you need to change your end device so that it accepts a String and rediscover it so that the Channel gets converted from Number to String.
I hope I understand what both of you are saying. The firmware that is sending the homie definition is mine. I’d rather adapt the firmware to accept String (UP/DOWN/STOP). I actually did that and re-added the device. So the Item Type is a valid string. I am not changing the item type in the opehab GUI. However, even with that adaptation, I don’t see a command on the mqtt queue.
But string channels are not rollershutter channels. The command UP is of UpDownType (I think!), certainly it is not a string. You’d have to transform it.
We remain totally ignorant of how your Homie device is describing itself.
What does that mean though, are you now using a String type Item, and if so what kind of channel links it to the MQTT binding? What commands are you now sending to this Item?
We don’t see any command in your events.log to give us an idea of what the binding sees.
I still think you’re going at this backwards. You started with a number for a non-random reason. Is your device (or perhaps will it one day) give position information, or accept position commands? Make that work and transform UP/DOWN into numerics.
Ok, I’m getting an idea what I might be doing wrong here. If I understand correctly, I will probably have to use a transform in any case, since based on my understanding Homie does not have a way to describe a UpDownType. So I’ll have to transform UpDownType to String before sending to the channel.
The events.log lists UP, DOWN, STOP commands:
2020-04-01 19:30:35.665 [ome.event.ItemCommandEvent] - Item ‘ttRollershutter’ received command UP
2020-04-01 19:30:35.666 [nt.ItemStatePredictedEvent] - ttRollershutter predicted to become UP
2020-04-01 19:30:35.667 [vent.ItemStateChangedEvent] - ttRollershutter changed from 100 to 0
2020-04-01 19:30:36.642 [ome.event.ItemCommandEvent] - Item ‘ttRollershutter’ received command DOWN
2020-04-01 19:30:36.642 [nt.ItemStatePredictedEvent] - ttRollershutter predicted to become DOWN
2020-04-01 19:30:36.643 [vent.ItemStateChangedEvent] - ttRollershutter changed from 0 to 100
I started with a number, since my device sends position information, and I have developed it in a way to accept position and UP/DOWN/STOP commands.
On the assumption that Homie does not support any kind of roller function?
And you would therefore define two command topics at your device, a numeric for position command and a text for up/down/stop command?
(plus position reporting via another topic?)
Okay, so stick with your RollerShutter Item, and number channel link, Set up stateTopic and commandTopic for the numerics.
This will ignore UP/DOWN/STOP. (as you’ve already observed)
Now set up another string channel with commandTopic. No stateTopic. Use transform if needed (I think likely not) to convert UP/DOWN to string “UP”/“DOWN”.
I do wonder if you might need the transform to filter out numerics though.
Link this write-only channel to the same RollerShutter Item.
If that’s unworkable, a secondary String type Item may be need for the textual commands. With a rule responding to original Item commands, and reposting to the String dummy.
You’ll almost certainly want autoupdate false on your RollerShutter Item to stop that interfering with status.
Will do that, thanks!
