I was utterly oblivious of the health aspect of 3D printing, but now, after checking out your links, I am so freaked out that I also suspended any 3D printing until I build an enclosure with ventilation, something like this: https://www.instructables.com/id/Easy-and-Cheap-3D-Printer-Fume-Hood/
According to those links, the main potential health issue is the emission of nanoparticles or ultrafine particles during printing. As far as I can tell none of those sensors you listed can detect particles that are that small. Or am I missing something?
By the way, big thank you for bringing this issue up; I am amazed how much there is a lack of public awareness of these health concerns.
Yeah, it's a little scary. Pretty sure the particulate matter sensors (I'm using the PMS A003) do measure these particles. Haven't looked into best options for VOCs yet.
According to most researches (for example, https://www.ehs.pitt.edu/sites/default/files/docs/03-0253Dprinters.pdf or https://pubs.rsc.org/en/content/articlelanding/2019/ra/c9ra03248g#!divAbstract), printers emit particles with sizes less than 0.1um. The size of the smallest particles PMSA003 or SDS011 can detect is 0.3um. I'm not aware of any affordable sensors that can measure particles under 0.1um.
Ah I see, yes you're right. I was thinking of PM1, which is >=1um. I'll be using the finest standard I can - seems more than likely PM emissions are across a spectrum of sizes, not exclusively <0.3um.
I'll also be monitoring various VOCs across as wide a range as I can cover.
Having said that, progress is difficult, it takes me a day or so to do something that would take an experienced developer 10 minutes, so this is a long, long term project.
AFAIK there is no effective DIY ventilation solution on Thingiverse or elsewhere from the 3D printing community. I remember finding only one that had any testing, and the result was that it didn't do the job. At least when this project is ready, it'll be easy for creators to measure the effectiveness of their solutions.
This research found that over 99% of the particles emitted by 3D printers are nanoparticles, i.e., smaller than 0.1u: https://www.sciencedirect.com/science/article/abs/pii/S187155321630038X
Unfortunately, if that’s true it means that there is little point using these cheap sensors.
VOC detection should be possible though, I just ordered this sensor: https://www.aliexpress.com/item/4001158887646.html. Edit: just realized that's not the right sensor for the task. This is a better choice: https://www.aliexpress.com/item/32866392932.html
Because of the small sizes of the particles they can’t be filtered out by ordinary HIPAA filters. The only solution seems to be is to use an enclosure and ventilating the air out from it, like in the Instructable link I posted before, but there are several similar projects out there. This research found that the combination of enclosure and ventilation can reduce the presence of particles by 97%: https://www.hse.gov.uk/research/rrpdf/rr1146.pdf
There are a couple things I remember reading before starting this project that gave me some hope, but I don't know which article I read them in, so may not be accurate...
The 0.1um particles don't stay 0.1um forever - they bond to each other fairly quickly to create larger particles. If that is true, measuring larger particles will have some use. If not, I'll need to find a better sensor.
HEPA filters can work on particles this size if they're thick enough - not because the particles can't get through the holes as with larger particles, but because while they can get through the holes, there's no straight path, so they rebound and rebound, losing energy, until they no longer have enough energy to escape the other side and become trapped in the filter. I don't know how thick the filter needs to be.
I don't know if this has been discussed in this thread or not but I will say that the UFPs will in all certainty possess a negative charge. Grounding a metallic or electrically-conductive filter would in theory help to trap the particles. Applying a positive charge would be even better.
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?
- Write readings directly to database. Listen to/check for changes in the database to draw the chart.
- Write readings directly to database and draw readings directly on the chart.
- Draw readings directly on the chart. Do not use a database.
- 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.
