Tale of two conflicting(?) tasks? Need to subscribe and listen for MQTT messages as well as pull i2c sensor frequently?

[Jibun-no-Kage]

Tale of two conflicting(?) tasks? Need to subscribe and listen for MQTT messages as well as pull i2c sensor frequently? Have a project where I need to control some GPIO pins state based on the subscribe MQTT messages received, based straight forward, done this before. However, I also have a RGB light sensor I need to read from, and based on the values read, will override the GPIO pins state set by MQTT messages. Thinking of how to integrate the two tasks, if you will.

MQTT subscriber using one of the various MQTT Async modules. But to do the RGB pooling, say once per second, should be just a simple endless loop, no? Since the MQTT Async code will take care of its self via its own threading? Or is there a catch-22 here I don't see? Or someone has cracked this nut before?

Details if interested...

RGB light sensor happens to be i2c based, but that is straight foreword in its own right, it will be TCS3574 or VEML6040.

Thinking of using...
https://github.com/adafruit/Adafruit_CircuitPython_TCS34725/
Or...
https://github.com/CoreElectronics/CE-PiicoDev-VEML6040-MicroPython-Module

And for MQTT... Using Peter's code... Since I have used it before...
https://github.com/peterhinch/micropython-mqtt

The priority will be the MQTT message until the next RGB sensor state poll, so figure I just drop the RGB sensor polling code into the main loop, the MQTT messages will be a type of override to what the RGB sensor sets the GPIO pins to that communicates to a device down stream of the ESP32 or ESP8266 module.

Typical scenario....

RGB sensor reports red color for several seconds, downstream device is told red via GPIO pins set, for several seconds
MQTT message comes in overrides RGB sensor setting color to blue, downstream device is told blue via GPIO pins set
RGB sensor reports red color next polling cycle, i.e. next second, downstream device is told red via GPIO pins set
Etc.
Etc.

If the MQTT message, payload color or the current RGB sensor polled color matches previous color communicated, nothing happens, if MQTT message color is different, the downstream device is told the new MQTT color. This color stay in effect until the RGB sensor pool loop reports a different color or MQTT message color changes.

[jonnor]

asyncio is a cooperative scheduling system. That means that if you block the execution with a loop, the other asyncio tasks will not be able to run. A simple way of doing work periodically is to use asyncio.sleep - there is a releant example in the documentation: https://docs.python.org/3/library/asyncio-task.html#sleeping

In general there is a lot of good information about asyncio and MicroPython here, https://github.com/peterhinch/micropython-async/blob/master/v3/README.md