Odd timing response between Node Red and Pico W?

[Jibun no kage]

Odd timing response between Node Red and Pico W? To be clear I am not sure there is anything wrong in what I am going to outline, other than maybe my WiFi consistency is an open question in some way.

Have Node Red and Mosquitto broker. Each on a Raspberry Pi device. They are fast and smooth in operation given the limits of the respective Pi devices. Using MQTT linux CLI, as well, everything works and seems fast as possible, given the qualification above.

Here is where it gets interesting, I have Pico W, running MicroPython and using mqtt_as module. Using the clean.py example, i setup a simple script where as a 'command' is received, a 'status' is returned. Node Red sends the command, then waits for the applicable status to be received. If I do this via any method other than the Pico W (although I have not pulled out an ESP8266 or ESP32 yet, which I will do to validate), the timing is what I would call slow. From Node Red generation of MQTT command topic to Pico W sending back status can take 5 to 8 seconds for a simple transmit/receive. If I send 5 or 10 commands, things are still slow initially, but the Pico W processes all the commands and sends the status replies almost all at once. It is like there is some type of caching going on.

Watching the broker and testing other than with devices than Pico W, everything is smooth I only see this odd delay when Pico W is in the scope of the test. Once in a while the Pico W will drop connection and reconnect. But that does not seem to be an issue, because the odd lag or caching happens even when the connection holds.

Thinking it might be a WiFi quality signal issue, I changed routers, make sure the router used, is only used for the test, etc. So I am at a loss as to what the initial delay is or why it happens, especially when I send 5 or 10 commands for them to all be processed and return status to Node Red as fast as i would expect after the initial lag.

And no, subscribe and publish seems to be solid, I am not seeing dropped commands or failed publishing of status, since in each transaction I added a unique time stamp.

Sorry for the long discourse, but this is really a puzzle, at least to me, or is this a known issue of some type?

[Jibun no kage]

Oh For Crying Out Loud! I believe I found the issue... Power Management! After some extensive questioning my reality, I started digging into the Pico W architecture and realized that this might be a power issue, either the power supply was off, or otherwise. Sure enough after I figured out how to disable the WiFi power management, the Pico W started responding much better, significantly better.

To disable Pico W power management...

theWiFi=network.WLAN(network.STA_IF)
theWiFi.active(True)
theWiFi.config(pm=0xa11140)
Echo('WiFi! Power Management {0}'.format(thePower))
theWiFi.active(False)

I suggest that this be configured a configurable option in mqtt_as, so such is integrated to the class. To that I will post a feature request on git hub.

[pythoncoder]

Please could you point me to some documentation that explains this code.

[scruss]

Peter, it seems to be documented only in the Connecting to the Internet with Raspberry Pi Pico W PDF documentation (see "3.6.3. Power-saving mode"). I haven't had connection problems not using this power management switch, but then again, I'm not hammering mine with MQTT queries.

OP: Wifi power management is platform specific. It doesn't really belong in the MQTT code, which has to run everywhere.

[karfas]

OP: Wifi power management is platform specific. It doesn't really belong in the MQTT code, which has to run everywhere.

This is a mqtt_as design issue.

mqtt_as gets every parameter it needs to reconnect to WLAN.
It will most likely also need the pm= parameter for this use case.