Dry / Wet Bulb feature request

[eap904]

Is there a way to use 2 temp sensors and designate 1 as a wet bulb, and have it calculate RH?

I've used BME280 and DHT 22 sensors, both of which have trouble recovering from condensing fog which is optimal for mushroom pinning. Simple wet/dry bulb temps should provide an accurate and durable solution.

[kizniche]

How is this performed?

[eap904]

basically you measure the dry and 'wet' temperatures [cover one sensor with a wick that is connected to a reservoir of water] then you can calculate the RH based on this difference.

http://web.uconn.edu/poultry/NE-127/NewFiles/psychrometric_inset.html

[kizniche]

I can add a new section that can be something like "Input Manipulation" that can take several inputs and perform specific maths on them, such as, for this purpose, using a pressure measurement, and two temperature measurements (wet- and dry-bulb) and calculating a humidity that would be saved in the database for use elsewhere in Mycodo.

Do you have a concise equation to calculate the RH? Perhaps already written in Python?

[eap904]

I will look and see if there's already some implementation of it, otherwise I'll find an equation to use. Thanks

[kizniche]

I was able to successfully implement a new Math controller type that I can start adding modules that will allow different types of manipulation to Inputs. I currently only have available an option to Average inputs. I think this could be a good module to add, if we can come up with a good equation to use.

[eap904]

Thanks, I will scour for an equation as soon as I have a few minutes to do so

[kizniche]

I found this library that seems to work nicely https://github.com/wlong007/psypy

[eap904]

Thank you. Sorry I haven't had time to help look.

On Dec 7, 2017 11:39 PM, "Kyle Gabriel" notifications@github.com wrote:

I found this library that seems to work nicely https://github.com/wlong007/psypy

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kizniche/Mycodo/issues/335#issuecomment-350170482, or mute the thread https://github.com/notifications/unsubscribe-auth/AcnPx2b2aN17AoHU2IvjGSszcr5h5aXGks5s-L11gaJpZM4Qv-1Z .

[kizniche]

I implemented the library I mentioned above. It's working fairly nicely, calculating relative humidity (%), humidity ration (kg/kg), specific enthalpy (kJ/kg), and specific volume (m^3/kg), from inputs of dry-bulb temperature and wet-bulb temperature, with an optional pressure input. Below I have all the calculated values showing on a graph with the dry- and wet-bulb temperatures and pressure being used for the calculations. It's a little chaotic-looking with all the measurements on the same graph, I'm just showing it for demonstration purposes.

[kizniche]

I haven't made a setup with a fan, so I'm just using two different temperature sensors for now, so the calculations will not be correct. I'll try to get a setup made soon to see how the calculated humidity compares to my other two humidity sensors.

[kizniche]

If it can be determined which equation we can modify to change the airflow speed, in psypi.py, then I will add that as an editable variable.

[eap904]

This is exciting. I did not know it relied on an airspeed input but yes a small computer fan seems like it would suffice. Thank you thank you

[kizniche]

Airspeed might be negligible. It at least isn't an editable variable in the library, so I don't think it's crucial to add it at this point. Once one of us can get a test setup going and see how accurate it is, we can decide at a later time to look for it and maybe add it. I wasn't able to find a full copy of the ASHRAE 2009 that's referenced for the equations in the library, so I couldn't really understand what their generic variable names are.

If you would like to test it, I'll make a release to allow upgrades.

[eap904]

I would like to test it for sure. I think it will take about a week to get it going but will definitely get on it. Thanks

On Dec 8, 2017 9:24 PM, "Kyle Gabriel" notifications@github.com wrote:

Airspeed might be negligible. It at least isn't an editable variable in the library, so I don't think it's crucial to add it at this point. Once one of us can get a test setup going and see how accurate it is, we can decide at a later time to look for it and maybe add it. I wasn't able to find the ASHRAE 2009 referenced for all the equations in the library, so I couldn't really understand what their generic variable names are.

If you would like to test it, I'll make a release to allow upgrades.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kizniche/Mycodo/issues/335#issuecomment-350416970, or mute the thread https://github.com/notifications/unsubscribe-auth/AcnPx3_82yWUitsEFiy10N8Lbfsz51Ueks5s-e9HgaJpZM4Qv-1Z .

[kizniche]

Just released v.5.4.15 and successfully tested the upgrade to it.

[kizniche]

Using this calculator, and inputting my temperatures and pressure measured with Mycodo, the Mycodo percent humidity calculation came out exactly what the calculator yielded.

[eap904]

Was finally able to start playing with this... got the calculator up and running... Mycodo Humidity calc was reporting about 73%, while this analog hygrometer was around 63. Need more testing, also need to re-calibrate the analog hygrometer.

For some reason I had to manually deactivate and reactivate the math controller for it to start plotting on the graph after a reboot.

Time will tell, also need to devise a water reservoir. Might be nice to have a calibration or offset, so if the number that calculates is consistent, it can be tweaked to the 'actual' number

[kizniche]

I'm willing to add any type of variables or other ways to adjust the controller to make it more accurate. Do you have a sensor that can return the pressure so it may be used as the pressure input of the controller? I'm not sure how much this would affect your humidity, but I suppose that would depend on the pressure at your location.

I'm not sure about restarting the controller, but I do have the controller only make the first calculation after the first period (seconds). This is due to when the daemon starts up there are no measurements from the sensors for the controller to make a calculation from (if it tried when the daemon first started, it would cause an error "no measurements available"). This can be perceived as the controller not working if one isn't patient enough.

[kizniche]

It also looks like both your temperature sensors are very close to each other. I would separate them so the dry bulb is not in any moving air currents and only the wet bulb is in the moving air current.

[kizniche]

Also, there is a bug/feature that if there has never been any data for a particular controller/measurement, and the graph page is loaded, then the data starts being acquired, the graph page will not show that data. You will have to refresh the graph page to start seeing it.

The way that works is it will continually cycle the same number of measurements as new measurements come in. As 1 comes in, it will drop the last one. So, if there are 0 measurements, if one comes in, it will drop one, which is the one that came in. Weird, I know. So, if you load the graph before there are any measurements to pull from the database, it will appear as thpught there are no measurements coming in. In actuality, the graph is just adding and dropping the same number of measurements every update period.

[kizniche]

I had my Humidity Math controller crash. The commit above is a fix for that issue.

[eap904]

Interesting to learn how it works. I had dry and wet bulb data for a period of time but no math showing up.

Can it create data from past temp readings? Just in case something goes wrong?

Only reason I think it's important is for the end goal of controlling equipment with readings, needs to be reliable.

You're right about the sensors, I wanted them in the same area but that's a little too close. Will do more testing soon

[kizniche]

I had dry and wet bulb data for a period of time but no math showing up.

There's a bug I fixed, that still exists in your version until I make a release, that allows the math controller to crash. Check your daemon log for errors. If you are experiencing different errors than I was, I'll investigate and correct the issue.

Only reason I think it's important is for the end goal of controlling equipment with readings, needs to be reliable.

The Math controllers should be as reliable as the Input controllers. That is, the only thing that should stop it is if there's a sensor issue.

[eap904]

Thank you for the great work Kyle.

[eap904]

So I've been using this implementation of the humidity calculator. You can see my wet bulb reservoir, and on the right, one of many sensors dangling is the dry bulb.

Has been interesting to observe. When I took this picture the controller was reporting 92%rh, while my existing humidity controller was showing 95.

There are times when the RH reported is over 100%. This may be an error in my implementation, but also may be a lag in the wet bulb reservoir temp adjusting to quick temp swings. (Temp drops / rises 10 deg with the sun)

Also I find it extremely useful to look at asynchronous graphs as the live graphs often seem to have random periods of time you can actually load, and the math controller option isn't available in the asynchronous graph section.

[kizniche]

It looks like your wet-bulb sensor is submerged in the water reservoir with the sock around the sensor. Is there a way you can have just the sock touching the water and the sensor and sock covering it out of the fluid and in an air stream? This I believe will produce the best results.

I'm not sure why your RH would read over 100%, but your wet-bulb temperature should always be below the dry-bulb temperature (evaporation of water will cool the sensor, if the temperatures are exactly the same, the RH is 100%). If it goes above the dry-bulb temperature, I'm sure weird things like over 100% RH may result.

Thanks for pointing out the asynchronous graphs don't include Math controllers. I just pushed a fix that adds them, which will be included in the next release.

[zsole2]

I followed this issue from the beginning with great interest. Although I was/am a little skeptical that it can be useful for my project (given the low temperature and high humidity, the temp decrease is expected to be small). Finally my waterproof DS18 sensors have arrived and I could start to work. And I immediately run into a major problem with the sensors. The two are quite different, one is much noisier, and the readings are quite off. The difference now stabilized after a few hours at 8C to be 1.2-1.3C. The two sensors are 2-3 mm apart. This seemed high, but some googling showed that I should not expect too high quality from these sensors, and this kind of variance is possible. A useful site, although I did not read it through. But some of the links are also useful that I quickly checked. So back to the wet bub issue... I think I'll definitely get a few more DS18 to test. But until finding two sensors that are reasonably similar, I think it could be a good practice to set the higher measuring unit as the wet bulb, and use a temperature correction factor in the calculations. Kyle, can you implement this? I believe that would help more to avoid faulty readings (e.g. over 100%) than accounting for either the pressure or the air-flow.

[kizniche]

I can add a Math controller that either adds or subtracts a value from a measurement, then that can be used as the Humidity Math controller's input. I'm sure there are more complex calibrations, using multiple points (low, mid, high, etc.), but this would be a quick solution for most users. How does that sound?

[eap904]

Zsole2 what is your application for this? Over several years of trying different humidity sensors, there is basically no cheap accurate option. They are all supposed to be calibrated to the specific range of RH you are monitoring, and basically none of the widely used ones (I know of) are consistently accurate at near saturation. If you can use the dry wet bulb for your specific application and just find out which measurement corresponds to what you want, it is a far more reliable option than the digital humidity sensors that inevitably break.

I am basically trying to recognize the condition of visible fog in the air. Sometimes it seems even a camera screenshot could control the humidification equipment

[zsole2]

I agree that all humidity sensors are the same (that is being unreliable) at high humidity. I use Mycodo to control repurposed refrigerators to ripen cheese, mostly in the 8-13 Celsius range at 85-95% RH. In these conditions, it had DHT22 sensors malfunctioning within a few months, and had somewhat better results with HTU21D. Theoretically there is a HTU21DF version (if a remember correctly) that has a membrane to protect from condensation, but I could not find them when I was looking. The wet bulb system could be good enough for me, if the temperature precision could be kept around the range of 0.3-0.4C. That is about the precision limit of DS18 as far as I understand, but if the variance between the sensors is bigger than that, than I screwed.

[zsole2]

The math controller shifting measured values seems like a good solution. My worry would be the addition more and more inputs, and all of them is an extra burden on influxd, which seems the performance limiting factor on my PiZeros. I don't envision more complex calibrations for my usage, the temperature range being quite limited.

[kizniche]

I could add an equation field for all Inputs that will accept "x" as the input value and perform the calculation on it, such as "x + 1.234*x*x + 2.345*x + 3.456"

[kizniche]

This would allow a huge range of complex calibration equations to be used but not entail a huge amount of programming. Since there are a lot of calibration methods, I would rely on the user to perform this to yield their equation to correct the sensor error.

[kizniche]

BTW @zsole2, this has been a long and winding rabbit hole 😅

[kizniche]

Thinking about this more, it would be difficult to put an equation field on every Input because many Inputs return several values. It would make more sense to make a Math controller because it can isolate one particular measurement from an Input to affect.

[zsole2]

This equation controller is really helpful, allows to implement all kind of calibrations, which should be sufficient. The link you referenced is the same that I started with. Unfortunately, after checking my sensors this morning, I'm not very happy. Yesterday I rebooted (the graph sometimes lost one of the temp curves, I guess when data got old, I'll try to look into it). After rebooting, the two sensors measured almost the same value, within a 0.2C degrees. Left overnight, the curves are like these: Not very reliable. I'll get a few other DS18 to see the variability. Here you can also see that the green line does not show past data.

[zsole2]

BTW, can we get more than lines on the async graph? In this sensor testing project, it could be very useful to get a long time comparison only just for the sensors. And while I'm at the async graph, is there a particular reason that after selecting an input to show, the selection box resets to the first item? It would be more helpful if it showed the sensor choice that is actually graphed.

[zsole2]

On a closer look (i.e. on e.g. 1h resolution), the green line above looks really noisy, maybe replacing that sensor will help more than any claibration.

[zsole2]

Update on the sensors. I found another DS18, isn't waterproof, but added for testing. Here is the initial run:

It is clear now that the sensor with the black line is quite useless. For the other two, I added a Math Difference. Here is the longer run with these:

This is kind of wavy, but did not want to change too much, and unfortunately the PID is set up for the bad sensor. Now it looks feasible to use these two sensors to start testing the wet-bulb humidity measurements, with the Math Equation to equalize the two readings by adding/subtracting a fix value determined by a long run of the two sensors at their final location within the chamber.

[zsole2]

On more thing... I decided to create a new measurement and unit for the Difference, to be able to use a different scale on the graph. I just did one single test with setting the Y-axis scale, and it is the same for both measurements, which obviously not ideal. This could be added to the list of later enhancements, if there are several y-axes on a graph, all should be able to set their scale manually for different values.

[kizniche]

Setting a manual y-axis for every data series requires a complete overhaul of how graph data series are stored. I don't think it is possible to do a database upgrade for that, so it will have to be a major version jump that will require everyone to manually download and install a new version. The alternative right now is to be able to set all y-axes at once.

[zsole2]

I see. For a major version jump I rather like to see a more streamlined install/upgrade process. It was already a topic of discussion, #131. I think this area could be still improved, but would require a lot of work. It is a little bit inconvenient waiting for compiling pigpiod and wiringpi, as well for checking all the requirements that I'll never use.

[kizniche]

I just thought of a way to allow setting manual y-axis extremes for each y-axis, following the same method I used for graph line colors.

[kizniche]

I had some free time and knocked out the custom y-axis code. You can now set the y-axis range for every y-axis of every graph. Here's a demo:

[kizniche]

You'll notice the actual axes don't hold strictly to the range that's selected. This is due to the graph adjusting so the major tick marks align. I may add another checkbox option to disable this if the user wants a very rigid min/max range without necessary alignment. Thoughts?

[kizniche]

For my own reference, startOnTick: false in yAxis is the option to disable the rounding. With it set to false, the above graph will look like this:

[kizniche]

Okay, I added 3 new y-axis options, Align Ticks, Start on Tick, and End on Tick, so you can customize most aspects and also create some truly hideous scales, such as this:

[zsole2]

That was quick! I'll test soon. Your hideous scale gave me an idea to set the scales to show only if a measurement is out of the preferred range, and see only the peaks. I'm not sure that is useful, but it can be done now.

[zsole2]

Back to wet bulbs...here is the status of continued testing of sensor errors. Both are dry sensor now, next to each other, one of them adjusted by 0.4C: The two temp readings look quite equal, and the deviations in humidity are within 1%, which is probably better than any cheap humidity sensor's. And kind of sensitive, I moved one of them a little bit in the evening, and it shows on the red line. Now I'll have to place the wet bulb correctly and start thinking about wetting it...

[kizniche]

I had a chance to test the Humidity Math (wet-bulb), and it's looking good so far. I'll be able to test a high-humidity environment by next week once I get my humidifier hooked up. The image below has two graphs: the top has two humidities, one from a HTU21D-F sensor and the other calculated from the wet-bulb (two DS18B20 temperature sensors and pressure from a BME280 sensor); the bottom has the temperatures of the wet and dry bulbs. You can see on the bottom when I added water to the sock encasing the wet-bulb and the temperature dropped. This is also when I activated the Humidity Math and can see it begin recording data on the top graph.