Probably wrong value of %iswifi% system variable

[mackowiakp]

ESPEasy_ESP32_mega-20211224 (custom version).
Below output of system variables.
%iswifi% variable is equal 2. The unit is fully connected to WiFi, IP address assigned and so.
In this case this value should be 7 according to docu. Value "2" is not listed as possible value of %iswifi% at all.
It was correct for sure in ESPEasy_ESP32_mega-20210223.
Is it intended change? If so, what are meanings of numbers of this value?

Screenshot_20211229_065045.png (90.13 KiB) Viewed 6231 times

[TD-er]

It should indeed be a bitmask:
- Connected
- Got IP
- Fully initialized

Apparently it missed the "connected" event.
So I wonder what remaining event isn't processed here to prevent it from being fully initialized.

Does a controller work well?

[Ath]

A search in the source has revealed this snippet of info:

Code: Select all

case ISWIFI: value = String(WiFiEventData.wifiStatus); break; // 0=disconnected, 1=connected, 2=got ip, 4=services initialized

(Last modified just over a year ago)
And you may know what is said about comments: They can be unreliable.

But I'm quite confident this is rather accurate, as there is also this function:

Code: Select all

String ESPeasyWifiStatusToString() {
  String log;
  if (WiFiEventData.WiFiDisconnected()) {
    log = F("DISCONNECTED");
  } else {
    if (WiFiEventData.WiFiConnected()) {
      log += F("Conn. ");
    }
    if (WiFiEventData.WiFiGotIP()) {
      log += F("IP ");
    }
    if (WiFiEventData.WiFiServicesInitialized()) {
      log += F("Init");
    }
  }
  return log;
}

(Last change > 4 years ago) And other code about the WiFi status indicates these 4 statuses are the only ones used.
The '+=' assignment seem to indicate that multiple statuses can be active at the same time, and on some active units I do see 7, so that seems reasonable.
Anything > 0 is fine, I guess, and probably 4 means you'll have to wait a bit to see the actual status.

Maybe only use that status *after* the "WiFi#Connected" event has been generated. Or at least wait for that event before sending out anything important via WiFi.

[TD-er]

Nope, the status not being initialized (thus < 4) means the code does not consider it being "Wifi fully connected".
So a value of 2 means it didn't receive the "connected" event and thus it will not set the last bit.
That's the reason I asked if controllers do work as they probably don't. (MQTT controllers check "connected" via the MQTT client, so that's different)

[mackowiakp]

More info. The HW is ESP-CAM without camera module connected. The only sensor connected is I2C Gyro - MPU 6050 as vibration detector.
Defined rule works as:
- every 4 sec %iswifi% variable is checked
- if %iswifi% < 7 - onboard LED - short flash. In other case LED on.
- if %ifwifi% < 7 for at least 10 min, reboot.
Static IP setup.
Primary and secondary AP defined. It worked correctly with ESPEasy_ESP32_mega-20210223 (custom compilation too)

Does a controller work well?

I think so. Gyro X,Y and Z axis measurements are correctly passed to Domoticz each 20 sec.

So I try at this moment DHCP instead static. Works as docu stands. So why it does not work with static IP config?
Even though it worked properly in version ESPEasy_ESP32_mega-20210223 ?
Screenshot with DHCP instead static

Screenshot_20211229_131448.png (89.26 KiB) Viewed 6202 times

[Ath]

Why check for %iswifi% if you can be signaled (correctly, AFAICS) by the "WiFi#Connected" and "WiFi#Disconnected" events?

[mackowiakp]

Yes, this is a workaround. Just please note the sequence of events.
I had a simple rule script that worked fine on ESPEasy_ESP32_mega-20210223.
I have installed the latest version of the FW and the device has stopped working properly.
I started looking for the cause and reported the potential problem. That's all.

[Ath]

Yes, this is a workaround. Just please note the sequence of events.

You have not talked about a sequence of events before, AFAICS, so I can't see why you need a workaround? The WiFi events I mentioned should be generated at the appropriate time, for you to respond to, if needed.

I had a simple rule script that worked fine on ESPEasy_ESP32_mega-20210223.
I have installed the latest version of the FW and the device has stopped working properly.
I started looking for the cause and reported the potential problem. That's all.

Please share your script.

[mackowiakp]

Below my script. I use PWM to light LED because onboard LED on ESP-CAM is extremally bright, dedicated to light-up area in front of camera.
Of course it is very easy to change it to use WiFi events for trigger action.

Code: Select all

on System#Boot do
 timerSet,1,300  // watchdog
 timerset,2,4    // OnBoard LED
EndOn

On Rules#Timer=2 do
 if %iswifi% < 7
  PWM,4,4
  PWM,4,0
 else
  timerSet,1,300
  PWM,4,1
 endif
 timerset,2,4
endon

On Rules#Timer=1 do    // if still no Wifi, reboot
  reboot
Endon