Hello again,
I’m currently wondering if someone already did some rule which will basically double check if cmnd was really received by target device. In this case Tasmota.
because QOS is currently possible to set only on broker level, which would not work for my whole setup I need to somehow make sure that one device will receive given command.
My idea is, because tasmota is broadcasting stats to the MQTT broker after cmnd is received to somehow monitor that after cmnd was sent and if there is no response, send command again.
But honestly not really sure if that will not create any kind of loop so some ideas would be appreciated
Something like
rule "check"
when
cmnditem received update
then
currcmnd = cmnditem.state
currstatus = statusitem.state
currstatus != currcmnd
cmnditem.sendcommand(currcmnd)
end
The best option is to disable autoupdate on the item.
This way the item state will ONLY be updated on receiving the stat payload and not automatically by openHAB
No, if you are only interested in “lost” commands, then that is the only time you need to check.
Example, trigger rule from command to Item X, start a timer that will report failure (or retry). If update arrives from X, cancel timer.
It depends on how the command is sent. But a simple rule would be something like that:
// put global vars on top of the file
var Timer tCheck = null
var String sCommand = ""
rule "double check state"
when
Item myItem received command
then
if(tCheck === null) {
sCommand = receivedCommand
tCheck = createTimer(now.plusMillies(500),[|
if(myItem.state != sCommand) {
myItem.sendCommand(sCommand)
tCheck.seschedule(now.plusMillis(500))
lodInfo("check","Resent command {}",sCommand)
} else {
tCheck = null
}
])
}
end
It’s possible to use the rule for more than one item with slightly different code, but you have certainly either to use a timer and command hash map or take care that the items are only used in sequence, as the command is repeated until the item got the correct state. Please be aware that that this rule is intended only for switch items.
You can make two Broker Things, each with different QOS settings. That would be the least amount of work over all.
This is a also a case where the retained flag would be appropriate. Then if the switch is offline or otherwise unable to receive the message, it will get it as soon as it can reconnect to the broker.
Then there is no need for the Rules even to make sure the device got the message in all cases. All that is left is to utilize autoupdate=false, as already mentioned so your Item doesn’t change state until the device reports that it has changed state.
It’s really not that simple. For some implementation retain is really not that great solution.
yes, it’s a way. But still bit of double work
@Udo_Hartmann thanks. It turned out that my main rule for given device is robust enought it kind of check itself as it is just resend command on value change, which is quite often. Not great, not terrible.
It’s orders of magnitude less work than trying to solve this problem using Rules.
Indeed. But from what you described, commanding ON/OFF a switch, retained is appropriate for this use case.
You asked whether your approach was the best option. The best option is to create a second Broker Thing with your desired QOS and set retained to true. Using a Rule will be tons more work and error prone.
