SwitchTopic 1 and unavailable MQTT server work as SwitchTopic 0

[nordeep]

Module Type: Generic
One Relay1 and two Switches - Switch1(Button), Switch8(HC-SR501 - Pir sensor)
Options: SwitchTopic 1, SwitchMode8 1
MQTT Library: MQTT_TASMOTAMQTT

When MQTT Server is unavailable Switch8 work as if SwitchTopic 0 mode is enabled - it changes the state of Relay1 - ON/OFF.
As far as I understand Switch8 should not to change Relay1 state, just tries to send MQTT messages.

[arendst]

It's a feature as the main goal was when MQTT is unavailable the switch on the device should still be able to control the relay.

That people are mounting up to eight switches to the device is their responsibility....

[nordeep]

I use an external MQTT-server, and, unfortunately, for me it looks like:
At night Internet provider has disconnect my router.
Sonoff Module lost MQTT connection.
Switch8(PIR-sensor) started to control Relay1 - lights at night began to switch on and off, while everyone was asleep around.

Why Switch8 map to Relay1 not to Relay8? Could I to unmap Switch8 from Relay1?

[Frogmore42]

Since you don't really have 8 switches defined, define one of the unused GPIOs (like GPIO 15) as a relay, probably a good idea to make it Relay2, and change the switch that is now Switch8 to 2 also. If you don't have a matching relay, it will control the one that is available.

[Frogmore42]

You might also want to get your own MQTT server to avoid the problem. Setting one up is pretty easy.

[ascillato]

You also can use rules that overrides switchtopic behaviour. See the wiki for examples

[andrethomas]

@nordeep Use rules as @ascillato suggest but it will be even better to do as @Frogmore42 said... get yourself a mqtt server on your network then you will not have this problem. I also used a mqtt broker until the internet was down one day and I couldn't turn stuff on and off because some of my devices are custom built and don't have pushbuttons (LOL)

Just get a pi-zero or something similar - Mine is running on a Pi A+ (which is really low spec) and its been running flawlessly since the original setup. You can then even install a HA software switches even more interoperable with other devices and software.

[ascillato2]

Hi,

If you think that your question has been answered, please close this issue. Thanks.

[nordeep]

Thank you all for the suggestions!
I have use local HomeAssistant instance on OrangePi PC but with external MQTT-server, because OrangePI PC based on Armbian not stable and reboot frequently. Local MQTT-server may also be unavailable for one or another reason.
I have tried to use rules, but this complicates the solution, and my Tasmota-devices was unstable.
I have used Switch8 by reason of integrate Tasmota-devices to HomeAssistant as PIR-sensor. I took the last Switch for this purpose.

For me it seems strange that Switch8 control Relay1.
And I noticed the following: If I'm not using Switch-Relay in order Switch1-Relay1, Switch2-Relay2, but Switch1-Relay1, Switch3(PIR-sensor)-Relay3 - Switch3 begins to control Relay1.
How do you think this is correct?

[andrethomas]

You can still install mosquito on the orange pi - even if it reboots the service will start again.

[nordeep]

Yes! But we still have a lot points of failure when MQTT may not be unavailable:

1. WiFi not available - router failure
2. DNS not available
3. PI-server not available - hangs or another issue

Each of them can lead to crazy house(in my case - switch on/off lights at night by PIR-sensor).

From my point of view - the device must do its job perfect. What I want to say - If I tell to Switch8 to send ON/OFF signals, I expect Switch8 will send ON/OFF signals and not to try to switch Relay1(which is controlled by Switch1) in any case.

[Frogmore42]

Is there a reason you are using Switch 8 and not 2?

Does it work like you want if you use switch 2 and define an unused pin as relay 2?

Does it work like you want if you use switch 8 and define an unused pin as relay 8?

All developers make decisions about the desired behavior of the code (what I call intent). The code is a reflection of that intent. It might or might not be an accurate reflection/implementation of it. In this case, Theo has made it clear that it his intent that the relays still be controlled when MQTT is down. It appears that the way the code implements that intent does not match what you want. I believe if you do what I suggest (use switch 2 and define relay 2 to an unused pin) you can let the code know your intent and then it can implement both or your intents.

Finally, if the device is not perfect enough for you, the code is available for you to fork and implement your intent exactly as you see fit. Once you have it working, you can submit a PR and it might get included for everyone to benefit.

[tlpbu]

The feature @arendst mentioned is well intended but cases undesired flickering with PIRs connected as some switch.
I noticed it yesterday when restarted Home Assistant and mosquito broker was down for a minute - PIR started to control relay on Sonoff Basic directly.

Is there a chance we can disable that for certain switches via rules or configure fallback per switch with some command?

[brainnex]

it will be really nice to see a switchmode that override this feature. Like tlpu mentioned is very annoying because the lights flicker in 2 seconds on and of if there is PIR and motion. The sonoff RF is for example switched on by a rf remote but it become unusable on PIR motion until wifi and MQTT is working again

[ascillato]

It is a feature as the main goal was when MQTT is unavailable the switch on the device should still be able to control the relay. If you don't want that behaviour, use rules that overrides this, and you can set the behaviour you need.

Examples of rules are in the wiki.

[brainnex]

ok. I give the rules a try when i have some time. But in my opinion will be nicer to have a new switchmode for that if this feature doesn't cost to much flash.

[ascillato]

Sorry. Rules are not a workaround for that. It is the way Theo has designed an option to allow the user to change the behaviour of the device to fit your needs.

May be, you didn't like the way it is presented this option to change your Tasmota behaviour. I understand that. May be in the future we can have a configuration GUI for rules in for example TasmoAdmin Software and to be shown as simple as IFTTT does.

[nordeep]

The reason why I have use Switch8 - this is last Switch and I can hang the PIR-sensor and apply mqttwarn topic templates like (topic = cmnd/+/POWER8) to gathering a statistics. I have use devices with 1,2,3,4 relays.
For now I have found the next solutions:

1. Use Switch1-Relay1, Switch2-Relay2 without missing.
2. Use last free Switch for PIR-sensor.
3. Add last free Relay to free PIN for PIR-sensor's Switch.

In this case if MQTT-server unavailable - PIR-sensor's Switch control its Relay not Relay1.

It remains strange for me if MQTT-server unavailable:

1. Why Switch without assigned Relay starts control Relay1?
2. Why if Switch-Relay order missing next free Switch-Relay, last assigned Switch starts control Relay1?

[tlpbu]

Please don`t just close the issue, @ascillato!
Hear what people are saying - this behaviour is quite confusing and in some cases even illogical which cases weird side effects thus should be finetuned.

While I completely agree that taking as an example Sonoff Basic switch1 with switchmode1 1 should have fallback to switchmode1 0 in case of MQTT unavailable and control relay1 directly.
But IMHO switch2 should not affect relay1.

I spent about an hour trying to understand why switch2 (PIR) is affecting relay Sonoff Basic. Event when I understood that this somehow correlated with MQTT broker being unavailable due to restart I still did not understand why until I found this issue.

[ascillato]

Hi,

It has been explained how Theo has designed the behaviour of these options before closing this issue. Sorry if you felt it differently.

I agree that it is confusing at first, but after reading the wiki you can learn how all this options works. There is no need for spending time in developing new switchmodes as it is actually a way to make the behaviour you want using rules. If the actual switchmode don't fit the behaviour you need, you can use rules to config the behaviour you need.