Support for SGP40 Sensors

I created a PR to add support for the SGP40 Sensor. I’m not a python pro, so I’m happy for any input. I’m also unsure about adding the klippy-requirement. it looks a bit “wild” to me to add a lib just to convert the raw value.

Link to the PR: sgp40: Add sgp40 support by meteyou · Pull Request #6738 · Klipper3d/klipper · GitHub

1 Like

If you look at the original code, there are just Python implementations, so there is no real need for external dependencies.

BTW,
Is it better than BME680?
They are the same type of sensors, and the VOC index is mostly useless without calibration under known conditions.

What is the purpose of that specific sensor here?
Strictly speaking, SGP40 is not a temperature sensor.
If you plan to use it in a filtration system or even in a chamber - the VOC index will be misleading.

According to the library code and the datasheet, it just shows you the difference from the average value of the past N hours.
So, just reloading the configuration is enough to show a polluted system as clean.

Maybe you do not even need that library in the first place.

1 Like

Thx for your feedback!

If you look at the original code, there are just Python implementations, so there is no real need for external dependencies.

I saw the “internal dependency”, but I could not find any example in the Klippy code for something like that. Where should i store the “VOCAlgorithm.py”?

The original lib was from here: DFRobot_SGP40/Python/raspberrypi/DFRobot_SGP40_VOCAlgorithm.py at master · DFRobot/DFRobot_SGP40 · GitHub

Is it better than BME680?
They are the same type of sensors, and the VOC index is mostly useless without calibration under known conditions.
What is the purpose of that specific sensor here?
Strictly speaking, SGP40 is not a temperature sensor.
If you plan to use it in a filtration system or even in a chamber - the VOC index will be misleading.

I just use this sensor in my Stealthmax Filter. One for “input air” and one for “output air”. So I use only use the relative values between these sensors to control the fan. I want to use a “display_template” to control a fan_generic with values from these 2 sensors. I just found it strange that this sensor is not directly supported in Klipper, so i have to import the files. so i thought i would create a PR for it directly.

FWIW, Sensirion is providing reference implementations here: Sensirion AG · GitHub

Thx! I also used this repo for the implementation: GitHub - Sensirion/python-i2c-sgp4x: The SGP40 is Sensirion’s new digital VOC (volatile organic compounds) sensor designed for easy integration into air purifiers or demand-controlled ventilation.

but it only reads the RAW value and doesn’t use any converter from RAW to VOC.

I’ve imported VOCAlgorithm.py and sgp40.py into my klipper and it’s works OK on my voron 2.4. Also I’ve created a macro to view sensor values. This sensor give you temp, humidity, raw voc data, and voc index.

BME680, I think that It is not sensitive to the vocs produced by our 3D printers

There are no kinds of VOCs and there is no VOC measurements.
Neither of these sensors can measure VOC.
To measure them there are some fancier like PMS5003

You literally measure the resistance of a wire (sensirion doc) in flame, where VOC + Oxygen makes it burn better.

The only difference is that the VOC index shows fancy meaningless numbers.
BME680 produces direct measurements of resistance and it is your job to map it or tune to real-world values in your environment. Ex: For tuned BME680 ~0kOm is heavily polluted and 1000kOm fresh air from outside.
(you can configure its temp/time of burn, to choose what to measure and how).

With SGP40 there is no configuration, actually just a 16-bit number, which can be mapped in the same way. The only difference is that by datasheet it looks reverse mapped, closer to 0 - cleaner.


Also, note some limitations:

So, again:

  • VOC Index - meaningless
  • You should not convert to a VOC Index if you wish to compare or measure something.
  • You should measure sensor values under known conditions to have an idea of what they mean.
  • To know if you really need temperature/humidity compensation - again it is preferred to measure raw values under known conditions.

There is no issue with an external VOC library because it is not needed.
There is no profit from the sensor if you do not spend time to at least get to know what it shows.

The only good analogy that I come up with, is the belt tensioner tool:


VOC sensors are really like this one. There is no general way to convert values from measurements in mm to real tension.
Or like a humidity sensor without temperature, you can say you have a 60% relative humidity and I have a 60% humidity, and they are very likely unequal underneath by several times in absolute humidity values.

If you want an analogy for the VOC index - imagine your thermistor will show the temperature difference between a cold start and “now”. Not 240 degree, just +220 degrees. You hit FIRMWARE_RESTART and now it is 0, and after cooldown -200.


You can spray the sensor with isopropyl alcohol, it is harmless, but you will get the idea of a “polluted” value from the sensor.

2 Likes

I know this. You measure VOCs on indirect response of metal oxide.
I have both sensors, bme680 and spg40+bme280.
If I put them into a voron chamber and I start to print ASA or ABS, BME680 offers less response than the SGP40. In sgp40 I do not use the value index, I use the raw value.
You measure VOCs in an indirect way, in this case by detecting organic compounds on a metal oxide. It is not about measuring the absolute value of the carcinogenic organic compounds that the printer produces but rather detecting their presence or absence. What I have verified is that the response of the bme680 is much lower than the sgp40 and the former sometimes gives random values. There are many organic compounds, what I am looking for is a sensor that gives a broad response to the chemical compounds that we may have inside the printer chamber.
ABS has two compounds that must be taken with special care, butadiene, which is a compound that causes cancer, and styrene, which is an endocrine disruptor.
If we had specific detectors for these compounds it would be wonderful, but with these sensors we can have a reference of what is inside the chamber.
I have a nevermore and two side The filter installed, one of them modified with a hepa filter. I also have an 8x8 LED matrix. When the value that the sensor gives is that there is a presence of contaminants, I activate the filters and put a red smalie on 8x8 Led matrix and it maintains the color until the value drops below a certain value, which turns yellow.
The idea is to adjust the values ​​until it is as safe as possible to open the chamber once the printer finishes its job.

There is a lot of established work proving out the use of these sensors for measuring VOCs in printer chambers:

(I’m not allowed to post more links.)

I wonder what’s the use case for a VOC sensor in a printer.
Just display in the web interface? Or is anyone gong to contorl fans based on VOC?

I’m also going to place a VOC sensor near the printer, but it would be linked in HA to a air purifier, the printer has to just print.

Yep, that was my intention to implement this sensor to mainline Klipper.

Yes, for nevermore filters the relative values between in and about will be important (when I read it correctly). I will test a “display_template” to do this only with mainline Klipper functions.

Yeah, adding a new requirement to all of Klipper for a single rare sensor doesn’t seem ideal. If it’s possible to implement the conversion with some math in sgp40.py that seems like a better option. Usually the sensor documentation will describe the math one can use (see klippy/extras/bme280.py for an example).

As to the sensor being useful or not, I don’t know enough about the sensor to make any comments.

Cheers,
-Kevin

thx for the answer and the example. I will refactoring it, update the PR and will finish the PR with docs.

I wonder what’s the use case for a VOC sensor in a printer.
Just display in the web interface? Or is anyone gong to contorl fans based on VOC?

Monitoring intake vs exhaust VOC readings is a good way to know when to replace filter media.

Oh ok, and that’s something that klipper should do? it sounds like a task for an external monitoring, like ESPhome, home assitant and the like, which works already without having to review+merge anything into klipper.

Considering the perennial scarcity of reviewers and the many (actually) print-related features waiting for review, this doesn’t seem to me a good use of time… since it works already, just not using klipper itself.

1 Like

Thank you very much for all your input! I refactored my PR and implemented the VOCAlgorithm directly in the sgp40.py.

I would greatly appreciate it if others could test the implementation and provide some feedback.