Java Runtime Environment: openjdk version “11.0.9.1” 2020-11-04
openHAB version: openHAB 3.0.1
Issue of the topic:
I am new to OpenHAB3. I’m coming from several years on HomeSeer and so far while I overall have liked what I’ve seen, the one challenge I’m running into is integrating MQTT with Points or Items. I have created an MQTT broker and Generic MQTT Things. On my Generic MQTT Thing, I created a channel with an event and command topic on it. My intention is to have various points or items update the topic with their status any time they change. For testing purposes I created a dummy switch and included a ZWave motion sensor. On the point for the motion sensor, I linked the MQTT Channel for motion that I created:
I would expect that whenever the sensor changed status between ALARM and OK, there would be something sent to the topic I created. Nothing happens and there isn’t anything I can see in the logs to indicate anything is happening.
I know that my MQTT broker is set up correctly because I tried going a different route and created a rule that looks for changes of Items that are part of a Group and then runs a script to send the Item status to the MQTT topic. And that works great! I don’t hate that solution but I would like to know if I am doing something wrong with linking my generic MQTT thing to my items. The output I get from my rule looks like this:
Alright, so far as I can see a change of state of Item ZoozSensor_Alarmmotion should result in publishing to /openhab/motion/state. There are no logs generated for this - though of course you should see one for the Item state change.
That’s what I thought too. I’m watching every topic with:
mosquitto_sub -v -h localhost -t /#
I’m definitely not missing anything that way but the only updates I get are the ones I force through the rules. With my rules set up I see updates from my temp sensor, OpenWeatherMap, my motion sensor, and my dummy switch. But none of them update the state channel on state changes when I link the items and generic thing. I guess I’ll keep playing with it and at least have a usuable workaround right now.
Only if the motion sensor is sending a command to the ZoozSensor_Alarmmotion Item. If it’s just updated the Follow profile won’t trigger, right?
I can’t say this is universal, but my one Zwave motion sensor receives updates from the binding for the motion sensor, not commands. @codefox, you can tell what’s happening in your system by looking at the events in events.log for that Zooz Item. If you only see “changed from X to Y” type log entries and never a “received command X” type log statement you will know that your Item is being updated, not commanded.
It typically requires a command to cause an Item’s change in state to be sent on to the binding and out to a device. Updates are usually just internal. So if you are only getting updates, your rules approach may be the best you can manage.
@rlkoshak Thanks for the advice. I was playing with it some more and what I’ve discovered is that (unsurprisingly) it was partially user error. I was using a text channel for the motion sensor when the device itself is a switch. I honestly don’t see why that would matter but when I created an switch channel, I just started getting updates to the command topic. I’m a little fuzzy still on why they wouldn’t go to the state topic but it’s progress. But my rule may be a better way to do this still unless I’m able to achieve more flexible output on the Generic MQTT Thing.
The output from the linked channel looks like this:
I started playing around with the transformation field in the channel properties but it hasn’t had any effect yet on the output. For the purpose of using the data being sent to the MQTT topic, obviously the more verbose output is more useful.
Because a string command “ON” is not the same as ON, and vice-versa. A switch type channel receiving “ON” won’t know what to do with it.
I was prepared to say “I missed that!” but the UI is just hiding the channel types here. I think that’s a deficiency.
There are some nasty little traps when linking dissimilar type Items and channels.
The channel sends the commands you send it. Like ON. There is no more verbose version of ON. What is it you want to send? You can transform in various ways.
The use of the follow profile upends this. Normally a command to an Item gets sent to all linked channels, but a state update doesn’t.
Follow profile blocks commands to linked channel, but translates state events to command instead for that one channel.
@rossko57 That’s funny you say that about not missing it because when I looked at the information I put in there I thought maybe I missed something but I realized that information doesn’t make itself obvious after you create the channel. I agree that they are absolutely different things. I’m assuming I could probably do a transformation on the Switch output to string but that seems unnecessary. This is all good though, I’ve only been playing with this for a couple of days and I can see that once I learn how everything works, there’s a lot of power here.
As far as what I’d like to send to the MQTT channel, just the device name or id. I’m using my own external rules (don’t ask, its a personal project for me 8) ) so I need to know the device that sent the status change. I updated my rules script to send this:
/openhab/motion/command ZoozSensor_Alarmmotion:ON
This way I can put all of my motion sensors into a single group and the rule will output the sensor name & status to the topic. I imagine I can do the same thing with the transformation on the channel but I’m not sure which I prefer more.
Since the channel is tied to only one Item, you can use the " formatBeforePublish" option or whatever the UI calls that to prepend/append any fixed text you like to the ON/OFF payload.
If you don’t like ON/OFF, you would have to use a transformation.
The Item type must match the type dictated by the Channel. You can’t mix and match without something to translate between the two.
The state topic is the topic openHAB subscribes to. That’s how the external sends messages to openHAB. The command topic is the topic that openHAB publishes to. That’s how openHAB sends messages to the external.
Don’t forget that Switch type Channels have a built in transformation for simple mappings.
