async support

[thijstriemstra]

Would be nice to use the async support in python 3.5/3.6.

[timofurrer]

Good idea! I'll have some time to look into it end of the month.

[FromChita]

really looking forward

[buldre]

Will this enable higher logging frequency with reduced resolution/precision?
Currently I managed to set precision from 12 to 10 bits in the RPI Terminal, but the 12 bits interval of 750 ms (+overhead) between reads remained unchanged. I expected to see 4 times higher frequency.
Whether reading the same sensor, or 2 sensors, the reading interval is the same. I updated the Python 3 library yesterday.

[timofurrer]

Will this enable higher logging frequency with reduced resolution/precision?

No, this has nothing to do with the precision or resolution of the sensor itself.

I expected to see 4 times higher frequency.

I think, we've clarified this via email, right? If not, please open a separate issue 🎉

[buldre]

Hi Timo! You explained this very well! Thanks, Ben Velde

…

3. nov. 2019 kl. 15:23 skrev Timo Furrer ***@***.***>:  Will this enable higher logging frequency with reduced resolution/precision? No, this has nothing to do with the precision or resolution of the sensor itself. I expected to see 4 times higher frequency. I think, we've clarified this via email, right? If not, please open a separate issue 🎉 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[jonte]

It seems like asyncio0 doesn't support asynchronous file I/O (for good reasons)1.

One way to still provide an interface which can be consumed by asyncio-based python code would be to execute the blocking read2 in a thread pool. There's support for this in asyncio, using loop.run_in_executor3. It would look something like this:

    async def raw_sensor_strings_async(self):
        try:
            with open(self.sensorpath, "r") as f:
                with concurrent.futures.ThreadPoolExecutor() as pool:
                    data = await loop.run_in_executor(pool, f.readlines)
        except IOError:
            ....

In my current code, which uses the W1ThermSensor library, I am wrapping the call to get_temperature in a similar fashion to the example above.

Given that we can't make the file I/O truly asynchronous, does it make sense to provide an async helper such as the one seen above (of course, we would have to make all the calls out to, and including get_temperature async as well)?

I guess it would be convenient to not have to wrap get_temperature yourself, but I am unsure if it makes sense to implement this. It might not be obvious to the user of such an async method that threads are used, and might to more harm than good. What do you think?

I could take a stab at a PR if we still want this functionality.