How to run an mqtt-repl?
Posted: Wed Jan 15, 2020 10:45 pm
I'm trying to write an MQTT Repl that accepts input by subscribing to a topic (the message payload is simply repl input) and that writes output to another topic (again, the message payload is simply repl output). I want to use Peter's mqtt_as, i.e. asyncio. I wrote an MQTTRepl class that inherits from IOBase and implements the readinto/write/ioctl functions that os.dupterm requires, and that fundamentally works.
The issue I'm running into is that right now I have main.py start the event loop (very much like the range.py example) and that's all good and dandy, except that the repl is now executing that event loop and it doesn't listen to input, so feeding it characters has no effect. How do I solve this? Do I need to create a separate thread? If so, what should it run and how do I avoid having MQTTRepl's method being called from the wrong thread by the repl?
I looked at the webrepl implementation and it calls setsockopt(socket.SOL_SOCKET, 20, accept_handler) on the listen socket, which presumably registers a callback with the bowels of the networking code. There's no similar thing available here...
BTW, looking at the synchronization primitives in https://github.com/peterhinch/micropyth ... er/asyn.py I was struck by the fact that they all end up busy waiting, i.e. calling await asyncio.sleep_ms(<some small number>) in a loop . Is that going to be fixed with Paul's new uasyncio?
NB: I"m running on an esp32, in case that makes a difference.
The issue I'm running into is that right now I have main.py start the event loop (very much like the range.py example) and that's all good and dandy, except that the repl is now executing that event loop and it doesn't listen to input, so feeding it characters has no effect. How do I solve this? Do I need to create a separate thread? If so, what should it run and how do I avoid having MQTTRepl's method being called from the wrong thread by the repl?
I looked at the webrepl implementation and it calls setsockopt(socket.SOL_SOCKET, 20, accept_handler) on the listen socket, which presumably registers a callback with the bowels of the networking code. There's no similar thing available here...
BTW, looking at the synchronization primitives in https://github.com/peterhinch/micropyth ... er/asyn.py I was struck by the fact that they all end up busy waiting, i.e. calling await asyncio.sleep_ms(<some small number>) in a loop . Is that going to be fixed with Paul's new uasyncio?
NB: I"m running on an esp32, in case that makes a difference.