Micropython ESPNow irecv()

[mmliam]

I've currently implemented an ESPNow irecv() similar to the form in Glenn's discussion:

while True:
    host, msg = e.recv()
    if msg:             # msg == None if timeout in recv()
        print(host, msg)
        if msg == b'end':
            break

I'm using the default timeout which is 5mins.
However, now I need to iterate with an MQTT message check.
I could simply change the timeout to something much quicker, but then I noticed the following code reference in Glenn's discussion:

Note: You may also read messages by iterating over the ESPNow object, which will use the irecv() method for alloc-free reads, eg:

import espnow
e = espnow.ESPNow(); e.active(True)
for mac, msg in e:
    print(mac, msg)
    if mac is None:   # mac, msg will equal (None, None) on timeout
        break

I'm not sure how this relates to irecv(); it mentions "timeout", but there is none shown. Are you supposed to call irecv(timeout) first to set the timeout, then why not just use irecv() in a loop. Or does simply reading messages [e.g. e = espnow.ESPNow(); e.active(True)] in some timeout loop work; but no timeout loop is shown in the example.

How is the simple message read supposed to be used?

Thanks MM

[davefes]

Before calling the singleton I have been issuing this statement:
e0.config(timeout=500) # listen for 0.5 seconds for subsequent ESPNow traffic
then changing it before calling the singleton again.

Seems to work. I think this has been changed to `e0.config(timeout_ms= xx)' is the latest releases.

[mmliam]

Hi dave,

I see that now, Glenn should have included that timeout dependency in the code snip-it. But, quite frankly there doesn't seem much advantage reading messages over the irecv() that I use now. I may investigate the ESPNow.irq(callback); it may offer some advantages.

Thanks, MM

[glenn20]

I agree - the option to iterate over the ESPNow object is just a convenience - and it does not allow you to set the timeout in the irecv() call. If you want to set the timeout, just use the irecv() call explicitly.

[glenn20]

Either is OK. You can set the default timeout with e.config(timeout_ms=xx) or just add the timeout as argument to e.irecv(xx).

Often you will want to set the default timeout in your app startup/config. I have often found that sometimes within an app I want to make a call to irecv() with a much shorter timeout (eg. send a message to a peer and wait only a short time for a response). So, I can set the overall timeout in the app config, but easily use a shorter timeout within a specific part of the app. You can achieve the same thing just with e.config(timeout_ms=xx) each time you want to change the timeout and back again, but it is very convenient to set the timeout explicitly as an arg of irecv() to override the timeout only for that call.

[davefes]

I re-read the config() text and convinced myself that it must be OK to do it that and then deleted my question.

Thanks for getting back.

[glenn20]

If I understand your use case correctly, you can also use the e.any() call to test if there is data available to be read and return immediately.

You may also be interested in exploring the select.poll() call which lets you wait on multiple IO requests and returns when one of them is ready. However, you would need access to the "socket" of your mqtt connection. ESPNow supports poll().

Another approach is asyncio, which is really useful when handling multiple IO connections. I recommend exploring this if you think you will be doing more of this kind of thing. There is a learning curve, but the excellent resources from Peter Hinch help a lot, including Peter's mqtt_as module (as well as all the python docs on asyncio).

And finally, the docs for the timeout_ms option are available at https://docs.micropython.org/en/latest/library/espnow.html#espnow.ESPNow.config

[mmliam]

Hi Glenn,
I've been using the irecv() default of 5mins. I have ESPClient.check_msg() in the ESPNow recv loop as a place holder for future messages to the gateway from a Node-Red flow, the check msg is also in a try-except construct that allows the gateway to know if it lost connection to the MQTT server.

However, now I want to implement messages from Note-Red to the gateway, so the ESPNow recv timeout must be reduced for a quicker response to the received MQTT messages, which in itself is not a problem. However, it's too bad that the ESPNow recv doesn't have a set-callback that would then include the callback routine into the internal loop of the ESPNow recv to check for incoming MQTT messages in addition to the received ESPNow messages.

BTW: Would simply be doing an ESPNow read routine as in your example, do an immediate return after checking for a received ESPNow message?

for mac, msg in e:
    print(mac, msg)
    if mac is None:   # mac, msg will equal (None, None) on timeout
        break

I think you mentioned that I would still need to set a timeout, either in irecv(timeout), or e.config(timeout=xx).

If there was an immediate return from a ESPNow read, it could be included in a timed loop with the MQTT message check. I suppose I could always set the ESPNow timeout to some minimum value. However, it seems as though I would be accomplishing the same thing by just specifying a minimum timeout in irecv(minimum) that I'm using now.

I'm going to look into that e.any(); it seems to me I used that in some code a while back.

Mike

[glenn20]

I'm finding it hard to understand just what the problem is. If I understand correctly, you just want to wait for espnow messages or mqtt messages. The simple solution:
(Warning: Untested code fragments.)

e.config(timeout_ms=200)
for mac, msg in e:
    if mac:
        print(mac, msg)
    mqtt.check_msg()

An alternative:

timeout = 200
while True:
    mac, msg = e.irecv(timeout)
    if mac:
        print(mac, msg)
    mqtt.check_msg()

Both these options will probably work fine for you. The timeout options are all clearly documented in ESPNow.config and ESPNow.recv()

If however, you don't like that you:

• wake up every 200ms whether there is a message or not
• may have to wait up to 200ms to respond to an mqtt message

you could either use the e.irq() method or the more advanced select.poll method (but this doesn't seem to be necessary for your use case):

def recv_cb(e):
    while True:  # Read out all messages waiting in the buffer
        mac, msg = e.irecv(0)  # Don't wait if no messages left
        if mac is None:
            return
        print(mac, msg)
e.irq(recv_cb)

while True:
    mqtt.wait_msg()

import select
poll = select.poll()
poll.register(e, select.POLLIN)
poll.register(mqtt.sock, select.POLLIN)

while True:
    for event in poll.ipoll():
        if event[0] == e:
             mac, msg = e.irecv(0)  # A message should be available, but set timeout to 0ms just in case
             print(mac, msg)
        elif event[0] == mqtt.sock:
             mqtt.check_msg()

The poll.poll() call will return as soon as there is an espnow or mqtt message.

Or asyncio ;).

[mmliam]

Glenn,
I apologize for not being clear; I actually I only had a minor issue, which I, perhaps ambiguously stated that I did have a solution.
Currently, I'm still using irecv() with mqtt.check_msg() in a loop; similar to your "alternative";

timeout = 200
while True:
    mac, msg = e.irecv(timeout)
    if mac:
        print(mac, msg)
    mqtt.check_msg()

Originally I was using the default irecv() timeout, without mqtt.check_msg(), which happens to be about 5 mins. This was much too long of a wait when I added mqtt.check_msg(). So as I stated I just reduced the irecv() timeout (actually to 5000ms). While not perfect it's acceptable.
I also mused that it would be useful if there was a irecv.set_callback() [similar to that used in MQTT] that I could include the mqtt.check_msg(); putting it in the internal irecv() wait loop.

I guess my only concern is to how short I could make the irecv() timeout; given the default of 300000ms, In a long past post on micropython.org with you, I mentioned, for the application at that time, I was using 100ms in an irecv() and you thought it could be a problem. However, with your last excellent suggestions; apparently there isn't a problem significantly reducing the irecv() timeout.

I much appreciate your last post, I will include it in my Glenn-post archive for reference.
Again, sorry for the confusion,

[glenn20]

Ah - now I get it ;). Sorry for the confusion - I think I was misreading your earlier post.

You can set the timeout as short as you want, you can even do:

def espnow_check_msg(e):
    if e.any():
        mac, msg = e.irecv(0)
        print(mac, msg)

while True:
    espnow_check_msg()
    mqtt.check_msg()

Which eliminates the timeout altogether. This will be very responsive to any mqtt or espnow messages coming in. You will be running through that loop at a furious speed though when there are no message. e.any() won't alloc any memory and mqtt.check_msg() probably won't - so that will probably be OK.

[mmliam]

Wow, all the way down to zero:
mac, msg = e.irecv(0)
I dropped the timeout to 1000ms, which for my application is quite adequate.

My Gateway automatically reports information on my remotes[battery voltage, Quality Factor (event triggers/transmissions), etc.].
The mqtt.check_msg() queries the Gateway, using Node-Red, for it's status, and remotely setting Gateway control parameters.

Again, thanks for the information.