[Idea] Air Quality / Health Impact Plugin - HELP WANTED!

Made a little bit more progress. Stuck on this though... I need my Devices array to be independent of the actual settings until I actually save.

When a device is added to the js arrDevices, it is not added to the settings until the Save button is pressed. However, if you edit a device in arrDevices that has previously been saved to the settings, the settings update immediately, without pressing the Save button. Any ideas? It's like the settings themselves are observable objects, except I can't figure out where I'm accidentally tying the JS and Settings versions of this data together. https://github.com/stantond/OctoPrint-AirQuality/blob/ae687377d69e898a2ea393efd523789ac9b49e24/octoprint_airquality/static/js/airquality.js#L143

Interesting thread, I get some info around the house from Netatmo but not designed for 3d printers. So looking at this your making progress on the plugin, but I am unclear on the hardware. Are we talking about some sort of hat/shield type aware, manually wiring to GPIO pins (doing something like i2c etc), or a raft of IOT sensors talking back to pi over wifi?

I believe @stringsonfire intent is to utilize USB connected sensor devices for simplicity to the end user if I'm not mistaken.

@stringsonfire I think the line here might be creating the instant association to existing devices in settings.

I think you're right, I just can't figure out how to get it copying across without causing errors or generally failing. I'll try some more when I next have time.

Cheap USB to Serial converters and a range of sensor options. The plan is to make hardware set up as simple and generic as possible. Eventually, wireless devices too, but that's more complex for the every day 3D Printing hobbyist, so it's way down the line.

So for 10 sensors you would have 10 usb connections, with serial dongles via a hub or such like.

I wondered if there might be a board already out there that had all the sensors on. There were a couple of tindie but didn’t seem exactly what you were looking for.

I have a box of sensors somewhere, will look to see what I have, mainly i2c I should think have loads of serial dongle, well at least 4. I wonder if it I might have enough stuff to knock something up, but then I am not sure I have the time. More just a thought in my head From hooking up i2c temp sensors to Acorn Electrons.

Yeah, you'd need a couple of USB hubs. There'll be alternatives, for example some FTDI chips have 4 UART controllers vs the single ones I've been using. As long as the OS views them as individual serial ports, they'll work with this plugin.

I'd be surprised if most users went with more than a couple of sensors though.

The only trouble using FTDI chips are the cheap ones are always fake knock of chips (I.e. anything on eBay, Ali express etc, original will be places like RS, Adafruit, sparkfun etc..), and sometimes they don’t work as expected. Not you issue but might cause false issues against plugin.

I have both fake, original and other manufacturers and 9.9/10 it isn’t an issue.

Not sure if you ever watch SM Baker's channel. I subscribe years ago because for his RC2014 stuff. But I noticed he did an environment monitor, linked in with Prometheus that was also linked in to Octoprint and his Prometheus plugin. Different requirements and solution to this thread but might be worth a watch for some ideas.


I'm about as far as I can get with Settings until more of the backend is in place, so time to think about collecting, storing and displaying data.

Is there any reason to choose one of these approaches over the others?

  1. Write readings directly to database. Listen to/check for changes in the database to draw the chart.
  2. Write readings directly to database and draw readings directly on the chart.
  3. Draw readings directly on the chart. Do not use a database.
  4. An alternative I haven't thought of

If you want to manipulate the data in anyway, especially if adhoc that is easier and faster in a database of some sort. And for a large commercial system you would effectively only have the option of 1. For a small embedded system probably less so, due to the overhead of running a database, although recent PIs are more than capable of running a database. Personally I am more familiar with Oracle based relational systems. So I would always do option 1 as that is what I am familiar with.

I do the second option in TPLink Smartplug power monitoring. When polling is enabled (this could be the default in your case) there is a RepeatedTimer that requests the data and stores it into the database stored in the plugin's data folder. Then when you activate the tab within OctoPrint it sends an API request to the plugin's SimpeAPIPlugin mixin implemetnation requesting the data to display in the chart. Then uses the returned data to graph using plotly js library. This gives you the ability to add filtering to your request etc from the UI, etc.

https://github.com/jneilliii/OctoPrint-TPLinkSmartplug/blob/a944e5245961cf84bc133e0b694670ac68daf7fa/octoprint_tplinksmartplug/__init__.py#L474-L481

That makes sense. Looking at it, you have IP address as the ID for a given plug, added to every record. I don't think I can assume that the serial port name will be stable, so I probably need an arbitrary ID, but if I do that, I think I'll need to move from having each device stored in Settings to storing each device as a record in a Devices table. This could take a while.

It would take fairly minimal work to add a uuid to each device in order to make them unique and still store those values in settings. The drawback like you said is the mapping of serial port to device. Pretty sure there are ways to lock that down in linux based on a dev id presented by the device, assuming it does, which would allow you to just use that as it's unique identifier.

Small progress update, Devices and Locations are now stored in a database with CRUD working, and I've just got the very first sensor reading from a PMSA003 stored into the Readings table using PyPMS.

1 Like

Sensor reading thread and general handling of changes to these settings and to physical serial devices is much, much better now. When I next have time, I'll start looking at turning the readings into a meaningful metric.

I was watching a 10 year Fukushima Anniversary stream by the people at safecast.org and they mentioned this PM monitor: Airnote · Blues Wireless that could give a template idea or even if someone wanted a drop in choice that already had everything bundled. It is aimed at outdoor use but it has a USB power input and could work for us as the path for data would remove the driver and mapping issues.