Smart air quality monitor by BettAir: innovative IoT solutions

BettAir is a data-focused medtech startup company, with in-house IoT development, implementing predictive tools to analyse environmental data, generate actionable insights, and provide recommendations.

The BettAir project, realised with LogiNet's participation, aimed to create an IoT application that accurately and reliably monitors air quality and provides real-time data to users in an easy-to-use, scalable and cost-effective IoT solution.

It calculates the air quality of enclosed spaces such as offices, meeting rooms or other public spaces based on specific data. The system helps company staff be aware of the indoor air quality monitor and its impact on productivity in their space, and it sends alerts about changes in air quality when necessary.

The system uses hardware sensors to measure temperature, humidity, carbon dioxide (CO2) levels, noise and light.

Based on the measured data, the formula is used to calculate a BettAir Score, which summarises the quality of the working environment in a single value. This score considers several factors. For instance, it decreases if it’s too cold or if the temperature is ideal but the carbon dioxide level in the air is too high.

The BettAir Score is a numerical measure that reflects air quality based on a combination of variables. By monitoring air quality, we can suggest different actions to the user and set targets.

In addition, the system allows the tenant to demonstrate air quality issues to the office building and enforce the contractual obligation.

During the project implementation, we prioritised cost-effectiveness as the goal was to create a production-ready MVP version. This would allow BettAIR to pitch and market the IoT devices and system functionality. A key consideration was to initiate future sales of BettAir, so the device had to be economical, reliable and aesthetically pleasing.

The aim was for the gauge to display real-time data in a mobile application and on a website by communicating with a back-end system.

The project utilised the following technologies:

To increase cost-effectiveness, we were looking for a solution that would greatly simplify the backend and act as a low-code tool for the mobile application, so that developer configuration would be sufficient to get it up and running. We chose the Supabase Lightwave backend solution because it was easy to set up and met the project's requirements.

In contrast to Firebase, Supabase can be operated completely free of charge in a local development setup, whereas Google's solution requires payment and lacks self-hosting options. The Docker solution also makes it easier to extend functionality.

To handle and process large amounts of data, we initially considered using InfluxDB and also evaluated the TimescaleDB option offered by Supabase. Given that we didn’t require the complex functionalities and detailed visualisation options of InfluxDB, the simpler solution of TimescaleDB proved sufficient. TimescaleDB is one of the Supabase plugins that made the integration tasks easier: authorisation management and API access (JWT, authentication, etc.) can all be handled using Supabase's built-in tools.

Due to the need for an application that would be accessible on both the website and mobile devices, we chose the Flutter software development kit, which we had experience with from other projects. This allowed us to cost-effectively develop the application for multiple platforms at the same time, which we'll discuss later.

By choosing the right technologies, we were able to complete the project within three months of starting.

Supabase offers a paid cloud solution, but because it is open source, it can also be run locally in a Docker environment. We chose the local solution for two main reasons: it's free, and it allows us to keep all data and control in-house. In addition, Supabase is extremely easy to run using Docker.

Docker's microservice architecture enables turning off unused Supabase features. In addition, if required, a service with a specific feature can be developed to work with the same database, using the same authentication service and other systems as Supabase.

While the Supabase documentation is generally detailed, it often focuses on the paid cloud solution and doesn't always provide sufficient guidance for local implementations. Configuration can often be easier with the cloud solution as it offers more options. Consequently, developers must adapt the instructions from the paid version to the local environment, which is not always straightforward.

For example, there is no comprehensive documentation on the local handling of environment variables, but most of this information can be gleaned from the source code available on GitHub.

An experienced server-side developer can work with Supabase locally. However, if the backend is entrusted to a mobile development team that is less familiar with this area, Supabase's web solution provides sufficient support to enable them to work effectively. In such cases, local development is not recommended.

Supabase provides a functional management environment, but it is designed for developers. The customer needed an easy-to-use admin interface to manage authorised devices, users and other data. We needed a cost-effective solution and Motor Admin was a great help as it can be set up quickly alongside Supabase.

Motor Admin is a no-code administration web tool that allows developers to configure all the necessary settings and restrictions during implementation. User permission groups can be created and managed for efficient access control.

A key consideration in developing the client was to make the application available on as many platforms as possible in a cost-effective way. We used the Flutter framework, which has a proven track record on mobile platforms, and compiled the Dart code written in Flutter for multiple platforms.

Compiling for multiple platforms is generally straightforward within Flutter, but it's important to ensure that all libraries support each target platform. The main challenge lies in adapting to different screen sizes: larger screens allow more information to be displayed, while smaller screens often require multiple views to display the same page. In addition, the size of the web interface can vary, so we have carefully designed transitions to adapt to different screen sizes.

An additional challenge was that due to the different functionality of web and mobile navigation, additional development work was required to harmonise the two routing solutions. Certain URLs, such as those used when requesting a new password, had to be handled individually to ensure proper support across the different platforms.

The password reminder link is sent to users via email:

For the email, we couldn’t determine whether it would be opened on mobile or web, so for mobile, we had to configure the app URL, and for the web, we had to handle the web URL uniquely to open the correct page.