#ESP8266 + Garage Door controller

219 messages · Page 1 of 1 (latest)

wraith forum
#

This was a first go at adding an ESP8266 to my garage door controller. It read the status from the LEDs on the mainboard. This has since had a relay added, and the tap point changed from the LEDs to one of the plugs at the bottom. Note the big caps on the low voltage side of the (dirty) 24v -> 3.3v DC-DC module to stop the ESP board browning out when the motor starts to run.

wide isle
#

You might also like try using an optocoupler instead of a relay to activate a trigger signal. Fwiw, not suggesting you redo this, but another tool in the toolbox that too many people don’t seem to know about. They’re perfect for low current applications like operating in parallel with the trigger button.

wraith forum
#

yeah - its a dry contact setup though - so I'm not sure an octo would work

#

but I haven't checked to see what setup it uses - it might be 24v -> ground, or 3.3v -> ground, or some other contraption

#

I have plenty of solid state relays if the actual relay itself becomes an issue

wide isle
#

sure, it's not a big deal, can just be a bit more compact and lower power. I have been using the KB815, which is rated for voltages up to 35V, so should be happy with your 24V signalling

#

or whatever else it actually is

wraith forum
#

interestingly, I looked at this again - and its not a relay, just GPIO directly to a pin on the mainboard

#

the mainboard pin is dragged to ground via the GPIO and it triggers

wide isle
#

eek 🙂

wraith forum
#

I wonder if I should put in a SSR

#

alas, I think I only have 5v, 12v, and 24v triggered SSRs 😦

#

no 3.3v powered ones

wide isle
#

transistor or opto sounds like a better idea

#

the optocoupler is perfect for a low current dry contact.

wraith forum
#

yeah - you can't put 3.3v on the transistor base though, right?

wide isle
#

why not?

wraith forum
#

I'm just trying to figure out how that'd work..... an NPN transistor?

#

my brain hurts on that kinda thing lol

wide isle
#

I honestly don't understand transistors either. That's why I'm happier to use an opto, where the input is just the same as an LED, and the other side just passes current 🙂

wraith forum
#

😄

#

just the one thing I don't have any of hahaha

wide isle
#

unfortunate!

wraith forum
#

Is that something like this?

wide isle
#

could be. That's a lot more than strictly required, though. I just have a series resistor on the input (like a LED). I guess the resistor and LED are for the output, to indicate when current is flowing.

#

or the other way around. A series resistor plus LED on the input, to show when the GPIO is active or not active, and a series resistor on the output to limit the current flowing through the transistor

glacial badger
wraith forum
#

I have no idea - I should look...

#

I don't know if its AC, DC, a logic level, or whatever it is...

#

just that pulling it to ground makes it work lol

glacial badger
#

I would expect logic level. If that's the case, you can use the ESP gpio.

wraith forum
#

that's what I'm doing now.

glacial badger
#

Use open drain output mode.

glacial badger
wraith forum
#

we went through this, remember? when debugging why the thing randomly triggers the door when wifi drops hahahah

#

it still does that by the way hahahah

glacial badger
#

Ok, I didn't know why it came up again, since I thought that had been already established.

wraith forum
#

oh, I posted some pics of it here before I modified it more

wraith forum
#

@glacial badger I was actually wondering if isolating it electrically will stop the weird triggers when the wifi dies....

#

it takes ~15 minutes of no wifi before it triggers.....

glacial badger
wraith forum
#

is there anything other than setting:

wifi:
  reboot_timeout: 0s

?

#

I also don't have an ap: section

glacial badger
#

Also in the api section.

wraith forum
#

api section?

#

ohhhhh - there's a reboot_timeout there too - which funny enough is ~15 minutes.

wraith forum
#

it looks like without wifi, these things still reboot

#

reboot_timeout: 0s set under both wifi and api

#

I dunno - maybe I need to move away from the direct connect method.

#

isolate it with something

glacial badger
#

Any chance you could get serial logs?

wraith forum
#

not exactly sure - its installed outside, so putting anything that can log serial on it will be...... interesting....

glacial badger
#

If you disconnect it from the opener does it stop rebooting?

#

And are you sure it's rebooting? Do you have an uptime sensor?

wraith forum
#

yeah - the uptime on it reset

#

it was the only thing with a sub-30,000s uptime

#

like I said, maybe it is worth isolating it from the garage circuit

glacial badger
#

That's why I'm wondering if it will stop resetting if it's not connected.

wraith forum
#

however, then I have to disconnect it, and then remove the wifi hahaha

#

cos it only resets when the wifi goes down

glacial badger
#

Does the wifi go down that often?

wraith forum
#

yes and no

#

when I've been playing with my PoE switch, yeah hahahahha

#

but also, dhcp had a problem last night - and nothing connected - so my garage door was opening and closing every 15 minutes hahahah

#

meanwhile, I was fast asleep

#

not the end of the world, but also not exactly ideal

#

the annoying part is that with my own code, it doesn't do any of that behaviour.

#

I wonder if it'd just be easier to put an ESPHome compatible HTTP call instead of the MQTT bits of my own code

#

I still think its got something to do with how ESPHome initialises the pins on boot.....

glacial badger
#

or how late it does

wraith forum
#

yeah

#

I just removed the on retstore -> ALWAYS_OFF - to nothing....

#

maybe something gets inverted in the logic or something

#

given that it is actually in inverted pin

#

ie:

switch:
  - platform: gpio
    pin:
      number: D1
      mode: OUTPUT
    inverted: true
    id: relay
    on_turn_on:
      - logger.log:
          format: "-- Pulsing Relay (200ms)"
          level: INFO
      - delay: 500ms
      - switch.turn_off: relay
#

(and yeah - I know it isn't a relay - that's why I mislead myself - its a direct GPIO connection lol

#

I wish I had a scope - cos it only takes ~50ms of grounding this pin to trigger the mechanism to operate

#

it'd be good to put it on the pin and see what it does on boot / reboot etc

wraith forum
#

Gah - I just pulled the trigger wire off the ESPHome kit

#

as I came home, and the garage door was wide open lol

fickle ore
#

Did you try a different pin?

#

A lot of the pins on an ESP are almost unusable.

wraith forum
#

@fickle ore yeah - its not the pin...... it only happens when ESPHome reboots after no wifi or no API connectivity

#

it doesn't act stupid on first boots etc

glacial badger
wraith forum
#

there's a bug somewhere 😄

fickle ore
#

I've had some modules poorly made. Parts on backwards, stuff not soldered on, bridges maybe something like that causing issues?

wraith forum
#

@fickle ore They key is, with my own arduino code, it never acted that way

#

and I can reproduce that just by flashing my own code to the device

fickle ore
#

So you are saying there is a bug in ESPHome?

wraith forum
#

I believe so

#

I think its somewhere in where the pins initialise or are set prior to a reboot

#

seeing as it doesn't happen on initial powerup

glacial badger
#

Do you have a reboot button?

wraith forum
#

yup

#

and no - forcing the ESP to reboot does not trigger the door

#

However when ESPHome reboots after a no wifi condition, or a no API condition, it triggers the door

glacial badger
#

Then something else is happening. You're going to have to get serial logs to find out what it is.

#

Because as already mentioned, you've removed the wifi timeout, so it really can't be that.

#

And that would be exactly the same as your reboot button anyway.

wraith forum
#

You'd think so 🙂

wide isle
#

optimistic initialisation of the pin?

#

ISTR there a setting which can override that.

glacial badger
#

You really need to find out why it's rebooting because that's where the problem is. It's not a normal reboot.

wraith forum
#

indeed. I should get a USB adapter + laptop out + USB extension

#

but I have to kill my wifi to test it properly lol

#

I guess I should set it in DEBUG too

glacial badger
#

What level is it normally at?

wraith forum
#

INFO

glacial badger
#

I assume it's actually crashing for some reason, so the log level doesn't matter in that case. But at least debug would be good.

wraith forum
#

I'm just getting set up with a USB cable etc to sit outside for 15 minutes or so

wraith forum
#

Of course, now I can't seem to reproduce it 😐

#

and I did remove all the reboot timeout settings - so its back to default

glacial badger
#

Do you have a USB to TTL uart adapter?

wraith forum
#

it has TTL->USB on the board

#

however, I noticed that a state changed on the garage door controller when the ESPHome device went into safe mode after 10 'failed' boots

#

cos both lights on the garage door controller started flashing

#

so something changed state at that point.......

#

but I powercycled everything before I tested this - including the GDO

#

so I'm going to let it fail again and try to go into safe mode, and see if that's the trigger.

glacial badger
wraith forum
#

yeah true - but I'm not sure that's the case..... I don't think its a problem with Vcc to the chip

#

if it was, I'd expect my firmware to act in the same way?

glacial badger
#

I don't know, but it's not doing it now. 🤷‍♂️

wraith forum
#

with 4Mb of flash, can I save the debug logs to the flash chip?

#

ie can it append to a 'file'?

glacial badger
#

no, there's no way to save the logs

wraith forum
#

ok - here's my theory....... The GDO was in error mode cos I power cycled it - so a trigger wouldn't open it anyway facepalm

#

however, every time the ESP endered into 'safe mode' - the LEDs on the GDO signalled an error - both lights started flashing at the same time

#

I think the error mode was initiated by the ESP going into safe mode - I managed to verify this twice.

glacial badger
#

ok, but why is it going into safe mode?

wraith forum
#

cos it can't connect to wifi?

#

it does reboot a lot

#

ie when it can't connect to wifi

#

let me pull the serial log from my laptop

#

I have to sneakernet the file - cos no wifi 😉

#

When it reboots, its this output:


 ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 3460, room 16 
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4 
tail 4
chksum 0xc9
csum 0xc9
v00083220
~ld
#

I figure that's the "I have no wifi, so reboot" timer causing that

glacial badger
#

It's not.

wraith forum
#

then later down:

[I][logger:262]: Log initialized
[C][ota:469]: There have been 10 suspected unsuccessful boot attempts.
[E][ota:476]: Boot loop detected. Proceeding to safe mode.
[I][app:029]: Running through setup()...
glacial badger
#

It's resetting when it's trying to connect. Something is triggering the wdt. If it was the timeout there would be an explicit message saying so.

wraith forum
#

oh - I thought that crash was the reset

#

I've left it powered up without turning on wifi - so if my theory is correct, it should open the door shortly

glacial badger
#

I wouldn't be surprised if it's the safe mode that's triggering the door.

#

Can you paste your entire config?

wraith forum
#

yeah - its across two files though - a 'common' and a 'device'

glacial badger
#

This is still in your show-off entry. 🤣

wraith forum
#

show off the problems too 😉

#
esphome:
  name: ${name}
  friendly_name: ${friendly_name}
  platformio_options:
    board_build.f_flash: 80000000L
    board_build.ldscript: eagle.flash.4m.ld
    board_build.f_cpu: 160000000L
  
esp8266:
  board: ${board}
  restore_from_flash: true
  board_flash_mode: qio

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: on
  power_save_mode: HIGH
  
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  # The SSID will be the device name.
  #ap:
  #  password: !secret fallback_password

preferences:
  flash_write_interval: 5min

web_server:
  port: 80
  local: false
  css_url: ""
  js_url: !secret js_url
  ota: true

logger:
  level: INFO

button:
  - platform: restart
    name: "Restart"
    icon: "mdi:restart"

sensor:
  - platform: wifi_signal
    name: "WiFi Signal"
    id: wifi_signal_db
    update_interval: 30s
    entity_category: "diagnostic"

  - platform: uptime
    name: Uptime

text_sensor:
  - platform: wifi_info
    ip_address:
      name: "IP Address"
      entity_category: "diagnostic"
    mac_address:
      name: "MAC Address"
      entity_category: "diagnostic"

time:
  - platform: homeassistant
    id: homeassistant_time
#

that's the common/esp8266.yaml entry

#

minus the one syntax error - cos the copy & paste totally screwed up for some reason

#

and right on cue, it just opened the door.

glacial badger
#

What was in the log at that point?

wraith forum
#

I had the USB disconnected and was back inside - but I'm about 95% sure it would have been a safe mode entry

#

the timing is too uncanny

glacial badger
#

When you get another chance, try enabling verbose logging and see if there's any more info.

wraith forum
#

is verbose higher than debug?

glacial badger
#

yes

wraith forum
#

oh.

#

I thought debug would have output more.

glacial badger
#

It also enables a lot of the lower level sdk stuff as well.

wraith forum
#

So just:

logger:
  level: VERBOSE
glacial badger
#

yes

wraith forum
#

ok - let me give that a whirl..... would be good to diagnose the actual crash / reboot reason as well - cos that might be the reason for safe mode

#

even though it takes forever to actualy trigger the door (at least 10+ minutes)

#

doing an OTA for that - and then I'll turn off wifi again....

glacial badger
#

It takes a bit over a minute to trigger the reboot and 10 cycles to trigger safe mode, so that's between 10 and 15 minutes.

wraith forum
#

its just a lil chilly outside lol

#

and living on a main street, I don't want to just leave it with a laptop connected where the door will randomly go up 😉

glacial badger
#

We're pretty sure that it's safe mode triggering the door, so you don't have to wait that long. You just need to see the logs for a couple of reboot cycles.

wraith forum
#

ok - let me get set up again.

#

I might also just disable that SSID - and not all the wireless this time

#

before I just killed the AP at the switch port

glacial badger
#

I need to sleep now, so I'll see what the result is in the morning.

#

You could disable safe mode in the ota: section to avoid this as well.

wraith forum
#

yeah

#

I got the logs now

#

Looks like this is the part of the crash:

[I][wifi:274]: WiFi Connecting to 'wifi-SSID'...
[V][wifi:276]: Connection Params:
[V][wifi:277]:   SSID: 'wifi-SSID'
[V][wifi:282]:   BSSID: Not Set
[V][wifi:300]:   Password: 'wifi-password'
[V][wifi:307]:   Channel: Not Set
[V][wifi:314]:   Using DHCP IP
[V][wifi:316]:   Hidden: NO
scandone
[W][wifi_esp8266:212]: wifi_apply_hostname_(garage-door): lwIP error -16 on interface st (index 0)
dev 378

 ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 3460, room 16 
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4 
tail 4
chksum 0xc9
csum 0xc9
v00085550
~ld

SDK:2.2.2-dev(38a443e)/Core:3.0.2=30002000/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-48-g7421258/BearSSL:6105635
glacial badger
#

You were watching it, right? Was there any delay between the wifi_apply_hostname_ line and the reset?

wraith forum
#

yeah

#

a few seconds

glacial badger
#

Then it seems to be a low-level issue below esphome...

wraith forum
#

so likely, that function is going to fail - nothing tickled the watchdog so it triggered a reboot

#

maybe that needs a check for if WiFi.connected()

glacial badger
#

It's past that.

wraith forum
#

yeah - I was just thinking that...... question is, what calls that lol

glacial badger
#

What version of esphome do you have?

wraith forum
#

v2023.6.5

#

right this second though, I've just disabled safe mode in ota: - that seems to be the quick fix until the wifi fix happens

#

then at least my garage won't randomly open when I'm doing stuff with the wifi or network that breaks stuff lol

glacial badger
#

right

#

Maybe I can get you a modified wifi component that gives more info. But I really need to sleep... 😭

wraith forum
#

sure - at least we've made some progress - thanks 🙂

glacial badger
#

I'm trying to test this and I get very different results, so I'm kind of confused about what's going on with yours.

#

What is your current wifi config?

#

Copying what you pasted earlier, I'm using:

wifi: 
  ssid: "notme"
  password: "nothingatall"
  fast_connect: true
  power_save_mode: HIGH
  reboot_timeout: 0s
#

This gives me logs that look like:

[15:06:58][I][wifi:274]: WiFi Connecting to 'notme'...
[15:07:01][W][wifi_esp8266:479]: Event: Disconnected ssid='notme' reason='Probe Request Unsuccessful'
[15:07:01][W][wifi:588]: Error while connecting to network.
[15:07:01][W][wifi:624]: Restarting WiFi adapter...
#

Endlessly repeating. This is quite different than what you get.

wraith forum
#

strange

#

what about if you remove the reboot_timeout? As I removed all of those.

glacial badger
#

Doesn't make any difference. I wouldn't expect it to.

#

You're getting:

[W][wifi_esp8266:482]: Event: Disconnected ssid='wifi-SSID' bssid=40:01:7A:38:32:21 reason='Beacon Timeout'
wifi evt: 1
STA disconnect: 200
[W][wifi:135]: WiFi Connection lost... Reconnecting...

which is a very different message.

#

It's like it sees the network but can't connect or something like that.

wraith forum
#

I wonder if it makes any difference if you have an SSID connected, but then disconnect / remove that wifi network?

#

ie maybe it has a BSSID stored?

glacial badger
#

hmm, I can try that

#

ok, that's it. I now get logs like yours. However, it still doesn't crash...

#

Can you try removing some other parts of your config?

wraith forum
#

yeah ok - so it looks like it saves a BSSID - which is part of the fast connect / wifimanager stuff

#

I'm not sure what other parts there are? 😐

glacial badger
#

It looks like it does reboot eventually. I left it running all night and currently the uptime is at 165s and it's doing the original requests. I guess I'll have to record the logs because it doesn't happen quick enough to be watching it.

#

But I'm away for a few days.