Home ventilation automation revisited

New season of our fight for clean air is here and I realised that there have been some useful updates of our home ventilation automation system that I haven’t shared yet. It is now much simpler and most importantly much more stable without the need to frequently fall into some plan B scenario.

Simplicity is elegant. I’ve already mentioned that there are some good smart relays on the market, like Shelly 1, open to the world via its cloud service. Apart from heating, we are now using Shelly 1 also to switch the ventilation. So we got rid of the whole IFTTT-based setup which was quite limiting. Also the whole controlling code is now running in the cloud. The architecture of the whole setup is in analogy to our heating automation project.

Originally, we were getting the air quality data solely from Sensor.Community. So first our air quality meters were publishing these data there, via Sensor.Community rest API, and then the controlling program was retrieving them from there and using those values to do the calculations. We mentioned those plan B scenarios. The typical case was when Sensor.Community API was unable to respond in time. All in all it’s a free service, it’s not really swift and stable enough for frequent invocations, so using it this way was not completely appropriate. For such case we have a plan B – turn off ventilation, i.e. if you don’t know the current air quality do what is safe to prevent contamination of indoor air. But often the air quality was OK but the service providing the air quality data was not. So to prevent this, it makes more sense to store your own data somewhere else, to some more reliable service. Moreover, for all our actuation use cases we currently have, we only need current data of temperature and air quality and it is unnecessary to store the whole history. You can still get the whole timeseries history for less critical use cases, like data analysis and visualisation, from the Sensor.Community or view it via aqi.eco service which we are still feeding as well.

So behold, now it’s simple as this: our air quality and meteorological sensors are sending current values not only to Sensors.Community service but also to our own “service”. The data are being passed via AWS Cloud Front distribution to the so called Lambda function URL. The lambda function itself is pushing current data to AWS Systems Manager Parameter Store. All our other controlling lambdas, which are actually eventually sending some actuation signals to Shelly’s API, are retrieving and using these parameters (current air quality and temperature data) to do their calculations. Same as in the case of heating, we can benefit from logging and monitoring options provided by the cloud. With this setup, fallbacks are rare and air quality is really checked and ventilation adjusted every 3 minutes.

Instead of users we have our sensors sending data regularly. Lambda function exposed via URL is finally storing data into Systems Manager Parameter Store in “upsert” manner.

Here you can read more details about how to setup Lambda function URLs and here about how to secure them with Cloud Front distribution. To avoid confusion I stress that there are two lambda functions. One is just handling data send by our sensors, always updating the current values in the Parameter Store. This is the one exposed via URL. The other one is running periodically every 3 minutes and checking current air quality values against the controlling logic and eventually sending signal to turn on or off the ventilation via Shelly API. The detailed code can be found here.

What else is new?

What is also new is that we are also respecting timers set in the Shelly mobile application. Say that there is a timer set to turn ventilation on between 9:00 and 16:00, then air quality is checked and ventilation adjusted only in this time window, otherwise the ventilation is kept off. This was quite easy to achieve because information about Shelly device’s state includes also information about timers which are currently set for a given device and all this can be easily retrieved via call to Shelly API.

The whole ventilation apparatus which is being automated was also upgraded. From small one room recuperation unit in the corner of the living room to much more grown-up and powerful central recuperation unit ventilating big open area in the middle of our house which consists of living room, dining room, staircase, and adjacent corridors.

I really like it now. Caching our own air quality and temperature data streamed directly from the sensors. Simple. Elegant.