Whole Home Air Quality Monitoring

[wjlove]

Introduction

Hello my name is Bill and I recently started at balena and my current goal is to learn as much as possible about the company and its products. To that end I will be following in the footsteps of so many before me and will be working on a residency project. For my project I have chosen to contribute and expand upon a project already being worked on here at balena.

Thought Process

My approach to this project is going to be slightly different from other lab resident projects in that I am going to view this from the perspective of an entrepreneur trying to prototype something quickly. Often entrepreneurs will do this because they need to generate some market interest or they need a demonstration to show potential investors. It is also during this process that many issues or questions may come up that you hadn’t already thought of and if any big changes need to be made this is the time to do it.

Interesting thing to observe is that for many entrepreneurs this is one of the most creative parts of the process and any obstructions or friction here can be very frustrating. Things that slow down the process tend to be avoided while tools that help clear a path are sought out. I hope to use balena’s ecosystem to provide the latter.

Some Detail

The balena indoor air quality (IAQ) project was originally implemented for the company’s October 2021 Summit as a way to monitor the air quality during its sessions. (GitHub - balenair/balenair: Build an indoor air quality monitoring device featuring a simple real time display and a detailed web dashboard) With the pandemic still being a concern it was hoped that this device might be a useful tool for the attendees as well as another example of how to use the balena software/build environment to create interesting things. My hope is to add new physical device configurations along with some new functionality to what is already in place thus creating a whole home air quality system with the ability to share data across multiple platforms. A second goal will be to add some more intelligence to the current rules based alerting system to help better characterize the air quality, eliminate false alarms and predict future conditions that may be considered harmful.

My initial plan is to work in two hardware design phases with a parallel track of incrementing overall software functionality of IAQ as needed for each step. However since the additional software functionality is not really a priority in the beginning it may just get moved to later in the process.

My next post later today will include a more detailed description of my project and hopefully a new name for the IAQ project.

[wjlove]

New Hardware for the IAQ Project

Currently the project has only one device and it generally looks like this:

There are a few options including having a bar graph display or just a single large led, and since the case is currently 3d printed each of the four sections could be any color.

For my project I hope to create a desktop device with the same sensors or sensor options. However, additionally I will add a touchscreen display allowing for more user interaction and to provide enhanced information about the air quality. This enhanced information would include historical data and predictive analysis plus the ability to view the information from other IAQ devices in the home. Initially the device will run on the same basic hardware/software platform however it will have expanded local storage capabilities for longer term data storage and a slightly more powerful processor to handle some new capabilities (more on that below.) While I like the idea of keeping the hardware platform the same, the processor power vs. pricing and space requirements may impact this decision. The good news is the balena software platform is flexible enough that the codebase should not have to change significantly, if at all, between this device and the original.

New Software Features

Here I hope to add three things:

1. Smart Alarming based on historical data
2. Local Device connectivity
3. External Service Connectivity

Smart alarming

The general idea here is that while statically defined warnings and alarms are very useful they can sometimes be misleading. There are some spaces that are just generally “dirty” and one might expect the air quality there to be just plain bad. An example of this might be an unfinished basement with very limited air flow and stacks of rarely used items or storage boxes. On the other hand you might expect the air in general living spaces to be quite good as these places tend to have a lot of movement and air circulation. Given this it might be useful if the device could learn over time what to expect in its current environment and alert the user appropriately. With the advent of tools like tinyML and Impulse Edge it is possible to put such intelligent decision making much closer to the situation at hand rather than having the device depend on remote processing. This will allow the IAQ devices to be much smarter about alerting without the need for external support.

Device Interconnectivity

Originally I felt that this would simply be the ability to have all devices send information back to a central location, in this case the desktop display, for further analysis and/or presentation. Further thought leads me to believe that there might be some value to adding some generic device-to-device communication as well. An example would be if one device triggers an alarm all the other devices in the home might indicate there is a problem somewhere that needs addressing. This solves a problem that a single alarming device might go unnoticed for a long period of time if located in a remote place such as an unused basement. In this case a simple broadcast message might do but there may be some other instances where something more intelligent might be useful. However what I am not interested in doing is creating yet another mesh networking layer, that is beyond the utility of this project.

External Connectivity

This last component is the inevitable/prerequisite open API into each device. How much information and control is exposed is unclear at this time. The security, privacy and value of the information made available requires some serious thought and will most likely need considerable discussion. I expect however that there will be requests for access by individuals using systems like Home Assistant, Alexa, OpenHAB, SmartThings, etc. Good news here is that it would be pretty safe to simply allow alerts to be exposed and worry about raw data access at a later time.

[wjlove]

Look what arrived today!

Well actually these arrived yesterday which is a day early and good news as we are in the middle of a snow storm. These are my sensors and cables to start working on my project and everything looks great.

BME680 - Temperature, Humidity, Pressure and Gas Sensor Breakout Board

BME280 - Temperature Humidity Pressure Sensor Breakout Board

SCD-40 - True CO2, Temperature and Humidity Sensor Breakout Board

PMSA003I Air Quality Breakout Board

ENS160 Digital Metal-Oxide Multi-Gas Sensor Breakout Board

These are just some cables that help connect the sensors together. If my image links worked correctly you’d see a bunch of qwiic cables and adapters. (They do now!)

The hope is to start hooking these together over the weekend and see what works and what doesn’t.

[wjlove]

Moving along

So over the weekend I did a few things such as building a mostly working IAQ device, think about case design and adding a new sensor. I also wanted to see if it was possible to get the current code to deploy to a balenaFin. While the latter should be easy sometimes there are quirks in the process and I was just curious. For now I am going to just talk about building my first test device.

Putting a test device together

Currently the IAQ system needs three devices, a PMSA003I, a SCD-40 and a SGP-30 to get all the information it needs for an air quality assessment. Good news is that it will still run if you are missing some of the sensors and in my case I was missing the SGP-30. I also didn’t have the needed display bits but don’t care right now as viewing the web page is enough to verify things are working.

For my first test run I used GitHub Desktop to download a copy of the repository from balena-io-playground. Next I made sure that I had spare Pi 3 in one of my fleets ready to upload the new software. (I am not going to go into creating fleets and adding devices here as there is a lot of information on the balena website on how to do that.) After that I connected the two sensors that I had and powered up the Pi 3 I wanted to use.

From here it was a simple matter of just pushing the current code to the fleet….

…and waiting for it to complete. This part took a lot longer than I expected but when you look there is a lot going on here during an initial build. After that I found making small changes only took a few minutes. After the push completes It is important to look at the balenaCloud dashboard to see how far along things are progressing with the fleet/device load.

Once that was completed I was able to get access to the main web page showing data from the sensors that are connected and also indicating what information that was missing. Once that was all done I knew I had a working environment for my further development.

Now I need to look into case options as the design lead time here could be significant….

[wjlove]

Another Thing….

One of things I am trying to do while at residency at balena is up my documentation game so here is a little side thing I did. I wanted to know if IAQ would work on a balenaFin, it should but sometimes there are little things that trip up software. I also wanted to know how good the air quality was in my makeshift server room which is basically a rack in my furnace room. In this space I think I’ve broken every best practice rule in data center design so suffice to say the air in there is not good.

So I created a Fleet of balenaFins and put one Fin device in it and then I pushed a copy of my version of the balena-iaq code to it and waited for everything to finish loading. This is what I see on the balenaCloud dashboard:

Everything looks good here!

Now I get to move the Fin near the servers, this is as a good a place as any:

…which is next to this:

…and this:

So after letting the Fin boot up I can connect to the IAQ web server and we can see the general air quality:

This is much better than I thought! The page displays some other values but the Air Quality Index is what I was looking for and proves that the device works. Not bad for a few hours of work. I’ll leave this running overnight and see if there are any trends as the furnace should be working pretty hard tonight with temperatures dipping to -5deg F tonight.

Next on to getting balena to boot on a touch screen setup, spoiler alert… it works!

[wjlove]

So as promised here is a look at what happened overnight:

Interestingly there really wasn’t much going on until it was time to bring the house up to temperature by 6am. Then we can see that the total CO2 levels rise but not too concerning at the moment. I think this is a pretty good real world example of the system working generally as designed and a good place to start adding features.

[wjlove]

Touchscreen Display - Buy vs Build

For my new device I wanted to have a slightly more informative and interactive display as it would have access to all devices in the home and all the data collected from each of them. Originally I was thinking that I would create a custom enclosure modeled on some thing like an Amazon Echo Show that housed a Raspberry Pi 7” touch screen. However upon further consideration I felt that while designing an enclosure might be a lot of fun, I really didn’t want this part of my prototyping process consuming a significant amount of my time as there are some software bits that are going to be challenging for me.

So I’ve decided that I would see what is already available either as 3D printable designs or cases that can be purchased off the shelf. A few assumptions: first, I will be using the 7 inch Raspberry Pi screen. Mostly this is because I happen to have one lying around and also because they are easy to find. They also have the added advantage of already being well supported in the Raspberry PI ecosystem. Secondly, I will be using the Raspberry Pi 3 or 4 physical platform for this stage of design as well. The layout of these devices is very similar and a simple design should be able to accommodate either one.

3D Enclosure Designs

There are several places to look for 3D designs including Thingiverse, THANGS, and yeggi. You can search any of these places and find thousands of enclosure options for the Raspberry Pi touchscreen and most are covered by a creative commons license which allows you to use the designs for your own purposes (there are some restrictions and you read about them online). This gave me a lot of options to choose from and I won’t bother going into details here, suffice to say there are enough that if I wanted to go down this path I shouldn’t have a problem.

Off the Shelf Option

The other option was to see what was available off the shelf from vendors online. Again there were lots of options but there was nothing I found that might be an exact fit for my project. There were several options that were close enough to my needs that maybe with a few modifications and an additional component or two they might just work. With that in mind I focused on a vendor I had already used in the past, Smarti Case of which I still have one in the lab.

Looks like this:

With the screen in it looks like this:

…sorry about the glare.

While this version doesn’t have enough room in the back to fit my needs they happen to have a Pro version that has a few options, including one large and one small. You can see them on their web site SmartiPi Touch Pro . This looks like a great option to get started quickly.

Going Pre-Fab

Since my time is valuable, I think I am going to purchase something rather than try and make my own. While the smaller enclosure looks like it will be able to hold all my sensors I would hate to find out it couldn’t after waiting a week. Since the price is reasonable I bought one of each and I am sure I can find use for the extra one on another project. Once they do arrive I can size up how things might fit and see what additional parts might need to be made to support my sensors inside the enclosure.

And for those who are following, my next post will actually discuss getting the balenaOS running and working with the touch screen.

[wjlove]

Interacting with the display

There are a lot of options for creating the UI (user interface or display) for my device and a lot of time can be spent on figuring out what is best for any given situation. These days one of the simplest and more ubiquitous ways of doing things is building a simple web interface. There are many advantages to doing things this way and you can go online to read countless articles about this approach. I like it for a few reasons:

1. Many simple design tools
2. Code once, display everywhere (well…. mostly)
3. Software handles display characteristics
4. Virtually no software vendor dependencies
5. Familiar functionality to most people

Since my design and architecture environment allows me to have simple web servers and/or services I think I will explore this path first.

balena Blocks - Specifically the Browser Block

Given that I am going to be using a web UI for my device I am going to need a way to display things on my 7 inch Raspberry Pi touchscreen. One of the cool things about the balena ecosystem is that there are building blocks already put together for common functionality. Many of these blocks can stand on their own as an application while others really don’t make much sense unless used with something else. The IAQ application itself is actually composed of several balena blocks along with some very nice glue code.

One of the many blocks that can be found on the balenaHub website under “Blocks” is something simply called “browser”.

Clicking on that block will give me access to all the files and a nice little readme.md file that describes what it does and what options are available. In short what this block allows you to do is to display a web page/site on your local display. There are all manner of ways the pages can be presented and again you will find all you need to know in the readme file. This is perfect for my prototyping needs.

Not so fast….

One thing we haven’t explored yet is if the Raspberry Pi touchscreen is supported by the balena environment because if it isn’t then we need to look at other options. I had mentioned in another post that the touchscreen is well supported by the Raspberry Pi but there are a few things different with the balenaOS, so let’s do some testing……

First we need to provision a device in the balenaCloud and create a SD card to insert into the Pi device. This is done via the balenaCloud dashboard and I won’t go into how to do that again here. Once you have a SD card ready and inserted in the Pi you can install it in the back of the touchscreen enclosure you are using. In my previous post I mentioned that for prototyping I am going to use a SmartiPi case I had lying around. The Pi goes in the back of the case like this:

With the cover on the back, power adapter cable and ethernet cable, it looks like this:

(Note the Y-adapter for the power supply to power both the Pi and the touch screen. There are other ways to get power to the screen but this is fine for now.)

Powering on the device we see the balena logo as expected, so this works…!

Those folks with good eyes might notice the little lightning bolt in the upper right of the screen. That means there is not enough power going to the Pi which will happen if you don’t use a larger power adapter after adding the screen. You will also see a “Danger!” notice on the balenaCloud dashboard about this which is very helpful. Right now I don’t care about under powering the Pi as I am just testing, more power is coming soon.

Testing the Browser block

In a previous post I talked about downloading and installing applications from the balenaHub so I won’t go into that again and if a balena block can work standalone then the process is pretty much the same. I downloaded the block with GitHub Desktop, verified that the docker-compose.yml was sane and pushed it to the fleet I was using for testing. After a short period of time the push completed and the device booted up with the browser block running showing its default web page:

Very nice….

Show me something useful

There are several ways you can manipulate the behavior of the browser block and those are documented in the readme file. One of the first things I wanted to do is view something other than the default web page and one way to do that is via environment variables. These values can be set via the dashboard under the “Device Variables” menu selection:

Selecting “Add variable” allows us to add an environment variable that tells the browser block to load a different web site or web application when it starts. The variable I want to add is “LAUNCH_URL” and the web site I want to point to for fun is “www.balena.io”:

Clicking “Add” gets the variable added:

and restarts the browser block displaying balena’s web site:

That looks pretty good but we can clean it up a bit. One of the environment variables we can set is KIOSK. Kiosk mode is common among web browsers and among other things it removes items like the toolbars and menus from the display. I can enable it just like I did with LAUNCH_URL only this time we set the KIOSK variable to “1”and I get a much cleaner looking display:

Now let’s point the browser block to my currently running version of IAQ:

Good news, the air in my server room is still ok to breathe

A good time to pause

I think this is a good stopping point for this kind of hardware prototyping. What needs to get done next is some detailed discussions on what the software architecture is going to look like. That’s not to say that I haven’t had one in mind while I’ve been tinkering with hardware options, but rather now that I have a good feel for my hardware environment options it might be best to sketch out my software vision. More on that coming soon….

[wjlove]

Because I had to know….

….And because it looked rather easy, how hard would it actually be to get the browser block and the IAQ application running on the same touchscreen device. If you recall from my previous post, IAQ is a bunch of balena blocks tied together with some custom code. The blocks can actually do a lot on their own such as find each other and configure themselves to chat politely amongst themselves. The custom code does most of the application specific work such as collecting data from sensors and displaying alerting information. Since the browser block can be a mostly standalone block it should be easy to ask the balenaOS to run it along with all the other blocks and then all I have to do is configure it with the appropriate environment variables to display the IAQ dashboard on the local touchscreen. Turns out it is actually easier than this and I will get to that in a second.

Stringing things together

First let me say that I struggled a little with this section because I wanted to show just how simple prototyping in the balena ecosystem can be, yet I found myself suddenly wondering how much of the underlying mechanics of the balena environment I should talk about now. There is quite a bit of “magic” happening behind the curtains, but I think right now it is not helpful to dive into this as I want this to be short. So ignoring the technology behind this….

What we need to know is where IAQ puts all its blocks together and then add our browser block to the mix. Turns out this is pretty easy to find and it is all in a file called docker.compose.yml. Opening up this file and looking inside I see:

I happen to know a little bit about Docker and containers in general so this file makes sense to me and to be fair it is a pretty simple example. (Check out the links if you want to know more Docker and containers) In it we can see that balena blocks are actually just containers and they are all listed under “services:”. For IAQ we have six different blocks, influxdb, dashboard, iaq, connector, mqtt and wifi-connect.

Now if we look at the browser block’s docker-compose.yml we see:

There is only one block so if I merge these two files together, I get:

A few things to note here: you don’t need to include the “version:” tag twice and the same with “volumes:” and “services:”. Also formatting is very important and indentation matters so be sure to line things up correctly. However if you do screw things up the balena tools will let you know about it automatically and that is very handy!

Now if I push my copy of the IAQ code repository with this new docker-compose.yml file to my touchscreen fleet and I connect my sensors to the Raspberry Pi in the touchscreen device I should be all set. Also since I am running everything locally on this one device, I no longer need the LAUNCH_URL variable that was added earlier. This is done in the same place I added it before however I left the KIOSK variable because I still want that clean look when the browser displays the page. I can make these changes at any time during the uploading of the new code or after it is running.

Tada! Everything works….

(…small FYI, this upload might take some time as the balenaClound software needs to install the new code on top of the old running code. You can watch the progress on the balena dashboard.)

Now I want to move on and look at those new Smarti Pi cases that arrived over the weekend and hopefully I can put those pesky(and expensive) little sensors somewhere safe….

[wjlove]

Finalizing the Prototype Packaging

For those who have been following along, in my March 2nd post I was playing around with case options for my 7 inch touchscreen device. I was going through the build vs buy decision process and was leaning towards buying something off the shelf. I had an old Smarti Pi case that looked nice but it wasn’t large enough to hold my Raspberry Pi and all the potential sensors I might have. Fortunately for me the Smarti Pi folks have been busy and had several other options to choose including the Smarti Pi Pro which looks to fit the jobs quite nicely. They have several options including a large and a small rear case so I ordered one of each to see which one would be best for my project. These arrived on Friday and over the weekend I started to review them both.

Old vs New

I am not going to review each individual component in the new enclosure kits as you can find that information on the Smarti Pi web site. Other than the camera placement, the front of the screen and base look pretty much the same as my original enclosure….

(the camera area is now located on the bottom area of the display)

Looking at the back we can see some significant changes in the way the Raspberry Pi is installed and some of the other hardware mounting options. The Smarti Pi Pro design has more cutout options for power and has standoffs for both a Pi and a Pi Hat.

Also there are two welcome additions to the enclosure kits, first there is metal insert for the bottom of the base to give the unit added weight. While not strictly necessary for my needs it might come in handy if there are lot of other devices added inside the enclosure. Second, they include a power Y-adapter for both the Pi3 and Pi4. For those who don’t know, the primary power connector on the Pi3 is a micro-USB while the Pi4 uses a USC-C. Since I don’t know if you will ultimately be using a Pi3 or a Pi4 this inclusion is very helpful.

With the screen installed we can see from the back we have a lot of space to work with:

Note the standoffs with brass inserts, that’s a nice touch. Also notice that there are four standoffs on one half of the back for the Raspberry Pi and then yet another four standoffs on the other half for a Pi Hat.

Powering the screen

In a previous post I mentioned there are several ways to power Raspberry Pi when it is connected to this type of touchscreen device. As a reminder, here is a closeup of the back of the touchscreen with its controller installed.

There are a total of five connectors on the controller, two are USB, two are ribbon and the fifth is a 2.5mm pin header. For power we only need to concern ourselves with the USB ports and the pin header. The controller gets its power from the micro-USB port and then can deliver power to the Pi via the USB-B port or the pin header but not both at the same time. Another option is to not power the Pi from the controller but rather use a Y-splitter cable from the wall adapter and power the touchscreen and the Pi separately via their micro-USB ports. This latter option is what I see most people doing and I suspect that is because the power requirements have increased in later Pi designs, it is also what I plan on doing.

Small vs Large

From what I can see the only major difference between the two enclosure kits is the size of the rear enclosure. While both have the same length and width, the larger enclosure has about twice the depth as the smaller enclosure.

Some quick toying around and I find that the smaller case can hold a Raspberry Pi with a Pi Hat stilling next to it while the larger case can hold a Raspberry Pi with a Hat on top and two more Hats stacked next to it. For my needs the smaller case will do just fine.

Installing the Pi on the back of the main enclosure gives me this:

and I can see I have about half of the back real estate leftover for my sensors. This is about 3 x 3inches (75 x 75mm) square which should be enough space for three or four sensors plus a little room for wiring etc.

How Many Sensors

Currently I have been using three sensors with the IAQ project, the SCD-40, the SGP-30 and the PMSA003I which I have talked about earlier. While these may not be the final set of devices I use they are good enough for my prototyping. I will need a way to attach these devices to the inside of the enclosure so that they are not bouncing around and so that they each get good airflow. Digging around my lab I find that I have some old blank PCBs that should be big enough to hold all my sensors and then be attached to the standoffs on the back of the case.

Trying a few layouts I discover one that I like…

….and drill a few holes.

(I also added some plastic film to cover the PCB tinned holes. When I attach the sensors to the PCB I don’t want to short out any of the traces on the back of the sensors, the film {actually tape} prevents that.)

Putting everything together with some screws and wires I get a nice looking little package.

Lastly, I install it in the enclosure…

…Look’n good and not bad for a few hours of work.

Closing things up:

(there is a cover for the side opening but I left that out as I may need those ports for testing)

Crap, it doesn’t work

Normally I do not enclose everything right away just in case something doesn’t work, however this time I was so happy with how things looked I did not follow my own rules. Of course Fate was paying attention and when I powered up my enclosure things did not work. Fortunately the author of the IAQ software provides a substantial amount of logging and I was able to discern that none of the sensors were found. Sounds like a wiring issue and a quick removal of the back of the case reveals that indeed this is the problem. The connector from the sensors to the Raspberry Pi was installed incorrectly. If you look closely at my previous image showing everything installed in the back you can actually see the connector is moved over to the left by exactly one pin. Doh! Moving the connector to the correct position fixes the problem and all is well.

Now I really need to get to software architecture documentation….

[wjlove]

A plan for Software

For some time now I have been thinking about how to prototype my project and mostly I have been playing around with some of my hardware options. However along with this hardware selection process I needed to consider some of the software options I might have available and in my previous posts you can read about some of my thoughts and hints as to what I was considering. I believe that for the most part it is a pretty bad idea to not be thinking about both the hardware and the software at the same time you are developing a product, unless of course you find yourself in the position of having created something completely new. Then you may need to create the complementary component(s) to complete the package. In my case I am not building a new product with elements that “…haven’t been invented yet…” but rather building and expanding upon the hard work of others, specifically the Open Source community and balena.

As a reminder, I mentioned in my introductory post in this forum that my project is based on some work already being done at balena, specifically the IAQ project. During my few weeks here at balena this project has seen some significant changes and improvements (and many more to come!), the overall design still remains the same. Given that I want to take the current design and incorporate it into my new idea I thought it would be helpful to spend some time to understand each component better. A good way to do that is to visualize what the current components are and what they do, or at least what I think they are and do. By doing this I get an instant framework for my next steps plus if I have made any mistakes other individuals can comment on that and I can then make the appropriate changes to my understanding and thought process.

With that in mind here is what I have come up with as the current architecture:

Current IAQ design features

While it might appear that there is a lot going on here it is really not all that complicated. This is because for the bulk of what is shown the balena ecosystem is handling the details and we do not have to worry about it. I have included those details in the diagram for my own education and for completeness going forward. For the reader I will touch on them below and where appropriate include links to balena’s own documentation with details. Again, you don’t really need to be an expert in any of these areas but I consider it helpful to have at least a working understanding of the computing environment I am in and to take advantage of as many of the appropriate features it provides as possible.

BalenaOS/Kernel

The balenaOS is the underlying operating system that all my software will run on. It has been optimized in many ways to help run application software on lots of devices. By this I mean not only a plethora of different types of computers but also many of them at once! This latter bit you will see often mentioned as “Fleets” in their documentation and is one of the prominent selling points of using the balena infrastructure. While it may appear that managing a group of devices that are exactly the same and running the same software is easy, the reality of this is significantly different, it’s hard.

BalenaEngine and Systemd/User Space

These are bits of software that run on top of the baleanOS. The baleanEngine handles the management of specific “chunks” of software in a rather special way called software containers. I have mentioned this earlier in my posts but in case you want to review it again I have included the previous link. I don’t really need to know much about the engine itself but the use of software containers will be a big component in my software design. Systemd is a relatively generalistic bit of software that does a ton of the configuration and housekeeping chores for the operating system. Again, this is something that is good to know about because of the features it provides, but again I don’t need to be an expert. User Space is really a term used to describe a place where generic programs run on top of the operating system. Since I will be using the balena environment almost exclusively I don’t have to worry about where my programs run, balena will just take care of it.

Containers

Ah yes, back to containers… This is where the bulk of my software work will happen and is indeed where the bulk of the components of the IAQ application. While the term container is relatively generic referring to running software in a protected environment, from my point of view in the balena system there are some containers that are categorized differently.

Supervisor - Special

The supervisor container is responsible for managing all the other running containers and includes many of the functions that allow for remote management of the entire software system. Yet again, this is something I don’t really care about other than it provides a number of useful tools for maintaining my application while it is running. Follow the link if you want to know more.

Blocks

These are chucks of software or containers that perform very specific functions. The concept is not new and balena provides a good overview of what they are trying to accomplish with them here. The basic idea here is that by connecting multiple blocks together I can create something that is “…greater than the sum of its parts…” or in this case, blocks. The IAQ application does this by using blocks to handle commonly desired functions while it handles specific ones not found in other blocks. For prototyping an application this is hugely advantageous as I do not have to concern myself with the boring bits and instead focus on the exciting stuff that does not already exist. Balena’s goal is to have so many block functions available that it is absolutely possible to create an entire application without having to write any custom software. When that happens then the exciting stuff is your own creativity.

I should also note that the blocks do not necessarily have to come from balena. There are other sources of generic containerised software chunks such as dockerHub. However, blocks found on the balenaHub tend to have complementary options or features to help them work with each other.

I’ll quickly touch on the blocks used by IAQ:

• MQTT:passes information or data to other blocks or chunks of software. Not actually a balenaHub block and an example of a generic container
• Connector: acts like a translator of data/information between blocks that don’t speak the same language
• InfluxDB: a database that is very good at handling a specific type of information know as “time-series data” Not balena specific
• Dashboard: a tool to create visually pleasing way of presenting complex information
• WiFi-Connect: tool to manage connecting devices wirelessly to a local network

You can look on the baleanHub web site under Blocks to find more information about each of these blocks plus a list of other blocks currently available for use in the balena environment. While there you can also find other examples of blocks in use in various working Projects or Fleets.

IAQ

Now all that is left is the IAQ code itself. Here I found all the software that provides functions that can not be found in either the underlying infrastructure or in the various blocks. I can summarize these as follows:

• Discover and initialize the air quality sensors. Currently there are three supported sensors and at least one needs to be present to provide any meaningful information. Some sensors need calibration in order to function correctly.
• Discover and initialize the display on the device. There are three options for a display, a single Led, Led light bar and a Led matrix. Where/when appropriate provider some user feedback about the device configuration.
• Collect and normalize sensor data from all the discovered sensor devices
• Calculate the air quality indexes from the available sensor data. This is calculated by applying simple and well known methods for air quality quantification.
• Update displays with air quality index information and provide a visual indication if there is a reason for concern.
• Package up all the information collected so that it can be sent to the database block, then send it.

Building upon the architecture

Tomorrow I will discuss how I am going to screw all this up, I mean expand upon this for my project…