While I can’t help much with custom modifications, new hardware revisions, etc.; I want to point out that you technically have a relay already with the MHCOZY. There are several unused GPIOs on PSF-B chip that you could connect to to trigger the relay (see my main post for the pinout). Just make sure you reduce the 5V down to 2.5V - 3.6V (3.3V nominal) to prevent damaging the ESP chip. Afterwards you can configure the Tasmota template to use the relay with with that GPIO…
Yes, that’s exactly what I did, I re-used the MHCOZY because I already had one here. Any ESP board with a relay would suffice, no RF needed because I’m now using the RF from the Reolink chime. When the Reolink chime is activated, the Blue LED will blink 10 times or so, and so it’s necessary to have some kind of circuit or logic to make the relay click only once: the ESP is very good for that.
I used the signals on that 3-wire cable between the two boards in the Reolink chime.
White is a signal that stays at about 3.3 volts at idle, and bounces down to about 1 volt when the Blue LED on the chime flashes. Black is ground, and Red is 5V.
Between this white wire and the ESP board I inserted a small circuit:
I had to experiment to get this to work, I haven’t done this sort of stuff in years. I used a 2N3906 because that’s what I had lying around.
I connected the output from my circuit to GPIO5. You could use any GPIO input you need to, but I went for one that didn’t look like it was used. I soldered directly to the ESP chip pins. The 3V3 signal also comes directly from the ESP pins. I just re-used the wires I had attached to put the ESP into flashing mode.
The template I used in Tasmoto removes GPIO0/button1, and inserts GPIO5 as switch1.
Much as I tried I could not get it to work using button, Tasmoto kept resetting itself and I would have to recover it each time. I had to use switch, and I had to use switchmode 1.
I then used these console commands to configure Tasmoto in a way very similar to what you originally had.
so114 1
pulsetime 5
switchmode 1
rule1 on switch1#state do event chime endon
rule2 on event#chime do backlog rule1 0; power1 1; ruletimer1 15 endon on rules#timer=1 do rule1 1 endon
rule1 1
rule2 1
I believe that it is possible to power the MHCOZY and the additional circuit from the red wire in the Reolink chime 3-wire cable. The MHCOZY will work with 5V coming in on its USB connector: I traced this to a good spot on the bottom of the board and injected 5V there. You still need to get 3V3 from the ESP on the MHCOZY board to use in the interface circuit: feeding 5V into the transistor would probably result in sending 5V into the GPIO input and damage the ESP.
This setup is now working, for one button press on the doorbell camera I get one relay click on the MHCOZY. From the doorbell camera management page you can turn off the sound on the Reolink chime, but leave the Blue LED enabled, and the MHCOZY then works to trip the old chime.
Franco
I’m going to return my V2 doorbell. In case it helps anyone looking here in the future, a spectrum analyzer shows that it transmits on 915 MHz.
1 Like
Thanks for the heads-up. I’ve added a warning about this, and will keep a lookout for a similar 900MHz type programmable smart device.
1 Like
One last note.
I discovered that if, by chance, the tasmoto device loses power during the few seconds where rule1 is disabled, after the restart rule1 will stay disabled.
I added a rule to enable rule1 on power up:
rule3 on system#boot do rule1 1 endon
I learned this morning after a brief power outage that the MHCozy continuously cycles the relay whenever it doesn’t have a connection to the WIFI. As soon as it makes a connection, the relay toggling stops. I can reproduce the issue by just unpowering the router and leaving the MHCozy powered. Is there a setting or rule I should have set to prevent this?
23:27:30.458 WIF: Connect failed as AP cannot be reached
23:27:31.459 WIF: Connect failed as AP cannot be reached
23:27:32.467 WIF: Connecting to AP1 (MyWIFISSID) in mode 11n as tasmota-792425-1061…
23:27:44.777 WIF: Connect failed with AP timeout
I’ve never had this happen to me, even after a couple major network updates that took everything down for several hours each time. Not something Tasmota would do all by itself, so sounds like a software glitch. Try the reset 6 fix I mention in earlier posts. If that and a 30 second power cycle doesn’t fix it, try erasing and flashing Tasmota again. Please post back here your results.
Thanks. I did the reset 6 and went back through your setup and it’s resolved now.
I think previously, in my misconfigured Tasmota, the LED was tied into the chime logic. When you lose WiFi, that LED toggles over and over, which caused my doorbell to ring over and over.
So now the doorbell chimes when you push the Reolink button and not when you lose Wifi, but the delay is longer. My guess is the LED lights up when it begins receiving the Reolink signal but the button1 discrete doesn’t get set until the full signal is received.
I’m wondering if I should have a rule to use the LED if Wifi#connected, which would allow a faster doorbell response without it going haywire when the Wifi goes out.
1 Like
Interesting thought, but I would check to see if the LED lights up when a different non-paired 433MHz (say the remote that comes with the MCHOZY if you have the battery) is introduced. It might come on when it detects any 433MHz signal. Just a possible concern. If it doesn’t I might look into that to speed things up. To be fair though, the current method is just as fast as my Ring Pro (v1) that uses the original chime.
False alarms are definitely a concern. If it was as I thought tied to the LED, I don’t recall having any random doorbell rings during the month or so I was using the setup. But I might just try. If I have any 3 am false doorbells, I will certainly revert it haha.
Good to know about ring. It’s not so slow, just a little bit.
For those who have the cam and chime v2, it now uses 915MHz, instead of 433MHz, check this:
now i am wondering, it seems not to difficult to just use a different transmitter and apply this same solution… would it be?
maybe this is closer to the solution being discussed here: