Getting Tasmota power state upon openhab (re)start

[JimT (jimtng)]

Tasmota’s power state is not published as a retained message on mqtt by default.

As a result, if say a light bulb was on and openhab is (re)started, openhab won’t know that the light is on.

My current solution is to add a state channel + item on my tasmota .things / .items file as such:

Thing mqtt:topic:mosquitto:front_porch_light "Front Porch Light" (mqtt:broker:mosquitto) {
    Channels:
        Type switch : power	"Power"		[ stateTopic="stat/front_porch_light/RESULT", transformationPattern="JSONPATH:$.POWER", commandTopic="cmnd/front_porch_light/POWER" ]
        Type dimmer : dimmer "Dimmer"		[ stateTopic="stat/front_porch_light/RESULT", transformationPattern="JSONPATH:$.Dimmer", commandTopic="cmnd/front_porch_light/Dimmer" ]
        Type string : reachable	"Reachable"	[ stateTopic="tele/front_porch_light/LWT" ]
        Type number : rssi	"Wifi Signal Strength"	[ stateTopic="tele/front_porch_light/STATE", transformationPattern="JSONPATH:$.Wifi.RSSI" ]
        Type string : state "State" [ stateTopic="tele/front_porch_light/STATE", commandTopic="cmnd/front_porch_light/STATE" ]
}

Group gTasmota

Switch Front_Porch_Light_Power "Porch Light Power" <switch> (gTasmota) ["Switchable"] { autoupdate="false", channel="mqtt:topic:mosquitto:front_porch_light:power" }
Dimmer Front_Porch_Light_Dimmer "Porch Light Dimmer" <dimmer> ["Lighting"] { channel="mqtt:topic:mosquitto:front_porch_light:dimmer" }
String Front_Porch_Light_Reachable "Reachable: [%s]"	<contactable> { channel="mqtt:topic:mosquitto:front_porch_light:reachable" }
Number Front_Porch_Light_RSSI	"WiFi Signal Strength [%d %%]" <wifi>  { channel="mqtt:topic:mosquitto:front_porch_light:rssi" }
String Front_Porch_Light_State "State"  { channel="mqtt:topic:mosquitto:front_porch_light:state" }

And created a rule:

import org.eclipse.smarthome.model.script.ScriptServiceUtil

rule "Poll Tasmota device status on startup"
when
    System started 
then
    gTasmota.allMembers.forEach[ item | 
        val baseName = item.name.split("_Power").get(0)
        val stateItem = ScriptServiceUtil.getItemRegistry.getItem(baseName + "_State")
        stateItem.sendCommand("")
    ]
end

This will send an MQTT message cmnd/xxxx/STATE thus getting Tasmota to respond with stat/xxxx/RESULT, which will get picked up by the corresponding _Power and _Dimmer items.

Once the MQTT Action bug has been fixed (hoping it will be in 2.5M2), I will change this to using MQTT Action rather than having a separate channel / item.

Does anyone have a better solution?

[rossko57]

There is actually an openHAB made-for-the-purpose command, REFRESH, which may be sent to any Item. It’s up to the bindings what to do about that, if anything.

It’s of limited value in MQTT. If the binding supports REFRESH (don’t know) it could fetch a retained topic from the broker. But if you can’t get Tasmota to publish with “retain”, that’s useless.

Then there’s the added complication that you’re probably restarting the broker at the same time. You may need to delay your rule because of that.

[JimT (jimtng)]

luckily I use a separate mosquitto process. Out of curiosity, how do you do a delayed startup rule?

[rossko57]

A generalized method

What is the best method to start executing the rules when all bindings are loaded

I really hate polling rules so instead of @bajan’s suggestion, which I don’t think would work in all cases, I would do the following: Create a Switch Item which will act as a flag indicating that the system is starting In all of your rule that you want to prevent from running until your bindings have finished loading add a check to make sure that Item’s state is OFF Create a system started triggered rule that sets the Item to ON, then sets a timer for however long you need to ensure that all t…

But if you only want one delayed task, use the createTimer rule from there and put the task (your existing rule code) in the timer code block.

[JimT (jimtng)]

@rossko57

If the binding supports REFRESH (don’t know) it could fetch a retained topic from the broker. But if you can’t get Tasmota to publish with “retain”, that’s useless.

AFAIK MQTT2 doesn’t support REFRESH - at least not that I know of.

Tasmota can be made to publish retained state (I think, I haven’t investigated it thoroughly, as I read there may be some complications to doing so which I haven’t looked into). In any case, my idea is so that I don’t have to go through too many steps in setting up a new Tasmota device and just use its defaults as much as possible. The default happens to be not retained.

Thanks for the rule loading pointer. Another thing to keep in mind.