(SOLVED) MQTT with Tasmota device not updating PaperUI

Teknix1 · July 30, 2019, 3:43am

Platform information:
* Hardware: DiskStation 1511+
* OS: 6.2.2
* Java Runtime Environment: Java SE Development Kit 8u212
* openHAB version: 2.4.0

Hi,

First off, I’m rather new to MQTT, I’ve been reading on the subject for a while, I think I get the general concepts but some things are definitely escaping me. I’m trying to setup this switch that I’ve flashed with Tasmota 6.6, I actually got it working. It’s visible in PaperUI, I can click the web UI and toggle its state but I can’t get the opposite to happen. I’d like to have the state in PaperUI reflected when I hit the physical switch. Right now nothing happens, nothing in the logs, I don’t have much to go on. I have several other devices (lights, not shown below) that act the same way. It seems to be one way only at this point.

Here’s my things file:
Bridge mqtt:systemBroker:embedded-mqtt-broker [ host=“192.168.x.x”, secure=false ]
{
Thing topic Test_Switch_Thing “Test Switch Power” {
Channels:
Type switch : Test_Switch_Channel_Power [stateTopic=“stat/DVES_7A8ACB_fb/Power”, commandTopic=“cmnd/DVES_7A8ACB_fb/Power”]
}
}

And my items file:
Switch Test_Switch_Power {channel=“mqtt:topic:embedded-mqtt-broker:Test_Switch_Thing:Test_Switch_Channel_Power”, autoupdate=“true”}

What do I need to do in order for the switch to publish back its state? I’ve tried writing Tasmota rules and various MQTT settings… Obviously my rule isn’t getting triggered either.

rule “Test_Switch_Power Changed”
when
Item Test_Switch_Power changed
then
logInfo(“Test_Switch_Power Changed”, “Changed!”);
end

Any help would be greatly appreciated, thank you!
Nic

rossko57 · July 30, 2019, 10:18am

This is the part that the binding uses to listen out for a topic to use to update the openHAB channel, and so update the Item state.

This is the part that the binding uses to transmit openHAB commands to the device. That you say works.

You probably just need to look more carefully at your Tasmota settings with that in mind, and then make your OH channel settings match . It’s case sensitive.

Teknix1 · July 30, 2019, 12:28pm

Thanks rossko57!

I double checked my settings, I just can’t find anything wrong. I saw online people are using POWER, Power or power. That part at least doesn’t seem case sensitive, I’ve tried them all and it’s the same deal. In the Tasmota console I have tried them all and they all work to control the device.

I thought perhaps it might be the firewall on my Diskstation NAS, so I disabled it and no change.

Here are my Tasmota settings for completeness sake.

Maybe two areas that I’m not too certain about. I’m using the embedded broker, I don’t quite understand the difference between that one or the system one (or are they the same?) and a custom one I would create myself. I had trouble setting up a custom one and found using the embedded one was the easiest way to go. Is this not recommended for some reason? And I’m not using MQTT security, Tasmota shows a Client/User/Password but if I blank those out, they come back (with the exception of Client I believe), I guess that’s what the checkbox above Password is for; to disable security on the device side. I also have the secure=false in the things file, but I don’t know if that overwrites the value in the config seen below… well if I had one set.

Again, thank you for all your help!
Nic

rlkoshak · July 30, 2019, 6:54pm

Have a look at https://learn.sparkfun.com/tutorials/introduction-to-mqtt/all or one of the many introductions to MQTT out on the web. There are tons of YouTube videos if that is more your thing.

To be successful in OH you need to have at least a basic understanding about how the technologies you want to use OH with work.

After that it is important to distinguish between the MQTT Broker and the MQTT Broker Thing in openHAB. The MQTT Broker is a server that MQTT clients connect to to exchange messgages. The MQTT Broker Thing is the representation of the MQTT Broker inside of openHAB.

You don’t create a custom MQTT broker. But you do have to create an MQTT Broker Thing that causes openHAB to connect to the MQTT Broker, even if that broker is the embedded one.

I don’t have access to any of my Tasmota devices (the are all unplugged at the moment) but the “sonoff” in the Topic looks suspicious. I think that would make the topic be

cmnd/DVES_7A8ACB_fb/sonoff or something like that.

According to the docs that topic would be cmnd/sonoff/SwitchTopic if I’m reading it correctly.

rossko57 · July 30, 2019, 9:09pm

You might find it helpful to use a utility like mqtt.fx to monitot traffic and observe what topics are really being published.

Teknix1 · July 31, 2019, 11:56am

Thank you for the great replies, I had to work a lot but I finally got things going! I had made a few mistakes which made the issue difficult to track down.

This was my first clue, I had originally watched a video on the subject and the person was using the fallback topic. I wanted a unique topic for my devices so I chose to do the same.

Thanks for the great tool, I wish I knew about this 2 weeks ago! Using it I discovered Tasmota devices do not publish on the fallback topic, hence why I wasn’t ever getting updates. So I changed my Topic to the client ID.

This makes the Full Topic unique across all my devices (unless there happens to be a collision with the MAC addresses).

Took me a while to actually see it, sometimes it works even though I didn’t use the correct case for sending a command, the other way around is not so lenient. So I switched my Things file to my new Full Topic and correct-case command.

Bridge mqtt:systemBroker:embedded-mqtt-broker
{
	Thing topic Test_Switch_Thing "Test Switch Power" {
		Channels:
			Type switch : Test_Switch_Channel_Power  [stateTopic="stat/DVES_7A8ACB/POWER", commandTopic="cmnd/DVES_7A8ACB/POWER"]
	}
}

Oddly enough things were still not working, one thing I learned the hard way is the model refresh whether it’s for Things, Items or Rules doesn’t always work, the log shows the refresh, but the new information isn’t taken in, perhaps the binding isn’t updated properly… who knows where the issue lies. For something like a case-sensitive change, it would never take. So I discovered I had to issue a restart command for it to be picked up properly

synoservice -restart pkgctl-openHAB

Things are finally good now, there’s still much work ahead, I still want to detect presence (doing that with network ping, but I find it’s too slow) and do proper initialization and recovery in case of loss of power or connectivity. Can I do presence detection with MQTT?

Thanks to every one for all your help, it was greatly appreciated!
Nic

rossko57 · July 31, 2019, 12:07pm

I’ve never pinned it down, but yes, small changes (which are what we most often make when fault-finding) do seem to harder to make dynamically.

It’s just a communication standard. If you can find or make a box that detects people and speaks MQTT …

The most successful schemes combine a whole variety of inputs e.g. someone manually changing a dimmer indicates presence.

Teknix1 · July 31, 2019, 12:08pm

I probably should also mention, the template on the Tasmota device page for the Kuled KS602S is incorrect. It specifies the button is a switch rather than an actual button. I also don’t need the relay in my case, the switch will not be wired to an actual light, it’s for remote control only, so I opened up the device and found a GPIO pin that’s unused and moved the relay value there. This way I don’t have to listen to the relay click. Without the relay, either Tasmota or openHAB gets messy around states. I still have to make sure the relay is in the open position by default but here’s what I’m using for now.

{"NAME":"KULED","GPIO":[17,255,255,255,21,255,255,255,255,56,255,255,255],"FLAG":0,"BASE":18}

I will eventually post this back (or one with the relay value in the correct place) on the Tasmota device page.

Cheers
Nic

Teknix1 · July 31, 2019, 12:13pm

Lol, I probably should have been a little clearer, I meant device presence, so when a device appears to openHAB or checks-in to openHAB. I want to keep a few devices in sync if power ever goes out and comes back on. All my devices are WiFi which is why I use network ping right now.

rossko57 · July 31, 2019, 12:26pm

This isn’t specific to openHAB, but there are two general approaches.

If you’re expecting your device to issue regular reports, you can look out for missed scheduled reports. openHAB expire binding is a useful tool for that job.

If you’re able to query your device, you could do so periodically and check for a timely response, maybe under rules control. A ping, if you like. openHAB REFRESH command may be useful, depending on device.

These methods are not always possible, example, zwave battery fire detector that goes into a deep sleep when nothing is happening.

Again, MQTT is just communication and whether you can tackle a device with these methods depends on device. Additional MQTT features that can be used -

rlkoshak · July 31, 2019, 2:31pm

It’s a known problem in the 2.4 MQTT binding. I believe it was fixed by the 2.5 M1 version. It’s only a problem for those using .things files.

Typically this is done in MQTT using the Last Will and Testament (LWT) message. When a client registers with the broker it can provide a LWT topic and message. When the broker detects that the client is no longer connected, it will publish the message to the LWT topic and anyone subscribed to the LWT topic will be told that it is offline.

However, in a power loss situation I’m not sure what happens if everything goes offline at the same time, including the broker. I could see that this LWT message might be lost.

If you can configure the device to publish a message when it reconnects to the broker, you can use retained messages. When the device connects, it publishes “ONLINE” as a retained message to the LWT topic. When it disconnects, the broker publishes “OFFLINE” as a retained message to the LWT topic. Then any subscriber at any time can see whether or not the device is online or not based on the message in that topic. Without retained messages, the subscribers would have to actually be online and connected to the broker and subscribed to the LWT topic at the time the device comes online or goes offline.

But it should be noted that it takes some time for the broker to detect that a device has gone offline, longer than the default polling period for the Network binding (NOTE: you can change how often the Network binding pings the device or service so if it isn’t fast enough for you, lower the polling number. It’s in milliseconds though I probably wouldn’t go lower than 1000 i.e. 1 second).

Teknix1 · August 2, 2019, 4:12pm

So I’ve gone back to the drawing board a little with this. I read about LWT but ultimately I don’t think that’s what I want. As for Thing presence, I had disabled the network ping but I think now that’s what makes the most sense, so I’ve re-enabled it. Still the way MQTT works is getting in the way a little. Let me explain my set up a little more; I’ve got a few on/off devices that I want to keep in sync, all of them ON or all of them OFF (it’s actually quite more complicated than that, but I think this is all that’s necessary to explain this problem). They are all working with Tasmota and MQTT. The controlling part all works, it’s the (re)initialization phase that doesn’t behave the way I’d like it to. Here’s what I’m trying to accomplish:

When the rules are first initialized, I want all the devices to turn off, I do this through a “System started” trigger and initialize everything the way I want them.
When a single device connects back to openHAB (I figure that’s when the subscription happens on the MQTT topic) after a power failure or else, the state should return to that of the group (not an actual item group, just a few devices programmatically kept in sync). I actually have a global variable that holds what the state should be.

openHAB and the network are on a UPS, so I’m not too worried about that going down, it’s really about the individual devices, if openHAB ever did go down, then the system restart would return everything to default (OFF).

It’s requirement #2 that’s problematic. To the best I can figure, when my device reconnects (MQTT), openHAB requests the POWER state of the device in question, which in turns triggers my change rule, but I can’t tell the difference between that and an actual human interaction with the device. This leads to a change in state and rules triggered, etc. Can this auto MQTT call be disabled, or at least the change rule trigger?

What I’d like instead is when the network ping determines the device is available again, a rule would be triggered to initialize the device to what it should be. I can still do this regardless of the automatic MQTT state command, but then I get a toggle and sometimes the timing isn’t right and it just ends in the wrong state.I don;t actually mind that it can take like 15 seconds to rectify itself, this power outage should be a rare occasion.

I saw a couple of SetOption in Tasmota about things it does on power up but none seem to affect this behavior. Hence why I’m thinking it must be coming from the openHAB side.

Thanks
Nic

rossko57 · August 2, 2019, 5:03pm

Can you not set it up to use LWT - even with no intention of using LWT - and subscribe to that topic to listen for ONLINE announcement?

Teknix1 · August 2, 2019, 5:14pm

I could, but I would still have the issue of openHAB checking the status of the device upon connection and triggering the change event. Unless I’m not seeing something…

rossko57 · August 2, 2019, 5:16pm

Oh, I didn’t see any need for checking, just issuing command to force whatever it was you wanted.

Teknix1 · August 2, 2019, 5:24pm

I get it, I’ll see tonight what I can do with LWT, perhaps I can ignore changes until I see “online”.

Thanks

rlkoshak · August 5, 2019, 2:53pm

There is no such thing a “requests” anything when using MQTT. What is probably happening here is that Tasmota has published the POWER message as a retained message. The difference between a retained message and a non-retained message is that the subscribers have to be actively online and connected to receive a non-retained message. When a client subscribes to a topic with a retained message, it receives that message immediately upon subscription. See Retained huh, what is it good for? Absolutely for details.

It really does seem like retained is the solution for this. If OH publishes it’s messages as retained messages, then when the devices come back online and connect to the broker, they will immediately get the last command sent. There would be no need for a system started Rule then and all your devices will remain in sync because they are all getting the last retained messages.

Don’t use retained messages in cases where you are simulating momentary events (e.g. a button press) but in cases where the command also represents a state you want the device to be in, retained makes a lot of sense.

tl;dr, the MQTT protocol already solves this problem for you, and does it in a much better way than you will ever be able to do in Rules.

Teknix1 · August 10, 2019, 3:48pm

Thought I’d clear out my old threads…

In the end, LWT has proven to be very effective at determining when Things are back online, much better than network ping as it needs to fail for some time to detect that the device has disappeared from the network. LWT is definitely more constant in achieving what I’m after.

As for the original subject on this thread, ultimately I was missing the stateTopic in my things file. I have left autoupdate unset in my items file.

Thank you both rossko67 and rlkoshak, your information has been extremely valuable! I know it takes a lot of effort to reply to all these threads, much appreciated!

Nic