As I mentioned in my previous post about building a Raspberry Pi weather station, one of my goals is to move to a Pi Zero W. I’ve spent most of my time since Pi day (March 14) on that, I am most of the way there. It’s taken a bit more effort than I anticipated.
First of all, as it turns out, the Pi Zero uses an ARMv6-based architecture, and can’t run the version of Node.js that I was running for the previous Azure tutorial. I had to find another way to read data off the BME280. I ran down a considerable rabbit role with C, before giving up and going with Python.
Second, while the Node.js tutorial included both an app to read data and send to the cloud, the Python tutorials for Azure that I found will 1) read data and 2) send simulated data to the cloud. My next goal is to splice the two so that I’m basically doing again in Python what I was already doing with Node.js.
Re-Architecting in Python 3
First of all, yes, in my line of work “architect” is a verb. I will architect something, we need some architecting, etc. Somehow “design” doesn’t quite capture the scope, especially in larger applications.
I did try getting Node to run. However – and I’m having a hard time fully retracing my steps here, bear with me – the initial tutorial wants Node.js 10 or higher installed. The Pi Zero, at least the one I have, uses the ARMv6 instructions set, which does not support that high a version of Node. You can visit the Node download page here.
I also went down the C path, but ran into some challenges getting everything unpacked correctly, so that left Python.
To use Python, I had to install Python 3. Specifically I ended up with 3.5.2. To do this, however, I had to install PIP: sudo apt install python3-pip.
I leaned heavily on this article from Adafruit, as well as this one for the BME280 wiring.
The result is that when I run boardfull.py I get a steady stream of data from the sensor. It’s pretty comfortable, running on my desk:
Regarding altitude, there is a value in the script to essentially baseline the air pressure at your location. I haven’t done that yet.
Sending Telemetry to Azure with Python
The steps outlined in the “Send Telemetry with Python” article were very straightforward. Most of the article steps through creating the Azure resources needed by using the Azure CLI (Command Line Interface), but since I had already created most of the resources that I needed, I just had to skim along to make sure I hadn’t overlooked anything.
There is a downloading package of resources which, once I had on the Pi Zero, basically came down to “run simulateddevice.py”. I did that, and data showed up in the hub. Yay.
Bonus Round: Headless Pi
Before I could get on with any of the above, I had to read up on how to configure a headless Pi to connect to my network automatically. There are many tutorials (here is one) that spell this out better than I can, but the basics are:
- Pre-configure the WPA Supplicant config file with data needed for wireless.
- Create an empty file call ssh.
- Put these files on the boot card for your Pi.
A couple of caveats:
- Windows can’t read a Pi startup volume and will keep bothering you to format the disk. Oddly, it actually can read the disk. Just be prepared for, and ignore, all those prompts.
- Windows will also by default append a hidden file extension, resulting in something like wpa_supplicant.conf.txt. This was the source of much profanity. Show fie extensions or work on a Mac, if you can, and make sure the file is named correctly in full.
- You’ll need to repeat these steps unless, once you ssh in to your headless Pi,
sudo raspi-configand set your wifi settings permanently.
Since doing all this, especially that last step, I’ve been able to reboot my Pi and reconnect. It usually picks up the same IP# it had previously, so that’s convenient.
Ongoing Assessment
I’ve let the sensor-reading app run hours at a time now. About once a day, it seems to require a hard reset. What will happen is, my ssh connection gets reset. I reconnect, try to run the boardfull again, and I get a series of errors amounting to “I can’t find that device”.
Running the following command shows the no device is present:
sudo i2cdetect -y 1
You should get something like the following:
Instead, all registers will be empty. The first time this happened I randomly reseated all the cables. The second time, I removed first the power (5V) from the BME280 and then reseated all its cables, then I did the same on the GPIO pins of the Pi Zero – removed the power, reseated the other cables, put power back on.
That seems to fix things. I expect I’ll need to find a way to failure-proof that for production.