search

rstrouse / ESPSomfy-RTS

A controller for Somfy RTS shades and blinds
The Unlicense
531 stars 36 forks source link

Appears that WiFi AP is broadcast when connected over ethernet (possibly during boot?) #271

Closed Particpant closed 7 months ago

Particpant commented 7 months ago

Hardware

LilyGO T-Internet POE

Firmware version

v2.3.3

Application version

v2.3.3

What happened? What did you expect to happen?

My WiFI APs seem to see the ESPSomfyRTS broadcasting it's AP, at least intermittently, despite the device being on a wired connection with POE power. I'd expect that the wifi ap isn't being broadcast when connected over ethernet, even during boot.

How to reproduce it (setp by step)

1. Set up lilygo POE ESP per directions.
2. connect via wired ethernet/POE
2a) (possibly) power cycle POE?
3. observe that the WiFi AP is broadcast on occasion.

Mine has been set up (and powered on for weeks), though my Unifi APs report having seen the AP broadcasting in the last day. I don't currently see it advertised, and the Unifi console isn't more granular on timing.

I'm unclear on how to obtain logs, but happy to try and gather some!

Logs

No response

rstrouse commented 7 months ago

If it is broadcasting the AP then its connection has failed and is not connected. It will fall back to the AP if it loses network connection.

EDIT: Is this possibly happening after power loss. Is it possible that the network is still booting and the ESP is already up. In this instance it will try to connect to the network, if that fails then it will open up the AP to allow configuration but if it does not get any takers after 3 minutes on the AP it will again attempt to connect to the network.

Particpant commented 7 months ago

It would have occurred after a PoE power cycle. I believe the upstream port has power flowing again before the downstream switch is sending packets. Would it be possible to disable the AP mode (or would having wifi fallback turned on) prevent that?

rstrouse commented 7 months ago

How long does it take for the switch to come alive. It is waiting a full 7 seconds in that condition. Disabling the AP mode is not an option because it would essentially brick the device if the network creds change.

Particpant commented 7 months ago

I'll get some timing on that for you over the weekend. If not an option to disable it, an option to set a longer wait time could be useful.

Particpant commented 7 months ago

So, doing a power cycle on the upstream switch port (which is powering the hub, and in-turn powers the lilygo running ESPSomfyRTC) takes about 17s total before connectivity is restored. Based on the lights on the downstream switch, power is off and back on in about 3s. My main concern is I'm in a dense area, and the device itself being password-protected or not, I would rather not have the unit broadcasting an open AP if it's at all avoidable.

rstrouse commented 7 months ago

I was hoping we were close but 14s is a bit long. Let me do some thinking on this since there has to be a way to keep track of whether it has connected in the past and simply wait longer. The problem comes in when a big thumbed person attempts to connect to their network for the first time and it fails. This probably happens quite a bit where they enter the wrong passphrase and the shear number of help tickets that would generate would be a bit much as they would be stuck for an extended period of time. However. if the connection had been successful at one point it could continue to try for longer before bailing out and opening the Soft AP.

Particpant commented 7 months ago

Could it be as simple as waiting longer/not broadcasting if the device is configured to use LAN (and/or is PoE-powered?) I'm not using WiFi fallback, so no danger of a mistyped passkey.

I'm guessing that the behavior you have now is probably just great for ESPs configured to connect via WiFi. If it's possible to detect that there is an ethernet cable plugged in and the unit is set up to use that instead of wifi, it might be OK to either never broadcast an AP or have an extended wait before broadcasting. If it's possible to detect the presence of the ethernet cable, getting it to advertise an AP would be as easy as unplugging and giving it USB power.

rstrouse commented 7 months ago

If it's possible to detect the presence of the ethernet cable

I am looking into this possibility. The ETH library requires digging into the code to see how it is interacting with the PHY on the board.

rstrouse commented 7 months ago

Install the v2.4.0 pre-release. I have delayed the start of the AP for Ethernet connections if the PHY on the board has initialized but it is waiting on link. More importantly though I made it drop the AP much faster if it detects a cable.

Particpant commented 7 months ago

I'll try and give that a shot in the next day or so! Thanks again, this is a really tremendous project!

Particpant commented 7 months ago

Only had time to power cycle the PoE a couple of times, but both a phone and my Unifi APs failed to see the AP advertised with the 2.4.0 pre-release branch. I'd call this a success! I think the delta between traffic resuming and power is a bit larger than 14s if I reconfigure the switch port (including a change to PoE status from off->on) instead of the power cycle option, but it'll be a bit before I have an opportunity to try that out on this firmware.

rstrouse commented 7 months ago

I am going to close this one with a W for now. I think we managed to pin down our biggest offender.

Particpant commented 7 months ago

Sounds good, thanks again!