Already mentioned earlier, but it is not recommended to do that:
from board import *
because of namespace pollution and potential function clashes which could be hard to debug. Some background reading: A guide to Python Namespaces
Besides, you import the same module later:
But you could import just the functions you need eg:
from board import somefunc, someotherfunc
However it seems that you not even using the module in this code.
datetime also appears to be unused. Ditto for
busio. I recommend that you get rid of unused imports or variables because they are unnecessary distractions. The program could be more concise. A good IDE can highlight unused resources in your code.
The actions you are doing on your pins (?) right after the imports deserve to be commented in plain English. It's not obvious what these lines achieve exactly and why they are critical. Even one line or two would be welcome. Yours comments are a bit cryptic but no doubt you know what they mean now, but if you revisit your code in 6 months you may need a refresher.
The rest of the code is self-explanatory.
Mixing lowercase and uppercase in variables should be avoided but you can use the underscore _ character to separate keywords. Read up on PEP8.
The way the data is being parsed is a bit clumsy and may be not very robust.
You could use a regular expression and capture the desired pattern. Or simplify your split operation like this:
If you know that the temperature value is the rightmost data field, then you can just split the string like you're doing and take the first element starting from the right, hence the negative index. Then you can for example use a further
[2:] to extract the temperature from the string after
Instead of using print I recommend that you start the habit of using the logging module. To quote myself, an example. It would be beneficial for the following reasons:
- in addition to console you can also output text to a file, and the text can be formatted differently than on console
- the file can also be more verbose than the console - you can decide to send debug messages to file only for example
- your data samplings will be timestamped automatically if you so wish
- this is definitely desirable for unattended applications
There is no real exception handling presently, you are only handling the Ctrl-C event but the program could crash for any reason. Just add a catch-all except clause to handle other exceptions that are not explicitly addressed in your code, and log the full error details along with stacktrace. For this you use the logging module.
As mentioned by @Reinderien you can also add a finally clause in your try block and move this code to finally:
Thus, it will be systematically executed when leaving the program, even if the program exits as a result of an unhandled exception.
Improvements for the future - data collection
As I pointed earlier you are not logging anything, not keeping any history.
I think you may be interested in collecting data to analyze trends or answer questions like:
- How long has the temperature been above threshold within a certain time period ?
- How many times did the program turn on the air conditioning ?
- How long did the air conditioning operate within a certain time period ?
- What was the maximum temperature recorded ?
For example if you find out that the airco is running 25% of the time it could mean a number of things: possibly the room is not insulated enough, or the airco is not powerful enough. But it's not something you can easily tell without measuring and recording data samples.
If your program turns the airco on and off like it should, it's already good - it's doing its job. But it does not help improve the operating conditions in the long term.
What follows is outside the scope of the review and is merely a suggestion if you want to take your project to the next level, but you could have a machine running Prometheus that collects data from your sensors at regular intervals with the help of a custom exporter and all that data could be visualized on nice dashboards using Grafana. Free and open source of course.
Here is a long tutorial, you can skip a good chunk of it and start with the Prometheus section. FYI the default retention period in Prometheus is 15 days... but you can configure that.
Finally, you could have a graph like this in your dashboard to review observed temperatures with the ability to filter on a time range... (courtesy of the above-mentioned tutorial)
This may look like a big infrastructure project but if you run other machines or even servers it definitely makes sense. You can monitor all sorts of machines and collects all types of metrics to gain insight into the health and activity of your systems.