Trying to setup alarm panel. Flashed the FW, connected to the konnected-XXXX AP, setup WiFi
Get in the console log
[W][wifi_esp8266:505]: Event: Disconnected ssid=‘MyRepublic 2BC9’ bssid=20:23:51:62:9A:AD[redacted] reason=‘Auth Expired’
I suspect that when the FW is built, the default IP address 192.168.4.1 is used (even if I do set new static IP when configure the FW), but my router IP is 192.168.68.1 with network prefix length 22 (subnet mask 255.255.252.0).
So ESP is not able to connect.
Hey @alexbk66,
So 192.168.4.1 is the default IP address of the Access Point (AP) / Captive Portal when the device is in Access Point Mode. The WiFi component in ESPHome has two modes:
- Access Point mode – where the device acts as a wifi router, currently used for the captive portal to set WiFi credentials via the browser/API
- Client mode - connects to your home router as a WiFi client during normal operation
I think what you’re seeing here is the device falling back to AP mode after failing to connect to WiFi. Try disabling the captive portal to see if you can avoid this behavior. You can set the WiFi credentials in the firmware settings, and therefore the captive portal isn’t needed.
As to why you’re getting the repeated Auth Expire errors when connecting to your router … I really don’t know. The best way to debug this is to check the DHCP logs in your router and see if you can correlate the connect failures with any messages in the DHCP logs. If you’ve set the manual IP settings in the firmware, and also have a IP reservation setup in your router, the router may not like that.
@nate, as I explained above, I do set the WiFi credentials, but it looks like it keeps using the default IP. It’s interesting that it shows both IPs
And as you can see from the app screenshot above, Captive Portal is disabled
When building new FW (with static IP configured) - it still shows the default IP - and I think that is the problem.
From router log (MAC 3C:E9:0E:E2:4D:B3):
Mon Nov 11 11:23:10 2024 daemon.notice nrd[29242]: wlanifLinkEventsCmnGenerateDisassocEvent: Client 3C:E9:0E:E2:4D:B3 disassociated on APId 255 ChanId 3 ESSId 0
Mon Nov 11 11:23:10 2024 daemon.err nrd[29242]: send ioctl failed
Mon Nov 11 11:23:10 2024 daemon.info hostapd: ath0: STA 3c:e9:0e:e2:4d:b3 IEEE 802.11: disassociated
Mon Nov 11 11:23:10 2024 daemon.err hostapd: hostapd_notif_disassoc num_sta 2
Mon Nov 11 11:23:10 2024 daemon.info hostapd: ath0: STA 3c:e9:0e:e2:4d:b3 IEEE 802.11: authenticated
Mon Nov 11 11:23:10 2024 authpriv.info dropbear[15487]: Child connection from 192.168.71.250:51310
Mon Nov 11 11:23:11 2024 authpriv.notice dropbear[15487]: Pubkey auth succeeded for 'root' with key sha1!! 7f:6a:68:6d:a1:3a:af:8a:64:3d:c0:a6:42:43:6d:d2:f6:8a:eb:0f from 192.168.71.250:51310
Mon Nov 11 11:23:11 2024 authpriv.info dropbear[15487]: Exit (root): Exited normally
Mon Nov 11 11:23:12 2024 daemon.info hostapd: ath0: STA 3c:e9:0e:e2:4d:b3 IEEE 802.11: disassociated
Mon Nov 11 11:23:12 2024 daemon.err hostapd: hostapd_notif_disassoc num_sta 2
Mon Nov 11 11:23:12 2024 daemon.notice nrd[29242]: wlanifLinkEventsCmnGenerateDisassocEvent: Client 3C:E9:0E:E2:4D:B3 disassociated on APId 255 ChanId 3 ESSId 0
Mon Nov 11 11:23:12 2024 daemon.err nrd[29242]: send ioctl failed
Mon Nov 11 11:23:19 2024 daemon.err client_mgmt: client(96-54-7F-4D-35-F2) not found in arp table disconnect_counter=2
Mon Nov 11 11:23:19 2024 daemon.err client_mgmt: client(40-5D-82-2E-70-1D) not found in arp table disconnect_counter=0
Mon Nov 11 11:23:22 2024 authpriv.info dropbear[15660]: Child connection from 192.168.71.249:48962
Mon Nov 11 11:23:22 2024 authpriv.notice dropbear[15660]: Pubkey auth succeeded for 'root' with key sha1!! 7f:6a:68:6d:a1:3a:af:8a:64:3d:c0:a6:42:43:6d:d2:f6:8a:eb:0f from 192.168.71.249:48962
Mon Nov 11 11:23:23 2024 authpriv.info dropbear[15660]: Exit (root): Exited normally
Mon Nov 11 11:23:24 2024 daemon.notice nrd[29242]: wlanifLinkEventsCmnGenerateDisassocEvent: Client 10:52:1C:45:CE:44 disassociated on APId 255 ChanId 3 ESSId 0
Mon Nov 11 11:23:24 2024 daemon.notice nrd[29242]: stadbUpdateAssoc: Station 10:52:1C:45:CE:44 roams itself
Mon Nov 11 11:23:24 2024 daemon.notice nrd[29242]: stadbEntry_updateARBtmThreshold: update threshold of client 10:52:1C:45:CE:44 for reason 2
Mon Nov 11 11:23:24 2024 daemon.err nrd[29242]: ar_config_set_thres[line 28]: Null thres!
Mon Nov 11 11:23:24 2024 daemon.info hostapd: ath0: STA 10:52:1c:45:ce:44 IEEE 802.11: disassociated
Mon Nov 11 11:23:24 2024 daemon.err hostapd: hostapd_notif_disassoc num_sta 1
Mon Nov 11 11:23:24 2024 daemon.err hostapd: hostapd_notif_disassoc num_sta== 1 , do wpa_auth_sm_event
Mon Nov 11 11:23:25 2024 daemon.info hostapd: ath0: STA 10:52:1c:45:ce:44 IEEE 802.11: authenticated
Mon Nov 11 11:23:26 2024 authpriv.info dropbear[15706]: Child connection from 192.168.71.250:51312
Mon Nov 11 11:23:27 2024 authpriv.notice dropbear[15706]: Pubkey auth succeeded for 'root' with key sha1!! 7f:6a:68:6d:a1:3a:af:8a:64:3d:c0:a6:42:43:6d:d2:f6:8a:eb:0f from 192.168.71.250:51312
Mon Nov 11 11:23:27 2024 daemon.info hostapd: ath0: STA 3c:e9:0e:e2:4d:b3 IEEE 802.11: authenticated
my 2 cents … i’ve managed a few networks in my time…
personally speaking i’ve found that when it comes to 2.4g only IOT devices, some modern 2.4g/5g wifi systems are just problematic (mesh systems even more so), splitting the wifi bands on the access points/routers sometimes helps but it’s not an ideal “fix”
my unelegant answer has always been something your prob not going to like, but its always worked for me for a solid, setup and forget, solution
Just get an old 2.4g only wifi router, switch off its dhcp server/upnp and assign it a static ip on your existing network outside its dhcp range and plug it into your existing router. Then setup a wifi network called IOT say on this “AP”, exclusively for IOT type of devices
On hindsight i think an alarm panel should always be wired into the network no matter how much the hassle to do so, as even the most stable wifi network can go awry occasionally/randomly., after firmware updates, rouge device connecting/nearby and so on and so on…
While I haven’t looked into the logs, my symptoms seems very similar. My mesh system is the old Google wifi.
After reading this, I think I may very well utilize one of my Google wifi node to and provide a wired connection to the panel.
Ok, well this is embarassing 
I looked into @alexbk66’s configuration on our firmware config service back-end and discovered a bug. It turns out that, despite the app showing the Manual IP settings and disabled Captive Portal, the Konnected app wasn’t properly passing those configuration parameters to our back-end.
This is fixed already in Konnected app v1.6.0 which was released in the app stores yesterday (14-Nov). @alexbk66 please update your Konnected app, go back to the Network settings page and re-save and re-build the firmware. The next update should actually apply those Manual IP settings.
The result of this bug was that the Manual IP settings were simply being ignored, and the device was trying to connect via DHCP in all cases. After updating, it should apply the IP settings correctly going forward and yield more expected results.
Thank you for reporting, and my apologies for the inconvenience and frustration caused!
@alexbk66 Did you have a chance to revisit this after the fix was identified?