How to send an initial MQTT message to get the status of a tasmota switch?

Hi,
I'm new to node red, but could at least implement a switch to a tasmota switch via MQTT.
It worked after I change the switch.
But due to the fact, that I've initially missed the last state, I'm searching for a mechaism to send an initial command (which is known) to the switch to get the current state.
How is it possible in node red?

You could try this, replacing the name SPOW-02 with the name of your tasmota device (topic mqtt) and also de broker MQTT
Press once on the injection node and the answer arrives on the debug node
Nodes:
image

Flow:

[{"id":"9c507fdbc5f56a9f","type":"tab","label":"Tasmota ask status","disabled":false,"info":"","env":[]},{"id":"90a068732a3eeb9f","type":"mqtt out","z":"9c507fdbc5f56a9f","name":"Ask status","topic":"cmnd/SPOW-02/STATUS","qos":"","retain":"","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"84fa01dd79cb7065","x":490,"y":120,"wires":[]},{"id":"bbbd7e9d0e1d06f4","type":"inject","z":"9c507fdbc5f56a9f","name":"Ask status 8 to Sonoff","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"30","crontab":"","once":false,"onceDelay":"1","topic":"","payload":"8","payloadType":"num","x":270,"y":120,"wires":[["90a068732a3eeb9f"]]},{"id":"2ded94c6faf4b4cb","type":"debug","z":"9c507fdbc5f56a9f","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":470,"y":200,"wires":[]},{"id":"fb245c79da2948bc","type":"mqtt in","z":"9c507fdbc5f56a9f","name":"Télémétrie SPOW-02","topic":"stat/SPOW-02/STATUS8","qos":"2","datatype":"json","broker":"84fa01dd79cb7065","nl":false,"rap":false,"inputs":0,"x":240,"y":200,"wires":[["2ded94c6faf4b4cb"]]},{"id":"84fa01dd79cb7065","type":"mqtt-broker","name":"test","broker":"192.168.10.10","port":"1883","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willPayload":"","willMsg":{},"sessionExpiry":""}]

Debug exemple:
image

Make the switch topic Retained (that is configurable in tasmotta I think). Then when node-red starts up the broker will automatically give it the current state.
Read this excellent tutorial on MQTT and it will tell you lots of useful stuff. MQTT Essentials - All Core Concepts explained

Thx and yes, I've already read, that I can enable the retain flag.
I just hopped that there is another way, something like a single shot timer after the startup of node red.
Or a timer, which will be automatically started and which I can stop after receiving the response.
Something like that.

Isn't there a status message that is sent every now and then that gives you the condition of the device?
(Sent from said device)

The problem I can see is if NR is not active and the switch changed its state..... Even if the state is stored in MQTT broker: it will then be wrong.
Won't it?

I have done stuff with Tasmota switches but I am like you and still only just keeping myself above the water line of knowledge.

Why? What would another way do that a Retained topic does not?

No, it won't be wrong. The switch will send it's new state to the broker whether node red is running out not.

Yes, but I meant if the MQTT BROKER is down..... I don't know if the broker is on the same machine as that which is being turned on/off.

Sorry for the confusion.

I apologise for saying NR in my post. (Crossed wires) :wink:

Ok, understood. On my systems I consider node red to be the master so I make the device command topic that controls the switch Retained too. The result is that when the device connects to mqtt the command gets sent and the switch is forced to the required state.
If you want the state of the device to be the master then I seem to remember a setting in tasmota to publish the state when it connects, but I am not certain about that.

Yes, and I am sorry for the confusion.

I thought the example was an all in one at this point.

Anyway. All good. Glad that confusion is/was resolved....

Well.... Is it?

Ok, as I see things:

The switch (Tasmota)
MQTT broker
RasPie

When the RasPie gets turned on, it needs to get the state of the switch and sync with it.
Yes, if the retain flag is set on the state of the switch then the RasPie should get a message telling it the state and then process the message to set the indication on the dashboard accordingly.

Under what circumstances would the pi be off long enough for the switch to be manually changed? I assume that would only happen in some sort of fault condition.

If it is their test machine......

Sorry, I am not seeing it in the same context as you. No problems.

I'll leave well enough alone.

Yes, I am sure that activating the retain function should work. I'm going to test this out today.
My question is rather general.
As a C ++ developer, I just expect there to be something like initialization so that I can do things like turning on the retain flag if I haven't already.
By the way. I'm not sure how long this state will be stored, ideally in the eeprom, but this is not documented. And I'm not running on a PI, but on a Windows server. But even there, updates can lead to reboots or whatever. And after the reboot, I'm in an unknown and possibly wrong state.
I know I might be able to fix this with the retain flag.
But I don't understand this loophole or requirement that one should get along without initialization.
I will now check the timer nodes. If I can force a timer to be called every second or so, I'll be close to this type of initialization. If I find a way to turn the timer off again...

Hmm. If a fault condition can arise, it will arise. (sods law?)
And if a fault condition cannot possibly arise, it eventually will arise ("nothing can possibly go wrong with our nuclear reactor")

I see I am going to have to look into mqtt retained messages.
With my Tasmota switches I send cmnd/device/status (as @Jean-Luc suggests) at intervals. If I don't get a response in n seconds I know something is wrong and I can change my dashboard display from an assertive "The heater is off" to a neutral "No data"

For ever, provided the MQTT broker is correctly configured. Mosquitto, for example, saves them to a file.

It makes no difference

No, the broker will restore the retained topics from the disc (or wherever it has stored them).

There is initialisation, when a client gets connected to the broker it gets given the initialisation data. Why would you need to ask for it again later?

What exact scenario are you trying to recover from that needs this?

I guess they are just covering all the bases.... Not fully understanding all the workings of MQTT the question begs to be asked.

Aren't there messages that are sent by/from the TASMOTA device every now and then?

A satus message or something?

No, I don't mean the broker. That's clear. I mean the tasmota device.

I would like to have a node, which will be called automatically during the startup like the injector node, without the need of pressing a button manually (which is nice for testing but not usable for a setup-and-forget smarthome server).

You may want to look at the poweronstate

I just checked and I am seeing a ...../tele/STATE message now and then and it tells me all about the device. If it is turned on/off and all the other stuff.

Would that be helpful for you to keep things in sync if things go awry?