Cutting through the smog: making an air quality bot with Haskell

I've been working on a side project related to the air quality too, for a few months now. However, the technology stack is less impressive than Haskell: plain PHP7 + MySQL. I just wanted to have a single page presenting the air quality stats [1], fetched from the DIY detector Luftdaten [2], that can be hosted anywhere (so other people can grab the code from github [3] and use it too).

Then, people started to requesting new features and I had ideas for new features and it was no longer a single-page project.

Then, people started to reporting issues with their PHP hosting accounts, so I was spending time debugging problems in their deployments.

Then, I thought it may be easier to introduce multi-tenancy so I can just support a single environment, the one that I own. So I added registration, dashboard, maps, Let's Encrypt, etc.

This way I ended up owning a small, open-source SaaS written in PHP7 and MySQL [4]. If I knew how my single-page app will grow, I'd choose something more suitable, like Rails or Dropwizard. On the other hand, it works, is usable and maintainable, so maybe it's fine the way it is.

[1] https://smolna.aqi.eco/ [2] https://luftdaten.info/ [3] https://github.com/trekawek/air-quality-info/ [4] https://aqi.eco/

I recently wrote something similar to pull data from Kaiterra Laser Eggs (also in Haskell!) -- https://github.com/ford-prefect/laser-egg/

On a related note, I've been looking for a good sensor that is hopefully plug & play and reliable for integration with home assistant. Is something like https://www.banggood.com/Geekcreit-Nova-PM-Sensor-SDS011-Hig... really the best way to go about it rather than an Awair? Would be keen on VOCs and CO2 as well.

edit: Looks like esphome with the following low-cost sensors is the way to go: * MH-Z19 for co2 (or CCS811 CO_2 for VOCs as well) * SDS011 for particle counts

I know it is hard to strike a good balance between academic and technical focus, especially when writing about haskell, but I think starting out with language extensions and imports without writing about what and how we're going to do it, makes for difficult reading.

The smaller parts with the types and small implementations should be at the top and only at the end all is easily combined.

And I highly doubt that the author went about writing the chatbot by writing out all the language extensions and imports first (which makes the coding-along line at the and a bit cynical).

Edit: This sounds so negative. I think the article is good and shows how the small pieces work together but I think the order is all wrong.

A good article! I agree with another commenter that explaining the language extensions would have been good.

I liked the comment at the end:

>> It’s the same bot as we have detailed in the tutorial with the exception that it uses PostGIS instead of a transactional variable to store users.

I am not a Haskell expert (I use Haskell a lot but I consider myself a student) so this is probably horrible advice, but recently I have started using embedded SQLite for transactional data instead of TVars. In some sense it is the same thing since the Simple SQLite wraps the SQLite code in an IO. I always try to minimize impure code. I write as much pure code as I can in a REPL and then study/research how to handle the impure parts.

I hope I never have to move to a place where I want to monitor the air quality at all.