It seems "SwitchTopic 2" (or "SwitchTopic mytopic") would allow this behavior, but the relay output is still getting triggered when the device is first booting. (Maybe other times too, not sure).
https://github.com/arendst/Sonoff-Tasmota/wiki/Understanding-SwitchMode-and-SwitchTopic
Have you look for this feature in other issues and in the wiki?
This is the closest I have been able to find:
https://github.com/arendst/Sonoff-Tasmota/issues/2795
Is your feature request related to a problem? Please describe.
I wish to be able to connect door sensors and other inputs (assigned in the Configuration as "Switch1", "Switch2", etc.) and have an MQTT message be sent to SwitchTopic, but without turning on/off the corresponding relay ("Relay1" for example) if it is present.
Describe the solution you'd like
I would like to add another SwitchMode which behaves similar to "SwitchMode 1" (FOLLOW), but does not control a corresponding relay number. I believe this only requires adding an option to the "SwitchModeOptions" enum in sonoff.h and adding code in the "SwitchHandler" function in sonoff.ino to implement this behavior. For example, we could add the following case to handle this new mode:
case INPUT_ONLY: // Allows sending of input state via MQTT without controlling relay
switchflag = button &1; // Follow input state
break;
And then add the check below before calling the ExecuteCommandPower function as follows:
if (Settings.switchmode[i] != INPUT_ONLY) {
ExecuteCommandPower(i +1, switchflag, SRC_SWITCH); // Execute command internally (if i < devices_present)
}
Note, I have not yet tested this change but I believe it will work and will allow a flexible way to read input pins on the device without also controlling connected relays if this is not desired.
Describe alternatives you've considered
An alternative might be to use a different Switch number than the Relay number (for example, so a change in Switch2 does not affect "Relay1", however in my case I am using all 8 switches so this is not possible.
I just tested the code change above and it did in fact fix my issue. As mentioned I believe the issue where the relay triggers during boot-up may also have to do with the fact that I am using "Relay1i" and "Relay2i" (inverted logic relays). [It may also have to do with the fact that I am using "PulseTime", not sure.] Just guessing, but is it possible when using "Relay1i" (inverted relay), it is not setting the output value to the correct state before changing the pin from an input to an output?
I have a similar issue which would benefit from this change. The relay only triggers when the MQTT broker is unavailable:
I have a Sonoff SV with a PIR configured on GPIO 4, as below:
{"GPIO1":"0 (None)","GPIO3":"0 (None)","GPIO4":"10 (Switch2)","GPIO5":"1 (DHT11)","GPIO14":"0 (None)"}
{"SwitchMode2":1}
{"SwitchTopic":"sonoff1"}
When my MQTT broker is running this works as I expected, tripping the PIR results in a MQTT message thus:
09:34:03 MQT: cmnd/sonoff1/POWER2 = ON
and the relay is not toggled on. This is what I want to happen. When the MQTT broker is unreachable the following occurs on PIR trigger:
09:36:00 RSL: stat/sonoff1/RESULT = {"POWER":"ON"}
09:36:00 RSL: stat/sonoff1/POWER = ON
The relay closes and the device connected to the output turns on. I do not want this to happen, if the network or broker is down I do not want the power to turn on after the PIR triggers, I want nothing to happen.
See below for example console output from the web page when my device boots-up when using "SwitchMode 1" and with SwitchTopic set to a custom topic... notice how the POWER1 and POWER2 relays are changing states (b/c the corresponding switches "Switch1" and "Switch2'" are changing states when the device is booting). I believe this should not happen with "SwitchMode 1" and "SwitchTopic mytopic" set, so maybe this issue needs to be fixed, rather than adding a new SwitchMode to fix the issue as I have shown in my initial post.
00:00:00 Project sonoff HDMI Switch (Topic hdmi_switch, Fallback DVES_EXXXXX, GroupTopic sonoffs) Version 6.1.1-2_3_0
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER2":"ON"}
00:00:00 RSL: stat/hdmi_switch/POWER2 = ON
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER1":"ON"}
00:00:00 RSL: stat/hdmi_switch/POWER1 = ON
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:00 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER2":"OFF"}
00:00:00 RSL: stat/hdmi_switch/POWER2 = OFF
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:00 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER2":"OFF"}
00:00:00 RSL: stat/hdmi_switch/POWER2 = OFF
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:00 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:00 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:00 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:00 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:00 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER1":"ON"}
00:00:00 RSL: stat/hdmi_switch/POWER1 = ON
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER1":"ON"}
00:00:00 RSL: stat/hdmi_switch/POWER1 = ON
00:00:00 WIF: Connecting to AP1 my_wifi in mode 11N as hdmi_switch-12345...
00:00:00 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:00 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:01 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:01 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:01 RSL: stat/hdmi_switch/RESULT = {"POWER2":"ON"}
00:00:01 RSL: stat/hdmi_switch/POWER2 = ON
00:00:01 RSL: stat/hdmi_switch/RESULT = {"POWER2":"OFF"}
00:00:01 RSL: stat/hdmi_switch/POWER2 = OFF
00:00:01 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:01 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:01 RSL: stat/hdmi_switch/RESULT = {"POWER1":"ON"}
00:00:01 RSL: stat/hdmi_switch/POWER1 = ON
00:00:01 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:01 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:01 RSL: stat/hdmi_switch/RESULT = {"POWER2":"OFF"}
00:00:01 RSL: stat/hdmi_switch/POWER2 = OFF
00:00:01 RSL: stat/hdmi_switch/RESULT = {"POWER1":"ON"}
00:00:01 RSL: stat/hdmi_switch/POWER1 = ON
00:00:02 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:02 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:02 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:02 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:02 RSL: stat/hdmi_switch/RESULT = {"POWER1":"ON"}
00:00:02 RSL: stat/hdmi_switch/POWER1 = ON
00:00:02 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:02 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:02 RSL: stat/hdmi_switch/RESULT = {"POWER1":"ON"}
00:00:02 RSL: stat/hdmi_switch/POWER1 = ON
00:00:02 RSL: stat/hdmi_switch/RESULT = {"POWER1":"OFF"}
00:00:02 RSL: stat/hdmi_switch/POWER1 = OFF
00:00:03 WIF: Connected
Hi,
If you use a rule like:
rule 1
rule on switch#state=1 do publish cmnd/sonoff/something ON endon
it will do as you expected.
Please, read the wiki at commands and rules. Thanks.
Thanks for the suggestion to workaround this issue, I'll give it a try. However, I believe the fact remains that there is a bug during start-up that needs to be fixed. According to the wiki (see text below), when a user-defined topic is defined ("SwitchTopic 2", in my case "SwitchTopic hdmi_switch_source"), it should not trigger anything unless a device is listening to that topic. Should I close this and open a new issue?
SwitchTopic 2
Set MQTT switch topic (32 chars max)
This will send a MQTT message with a user-defined topic. Whether this message will trigger anything
depends on the setup of the user. For example, when setting the topic to sonoff2 this could trigger the
relay on the Sonoff device that listens to messages with this specific topic.
Hi,
It is designed like that. If you do not have a connection to a MQTT Server, it will act as a normal switch.
The rule is not a workaround, it is the way of changing the above behaviour to the one you want. That is the way that was designed.
Hope this clarification helps. Do not hesitate on ask anything else you need. Thanks
I understand the concept of creating a rule to publish a message when the switch changes state.... but it is not clear from the documentation how this rule prevents the relay from changing state when the switch changes state. (I do not want the switch to affect the relay.) All available SwitchModes indicate affecting the relay in some way.
You are right. It is not enough clear on the wiki. Rules overrides switchtopic.
I have tested this and it indeed overrides switchtopic, as long as switchtopic=0
Spent a frustrating hour or so trying to get it to work before I tried that.
Possibly the wiki needs updating that rules for switches will NOT trigger unless switchtopic=0
Yes, can you do that please?
Done.
Great! Thanks a lot :+1:
Ok I made the updates to use a rule and it is also working as expected. Thanks!
However, I still like the idea of creating a new switch mode which always just sends the state of the pin via MQTT using the defined switch topic, without the need for rules. This seems simpler and cleaner to me (would reduce user confusion). Also I think this would be a pretty common use case when using inputs (such as door sensors) that do not influence the outputs (such as a relay).
Thanks again for the help. Here's to hoping a new switch mode is considered for a future update.
Oh and I believe the docs could be updated similarly to indicate it is necessary to set buttontopic=0 to allow rules to override the behavior.
FYI, I just figured out that rules don't currently support publishing retained messages...
https://github.com/arendst/Sonoff-Tasmota/issues/2861
So I'm back to using my custom "INPUT_ONLY" SwitchMode.
@jsmath will you help me out. i'm a tasmota noob console is confusing to me. i have a PIR sensor connected to GPIO 14 of sonoff basic what im trying to achieve is when motion is trigger send an MQTT command if mqtt broker is connected and do nothing if its not connected.
PIR is on GPIO pin14 = Switch2 (10), SwitchMode1 = 0, SwitchMode2 = 0. when i try to send command SwitchTopic 2 i get below result which says SwitchTopic is set to 0.
06:40:54 CMD: SwitchTopic 2
06:40:54 MQT: stat/sonoff/RESULT = {"SwitchTopic":"0"}
@ashfaaaa
Please, address your issue in the Tasmota support chat. Thanks.
Most helpful comment
Ok I made the updates to use a rule and it is also working as expected. Thanks!
However, I still like the idea of creating a new switch mode which always just sends the state of the pin via MQTT using the defined switch topic, without the need for rules. This seems simpler and cleaner to me (would reduce user confusion). Also I think this would be a pretty common use case when using inputs (such as door sensors) that do not influence the outputs (such as a relay).
Thanks again for the help. Here's to hoping a new switch mode is considered for a future update.
Oh and I believe the docs could be updated similarly to indicate it is necessary to set buttontopic=0 to allow rules to override the behavior.