I have wired some light switches with Shelly1 which are running ESPHome. They were running Tasmota previously, and there I have never seen the issue.
The Shelly1 extends a normal light switch setup, previously there was the light switch on the wall directly switching the light with 230V AC.
The Shelly1 is now used to extend that setup with some features, the main feature is to turn off the light after 10 minutes if forgotten to be switched off via the light switch.
So the light switch should keep its function, switching the light on/off, but this is done via the Shelly1 SW Input, which uses 230V over the physical switch to detect if it is closed or open. Any state change of the switch turns the light on, if off, or off if on (the physical switch is a switch which stays in position and is not a button which goes back to its original state after releasing). In addition to this, the light can be turned off via esphome after 10 minutes.
What is the issue:
In some cases, which I need to figure out now. The Shelly1 turns off the light before the 10 minutes are over or the button was pressed.
Looking this up in the logs and correlate the button (the physical switch which triggers it) and the relay shows some gaps. Which could be normal, but the time gap is not 10 minutes as configured.
So I must assume something else is happening there, and I see the issue on all 3 installed Shelly1 running ESPHome, so I conclude that it is not a hardware issue (or at least I hope).
Here is the yaml I use for the Shelly1 - perhaps the issue is there.
Also, if your button binary sensor is wired to short the GPIO to ground when the button is pushed you need to add a pull-up resistor between the GPIO and 3.3V.
OR
If your button binary sensor is wired to short the GPIO to 3.3V when the button is pushed you need to add a pull-down resistor between the GPIO and GND.
Anywhere between 10K to 51K Ohms would be ok, use a resistor from the lower end of that range of values if the wires to the GPIO are longer than a meter.
Thanks, going to try changing the switch behavior.
About the wiring and the resistors, this is all 230V AC, so I do not really know how the Shelly handles all of this internally but even the switch is using 230V phase (L) to know if closed or open.
Also interesting is, that the original software as well as tasmota never showed the problem over weeks / month of usage and they were “setup” to act the same way as with esphome.
Perhaps you could give me some more advice on the resistor part in this setup, because I am not sure if and why it is needed on that 230V AC setup.
I tested your idea, but realized that it cannot work, and does not work. Because it turns on the relay, but never of if I use the switch again.
I would have to wait 10 minutes all the time, so perhaps I was not precise enough in my previous statement.
The switch is a normal 230V On/Off switch used in homes to turn of lights, but now instead of directly wired to the light the Shelly is in between.
The switch stays in its position and should turn on / turn off the light if used. If the light is turned on for 10 minutes the shelly should switch it off.
This is because sometimes you just forget to turn off the light when leaving the room.
I hope this helps to get this figured out somehow.
Thanks
Thanks for the fast response, but this does not work es expected
Because the switch stays in its position when switch we do run in situations where the switch closes the circuit, light gets turned on, after 10 minutes it is turned off by the delay setting. Well, now the switch is closed, so I need to change its position to be “open” again and “close” it again to turn on the light.
My solution does not care about the state of the switch if it is closed or open, but as soon as the switch changes from one state to the other, the light is either turned off (if it was turned on) or it gets turned on (if it was turned off). And important is, that it should not matter if the light (relay) got turned off via the switch or the delay instruction.
This is why I have chosen the “on_state” option. With your solution the switch must always stay in the “right” position like a real physically wired switch, which adds extra “switch actions” if turned off automatically.
What I am investigating also, right now, is if the Shelly “reboots” or “shuts down” if this weird things are happening. Because if the Shelly loses power while the light is turned on, the light immediately gets turned of because the relay falls back to its default position which seems to be “open”.
A firmware restart does not have this effect, but a power loss does. I am still not sure if this can be somehow avoided on the Shelly but for now I have an “uptime sensor” installed to see if the uptime gets reset if the issue occurs.
Basically because I do want to avoid external communication This is also the reason why I am using Home Assistant. And for the Shelly, at least the firmware updates need Internet access, and firmware updates are there for reason so the should be done.
Also for the Shellys I have, I would need to go to every single one of them to get it updated, whereas with ESPHome on HA this is so much easier to rollout a new firmware to all my devices.
But anyhow, I will try to troubleshoot the issue as good as I can, if it is a error in the code or a missing feature this should / could be resolved. The hardware is capable of doing it, tasmota and the original firmware was able to do so, so esphome should be too.
Flashed the devices with Tasmota month ago, never happened again. The behaviour of the devices stayed the same, but no random relays which drop and turn of the lights.
I’m just pointing out that the reason you gave was incorrect and that a perfectly working local solution exists that does not require all this effort. But by all means use what you prefer.
There are benefits to esphome over the stock firmware. Anyhow, besides the reason it seams that with esphome the relais is dropping randomly. So I asume a bug or something I am not considering and nobody else has experienced yet.
Anyhow, fact is stock firmware works, tasmota works - no hardware issue but a software related issue.