anyway now I have problem with uploading it to WeMos
This is related to known problem on Mac’s with Ardunio not finding USB port
esptool.py v3.0
Serial port /dev/cu.Bluetooth-Incoming-Port
Connecting........_____....._____....._____....._____....._____....._____.....____Traceback (most recent call last):
File "/Users/Hotest/Library/Arduino15/packages/esp8266/hardware/esp8266/3.0.0/tools/upload.py", line 66, in <module>
esptool.main(cmdline)
File "/Users/Hotest/Library/Arduino15/packages/esp8266/hardware/esp8266/3.0.0/tools/esptool/esptool.py", line 3552, in main
esp.connect(args.before, args.connect_attempts)
File "/Users/Hotest/Library/Arduino15/packages/esp8266/hardware/esp8266/3.0.0/tools/esptool/esptool.py", line 529, in connect
raise FatalError('Failed to connect to %s: %s' % (self.CHIP_NAME, last_error))
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header
You have the incorrect port selected. If you go to Tools → Port and select your usb port. If you don’t know which one to choose then unplug your device, come off the menu, open it back up again and see which one has disappeared. Then plug it in a select that one.
@jampez77 I was able to complete this using your guide! Many thanks!
It does work but it’s temperamental. Quite often I need to press open or close many times before relay clicks in. I’m constantly pinging wemos so for sure this is not related to WiFi. Also sometimes stop button acts like open/close and it doesn’t update the status when doors are open or closed?
Did you experience such a issues? I wonder if this is related to relay / wemos or there is some bug in the code?
I wonder if maybe you could add some logging future which could be check via http to see what signal wemos is sending, then it would be easier to understand if this is related to wemos or relay
I’ve had the open/close status issue once or twice before. For me this was because the status comes from an analog pin where the values are usually between 0 - 50. 0 being fully open and 50 fully closed.
The problem I have had in the past is that the open / closed threshold can vary a lot. Most of the time it reliably changes from open to closed at 15. Occasionally this shifts and I have to change the threshold to prevent the incorrect status changes.
You can try and change this threshold in the line 23, Helper.h file.
The only delays i’ve ever experienced I’ve put down to WiFi issues as my device is located far from an access point. As for the stop button, i’ve never really used it actually.
Sorry I couldn’t be more help but I will try and find some time to add in some logging over the weekend if I can find the time.
Hi, I’m considering getting one of these garage openers second hand and I was wondering if any of you have tried to get this working without the conex and/or output OC. From the limited pictures of these modules, they seem quite simple.
If anyone could add a few high res pictures of both sides of the modules, that would be great.
Determined it would cost me too much, instead I just hooked up a relay to an extra remote (same thing I did with my old garage door opener. I also output the 3V from my ESP8266 to power the remote and then just trigger open and closes off of that. Combine that with a simple door sensor and its been working great.
The Conex / Zooz Zen16 combo has worked fantastic. Door open / close using conex, door status using external sensor all through Zen16 using z-wave. One of my requirements was to not use WiFI and this worked perfectly.
@jspanitz not needed anymore, but thanks for the effort! Meanwhile I’ve found the SommerESP solution as I wished to avoid the conex and output OC requirement. Check this:
Nice find. My only reservation is i prefer to have my door locks / controls on zwave or zigbee vs wifi. But I’m definitely looking at that project as an alternative if my zooz relay ever dies.
