@boorky I have noticed that if I leave the lights on for a while, after a couple of hours, the relay bounces and the light flashes. Have you noticed any similar behavior?
Yes, I noticed that too
I`d like to share some findings after a weekend playing around with these devices. I have a few Blitzwolf BW SS5 2 gang relay. But they look like an exatc match for the Moes hardware we are talking on this thread. Here are all the issues that I found and how I solved them?
- AC Frequency detection
- Light on when turn the device on
- Relay bounces every once in a while
- When S1 is on and the device is turned on, L2 flashes
Issue 1 was heavily discussed on the threads and solved. However, I would like to add some thoughts, frequent pulse counter is very unreliable unless you increase the update_interval and delay_on_off values to a point where you will notice the delay when you toggle the switches. And depending on how long you leave it on, it will still happen that the light will flash. But if you still decide to go on that road, make sure you change the log level to INFO, avoiding that the log will send mqtt message every time the pulse counter updates, also causing the device to heat up as it is almost always as 100% consumption. So âunfortunatelyâ, the only real solution I could find, is the one from this github issue, which is basically add 2 capacitors to the GPIO inputs. 4.7uf to 10uf will do the trick without adding any delay to the switches, since the vdc is 3.3v you may add the smallest you can find to fit the case.
After this, the flashing, delay, heating and logging issue are all gone. I did that for all my devices.
Issue number 2 is also fixed with the capacitor trick, otherwise, refer to my previous post where I suggest a global variable to ignore the first changes to the pulse counter.
Issue 3 happens because the API connection gets lost every once in a while, and in case it stays disconnected for more than 15 minutes, esphome will reboot to try to fix the issue. I could notice that behavior in the full logs after adding the capaciotrs. Then I tracked down this github issue which uses the same chip and faced the same error. So basically the solution is this:
esphome:
name: xxxxxx
platform: ESP8266
board: esp01_1m
arduino_version: 2.4.2
This arduino version works well with this chip and I havenât noticed the api disconnecting anymore.
Issue 4 I could not fix it, and it also happens on the standard firmware, so I take this is a hardware issue, as this behavior happens only when the switches are in a given position in case of a blackout, I let this one stay.
Sorry for the long reply, but I hope this info helps anyone who is facing those issues.
Sure, I use several files with includes and substitution to avoid duplicated code, but here is the translated part for what you are requesting:
output:
- platform: gpio
pin:
number: 14
mode: OUTPUT
inverted: false
id: relay_01
- platform: gpio
pin:
number: 15
mode: OUTPUT
inverted: false
id: relay_02
light:
- platform: binary
name: esplightsbackup01 Light 01
id: light_01
output: relay_01
restore_mode: RESTORE_DEFAULT_OFF
- platform: binary
name: esplightsbackup01 Light 02
id: light_02
output: relay_02
restore_mode: RESTORE_DEFAULT_OFF
binary_sensor:
- platform: gpio
pin:
number: 13
inverted: true
mode: INPUT
name: Switch 01
id: switch01
internal: true
on_state:
- then:
- light.toggle:
id: light_01
- platform: gpio
pin:
number: 12
inverted: true
mode: INPUT
name: Switch 02
id: switch02
internal: true
on_state:
- then:
- light.toggle:
id: light_02
But I highly doubt that you coded the pins incorrectly. Some issues that I faced that might help you.
- After the modification, sometimes when you close the case, the button gets pressed, if that happens, the device does not respond, I had to drill a hole in the plastic on top of the little reset hole to avoid this in some of the devices.
- I noticed that if the switch is more than 3m away from the device, or if you have a 2 way switch, it also does not work every time. But to be honest I did not attempt to undo the modification to test if that was the issue because I was already too pissed with this device.
Meaning I am using those devices only inside the wall switch with the capacitor modification and the above config, I am having no issues besides some temporary wifi drop.
Let me know if you have any additional question.
1 Like
my version with capacitors:
switch:
-
platform: gpio
name: KĂ´ĹĄ
pin: GPIO14
id: Rele_1 -
platform: gpio
name: Dvor - prednĂ˝
pin: GPIO15
id: Rele_2
binary_sensor:
-
platform: gpio
pin:
number: GPIO12
id: rele1
on_state:
then:
- switch.toggle: Rele_1 -
platform: gpio
pin:
number: GPIO13
id: rele2
on_state:
then:
- switch.toggle: Rele_2
I assume that the picture is for the Blitzwolf devices. I have the MS104-B and it is, unfortunately, a much different circuit board layout.
The Moes device is horribly flaky in that it comes on spontaneously for some reason. When this happens in the middle of the night when everyone is sleeping it does not invoke feelings of love in the better half 
So lacking another solution I plan to replace it with the more expensive Shelly 2.5.
I had the feeling they were the same, given the image is from a github issue about moeâs device. Nevertheless, if you can avoid those, just do it. But once again I vouch for the loratap ones I mentioned above. Their official store on aliexpress even has an esp session now. I have 38 of those running lights and shutters flawlessly for quite some time now. The shipping is relatively fast too, one of my purchases arrived within 14 days.
Thank you for the update. The Moes devices were cheap but they seem a bit too unstable for reliable use. I will check out the loratap ones on aliexpress otherwise Iâll probably go with the Shelly ones as they seem to have a good rep as well.