Unexpected Virtual Switch Behavior

[leng]

Configuration:
Domoticz on RPI 4 running RPI OS.
Sonoff S31 plug flashed with Tasmota firmware
Sonoff is plugged into mains and a lamp plugged into the Sonoff
Two Hardware items:
Dummy for switches
Mosquitto – MQTT Client Gateway with Lan Interface
Virutal switch (on/off) for Sonoff shows correctly on the Devices Tab

From the Domoticz web interface everything works fine, complete control including scheduling of lights when a lamp is plugged into to the Sonoff

Here is my question.
I believe MQTT uses TCP/IP which is guaranteed delivery, so if I unplug a Sonoff from the wall, I should not see the virtual switch change state, but it does show go from on/off even though the Sonoff is not plugged in. I do see the off/message go out on the Domoticz out topic.
I don’t see any error in the Domoticz log and don’t seem to have any errors on the SYS topic.
In my application, I really want to know if the Sonoff endpoint actually changed state - got turned on or off.
Is there a way to make the virtual switch/icon not change state if the message is not received by the Sonoff?

Thanks for any help.
Len

[waltervl]

A virtual switch will only switch when commanded so. This can be done by the Tasmota switch or by a script. So if you unplug the Tasmota switch nothing should be sending anything to the virtual switch.

So you should check what is controlling your virtual switch next to the Tasmota switch itself. When using mqtt you can check with the programme mqtt exploreren if MQTT messages are sent afterwards. https://www.domoticz.com/wiki/MQTT#Debugging_MQTT

[FireWizard]

Hello @leng,

@waltervl wrote:

A virtual switch will only switch when commanded so. This can be done by the Tasmota switch or by a script.

That is correct, a virtual switch will change between "On" and "Off" in case that either the virtual button is pushed in the Domoticz Web UI, or by a received MQTT or HTTP message, or a script. In all cases the virtual switch will send a message on the topic domoticz/out, except if received by MQTT and the MQTT "Prevent loop" setting has been set to "True".


You have already observed that, as you said:

From the Domoticz web interface everything works fine, complete control including scheduling of lights when a lamp is plugged into to the Sonoff

You said also:

I believe MQTT uses TCP/IP which is guaranteed delivery, so if I unplug a Sonoff from the wall, I should not see the virtual switch change state, but it does show go from on/off even though the Sonoff is not plugged in. I do see the off/message go out on the Domoticz out topic.
I don’t see any error in the Domoticz log and don’t seem to have any errors on the SYS topic.

No, no guaranteed delivery.

Let me explain a little more about MQTT. Indeed it runs on top of TCP/IP.
It is a publish/subscribe protocol, which means that, if a publisher has something to transmit it will publish the message to an available MQTT server (previously also called broker). It will normally use QoS 0 (Quality of Service), and 0 means more or less "Fire and Forgot". A possible client has to subscribe to the topic on the same server in order to receive the message. The publishing party (Domoticz), has no idea, if and when, a client subscribes to that topic. In this case the subscriber is your flashed Sonoff with Tasmota.

In my application, I really want to know if the Sonoff endpoint actually changed state - got turned on or off.
Is there a way to make the virtual switch/icon not change state if the message is not received by the Sonoff?

I understand what you want but the answer is short: No this is not possible

I realize that this is a rather short answer, as there is one way, but I do not know if that is possible with Sonoff and Tasmota.

What to do?

Write an application for the Sonoff device that publishes an answer to some topic on the server, if an On/Off command has been received.
A script in Domoticz can monitor that topic, with a time-out, and control the virtual switch, so that in case a valid answer not has been received within an acceptable time the switch will be either turned On or Off.

But as said, I do not know, if that can be made on your device. In Domoticz it is possible.

Regards

[Kedi]

My Tasmota devices respond to a ping, so you could use the ping command or the System Alive Checker at least to see if the Tasmota device is still connected to the mains.
I have a Sonoff Pow R2 Module flashed with Tasmota and the status is sent to MQTT on: stat/<dev>/RESULT = {"POWER":"OFF"}

[leng]

Thanks to all for quick replies.
I do understand that I could modify the Tasmota code and add/or add a script in Domoticz to get behavior close to what I want.
However, I'm a bit perplexed that the behavior I want isn't more directly available for the following reason:

It seems like MQTT uses TCP/IP and if it tries to talk to the Sonoff and can't connect it will get an error, and then could send a message (to a specified subscriber) that an error occurred. I'm assuming MQTT tries to send a message to all "current" subscribers, and the broker would know about the failure. I did look briefly into the Mosquitto error logs and didn't find anything there, so I will revisit that and see if I can find anything on that side of the interaction.

--Len

[Kedi]

Two reading links: https://www.techtarget.com/iotagenda/de ... -Transport and https://www.hivemq.com/blog/mqtt-essent ... ce-levels/
Perhaps set your QoS to 2
Edit: Sorry, I just read that Tasmota can only use QoS 0

[leng]

Thanks for looking further into this, those references are great.
Everything makes sense now. I'll have to think about the best way to proceed.

--Len

[FireWizard]

Hi, @leng,

There is many information for MQTT available on the internet.
The links provided by @Kedi are good ones.
You might want to look at https://blog.akenza.io/what-is-mqtt?utm ... jQQAvD_BwE as well.

For QoS I recommend to read http://www.steves-internet-guide.com/mq ... os-to-use/

Keep in mind that Domoticz has no configuration option for QoS in the MQTT hardware, so I assume QoS is 0 and that means that the overal QoS is also 0.

I did not say that you can modify the Tasmota code, I said you can write a script for Domoticz.

I hope that you understand that MQTT is working in two steps.
1. Client 1 to MQTT server.
2. MQTT server to Client 2.

So the only solution is that the Tasmota device punlishes a confirmation message to some topic.
Then a script can subscribe to that topic and can switch the virtual switch back.

The $SYS topic does not offer a solution.

However you can ask the Tasmota device for its status.by sending an empty payload.

So if you create a script that sends an "On" or "Off" command and directly after it sends a status query, compare the result and if it is equal it is okay, if not received within a defined time or unequal, reverse the status of the virtual switch.

Just an idea.

Regards

[leng]

Thanks for the help.
Right now, it seems like the sending a "probe" message with a script is probably the most straightforward approach -- it's a good suggestion.
I've also posted a question on the Mosquitto forum to see if, by chance, they log any connection failure which could be put on a "bad connection" topic. I'm pretty sure this is not likely, but it would be a cleaner approach. I'll post here is they come up with something of note.

--Len

[FireWizard]

Hi, @leng,

This morning I have been reading about Tasmota and its MQTT commands and responses.
See: https://tasmota.github.io/docs/MQTT/

Previously I suggested to create something that could return a message from the Sonoff.
But Tasmota is doing that by default. So if you monitor the response of stat/%topic%/RESULT , you can check the result. If the response has not been received before the time-out has expired or if the result is false, you reverse the status of the virtual switch.

Regards

[Kedi]

@FireWizard Just a few replies above....

[FireWizard]

Hi, @Kedi,

Yes, you also said the same, that you had that with your Tasmota device, but I hope, that it is clear now, that this functionality is available.

Regards

[pikassent]

Hi!
I was looking for same solution for a long time and, at the end, the best approach was to use the autodiscovery python plugin by emontnemery (sorry, not allowed to post urls => forum topic 21918)
As mentioned in the features:

State in Domoticz in synchronized with device state (unlike if using Domoitcz MQTT + "Dummy hardware")

Based on "HaveTimeout" variable, you will see the red upper bar in switch tiles as currently for the sensors (utility tab) when using builtin hardware MQTT AD. At least, you have a visual warning to avoid not "reachable" on/off changes.

Hope this helps.

PS: Would be very helpful to include this feature in main hardware MQTT AD (sorry, no skilled enough to suggest a source code PR based on python plugin code (function onHeartbeat))

[leng]

Great suggestion. I've installed the plugin and it is mostly working.
Right now the only problem I have is the need to refresh the Web UI in order to get the red banner when a connection failed. It takes about 15 seconds before the banner appears if you constantly refresh.
I tried two browsers and get the same behavior.
Fortunately, the device "virtual light bulb" does not turn on (when switching a disconnected switch to on), while the connected ones show up as "on" immediately. So one can quickly see a problem connection even if the red banner doesn't appear.
This may be cockpit failure on my part, so it needs a bit more investigation.

I'm very impressed with Domoticz, and don't know why it doesn't get more positive PR.

--Len