CommandHandler.cpp, CommandHandlerType commandHandlers is a lookup table for functions to run based on the received command. 0x36 is startScanNetworks. From the name, I would expect that to communicate with wifi, and actually start a scan, the results of which will be available to check later. However, all that the startScanNetworks function does is set up a response packet that seems to indicate a scan is starting. Without actually starting a scan.
commandHandlers is used by CommandHandlerClass::handle. the 0x36 command is used by the ESP_SPIcontrol.start_scan_networks method from adafruit_esp32spi. The followup command from there is ESP_SPIcontrol.get_scan_networks. Both are called from ESP_SPIcontrol.scan_networks. get_scan_networks sends a 0x27 command to the handler. That translates to scanNetworks in CommandHandler.cpp. scanNetworks is what actually initiates the scan, then waits for the result.
What is the purpose of startScanNetworks? it does not seem to actually "do" anything. As a test, I pulled a copy of scan_networks out of adafruit_esp32spi, and ran it with some timing wrappers, (Firmware vers. 1.7.7) then again without sending the 0x36 start scan command (only 0x27). It worked, and there was no noticeable difference in the elapsed time.
Looking deeper, I see in CommandHandler.cpp scanNetworks, that it calls WiFi.scanNetworks, and gets the number of detected access points back. That says the complete scan is done inside that call.
arduino/libraries/WiFi/src/WiFi.h says WiFi is WiFiClass, and arduino/libraries/WiFi/src/WiFi.cpp
has WiFiClass::scanNetworks. That seems to be where the scan is actually initiated, waited for, and results collected. For the implied functionality of 0x36 _START_SCAN_NETWORK, it looks like WiFiClass::scanNetworks should be 2 parts. the first, should get as far as esp_wifi_scan_start, then return some sort of 'scan in progress' status. The second should pick up by checking the wait bits and getting the results.
A separate method could check the wait bits, without waiting, to change the status from in progress to scan complete, to let the caller know when to come collect the results.
CommandHandler.cpp, CommandHandlerType commandHandlers is a lookup table for functions to run based on the received command. 0x36 is startScanNetworks. From the name, I would expect that to communicate with wifi, and actually start a scan, the results of which will be available to check later. However, all that the startScanNetworks function does is set up a response packet that seems to indicate a scan is starting. Without actually starting a scan. commandHandlers is used by CommandHandlerClass::handle. the 0x36 command is used by the ESP_SPIcontrol.start_scan_networks method from adafruit_esp32spi. The followup command from there is ESP_SPIcontrol.get_scan_networks. Both are called from ESP_SPIcontrol.scan_networks. get_scan_networks sends a 0x27 command to the handler. That translates to scanNetworks in CommandHandler.cpp. scanNetworks is what actually initiates the scan, then waits for the result.
What is the purpose of startScanNetworks? it does not seem to actually "do" anything. As a test, I pulled a copy of scan_networks out of adafruit_esp32spi, and ran it with some timing wrappers, (Firmware vers. 1.7.7) then again without sending the 0x36 start scan command (only 0x27). It worked, and there was no noticeable difference in the elapsed time.
Looking deeper, I see in CommandHandler.cpp scanNetworks, that it calls WiFi.scanNetworks, and gets the number of detected access points back. That says the complete scan is done inside that call. arduino/libraries/WiFi/src/WiFi.h says WiFi is WiFiClass, and arduino/libraries/WiFi/src/WiFi.cpp has WiFiClass::scanNetworks. That seems to be where the scan is actually initiated, waited for, and results collected. For the implied functionality of 0x36 _START_SCAN_NETWORK, it looks like WiFiClass::scanNetworks should be 2 parts. the first, should get as far as esp_wifi_scan_start, then return some sort of 'scan in progress' status. The second should pick up by checking the wait bits and getting the results. A separate method could check the wait bits, without waiting, to change the status from in progress to scan complete, to let the caller know when to come collect the results.