Tuesday, August 30, 2022

(#40) Garage Door Revisited

 Time passes - Garage Door Part Deux


Let's see: COVID, getting a son to school in Stockholm, getting the other two kids off to college.  Fixing the electric steps on the RV for the umpteenth time. Starlink testing (works great).  Work. Turning 65. Checking the 401K balance. Oh yeah - hip replacement. Blowing out the tendon in my left knee. Little stuff.

Recall that I've made a run at keeping the garage door closed before. Look here.

Switched the Eaton Home Heartbeat system from a Raspberry Pi 2 to a Pi Zero W 2 - and had things stop working. The FTDI driver on the Zero is slightly different from the driver that loads on the Pi 2. Same "version" of Raspberry Pi OS best I can tell.

On the Pi Zero - the serial port will work for a time, and then garbage data floods the line and communication with the Home Heartbeat dies.  I spent very little time looking into this but switching back to the Pi 2 and a slightly "new" rev of the FTDI driver made the problem go away.

 

Zigbee.  There's a renewed interest in Zigbee here.  More so as the number of WiFi devices multiplies. If someone could invent a wearable Faraday cage, I'd buy it.

Months ago, I grabbed the SonOff Zigbee 3.0 USB dongle and a handful of cheap
Zigbee sensors from Aliexpress.


From there was a short hop to zigbee2mqtt as my commitment to MQTT remains strong. It works. It works great - 'nuff said. Getting that installed was easy, but paring devices, moving configurations to different computers - was a bit of a chore. But it's up and running.


From that hop, a skip to Home Assistant. Same thing - installation was a bit of a learning curve. Eventually I bailed on installing "core" on an spare Ubuntu laptop and grabbed a spare Pi 3B+ and loaded their image.  That is clearly the easiest route to get things up and running.

 

 

And then the final jump to ESPHome.




Wow! What a delightful hunk of software! Again a few hiccups getting my NodeMCU to connect initially but it was because I had loaded an image already and had forgotten how to reset the device into boot mode. Once that was done, the basic firmware image was uploaded and the ESP8266 device was online. It appeared immediately in both ESPHome and Home Assistant.

[ PS: Don't use Firefox - it doesn't support WebSerial.  I downloaded MS Edge and got things closer. I also went through the steps to build and install "esphomeflasher" and that worked great. ]

Sweet. Fantastic job on the development!

See here:



And here:


There are quite a few examples of how to write a YAML configuration for controlling a momentary relay. That's how my garage door works - to raise or lower, it's a momentary press of the button.  Here's my version 0.1 YAML that's working on my test bench:

esphome:
  name: test-8266-hiletgo

esp8266:
  board: nodemcuv2

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "blah blah blah"

ota:
  password: "blah blah blah"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Test-8266-Hiletgo"
    password: "blah blah blah"

captive_portal:


switch:
  - platform: gpio
    pin:
      number: 14
      inverted: true      
    id: relay
    name: "Garage Remote"
    icon: "mdi:car-connected"
    restore_mode: always_off
    on_turn_on:
    - delay: 1000ms
    - switch.turn_off: relay

Let's get right to the wiring since that's where I learned a few more things. On these relays, the pin outs are (Thank you RandomNerd Tutorials!):


I run the two wires to the garage door from the relay's common and "normally open" connections. This seemed to have the desired behavior when the power to the NodeMCU was cut (the relay did not trigger).  For now the JD-VCC / VCC jumper is on - meaning the power to the relay is coming from the NodeMCU board. I think this will be fine, as there should be little power on the relay. The door trigger is simply a momentary close (continuity) of the circuit.


Ground on the 4 pin connector goes to GND on the NodeMCU. VCC (on the 4 pin) goes to the 3.3V pin on the NodeMCU.



And IN1 is connected to D5 - GPIO 14. Again thank you to RandomNerd Tutorials for pointing out that the pin you pick does matter!  Some pins are triggered on boot. And this would trigger the door if the NodeMCU lost power, or rebooted. We don't want that.

Quote:  "Some ESP8266 pins output a 3.3V signal when the ESP8266 boots. This may be problematic if you have relays or other peripherals connected to those GPIOs.

Additionally, some pins must be pulled HIGH or LOW in order to boot the ESP8266.

Taking this into account, the safest ESP8266 pins to use with relays are: GPIO 5, GPIO 4, GPIO 14, GPIO 12 and GPIO 13."

 

Note the two lines highlighted in red in the script. "inverted: true" was the only way I could find to have the pin power up as Low.  Without this, when the NodeMCU booted, the relay was powered up and continutiy established -- ie. like holding the garage door remote button down.

Not good.  Using "inverted: true" now powers up with the relay not engaged; no continuity; button not mashed.



And "on_turn_on" seems to be a great way to get the behavior I want from the relay - energize (mash button), hold for a second, then release.

It's time to head out to the garage, unplug the Raspberry Pi solution that's been there for years and try this. One thing I'll lose is the automation and rules I had about closing the door.  I'll have to see if they're able to be recreated in Home Assistant.