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.
#ESP8266 + Garage Door controller
219 messages · Page 1 of 1 (latest)
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.
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
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
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
eek 🙂
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
transistor or opto sounds like a better idea
the optocoupler is perfect for a low current dry contact.
yeah - you can't put 3.3v on the transistor base though, right?
why not?
I'm just trying to figure out how that'd work..... an NPN transistor?
my brain hurts on that kinda thing lol
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 🙂
unfortunate!
Is that something like this?
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
What's the pulled up voltage?
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
I would expect logic level. If that's the case, you can use the ESP gpio.
that's what I'm doing now.
Use open drain output mode.
Ok, I wasn't clear on that.
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
Ok, I didn't know why it came up again, since I thought that had been already established.
oh, I posted some pics of it here before I modified it more
@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.....
That sounds like the reboot timeout.
is there anything other than setting:
wifi:
reboot_timeout: 0s
?
I also don't have an ap: section
Also in the api section.
api section?
ohhhhh - there's a reboot_timeout there too - which funny enough is ~15 minutes.
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
Any chance you could get serial logs?
not exactly sure - its installed outside, so putting anything that can log serial on it will be...... interesting....
If you disconnect it from the opener does it stop rebooting?
And are you sure it's rebooting? Do you have an uptime sensor?
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
That's why I'm wondering if it will stop resetting if it's not connected.
however, then I have to disconnect it, and then remove the wifi hahaha
cos it only resets when the wifi goes down
Does the wifi go down that often?
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.....
or how late it does
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
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 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
Except that it shouldn't even be doing that...
Agreed!
there's a bug somewhere 😄
I've had some modules poorly made. Parts on backwards, stuff not soldered on, bridges maybe something like that causing issues?
@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
So you are saying there is a bug in ESPHome?
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
Do you have a reboot button?
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
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.
You'd think so 🙂
You really need to find out why it's rebooting because that's where the problem is. It's not a normal reboot.
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
What level is it normally at?
INFO
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.
I'm just getting set up with a USB cable etc to sit outside for 15 minutes or so
Of course, now I can't seem to reproduce it 😐
and I did remove all the reboot timeout settings - so its back to default
Do you have a USB to TTL uart adapter?
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.
Yes, but you're also powering it from the USB in that case. An external adapter only reads the serial data without powering it.
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?
I don't know, but it's not doing it now. 🤷♂️
with 4Mb of flash, can I save the debug logs to the flash chip?
ie can it append to a 'file'?
no, there's no way to save the logs
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.
ok, but why is it going into safe mode?
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 😉
Here's the entire log
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
It's not.
then later down:
[0;32m[I][logger:262]: Log initialized[0m
[0;35m[C][ota:469]: There have been 10 suspected unsuccessful boot attempts.[0m
[1;31m[E][ota:476]: Boot loop detected. Proceeding to safe mode.[0m
[0;32m[I][app:029]: Running through setup()...[0m
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.
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
I wouldn't be surprised if it's the safe mode that's triggering the door.
Can you paste your entire config?
yeah - its across two files though - a 'common' and a 'device'
This is still in your show-off entry. 🤣
show off the problems too 😉
Device Specific:
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.
What was in the log at that point?
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
When you get another chance, try enabling verbose logging and see if there's any more info.
is verbose higher than debug?
yes
It also enables a lot of the lower level sdk stuff as well.
So just:
logger:
level: VERBOSE
yes
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....
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.
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 😉
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.
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
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.
yeah
I got the logs now
Looks like this is the part of the crash:
[0;32m[I][wifi:274]: WiFi Connecting to 'wifi-SSID'...[0m
[0;37m[V][wifi:276]: Connection Params:[0m
[0;37m[V][wifi:277]: SSID: 'wifi-SSID'[0m
[0;37m[V][wifi:282]: BSSID: Not Set[0m
[0;37m[V][wifi:300]: Password: [5m'wifi-password'[6m[0m
[0;37m[V][wifi:307]: Channel: Not Set[0m
[0;37m[V][wifi:314]: Using DHCP IP[0m
[0;37m[V][wifi:316]: Hidden: NO[0m
scandone
[0;33m[W][wifi_esp8266:212]: wifi_apply_hostname_(garage-door): lwIP error -16 on interface st (index 0)[0m
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
You were watching it, right? Was there any delay between the wifi_apply_hostname_ line and the reset?
Then it seems to be a low-level issue below esphome...
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()
It's past that.
yeah - I was just thinking that...... question is, what calls that lol
What version of esphome do you have?
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
right
Maybe I can get you a modified wifi component that gives more info. But I really need to sleep... 😭
sure - at least we've made some progress - thanks 🙂
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.
Doesn't make any difference. I wouldn't expect it to.
You're getting:
[0;33m[W][wifi_esp8266:482]: Event: Disconnected ssid='wifi-SSID' bssid=[5m40:01:7A:38:32:21[6m reason='Beacon Timeout'[0m
wifi evt: 1
STA disconnect: 200
[0;33m[W][wifi:135]: WiFi Connection lost... Reconnecting...[0m
which is a very different message.
It's like it sees the network but can't connect or something like that.
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?
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?