Pythons, bashs and PIs

A few weeks ago I realised I had to get my lazy ass out of my day job Helpdesk routine and needed to do something develop-y again.
A RaspberryPi3 was lying around already and buying more stuff for these little buggers is fun anyway. Tinkering with it even more.
So what did I do, I bought a(nother) Pi Zero W, a display, Pi Camera and cases. None of them used for the Twitterbot ;-(. I’ll use it for other stuff & projects soon (even here!).

I wanted to have the Pi’ tweet something to start getting into Python again and also to play with Twitter or so. And, working for a network monitoring company, I wanted a way to see how the Pi’ were doing health-wise (aka free disk space, free memory, CPU load and temperature and finally uptime – 140 characters can only show so much).

And Scene! (Python)

We need time to calculate the uptime in seconds later on. psutil is to gather all the metrics. tweepy is for the tweeting itself (Who would have thought?!). PIPE and Popen is because we can only get the cpu temperature from the shell. We’ll do that with the following function:

psutil & tweeps via Pip (in virtualenv)

You’ll likely need to install these two modules. You simply:

$ sudo pip install tweepy
$ sudo pip install psutil

in a shell. You may need to ‘$ sudo apt-get install gcc python-dev’ to be able into install ‘plutil’ (do so if bash throws an error about python.h into your face when trying to install psutil).I absolutely recommend to install these modules in a virtualenv(ironment), so that they are not installed globally (psutil may be helpful globally, tweepy may be not so much). In case virtualenv doesn’t ring a bell for you, here is great guide: [A non-magical introduction to Pip and Virtualenv for Python beginners] (trust me it’s not hard at all, and that coming from me, who no zilch about this a couple of days ago, and I’m no rocket scientist!).

The rest

While most of the metrics are easy gathering via psutil (again, this from me!), uptime was a bit tricky:

I’m sure there are other more efficient ways of doing this, still I’m a bit proud. It calculates the difference of the time now versus the time the Pi booted (in seconds since *epoch*, so 1970-1-1 unix-date-stuff, and then calculates this with **divmod** up into days, and giving me the rest as smaller time unit of each call. This culminates in a surely glorious way of building a string of the uptime [/irony].