Determining the cause of WiFi connection problems

General
#1
  1. My goal is: I want to determine why my ESP32 device gets disconnected from WiFi. I would like to provide enough feedback to our clients so that they can troubleshoot their WiFi settings and get their device back online.
  2. My actions are: I think I should create a callback for the MGOS_WIFI_EV_STA_DISCONNECTED event. I’ve examined the mgos_wifi_sta_disconnected_arg struct, but I’m not sure how the reason field gets populated, what values it can take, etc. That reason field could be enough information to provide actionable feedback for the client.
  3. The result I see is: Well, 15, if I use incorrect WiFi credentials. However, a uint8_t has 255 other possibilities, so here we are.
  4. My expectation & question is: I expect to be able to determine why a device becomes disconnected from WiFi. What’s the best way to do this, so that our clients can address networking problems and keep their devices online?
#2

I’m interested in this as well. My debugging the other day was that 15 was timeout. Which isn’t strictly because of incorrect wifi credentials, more of a symptom of not having correct credentials.

I looked around for an enum lookup on the reason field and could not find one. There may be one buried in ESP32-IDF

#3

Incidentally I’ve been writing a status light library to drive a RGB LED. It’s required a bit of updating the RGB LED library, some extra enum’s around mos events and mqtt (which I’ve submitted as PR’s), and a fair bit of trial and error to figure out a good way to fade / blink (i never saw the mgos utility function for it!) / and hook into the various wifi and cloud events.

At the moment it uses white steady light as soon as it boots (its super fast), blinking white while connecting to wifi, rapid green when connecting to cloud and then a fading green when successfully online with cloud. Also in there it can mix in an orange 2 second blink in the middle of a color such as white or green (or others) to indicate an error with that process. …which brings us neatly back to reason 15 timeout.

I’ll be also hooking in Bluetooth status (blue light) in the next few days. Ultimately I’ll hook in OTA update as Yellow or Magenta. Hard faults etc are red, I’m thinking of using this if it can’t initialise anything over i2c etc, but haven’t hooked one of those up.

#4

Reasons ESP32
Reasons ESP8266

#5

Perfect, thanks @nliviu