The wheel can move slowly. Every time a beam is established there's one clock pulse. You don't have to spin it like a top.

The approach I'm envisioning is having the sensor and wheel. Those wheels come in many configurations. The illustrations have 33 to over 50 windows. You can get them with hundreds of those marks. They're much smaller.

So the wheel slowly rotates as the weight of water in the bucket opposes the spring tension. As the weight increases you get a pulse every time a window opens. The electronics would consist of something like a decade counter and an encoder that would produce digits. For higher number counts you would need two decade counters and as many encoders as digits you want. Or, since microprocessors are NOT my forte you could program a controller to count the openings and give you a readout. When the bucket is drained you can disable the counts until the bucket has fully emptied and the weight of the bucket has returned to the zero point. OR you can use a large enough capture vessel, one that won't need to be reset until rain tops 20 inches. When the storm is past you reset the system and measure again.

It's a great idea, though it would take a lot of training for me to learn how to make all that. Would be great if there were at least partially pre-built components. Example, an LED, phototransistor and counter all together with an I2C output. Connect 3 or 4 wires to a Raspberry PI, execute a script and numbers are flowing on the screen. The more "plug and play", the better. I'm just not mechanically and tech savy enough to know how to source all kinds of random components, what specs they need to have, wire them all together in the proper way, make them all communicate with each other, etc..

Not having to empty until the rain is over would be a plus. That would prevent the need of the top solenoid.

As for measuring snow - that's a whole different animal. Or maybe not. If you're measuring the weight of the apparent water weight then inches of snow won't matter to you. 10 inches of snow can have the same weight as 1/4 inch of snow. Just depends on how wet the snow is.

Weight of the snow pack is all I need directly from the rain gauge. Snow depth on the ground would be obtained through a different method and a script would combine the values to determine snow depth to liquid ratio.

 

It's a great idea, though it would take a lot of training for me to learn how to make all that. Would be great if there were at least partially pre-built components. Example, an LED, phototransistor and counter all together with an I2C output. Connect 3 or 4 wires to a Raspberry PI, execute a script and numbers are flowing on the screen. The more "plug and play", the better. I'm just not mechanically and tech savy enough to know how to source all kinds of random components, what specs they need to have, wire them all together in the proper way, make them all communicate with each other, etc..

Not having to empty until the rain is over would be a plus. That would prevent the need of the top solenoid.



Weight of the snow pack is all I need directly from the rain gauge. Snow depth on the ground would be obtained through a different method and a script would combine the values to determine snow depth to liquid ratio.

I was referring to that earlier. The weight to snow depth coefficient can vary I think. You could look into that anyway. I think it has to do with big crystals vs small crystals. This is like trying to measure different shape spaghetti noodles using a liquid measure.

 

I was referring to that earlier. The weight to snow depth coefficient can vary I think. You could look into that anyway. I think it has to do with big crystals vs small crystals. This is like trying to measure different shape spaghetti noodles using a liquid measure.

It absolutely does..... 1 inch of water can be 5 inches of snow or 50 inches of snow, depending on how dry or wet the snow is. Same applies to weight, since the weight is based on the liquid amount only.

For simple math, say 1 kg of weight in your gauge equals 1 inch of rain. If your snow weighs 1 kg, then that snow would melt to 1 inch of water. No matter if that snow is 5 inches deep or 20 inches deep. That's actually part of what we're trying to measure. We first measure the depth of snow on the ground. Then we measure the liquid equivalent (how much rain it would have been if the weather was warmer), then we divide it out to make a snow to liquid ratio (to tell us how wet or dry the snow was)....

 

Was just perusing the website and saw this thread. After reading all the advice I'm left wondering why you need such high accuracy. The difference between 0.1 and 0.01 may seem like a big step. But 0.01, 0.02, 0.03, and on up to 0.1 may be 10 steps but do you really need to be that absolute in your measurements? Rainfall in tenths seems reasonable.

 

It absolutely does..... 1 inch of water can be 5 inches of snow or 50 inches of snow, depending on how dry or wet the snow is. Same applies to weight, since the weight is based on the liquid amount only.

For simple math, say 1 kg of weight in your gauge equals 1 inch of rain. If your snow weighs 1 kg, then that snow would melt to 1 inch of water. No matter if that snow is 5 inches deep or 20 inches deep. That's actually part of what we're trying to measure. We first measure the depth of snow on the ground. Then we measure the liquid equivalent (how much rain it would have been if the weather was warmer), then we divide it out to make a snow to liquid ratio (to tell us how wet or dry the snow was)....

I never argued against that. If you weigh the water than you can say how much snow of a particular density you have, but you can't know the depth from that alone. You need some sort of conversion factor if you want to give the depth of snow.

 

Was just perusing the website and saw this thread. After reading all the advice I'm left wondering why you need such high accuracy. The difference between 0.1 and 0.01 may seem like a big step. But 0.01, 0.02, 0.03, and on up to 0.1 may be 10 steps but do you really need to be that absolute in your measurements? Rainfall in tenths seems reasonable.

In terms of one particular rain event, a few hundredths does not make much difference. But those minor differences build up over time and can make a noteworthy impact on seasonal/yearly rain totals.

Example, say your gauge reports 10% low. If it rains 1.00" in your gauge, your actual total would have been 1.10"...Not a big deal. But suppose your yearly total is 75 inches by that gauge. Your actual total is 82.5" ( 7.50 inches underreported)...

Obviously, the more rain an area gets, the more significant of an issue this is.

I never argued against that. If you weigh the water than you can say how much snow of a particular density you have, but you can't know the depth from that alone. You need some sort of conversion factor if you want to give the depth of snow.

Right, but we're not trying to calculate the depth from these numbers. We measure the depth directly by either manually placing a ruler into the snow or by using something like an ultrasonic sensor to measure how deep it is. Then we determine how much liquid it would have been by either measuring it's weight or melting and pouring into a beaker. Then we use those 2 measurements to calculate how wet or dry the snow is. Our end measurement is in terms of "inches of snow per inch of rain"...

10:1 (10 inches snow per 1 inch of rain) is an example of a wet snow....20:1 (20 inches snow per 1 inch rain) is an example of a dry snow...

So lets say my ruler (or ultrasonic sensor) shows the snow is 3 inches deep. The weight in my rain gauge corresponds to a liquid amount of 0.25 inch..... 3 / 0.25 = 12....So my ratio is 12:1 (that is, if it had continued snowing until it reached 12 inches deep, my liquid would have been 1 inch)...A 12:1 ratio means a semi-wet snow...

Suppose another day, I measure 6 inches deep of snow and my rain gauge shows a liquid equivalent of 0.30"....6 / 0.30 = 20.... A 20:1 ratio is a somewhat dry/slightly powdery snow...

That "X snow : 1 rain" ratio is what I'm trying to calculate for each event, using the depth value provided by my ruler (or ultrasonic distance sensor) and the liquid equivalent provided by my weight-based rain gauge.

 

In terms of one particular rain event, a few hundredths does not make much difference. But those minor differences build up over time and can make a noteworthy impact on seasonal/yearly rain totals.

Example, say your gauge reports 10% low. If it rains 1.00" in your gauge, your actual total would have been 1.10"...Not a big deal. But suppose your yearly total is 75 inches by that gauge. Your actual total is 82.5" ( 7.50 inches underreported)...

Obviously, the more rain an area gets, the more significant of an issue this is.

The laws of statistics predict that your 0.49's and 0.50's will average out. If you take 1000 people and give each a penny to flip, have them all flip their pennies at the same time - "Statistically" you will get nearly 50/50. The minor variances are almost meaningless. "Almost"! Suppose you got 51% heads. Now you take those pennies and give them back to the flippers and have them do it again - statistics predict that you are probably going to get 50/50 again. You might get actually 51% heads. Overall, you're right where statistics predict you'll be.

A variation on the penny flip predicts that if you take 1024 people and have them flip their pennies, then everyone who got tails are dismissed from the trial. Now you're left with 512 people. Have them all flip their pennies and you will get half heads again. So now you have 256 people with tails. They're dismissed. Have the remaining 256 flip their pennies again and statistically you're still going to get a 50/50 split. 128 poeple get heads and 128 get tails. Dismiss the tails again and do the flip again. Now you have 128. Do the same thing again, 64 people have consistently gotten heads. Do it again. 32 heads. Again? 16 heads. Again, 8, 4, 2 then finally you WILL have one person who flipped the penny and got heads 100% of the time. THAT is statistics. But in your measurements you will never be off more than 1 least significant factor. Excel will calculate dollars and cents to two decimal places. You might get two inputs of $0.494. Each individual be represented as $0.49. But if you add the two together, $0.494 + $0.494 = $0.998. But Excel will return $1.00. Your point about drifting error is valid. However, there are equally as many chances that you will get an equal amount of $0.495 which will come back as $0.50. The errors to both sides will equal each other and negate the errors.

 

The error you talk about will only be significant if you cherry-pick the stat's. The penny experiment deliberately picks out the heads and discards the tails. Your rain gauge will not be picking out those readings that are slightly less than the least significant value. You will get some that drop the least significant while you will likely get an equal amount of measurements that include the least significant value in the overall calculations.

Like I said, if you cherry-pick the data you can get a growing error. But over time that will be self correcting.

 

I agree with @ThePanMan. The pluses and minuses will cancel out each other.

 

I get what you're saying, and in a perfect world where some rains are a little over and some a little under, they could cancel each other out. But unfortunately, that does not work for the tipping bucket style rain gauges because you're not dealing with just 2 numbers and 50/50 odds of getting one or the other. We try to calibrate them for that perfect middle spot hoping that the pluses and minuses cancel out, but the numbers rarely balance out. One rain may under report by 10%, the next may over report by 5%, etc...At the end of one year, your yearly total may be 8% high, the next year 6% low. It all depends on the number of rain events you have, the number that were pluses vs the number that were minuses and how significantly plus or minus each one is....

 

Most digital, consumer rain gauges use the tipping bucket design where the tipping buckets fill with a known amount of water (typically the amount that corresponds to 0.01" inch or either 1mm, depending on region), then flip over to dump the water while triggering a reed switch. It's a simple and low cost design, but accuracy is +/- several percent, at best as it's sensitive to rain rate, etc.. For that reason, they're often not accepted for official measurements (ie. the Cocorahs program with the United States National Weather Service requires the use of a manual rain gauge, but they do allow you to weigh the collected water contents on a kitchen scale for precise accuracy.)

This got me thinking of affordable ways to more-accurately automate the process by scrapping the tipping buckets for a weight-based approach using load cells and a Raspberry Pi....But it's not without drawbacks of it's own, which I will point out later...

My initial thinking was using an upside down bucket with a funnel as the rain entrance. Water flowing out of that funnel then passes through a normally-open solenoid, drains into a PVC pipe, which has a normally-closed solenoid on it's bottom so that water is stored inside the PVC pipe. The PVC pipe is mounted against a piece of flat board with load cells connected. At a given time interval (say once per day) and/or at a certain rain amount (before the pipe fills), the system automates the emptying process by applying voltage to the 2 solenoids. This causes the bottom solenoid to open, draining the stored water out of the pipe, while the voltage closes the entrance funnel solenoid (in case it's still raining, that rain will be temporarily stored in the top funnel)...After a few seconds/minute (long enough to empty), the power cuts off to the solenoids, closing the bottom solenoid and opening the top solenoid.

Sketch:

View attachment 353472

Sketch while collecting and weighing rain:

View attachment 353473

Sketch During Emptying:

View attachment 353474

As alluded to earlier, there are some issues with the design...Most significant being "load cell creep" where the weight values drift over time when the cells are under constant load. There could also be drift due to temperature, humidity and other environmental changes.

A potential work around could be to automate the tare function frequently to zero the scale before any drifting occurs and use a script to log the values before each tare which it can add for calculating daily rain. It would also have to tare after each emptying phase completes.

The size I would need to make the gauge depends on the significance of this drifting. Example, I would prefer it to be accurate to the nearest 0.01" inch...If I use an 8 inch (~25cm) diameter collection funnel, that would be approximately 4 grams of water weight for each 0.01".....Larger diameter collection area would mean a greater weight in grams per 0.01" (thus the more weight error I could stand while maintaining the needed accuracy)...On the flip side, the larger the gauge, the harder it is to work with and the heavier your load (less precision from the load cell)...Not having worked with load cells under constant and changing loads, as well as subject to quick temperature changes, I'm not really sure what kind of drifting errors I should expect.

I would also need to figure some sort of switch that could activate by script to send voltage for emptying at the appropriate times.

Interested in hearing other's thoughts on how to make this work and any possible improvements.

Your weight-based rain gauge idea is good. It can improve accuracy over tipping-bucket designs. The funnel collects rain into a PVC pipe. Solenoids control water storage. Load cells weigh the water. Each 0.01" of rain adds a few grams. High-resolution, low-creep load cells are needed.


Load cells can drift over time. Creep, temperature, and humidity cause errors. Frequent automated taring reduces drift. Logging weights before each tare improves accuracy. Using multiple load cells can also help. Environmental protection shields cells from sun and rain.


Solenoids may have reliability issues. A servo or small pump could replace them. A Raspberry Pi automates weighing and emptying. Data can be logged for analysis. This system can exceed tipping-bucket accuracy. You can see this IoT weather station for some more idea. https://www.theengineeringprojects....weather-station-in-raspberry-pi-4-part-2.html

 

Your weight-based rain gauge idea is good. It can improve accuracy over tipping-bucket designs. The funnel collects rain into a PVC pipe. Solenoids control water storage. Load cells weigh the water. Each 0.01" of rain adds a few grams. High-resolution, low-creep load cells are needed.


Load cells can drift over time. Creep, temperature, and humidity cause errors. Frequent automated taring reduces drift. Logging weights before each tare improves accuracy. Using multiple load cells can also help. Environmental protection shields cells from sun and rain.


Solenoids may have reliability issues. A servo or small pump could replace them. A Raspberry Pi automates weighing and emptying. Data can be logged for analysis. This system can exceed tipping-bucket accuracy. You can see this IoT weather station for some more idea. https://www.theengineeringprojects....weather-station-in-raspberry-pi-4-part-2.html

That's basically the idea I'm aiming for.

Using the PVC pipe for storage would require frequent emptying. I've been wondering if I could avoid that by instead using a smaller bucket (smaller than my outer shell bucket) to collect the water, then drilling a 1/4" drain hole in the bottom and gluing a small piece of 1/4" PVC pipe to the drain hole (then solenoid to the PVC pipe)...That way, I could collect several inches in the bucket before it needs dumping and the PVC pipe would only be for drainage rather than storage. If this would work, I could possibly avoid needing the top, normally-open solenoid.

The goal is to attach a temperature sensor against the load cell and let the script on the Raspberry PI adjust for the load cell's temp. If needed, can adjust for humidity too...The creep from constant load is my biggest concern. I've put in an order for some cheap 10kg load cells (resolution 2 grams) to try out. A 10" diameter funnel would be 12 grams for each 0.01"..A 12" diameter funnel would be 16 grams per 0.01".. I may ultimately have to spend more money on a better load cell, but hoping that using automated tare frequently (several times per hour) along with temperature correction will let me get by with the cheaper cells. Will find out soon, I guess...

What do you mean by "logging weights before each tare improves accuracy?" I would have to log the weight before each tare to keep track of how much rain has fallen; Especially if the tare is used several times per hour while rain is collecting. Tare would be used after each empty as well.

The bottom solenoid would be normally-closed and used as a drain. The top would be normally open and used to shut off entrance of new rain during the emptying phase. The bottom drain solenoid could be replaced with a low voltage pump. I don't know how that could replace the top "normally-open" solenoid though...That pump would have to be running at all times, except when emptying, which would wear out fairly quickly. Unless I could somehow use a pump like that to blow air into the entrance line with enough pressure to block the water from entering. That could be a workable solution...

 

That's basically the idea I'm aiming for.

Using the PVC pipe for storage would require frequent emptying. I've been wondering if I could avoid that by instead using a smaller bucket (smaller than my outer shell bucket) to collect the water, then drilling a 1/4" drain hole in the bottom and gluing a small piece of 1/4" PVC pipe to the drain hole (then solenoid to the PVC pipe)...That way, I could collect several inches in the bucket before it needs dumping and the PVC pipe would only be for drainage rather than storage. If this would work, I could possibly avoid needing the top, normally-open solenoid.

The goal is to attach a temperature sensor against the load cell and let the script on the Raspberry PI adjust for the load cell's temp. If needed, can adjust for humidity too...The creep from constant load is my biggest concern. I've put in an order for some cheap 10kg load cells (resolution 2 grams) to try out. A 10" diameter funnel would be 12 grams for each 0.01"..A 12" diameter funnel would be 16 grams per 0.01".. I may ultimately have to spend more money on a better load cell, but hoping that using automated tare frequently (several times per hour) along with temperature correction will let me get by with the cheaper cells. Will find out soon, I guess...

What do you mean by "logging weights before each tare improves accuracy?" I would have to log the weight before each tare to keep track of how much rain has fallen; Especially if the tare is used several times per hour while rain is collecting. Tare would be used after each empty as well.

The bottom solenoid would be normally-closed and used as a drain. The top would be normally open and used to shut off entrance of new rain during the emptying phase. The bottom drain solenoid could be replaced with a low voltage pump. I don't know how that could replace the top "normally-open" solenoid though...That pump would have to be running at all times, except when emptying, which would wear out fairly quickly. Unless I could somehow use a pump like that to blow air into the entrance line with enough pressure to block the water from entering. That could be a workable solution...

When I said “logging weights before each tare,” I meant recording the weight just before the scale is zeroed. This lets you calculate how much rain fell since the last tare. For example, if the cell reads 100 g before a tare, that counts as rainfall. After the tare, it starts counting again from zero. By summing these logged weights, you get total rainfall accurately, even with frequent taring.

 

1 gallon of water weights 8.33 lbs. Or 3.78kg.
1 gallon of water equals 231 cubic inches.
How big is your collector?

 

When I said “logging weights before each tare,” I meant recording the weight just before the scale is zeroed. This lets you calculate how much rain fell since the last tare. For example, if the cell reads 100 g before a tare, that counts as rainfall. After the tare, it starts counting again from zero. By summing these logged weights, you get total rainfall accurately, even with frequent taring.

Got you! That's what I'm hoping to do. Only potential issues I see with this resolve around

1. How stable the weight is
2. How quickly does it drift
3. Do I have to tare so frequently that light rain doesn't get measured

If the weight output is not stable (ie. it jumps around every second by a gram or two even when there's no weight change) then that could be a problem.

Also, if it drifts so quickly that I have to tare every 10 minutes to maintain zero, and it measures to the nearest 2 grams; What happens when there's a light rain that produces 1 gram every 10 minutes? It's not enough to flip the gauge to 2 grams (enough to actually measure) yet I'm zeroing it out before it reaches that measurable amount. A steady light rain all day like that could add up while I keep zeroing before there's enough to measure. Just a possibility I would have to watch for.

1 gallon of water weights 8.33 lbs. Or 3.78kg.
1 gallon of water equals 231 cubic inches.
How big is your collector?

Planning to use a 5 gallon bucket at the outer shell (ie. housing that protects the electronic connections from water)...Was thinking maybe a 2 gallon bucket inside as the actual collector. A 2 gallon bucket would hold 7.56kg which would be 6.3" of rain using a 10 inch diameter funnel (or 4.7 inches using a 12 inch diameter funnel)...But if using a 10kg max scale, that would only allow 2.44kg (~ 5 lbs) before maxing out the gauge. The weight of the container, pipes, solenoids, funnel, etc. would all have to be added in as well, which would likely get me very close to maxing out the gauge. So I would probably only be able to partially fill the 2 gallon container before needing to empty in order to keep a fair distance from maxing out on weight.

If I have to use a PVC pipe, I'd probably have to empty every quarter to half inch of rain in order to keep the pipe from overflowing. Doable, but would definitely need the top solenoid because we can get 2 inches of rain in one quick few minute downpour here (tropical environment)...

The top solenoid is one of the costliest parts of the project, so skipping it would be a noteable cost savings. Plus one less mechanical part of potential failure...But no way to skip it with a PVC pipe, and can't guarantee to never need it even if using a 2 gallon bucket. In a hurricane, we could get 12 inches of rain in a few hours which could fill that 2 gallon bucket twice, so no way to get around not emptying in a situation like that. Rare, but I'm only 100 miles inland from a tropical ocean and we have had a few direct hurricane hits over my lifetime. Even an indirect hurricane a few years back that caused over 20 inches of rain in one day. So I guess I'll have to go with the top solenoid regardless, just based on our history of extreme rain events. Even though it may be 10 or 20 years before getting a rain of that magnitude, but the next one could just as easily happen next month or next year. You never know.

 

Hire somebody to stand out in the rain with a measuring cup and umbrella

 

Had a shipment of cheap load cells arrive yesterday. Will see how it goes.

Also had some time of flight sensors, ultrasonic sensors, relays, multiplexers, temperature sensors, etc. arrive with the load cells, so I've got a bunch of toys to play around with.

Just spent the better part of 2 hours soldering about 100 microscopic header pins What a pain that was! First time I've ever attempted soldering those. They're not the prettiest, but hopefully the joints are solid enough. Wouldn't be as bad if the parts were larger, but when your whole circuit board is the size of a finger nail and you're trying to solder some 10 different pins onto it, it's a challenge. Even worse considering I have poor eyesight!

 

Had a shipment of cheap load cells arrive yesterday. Will see how it goes.

Also had some time of flight sensors, ultrasonic sensors, relays, multiplexers, temperature sensors, etc. arrive with the load cells, so I've got a bunch of toys to play around with.

Just spent the better part of 2 hours soldering about 100 microscopic header pins What a pain that was! First time I've ever attempted soldering those. They're not the prettiest, but hopefully the joints are solid enough. Wouldn't be as bad if the parts were larger, but when your whole circuit board is the size of a finger nail and you're trying to solder some 10 different pins onto it, it's a challenge. Even worse considering I have poor eyesight!

How many of these things do you have to build?

 

How many of these things do you have to build?

The plan is one weather station for myself. But I bought extra parts for a few reasons:

1. Cheaper to buy in bulk
2. International shipping takes forever, so I wanted extra replacement parts on hand for quick repair if something breaks
3. If something is not working correctly during building, I can swap parts around to help narrow down the problem.
4. Can put together more than one design and compare their results side by side to see which design performs best (ie. a snow depth sensor using ultrasonic next to one using laser)

Note, as a secondary part to the rain gauge, I would like to solve another issue with weather stations on the market, which is drifting humidity sensors when exposed to high humidity for extended periods. This involves artifically heating the humidity sensors to keep them from long term, continuous saturation. There's 2 options for that; One using a single temp/humidity sensor with brief heated pulses between observations, allowing them to cool down/adjust before taking a measurement. The other being 2 temp/humidity sensors with one continuously heated, let the script use psychrometric equations to derive a dewpoint from the heated sensor and apply that against the unheated temperature sensor to derive relative humidity.

In any event, I wanted all my extra parts soldered and ready, so that they're plug-and-play if/when needed.

 

Update for those following along...The verdict is still out and lots of work to be done, but some encouraging news...

I have set up a cheap 10kg load cell between 2 wooden blocks and wired to a Raspberry Pi Zero 2W...I calibrated and left the scale empty for a few hours and the values were staying within 2 grams (most of the time within 1 gram)...I then added 3 pounds and let it sit for about 4 hours. It maintained it's accuracy still within 2 grams...Of note, some of this appeared to be thermally related as it would start drifting downward when my air conditioning cycled on and instantly start increasing back once the AC cycled off. So temp compensation would definitely help.

I then put 10 pounds of weight on the scale and the results were a little less impressive as the values immediately started drifting downward (by about 10 grams after only a few minutes)..My temporary mount was a bit wobbly, so perhaps the issue was simply this much weight requiring more-stable mounting.....Will work on better mounting to better test the limitations in terms of higher weight.

Either way, the fact that the results were stable to the nearest 1-2 grams for the first few pounds over several hours is a very promising sign. Keeping in mind that even an 8 inch diameter gauge has 8 grams per 0.01" rain, so a 1 or 2 gram error range is still well within the limits of the needed accuracy.

Bigger gauge only improves the possibilities...An idea I'm experimenting with is I found an old top plate to a bird bath in the shed that is 15.75 inch diameter. It has about a 5 inch diameter opening in the center where it mounts to the post of a bird bath. I got some Gorilla glue and glued a cooking funnel over that hole. So far it's sealing it water tight to where water added to the bird bath plate flows out of the funnel...I've also found some old containers that I saved (milk jug, clothes detergent containers, etc.) that I could use as temporary collection containers. For that size catch area, each 0.01" would be about 31 grams...Which also means about 3.1 grams for every thousandth of an inch of rain (which is potentially doable based on my initial 1-2 gram error range)...Would be cool if a "modified bird bath" could become a digital rain gauge accurate to the nearest thousandth of an inch!

Granted, there's still a number of issues to work through before having something permanent.

1. Temperature compensation. I've got an SHT31 sensor mounted right next to the load cell. But the metal load cell reacts quicker to temp changes than the air, so there's a bit of a lag. One option may be to include some kind of insulation (foam, bubble wrap, etc.) around the load cell and temp sensor so that even a fast change in outdoor air temp gets slowed....Another option is mounting a temp sensor directly to the surface of the load cell. The SHT31 sensor that I have is embedded in a small circuit board that's full of capacitors and other electronics, so it will be difficult to mount that board cirectly to the load cell without the metal shorting out the other electronic components. Perhaps a temp sensor inside a probe would be easier?

2. Connecting a larger collection container to a solenoid that uses 0.25" tubing...For the time being, I'm just using my larger containers (detergent, etc.) upside down, a small hole drilled into it's cap, .25" tubing going into that hole and sealing around with the Gorilla glue. Perhaps fine for a tempory solution, but not sure how long it would last....My original goal was PVC pipe, but that's going to require several reducers with pieces of smaller pipe in between each reducer to gradually taper down. Hard to do in a small space..This would be a great time to have a 3d printer! Starting to wonder if a pump may be a better idea for emptying than a solenoid (pump motor at the top of the container with a hose running down to the bottom that sucks the water up and then out through a second tube.