I have the funny idea to propagate a command to my MQTT broker for further processing.
I’m on openhab3 - very cool version by the way
Currently I have this configuration for test purpose: DateTime UG_Sensor_TS01_TIME "Sensor Zeit" { channel="mqtt:topic:SHELLY1_T_68A42D:LASTSEEN" }
Thing mqtt:topic:SHELLY1_T_68A42D "Shelly 1 - Sensor Test" (mqtt:broker:mosquitto) {
Channels:
Type number : TEMP0 "Temperatur 01" [ stateTopic="shellies/shelly1-68A42D/ext_temperature/0" ]
Type number : TEMP1 "Temperatur 02" [ stateTopic="shellies/shelly1-68A42D/ext_temperature/1" ]
Type number : TEMP2 "Temperatur 03" [ stateTopic="shellies/shelly1-68A42D/ext_temperature/2" ]
Type string : LASTSEEN "Timestamp" [ stateTopic="shellies/shelly1-68A42D/lastseen", commandTopic="shellies/shelly1-68A42D/lastseen",postCommand="true", retained="true"]
}
In my rule, on every change I want to have a last seen time stamp propageted to the mqtt broker.
The catch seems to be I’m triggering on a group:
import org.openhab.core.model.script.ScriptServiceUtil
rule "DEV - DIAGNOSTIC RULE"
when
Member of gShellyExtTemp changed or
Member of gTempHumid changed
then
logInfo("diag", "update for " + triggeringItemName )
var String tsName = triggeringItemName.substring(0, triggeringItemName.lastIndexOf("_"))
tsName = tsName + "_TIME"
val DateTimeType dt = new DateTimeType(Instant.now().toString)
logInfo("diag", "updating for " + tsName + " : " + dt)
var item = ScriptServiceUtil.getItemRegistry.getItem(tsName)
//val mqttActions = getActions("mqtt", "mqtt:broker:mosquitto")
//mqttActions.publishMQTT()
item.sendCommand(dt)
end
The command is not propagated to the mqtt broker.
Am I expecting too much or is there an error in my thinking?
Not related to your problem, but new DateTimeType() is equivalent to new DateTimeType(Instant.now().toString).
Also, I don’t know for sure if this would work or not but you might be able to apply the timestamp profile and the follow profile on the Item linked to the LASTSEEN Channel. If you can (and I don’t know if you can apply more than one profile to a single Link) you can at least use the timestamp profile and when the Item changes use the publishMQTT Action to publish the new timestamp. That at least would make the rule simpler and you wouldn’t need a separate Channel.
Also, since your LASTSEEN Channel is configured to publish and subscribe to the same topic which is likely going to lead to an infinite loop. If the only thing publishing to this topic is openHAB then get rid of the stateTopic on that Channel. If not, then the stateTopic and commandTopic need to be different.
That looks like a bit of a screaming loop to me? Item command seen by channel and published to command topic X, channel subscribed to identical state topic X will also get the payload back, apply the option to post it as a command to the Item … and round we go again?
I’ve seen no mention of it not working but that doesn’t mean anything. I may have missed it.
Yes but you might be getting into a loop of some sort preventing the messages from being sent. It’s hard to say. You’ve provided no logs to show what is actually happening. For all we know the Rule isn’t even running given the evidence we have.
The bit we are missing now is what the channel this Item is linked to currently looks like.
When last seen, the channel was of type string which I suspect will not mate easily with an Item of DateTime type?
postCommand literally does not do anything when you have no stateTopic for it to apply to. I don’t know how else to put that.
When editing parameters, sometimes the binding needs to be restarted to pick up new settings. After that, please expand on “not work”.
No. I have no idea what topics you should be listening to, or how to interpret payloads received, nor what topics you want to send what payloads to.
This forum contains a great many examples of MQTT configuring, mostly for OH2, which is the same as OH3 when you have chosen to use xxx.things files.
Again you have implemented a loop here.
If an incoming message is received on the stateTopic that is subscribed to, the postCommand option takes the payload and transforms it into a command to the linked Item (instead of the more usual state update).
Commands to Items are passed to linked channels, so it comes back to this MQTT channel and is sent to the broker using the commandTopic.
At least the topics are different, so it is not an endless loop
I’m not sure if you misunderstand what postCommand is for, or more fundamentally what Item states and commands are about?
To my understanding, stateTopic is incoming from device, commandTopic is outgoing to device.
As you descibe it, this might be an absolute misconception of the function.
But I still don’t get, why updates, neither via postUpdate nor sendCommand, are not send to mosquitto.
Should postUpdate be reflected on the MQTT?
Loop or not - shouldn’t I be able to see something incoming on the topic when there is a postCommand or sendUpdate triggered from the rule?
That’s correct. That describes the MQTT side of affairs.
So let’s look at what happens when you do get a message on stateTopic, that needs communicating to the Item.
By default, that is done by sending a state update to the Item.
Exceptionally, you might want a command within openHAB instead - say the MQTT payload represents a remote control button and you want that to emulate a UI click.
For that purpose, the postCommand option is provided. When invoked,it changes the usual stateTopic action so that an incoming MQTT message puts a command on openHAB’s event bus for the Item instead of a state update.
An OH command will trigger rules etc. like any other command, and also any bindings, so you need to take care about loops when using this unusual option.
No. The binding listens out for commands to the Item.
Bit confused what you’re expecting here, maybe above clarifies.
That should be clear now - they’re not supposed to be.
Depends where you are looking. sendCommand should result in a message going to the MQTT broker, what happens then is outside our control. You should be able to see that with an external monitor tool like mqtt.fx.
sendCommand would not normally result in an incoming (to openHAB) topic unless you have deliberately configured a loop with in/out topics the same.
Thanks for the fast reply.
I will try again and report back. Currently it feels like something is not going the right way, as it was working until I restarted my OH3 host - but I can’t exclude human error at this point
