whaleygeek
commented
8 years ago The existing work on the device_classes branch introduces a simple energenie.loop() that will sequence the radio into receive mode for a defined period of time, and if a message arrives, it will pass it down the fsk_router pipeline to get it processed within the context of the thread that called the loop()
The way the radio API works, if you sequence the radio into receive mode and leave it there, the radio can receive a single payload even when your python code is doing something else - as long as the code gets back to calling the loop() reasonably regularly (so that it can call radio.is_receive_waiting to detect the waiting payload in the radio FIFO buffer), then you can mostly leave the radio in receive mode and you won't miss any device reports.
Prompted partly by #56 we'll have to consider the concurrency model, especially if callbacks are used for new device discovery.
At the moment, the sample test apps are main-loop style, and loop round spending time in receive mode so they can receive packets. But as more of this is abstracted away, we may have to provide a clean concurrency model for app writes to use (hopefully a flexible one, so that if app writes are building this as a peripheral to a much larger framework, they don't have to be dictated to about how concurrency should work). Usual solution is a .loop() that can be called in a number of different ways.