I’ve not had the first problem that you describe, but number 2 does sound very familiar. I know what you mean about it seeming like MQTT lag as there is a slight lag even when it works, but of course MQTT should not come in to play here as the switching is being done from within the firmware. You are right that sometimes it seems like the failed switching attempts are grouped, i.e. that it can work fine 20 times then all of a sudden 5 times in a row it will fail.
Im afraid im not clued up enough to advise on how a resistor or capacitor might fix the problem, but I did carry out the experiment above on Rudie’s advice although I’m not sure if it is any help to you.
The only thing i can think of is to replace my standard lighting cable with shielded speaker cable in case that is the problem.
The resistor between 3V and GPIO is a Pull-up. It should not he necessary based on Cint’s test (that seems to indicate there is already a pull-up in the circuit) but can’t hurt to try. The capacitor between gpio and gnd is to debounce the switch. This is worth a shot if you get multiple triggers caused by the contacts bouncing. You can put a cap over the switch contacts on the wall plate side saving you having to open the mini in the ceiling.
I’m officially out of ideas for the erratic behaviour. Multiple triggers can be explained but a switch that sometimes works and sometimes doesn’t is beyond my skills. It would be great to have a oscilloscope on gpio to see what’s happening.
Maybe try the shielded audio cable next and let us know if anything changes.
I replaced the sonoff mini with another one. Same behaviour… I upgraded all the sonoffs to Tasmota a few days ago. The original ewelink software didn’t cause this lag and/or ghost switching. I am starting to believe it is related to tasmota. How is this possible… I don’t want to go back to ewelink though
Umm I find this whole discussion very interesting.
My story is that I run a little AirBnB (granny flat) on my property. The main house is constructed in such a way that ANY wiring is very difficult to do/hide (redwood clad walls Etc.) I initially wanted a simple way of knowing when the hot water service was in use so that I could avoid using the washing machine Etc. when guests were in the shower - my old Rheem system didn’t have a wireless remote control unit. As such, the the normal remote units were not that practical as they use fixed wiring and the signals are not readily decoded. My solution was to install a flow switch on the inlet pipe of the heater and use the switch to operate S1,S2 on a Sonoff Mini. The mini doesn’t actually do anything other than triggering an automation in Home Assistant when turning on and off. Because it does this I can use any number of other Sonoff Basics around the place to turn on their LED’s when triggered. Again as such, the Mini acts like a broadcaster and the remote units act like receivers and light up. The whole system works fantastically and because S1,S2 are 3.3v it’s almost decoupled from the hot-water service. In fact, the flow switch is plastic… So all good and works well with the Sonoff Mini about 1m from the hot water service. I’ve got these in three bathrooms, kitchen, laundry Etc.
My second project was to try to improve my commercial wireless doorbell system to stop it going off when guests arrive at 02:00am next door Etc. or after power failure’s where it would seem to latch onto the frequency that is first used nearby. For this project I already had a wired 12V doorbell from the street into the house that would then operate various receivers in the house, shed Etc. This seemed like a good candidate for the the same strategy Eg. use the doorbell button press to connect to S1,S2 and then use triggers to operate various ding-dong appliances that were on my network.
Now what I found is that the length of the cable from the pushbutton into the house makes the the Sonoff Mini oscillate crazily. It’s not quietly “ghosting” but rather going crazy. If I put a simple switch onto S1,S2 with negligible wiring it’s fine. I assume therefore that the cable I’m using for my doorbell is profoundly influenced by nearby 12V, 240V Etc. The cable is of course old telephone cable. I thus conclude that because the Mini has 3.3V on GPIO4 that it very prone to induction, interference and other stuff if the cable is anything other than short, well-shielded and possibly twisted.
If you have any ideas how I might fix this problem I’d be grateful. Is a low pass filter the answer? If so how does it get wired on a Mini as I’m just a newbie.
I ended up doing a klutzy work-around for my specific issue. To close S1/S2 I used a solid state relay. That worked fine as the wires were only 15cms long. To operate the relay I converted the the old doorbell system from passive to active by squirting 5v down the line from an old phone charger. Looking back the Mini was a bad choice because it is VERY SENSITIVE to induction issues. I only used it because it had an on/off switch already exposed. I’ll probably redo this with a ESP-01S and daughter Relay Board at some stage in the future. So my experience with the Mini is mixed. The first project was a dream the second showed that is a bit less than “Nearly Perfect”
Mmm. You might be onto something here jmann! Maybe Cint’s problem could be explained by a noisy induced signal drowning out the 3v signal. Once in a while the 3v might win and switch and them seem erratic. This is the opposite of the induced signal creating false triggers but is a theory that could be explored.
The passive approach sounds like a plan… switch a relay in the attic next to the mini with the wall switch and switch the mini with the relay contacts. Or put some more serious filtering on the line and mini input. My analog skills are unfortunately to a standard to give you proper advice on how.
Forgot to add that perhaps the Ewelink firmware has beter software de-bounce or filtering than Tasmota. ESPHome is nice in that sense that it gives you full control over debounce, delays and filters so there might be a software solution after all.
Hi, did anyone get to the bottom of this? I have a simple switch with a series of downlights. The s1 and s2 are rigged up to a physical switch. Sometimes it works. Sometimes it doesn’t. I’ve tried the capacitor idea, but still no use.
The issue seems to be more of a problem if I’ve turned the lights on with Alexa, they then won’t turn off with the physical switch.
Any support would be really well received. It’s driving me mad (and my wife now hates the fact I’ve rigged the house up with sonoffs).
I changed the bulb, from an old CFL energy saving type to an LED and it seems to have improved the performance a lot, maybe from working 75% of the time to working 95% of the time, and being a lot quicker to respond. Not sure why, or why it still occasionally fails but its so rare now it has stopped bothering me and my wife has not even complained
I’m seeing the same symptoms here, also a Sonoff Mini:
Originally running Tasmota 6.6.0, configured to subscribe to my MQTT server
Wall switch hooked up with a ~4 meter copper cable
No 220V running parallel to the cable
Symptoms:
Wall switch “sometimes” doesn’t immediately turn on the light. When in this state, it can help to slowly turn it on and off a few times. Then it will start working again.
After a LOT of experimenting, I’ve narrowed it down to a software issue. If “MQTT support” is disabled, the problem goes away! This means it’s a software bug, since the electrical characteristics are the same with or without MQTT support.
I’m trying to upgrade tasmota versions (now testing 7.2.0), to see if moving to a newer release makes the bug go away. I’ll report back if I find something.
Hi, I have the same behavior with fan. Sometimes the hw switch does not switch it at all, sometimes it does many times in a row. Control over HA is reliable.
How can disabling MQTT can solve it while it communicate over MQTT? Or what particular “MQTT support” option you have on your mind? Thx
Well, disabling MQTT obviously removes the ability to talk to it over MQTT
What I meant was, that with MQTT disabled, the physical switch works reliably. That seems to rule out an electrical problem, and proves it’s a software bug.
