Send a retained MQTT command from OH

Setup, Configuration and Use Beginners
,
1

Hi there,
I’m using OH 2.5.0.1 on a Raspi Pi3. Have it running an stable for about half a year now with several Sensors and switches on Wifi mainly using native Shellies and Tasmota flashed devices as well as a few Zigbee devices. Nearly half of devices is controlled by MQTT - using the standard Mosquitto broker.
My current project is a completely selfmade rollershutter solution on 12V DC. Using Wemos D1 mini with Tasmota in rollershutter-mode. As everything runs solar-powered i’m aiming to save as much energy as i can and put the D1 mini into deep sleep. It wakes up every x(5) minutes and then goes to deep sleep again. In deep sleep it consumes a minimum of energy but is of course not able to reveive the MQTT commands.
The idea was to work with retained MQTT commands, so if the device comes up and the command was sent during deep sleep it will be performed anyway, once the device is up and running. I did manage to get that behaviour using MQTT.fx, where I published the message during deep sleep and did close the program. Later, when the D1 mini came up it did the shutter movement as expected. As I did close MQTT.fx before I’m expecting that the broker retained the message correctly (and not the client=MQTT.fx). But from OH I can’t get it working. Using a separate bridge and tried several syntaxes as shown below (no error messages from OH):

Bridge mqtt:broker:MQTTBroker “MQTTBroker” [ host=“127.0.0.1”, port=1883, secure=false, username=“XXX”, password=“XXX”, clientID=“openHAB2”, qos=“1” , retainMessages=true] {

Thing mqtt:topic:Rollo_SZ "Rollos Schlafzimmer" { 
    Channels: 
        Type rollershutter : Shutter_Percent_links  [ stateTopic="stat/tasmota_65A31F/SHUTTER1", commandTopic="cmnd/tasmota_65A31F/Shutterposition1",retainMessages=true ]
        Type rollershutter : Shutter_Percent_mitte  [ stateTopic="stat/tasmota_65A31F/SHUTTER2", commandTopic="cmnd/tasmota_65A31F/Shutterposition2",retained=true]
        Type string : Control_links                 [ commandTopic="cmnd/tasmota_65A31F/Shutterposition1", retainMessages=true] 
        Type string : Control_mitte                 [ commandTopic="cmnd/tasmota_65A31F/Shutterposition2", retained=true] 
}

}
The following items are configured:
Rollershutter Rollo_SZlinks “Rollo Schlafzimmer links”
Rollershutter Rollo_SZlinks_Percent “Rollo Schlafzimmer links” {channel=“mqtt:topic:Rollo_SZ:Shutter_Percent_links”}
String Rollo_SZlinks_Control “Rollo SZ links Control” {channel=“mqtt:topic:Rollo_SZ:Control_links”}

The command is sent by a rule like:
if (receivedCommand == DOWN) rollopercent.sendCommand(0)

I’m aware that I need to reset the retained command afterwards (tried it with MQTT.fx with an empty message which worked).
So summarizing I’m struggling to send a retained MQTT command from OH.
Can someone help me out?
Best regards
Frank

2

i don’t think you can just make syntax up. There’s no mention of any retainMessages option in the channel docs.

retained is in the docs, but usage is not made clear. If it is similar to trigger then you would us it like
retained="true"

if that works for you, we should clarify the docs.

You might need to think about that, the binding isn’t really set up for on-off retain operations.

3

Thanks for your quick reply!

Blockquote i don’t think you can just make syntax up
Agree - I just tried a few different ways in the hope that one would work :slight_smile:

I finally felt that the need to clear retained commands afterwards adds the need for some more code and decided to create a kind of own retain-logic, which is probably comparable with an off-the shelf retain-solution.
I’m finally sending commands the usual way with MQTT and remember the actions performed in some local variables. If the device is online then the actions are performed immediately (not necessarily to the end as the deep sleep cuts every action once its time arrives). Once the device comes up again from deep sleep (I check that with the LWT status from the Tasmota device) I perform the stored actions and delete them afterwards. Seems not as elegant as I wanted but also not completely uggly.
Thanks again for looking into that! Cheers

4

Just to add: Of course it would be nice to have the retained options documentation improved to avoid guesswork :slight_smile:
Cheers

5

Someone needs to verify what works here. There’s more than one binding picky about params =true or =“true” etc. so it needs testing.