Just a note for any Domoticz users who may try this sketch - it presents in the log, but is not available under 'Devices' to be added UNTIL it gets a reading > 0. My solution to that was to go put the node over the gas hob and let the gas run (unlit) for a few seconds so that it generated a reading

I believe it is on the cheap side. These price ranges are mainly for hobbyist sensor. The real calibrated ones are usually way more expensive. The cheap ones are only good to measure trends, not for the actual value.

Sure, the curve is there. I am trying to make sense out of two points curve that is used in sketch for MQ2 sensor, CO gas. "point1: (lg200, 0.72), point2: (lg10000, 0.15)" while I see on the curve from datasheet (lg200, 5.2) and (lg10000, 1.3). That is why I am asking for help, sorry for not making it clear.

Lack of support makes you think, so I figured out the "hidden" calculations in the sketch above and proposing the code modification to allow users to port the code to a different gas sensor using data taken directly from the sensor chart. Here are modified fragments of the code showing only CO curve for MQ2 sensor:

float CO2Curve[4] = {0.8,200,2.2,10};
//two end points are taken from the curve with two coordinates for each point
//in form of{Y1, X1,Y2, X2) where X is PPM axis, Y is Rs/Ro axis from the sensor chart for specifc gas
//then equation X=(Y-b)/m is used,
//where m is slope of the curve, b is Y axis intersept point
float Slope = (log(pcurve(1)-log(pcurve(0))/(log(pcurve(3)-log(pcurve(2));
float Y_Intercept=log(pcurve(1)-Slope*log(pcurve(3);

What I'm saying is that it is not a gas that dissolves in air, it is more particulate matter suspended in the air so an optical sensor is probably better given that the sensor could last as oil tends to stick to stuff

I spent the last few days trying to get a sense out of the black magic behind the calculations used for this sensor.
I got the math now but still there is something I feel like it is not completely accurate with the current implementation.
First of all the resulting ppm seems like a sort of normalized value; since I know e.g. CO2 ppm in clean air is around 400, the code seems not to take this into consideration. Also, configure it with a different MQ sensor doesn't seem an easy task.
For these reasons I've tried starting from scratch, inspired by http://davidegironi.blogspot.com/2014/01/cheap-co2-meter-using-mq135-sensor-with.html#.WyLQo6qFNn5.
Starting point is the power function y = a*x^b. The way to make the code more generic is to let the user provide the coordinates of two points (like @APL2017 was suggesting a while ago) which is an easy task and let the code solve the two equations and derive the values of a and b. Then, since ppm = a(rs/ro)^b, with a known value of ppm (e.g. the concentration in clear air of the gas, for co2 is 411), the equation can be solved for Ro by measuring Rs from the adc. Once a, b and Ro are known, the ppm comes naturally by solving again ppm = a(rs/ro)^b.
I'm not sure this is better than the other methods but at least I get the same results from the blog above, both in terms of values of a, b and Ro as well as a real value of CO2 ppm measured with a MQ135.
The downside of this of course is the difficulty to provide a known value of ppm for the calibration for other gas like e.g. Ch4, but if I claim I'm showing a ppm value, I want to be sure this is a real ppm
The code is here, within the dev branch of NodeManager, any feedback would be appreciated!https://github.com/user2684/NodeManager/blob/19e37a45792be4d698a1316bf6eb4f954a8455f5/NodeManagerLibrary.ino#L2441