WKHarmon / led-sectional

MIT License
34 stars 18 forks source link

esphome? #23

Closed kdknigga closed 11 months ago

kdknigga commented 1 year ago
          Nice. I see that you also implemented WiFiManager, which is something that I've been meaning to do for a while.

Originally posted by @WKHarmon in https://github.com/WKHarmon/led-sectional/issues/22#issuecomment-1532061796

New issue to not sidetrack the other... Really more of a discussion than issue.

Have you seen ESPHome? I wonder if this whole project could be refactored into an ESPHome component or two, and let ESPHome handle WiFi, LEDs, maybe even an html interface for managing airport to LED mapping. They even have a way to join devices to WiFi easily, Improv.

jcl-rv12is commented 1 year ago

Go for it! I'm brand new to microcontrollers, and without too much effort was able to make the changes in my fork. For something that's less than 500 lines (excluding comments), I'm not personally inclined to do much more. WiFiManager does a fine job of letting you join a new WiFi network, and eliminates the problem I had with the WiFi library not working well with some routers (unable to get an address via DHCP), which is what drove me to it.

Ahmedk1995 commented 1 year ago

Go for it! I'm brand new to microcontrollers, and without too much effort was able to make the changes in my fork. For something that's less than 500 lines (excluding comments), I'm not personally inclined to do much more. WiFiManager does a fine job of letting you join a new WiFi network, and eliminates the problem I had with the WiFi library not working well with some routers (unable to get an address via DHCP), which is what drove me to it.

Thank you for including WiFiManager in your fork, I haven't been able to find a way to message you or open an issue so I'll ask here, I noticed that when LEDs blink due to high winds or lightning, it causes the board to auto connect again which causes a bit of a delay, you can see that behaviour in the serial monitor. I was wondering if that's intended behaviour or a bug?

jcl-rv12is commented 1 year ago

Thank you for including WiFiManager in your fork, I haven't been able to find a way to message you or open an issue so I'll ask here, I noticed that when LEDs blink due to high winds or lightning, it causes the board to auto connect again which causes a bit of a delay, you can see that behaviour in the serial monitor. I was wondering if that's intended behaviour or a bug?

The "delay" you're seeing is not because of any WiFi activity. Rather, there is a delay/loop introduced whenever there is a need for LEDs to blink, i.e. whenever lightning/thunderstorms or high winds are found, so that there is time for the blinking activity of the lights. That delay has always been there. With the original code, you'll see something like the text below in the output when "lightning", i.e. thunderstorms, are found. It's that same loop being executed with my changes.

There is lightning or we're using a light sensor, so no long sleep. Loop: 1 Lightning on LED: 0 Loop: 2 Lightning on LED: 0 Loop: 3 Lightning on LED: 0

Ahmedk1995 commented 1 year ago

Thank you for including WiFiManager in your fork, I haven't been able to find a way to message you or open an issue so I'll ask here, I noticed that when LEDs blink due to high winds or lightning, it causes the board to auto connect again which causes a bit of a delay, you can see that behaviour in the serial monitor. I was wondering if that's intended behaviour or a bug?

The "delay" you're seeing is not because of any WiFi activity. Rather, there is a delay/loop introduced whenever there is a need for LEDs to blink, i.e. whenever lightning/thunderstorms or high winds are found, so that there is time for the blinking activity of the lights. That delay has always been there. With the original code, you'll see something like the text below in the output when "lightning", i.e. thunderstorms, are found. It's that same loop being executed with my changes.

There is lightning or we're using a light sensor, so no long sleep. Loop: 1 Lightning on LED: 0 Loop: 2 Lightning on LED: 0 Loop: 3 Lightning on LED: 0

I should have clarified, I understand the delay is there for a reason, what I mean is that everytime the "Loop" goes off, WM decides to restart the autoconnect procedure. Looking at my serial monitor this is what I see every 5-10 seconds when high winds/lightning are detected

There is lightning, thunderstorms or high wind, or we're using a light sensor, so no long sleep. Loop: 1 WM: WM: AutoConnect WM: Connecting as wifi client... WM: Status: WM: 3 WM: Using last saved values, should be faster WM: Connection result: WM: 3 WM: IP Address: WM: 192.168.68.124 Connected to local network High wind on LED: 1 Loop: 2 WM: WM: AutoConnect WM: Connecting as wifi client... WM: Status: WM: 3 WM: Using last saved values, should be faster WM: Connection result: WM: 3 WM: IP Address: WM: 192.168.68.124 Connected to local network High wind on LED: 1 Loop: 3 WM: WM: AutoConnect WM: Connecting as wifi client... WM: Status: WM: 3 WM: Using last saved values, should be faster WM: Connection result: WM: 3 WM: IP Address: WM: 192.168.68.124 Connected to local network High wind on LED: 1 Loop: 4 WM: WM: AutoConnect WM: Connecting as wifi client... WM: Status: WM: 3 WM: Using last saved values, should be faster

Is this normal behaviour? Should it not stay connected from bootup and only loop to refresh the lights instead of calling the wifi connection every time it loops?

jcl-rv12is commented 1 year ago

I'm not sure how the output you showed differed from mine...must have made some edits? It never actually reconnected, rather I would get messages that it was already connected.

Regardless, there was a defect, which has been fixed. Thanks for the feedback!