I was wanting to know if someone could help me with a problem i currently have that i need to solve.
Equipment:
Sonoff T1 2CH
Sonoff T1 1CH
I have the T1 1CH in the hallway and it has just a neutral and a live connected to keep it powered. I need this 1CH switch to turn on the light and the light is currently on the T1 2CH (2nd button/bottom).
I need it to act by turning on both buttons when the light is ON and when the light is off then both bottoms need to be OFF.
Im not sure if there is a easy tasmota setting with ButtonTopic? or do i have to do this with MQTT?
Which is best and how does one do it?
The easiest way to do this is to have a rule like this on the single switch
on power#state do publish cmnd/DOUBLE_SWITCH/power2 %value% endon
This will fire every time the power state changes on the switch (which will normally happen when you press the button), and it will publish an MQTT command for the second relay on the other switch to make its power state the same.
Then we need a similar rule on the double switch:
on power2#state do publish cmnd/SINGLE_SWITCH/power %value% endon
Now each time either switch’s power state changes, it’ll send a message to the other to match itself. No need to involve Home Assistant at all.
If one of the devices gets a command that would put it in the state that it’s already in, then those rules will ignore it because the power state will not have changed.
Cool. I only used the example of POWER2 because you said it was the second switch. But it would totally depend on how you had it configured in TASMOTA. Glad to hear you got it working.
Are you implying that it’s still doing the crazy switching like in that video?
Can you view the console of one (or both) of these lights and the HA log when this is happening? Could there be other TASMOTA rules or HA automations at play here? I have the same two rules on two switches and my setup behaves exactly like you want.
I’ll be damned. I just experienced the same thing. My solution is to not do that I can’t see why you would ever do that under normal conditions. This must be a race condition within TASMOTA.
Allow immediate action on single button press 0 = single, multi-press and hold button actions (default) 1 = only single press action for immediate response (i.e., disable multipress detection). Disable by holding for 4 x button hold time (see SetOption32).
I have mine set to 1, wondering if i should delay it.
I have SetOption13 set to 0, so I don’t think that’s your issue. I believe that this is caused by the difference in time it takes to switch the relay locally on a button press vs. publishing the MQTT command for the other switch to switch. If you press one of the buttons twice before the other switch has processed the command, then the command the second switch sends back when it toggles will be the “wrong” one.
I don’t have a good solution for this. There will always be some finite amount of time between when a relay has toggled and something else has processed an MQTT message resulting from that toggle. If your actions are quick enough, or MQTT messages fall in just the right order (which is what I think is happening here), then you would experience this. It’s definitely caused by the two switches sending messages to each other; I just never experienced it before today.
You could rewrite the rules as HA automations, and I’ll bet it would introduce enough latency that this would never happen. You could even include conditions to see that the other light was not already in the state you wanted, and just not publish another command, and that would completely eliminate the problem. If I can circumvent HA and just have things work on their own, I like to do that, but this might be a case where you choose to do involve HA for better logical decision making.
I came back to this recently after our happened to me with only two presses. I’m glad that I heard about this problem or I would have been seriously freaked out
Anyway, I’ve solved it by just having two discrete rules for on and off rather than one for toggle. The problem arises from the toggle command always doing something whether it was in the “right” state or not. Each switch just needs this defined with the MQTT topic of the other.
on POWER1#state=0 do publish cmnd/LaundryRoom/POWER 0 endon on POWER1#state=1 do publish cmnd/LaundryRoom/POWER 1 endon
Did you manage to find a solution to this?
I’m doing a 2way switch and all is working unless accidentally double press the button and then they go in to a very fast loop?
Any sort of debounce function to stop it from this behaviour?
It’s not really a “debounce” kind of situation. I haven’t found a “good” solution, but I have a “good enough” solution for my situation. The two switches I’m using are for a bathroom, and an attached laundry room with no other entrance than the one inside the bathroom.
I have set up the bathroom switch to cause the laundry room switch to match its state, whatever that happens to be, but not the other way around. Then the laundry room’s long press toggles the bathroom. This way the MQTT messages will never occur fast enough to cause this type of feedback loop.
There’s another solution where you can have the rules fire only for the switch state, and not for the power state. So like this:
on switch1#state=2 do POWER TOGGLE endon on switch1#state=2 do publish cmnd/other_switch/POWER TOGGLE endon
I use two separate rules rather than a backlog command here because the time it takes to process the backlog command is noticable. Separate rules seems to be faster, especially when it comes to control of the local relay. However, since this solution is only using toggles and not explicit on/off, the switches can get out of sync if they are operatated by means other than the switch (i.e., REST, MQTT, etc.)
Everything I’ve tried has drawbacks…I haven’t found a “perfect” solution yet.
Thanks for the quick reply Steve, much appreciated. I’m going to be using an MQTT PIR sensor to trigger these lights so the power toggle probably won’t work for me.
I’ll be sure to come back and update if I find anything that helps.
The only real problem with the crazy switching is when you have a two devices that control each other’s power based on their own power. You can get a feedback loop. Using a PIR sensor, shouldn’t be any problem.
Found this topic after I had my switches go into a loop several hundred times within a few seconds having the exact Rule as you. Interestingly never happened on 6.5.1, but only when I updated to 8.x recently. Maybe it was too slow before
I can’t see why you would ever do that under normal conditions. This must be a race condition within TASMOTA.