Hi,

Are you saying that the WARNING: Scan stop failed always happens before subsequent scans fail? So it's possible that whatever causes that error isn't clearing state properly?

It's not entirely unexpected that this happens even after calling reset() because the reset() will reset the JS interpreter's state, but not the WiFi.

I'm afraid I'm too busy to look into this properly today.

For now a hack would be to detect the scan failing (a setTimeout to see if you got a result in 30s?) and then do a hard reboot with E.reboot()

Are you saying that the WARNING: Scan stop failed always happens before subsequent scans fail? So it's possible that whatever causes that error isn't clearing state properly?

Yes, but ... it turns out this warning is related to BLE, so it's probably unrelated to my issue. I only get this after flashing, but not when resetting the hardware (either by cutting power, or using ESP32.reboot()).

It's not entirely unexpected that this happens even after calling reset() because the reset() will reset the JS interpreter's state, but not the WiFi.

That explains it 👍. I might add that everything seems to work fine after using ESP32.reboot() too.

For now a hack would be to detect the scan failing (a setTimeout to see if you got a result in 30s?) and then do a hard reboot with E.reboot()

Nice tip, but I feel that in my particular application, a hard reboot would be a bit drastic (the scan is kind of a secondary function only) 🙂.

I think I see the problem a little more clearly now. This seems to be directly related to flashing the device, and that comforts me a little, because I would probably not see the issue "in the field".

• I still think my original observation about a potential issue is still valid though.

• I think the state of the WiFi should be cleared after a flash (not doing so is probably also what causes the BLE issue above), because having to jump through hoops to simulate a "fresh", "in the field", device makes it very awkward to do development 😊.

Thanks - yes, what you're saying about the callback seems totally valid, and like a complete mess.

I think the state of the WiFi should be cleared after a flash

Yes and no :) definitely g_jsScanCallback should be freed and cleared on the "kill" event handler, as should other stuff like that.

However WiFi itself shouldn't drop out on reset() as quite a few people seem to connect in via telnet to develop...

definitely g_jsScanCallback should be freed and cleared on the "kill" event handler, as should other stuff like that.

Great, so leaving the issue open then 🙂?

However WiFi itself shouldn't drop out on reset() as quite a few people seem to connect in via telnet to develop...

Oh, sure--I don't have an overview of which resources are block/unblocked like g_jsScanCallback at all, but returning stuff like that to their initial state was what I meant 😊.

so leaving the issue open then?

Yes, totally!

what you're saying about the callback seems totally valid, and like a complete mess.

Well, there is Wifi for ESP8266, for ESP32 and for Espruino boards using a ESP01 as Wifi module and they are all slightly different to the "ESP01 as Wifi implementation" until some starts working on it and align the callbacks.

Nice to have would be callback(err, .....)

At the moment I only see some user reporting their findings and less than a hand full of contributors for unsupported boards.

To be honest, if you need this functionality for your project, jump in and contribute.