search

timofurrer / w1thermsensor

A Python package and CLI tool to work with w1 temperature sensors like DS1822, DS18S20 & DS18B20 on the Raspberry Pi, Beagle Bone and other devices.
MIT License
493 stars 113 forks source link

async support #52

Closed thijstriemstra closed 4 years ago

thijstriemstra commented 5 years ago

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

timofurrer commented 5 years ago

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

FromChita commented 5 years ago

really looking forward

buldre commented 4 years ago

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 commented 4 years ago

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 :tada:

buldre commented 4 years ago

Hi Timo!

You explained this very well!

Thanks, Ben Velde

  1. nov. 2019 kl. 15:23 skrev Timo Furrer notifications@github.com:

 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 commented 4 years ago

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.