I live in an area with known hi-radon gas emissions from ground, so I have just installed a EC fan that is sucking air/gas from underneath my house.
The fan can be controlled by a 0-10V interface, so I have ordered a Qubino 0-10V dimmer for this.
I have three sensors in the house that report the radon gas levels every 10 minutes.
What I want to achieve, is to have the fan run on as low speed as possible, while doing its best to maintain a target value.
The radon gas emission varies very much over a day, normally peaking early mornings, but also it changes over the seasons and weather conditions, so there’s really not “one good value” not even close!
Also the gas builds up over time, so the adjustment system needs to be looking at trends rather than thresholds, I think (?).
For instance, if I power off the fan, it may take a day before the levels are too high, but it could also be a matter of an hour.
In some situations, it may be that the fan cannot keep the target at all, but in the summer, maybe there no need at all for the fan to run from time to time. You get it - the variations are very big.
So, since there’s a lot of knowledgeable people here, I thought I should ask if someone has done something like this - I guess this is a common problem for a lot of controlling equipment, maybe the same for some temperature management systems etc etc.
Any kind of suggestions or pointers welcome.
Cannot offer you real code, but here some ways to get this accomplished.
Preamble:
any real implementation it will depend on how your system behaves, especially how quickly does Rd build up, how effective is your fan at various settings; once you chart fan settings and Rd levels, it will give much more details. From there it is trial and error
for this discussion let’s just assume that your target Rd level is 100:
you will need to decide if you just use the average reading of all three sensors or will take the highest value of all three (or any other scenario)
you may need to play with your dimmer, at very low settings the fan maynot be effective and in reality you may only have a range of e.g., 3-10V; but trial and error will tell. Don’t apply voltage that is too low to make your fan turn for a longer time, it may damage the motor.
Threshold approach:
coming form low levels (check with persistence what the level has been at an earlier time), if you reach 50, you may want to switch on the fan to say 10%, if you reach 75, the fan setting may go up to 30% and at target level, you may want to set it to 50%; at 120% target level you may want to set it to 75% and so on; this scenario presumes that the target level of 100 corresponds to the desired Rd concentration and that the fan is powerful enough at 50% to actually do something…you may need to adjust the values according to your sensor response. Edge case: you may need to deal with hysteresis (endless frequent and quick cycling around any one of the thresholds), for this you would set the value to switch the fan on a little higher than the target and to switch it off with at a little lower level (say 45 and 55 if the value is 50, but this will depend on your systems behavior); as indicated above you may need a persistence service with which you can compare to an earlier timepoint and decide whether the concentration is increasing or decreasing (you could also use a second variable that saves the previous fan setting and compare with that);
Continuous approach:
the fan response is adjusted continuously according to a function that in its simplest form is just a straight line between 0 at 50% and 100% at 150%; in the previous example it is easy (Rd-50 give you desired power setting); in a more general way you can calculate this from this equation: result = (Rd-Conc - lowest_value)/(highest_value - lowest_value), which will give you a response of 1 a the highest level and 0 at the lowest level; edge cases: you will need to make sure that the value does not exceed 1 (or 100%) as otherwise you may receive error (e.g., just test whether the value of the equation above is larger then 1 and if so, simply reset the variable to 1e.g., (if result >1 then result =1)); you will not have to deal with hysteresis here
Thank you for sharing your thoughts!
The continuous approach is probably a good start for me. But I think that it will cause a kind of very low frequency (hours) oscillation; see the fan suction pipe is in the ground, and will suck the radon from the ground. So if it is running at too low speed, the radon will push into house slab. So if the algorithm then increases the fan speed, it will not do anything on the values inside the house, since it is not venting the house. It will take hours for the Rd level to go down “naturaly”. So if the levels are too high, the only thing we “know” is that the fan speed was too low in the past. Not that it is now. But maybe this is a case that needs special attention; if it is outside the normal operating window.
But ideally, I think the solution should count in historic values/average and learn from previous experience. Maybe I’m overthinking this?
I’ll anyway start with the “continuous linear” approach, and log how the fan speed varies over time. Maybe this is perfect and smooth as ever.
Since I just installed the fan, (running it at approximately 50% static, until I get the Qubino 0-10), I don’t know how well it will do in peaks.
I see…sure you could put a learning system on top of OH2, there are efforts described to use neural nets for this;
BUT, it sounds it will take months or years to gather enough data for your system to have all the scenarios it needs to learn. Also be aware that most systems that have so much inertia build in (i.e., are as sluggish as you describe it) are extremely difficult to control (even with more advanced techniques), just because there is such a lag between action (fan) and response (Rd levels going down) and you can even get rather large swinging in the state such systems.
Silly question: why not just let the fan run at 100%…doesn;t sound it takes that much power…
What sensors are you using? I’ve not spent the time to research them yet but something similar is on my list of to dos. I spent just a little time trying to find something that would work or that I could hack to work with OH but didn’t get past a few really old hacking threads.
I do something similar for temperature. I don’t have an AC so I use the temperature differential between the basement and the top floor to drive the heater’s fan to bring that cool air in the basement to the rest of the house.
rule "Turn on the fan when necessary"
when
Member of gIndoorTemps received update
then
// Wait at least five minutes before changing the fan state after the last change
if(vNest_Fan_LastChange.state != NULL && now.isBefore(new DateTime(vNest_Fan_LastChange.state.toString))) return;
// Get the target and upper and lower temps
val target = aNest_TargetTemp.state as Number
val lower = LowerFloorsTemps.state as Number
val upper = UpperFloorsTemps.state as Number
// Determine if the fan should be on or off: upper is higher than lower and the target and it is warm outside
// 1 degree as a buffer
val diff = upper - lower
var String fanState = "Stay"
if(diff >= 0 && upper > target && vWeather_Temp.state > 70) fanState = "ON"
else if(upper < target - 1) fanState = "OFF"
// Change the fan state
if(fanState != "Stay" && aNest_Fan.state.toString != fanState) {
logInfo(logName, "Setting the house fan to " + fanState)
aNest_Fan.sendCommand(fanState)
vNest_Fan_LastChange.postUpdate(new DateTimeType)
}
end
The fan will turn on if the basement is cooler than the warmest of the upper floors temps and it is warmer than 70 degrees F outside. Otherwise we turn the fan off. There is a one degree buffer to avoid flapping. And we wait at least five minutes between making any adjustments to the fan.
Similarly, you can base controlling your fan based on the maximum radon reading I would think. Your condition is a little more nuanced as you have multiple fan speeds to deal with, but the concept is the same. Turn on the fan when the max reading is too high and keep the fan on until the reading drops a certain amount below the target.
You can also base the fan speed on the rate of change. This gets a lot more complicated though because the fan itself will change the rate of change. You would probably need to depend on both the max reading and the rate of change. But I think just the value would be sufficient. As Lipp says, you will probably need to experiment to find the ideal.
The only information you have is inside the house. If those sensor readings lag that much and there is no correlation between the current readings and future readings, which you implied in the OP, there is no information you can use here to preemptively turn on the fan.You need a sensor in the ground or in the pipe so you can turn on the fan when the radon levels are increasing there.
Of course I am probably putting to much thought into this, but it is an interesting problem, I think. The reason for not running it 100% (actually, it sits at about 50% now, is that in the coldest of winter, sucking cold air below the slab is not ideal since, in worst case I have read about the ground being frozen, and also it will of course cool down the slab, and walls. The house is from the '30th, so some parts of the slab is totally unisolated (I dug down to put isolation in large part of it while changing pipes and adding the radon hose.
Yesterday, I received the 0-10V Qubino, so I can hopefully start doing some tests during the week-end.
I’m using the FTLabs RD200 with ESP8266 -> MQTT. Those are among the few to be fast enough to actually be useful in a control system.
I’ll see what I come up with, currenly I’m thinking to let the regulation be put into different operating modes, where the startup mode, simply starts at a known good value, and gradually let it go down over a week or so, until the readings inside starts to go up, then remember that value, and restart from 90% the good value, go down even slower, until the readings starts to go up inside. Then start again at 80% of the known good, and go down and so on, to find a ‘normal/base level’.
Then from that base, try to adjust up down as needed, similar to the temperature control. But maybe this will not work over the full year. I think I should be able to use TOD deviations, since they seem pretty much the same every day (just the amount of radon is changing), but that could be done with a simple fixed look-up table.
It seams that the increase inside comes not too late (a couple of hours afaict), just that the decrease can take a lot of time, days worst case.
I could also add some ventilation control into this, but currently I am not able to control the ventilation from OH - that is still on my todo list. But I also think the ground suction fan logic should be roughly in place before I also mix in the ventilation.
Sure is…and it is fun to play around with these things.
that just makes more life more difficult as in adding more variables (and as you undoubtedly already know)
Either way, whichever way you go there are only a few choices:
either you have enough data to model your system, which ideally means you have some Rd reading from the suction pipe (as this will give you more immediate details), aided with some reading from your house (as this is the point you really want to control) and of course all the details from your fan
or you have to make conservative guesses, such picking a setting that will be too high in most circumstances, but conservative enough that you are protected from excessive Rd most of the time.
As you describe it, your Rd reading in the house do not follow a strict pattern, once they are too high, it takes too long for your comfort/safety for them to go below safe levels, so you need a pre-emptive action level; this will in turn depend on how reliable your senor’s reading at low levels are, levels low enough that if you trigger a fan based on those readings, that considering the inertia in your system, the actions (rampint up the fan) will be an action that is early and decisive enough that it will prevent an overshooting of the Rd concentration. Of course, any machine learning can be applied too here, but you will need data, data, data and as you describe it over quite a long time period just to have your system learn…and then tweak and improve…
Now take into consideration that at the levels of Rd we are talking about here, it is about long-time averages and cumulative effects, so short spikes (within moderation) are not likely to change your risk level much. But ultimately, it is up to you what your comfort level is in this regard.
Taking it all together, this means you have to consider what you can measure and where, what you can control (and where), what your ultimately goal is, how your system responds (how do the controls affect your measurements and in with what lag time), what your comfort level is with fluctuations (above and below your desired target levels), what the cost implications are (you mentioned the poor insulation of your basement, which presumably will affect heating costs) and ultimately how much time and money you want to sink into this. The sum of all of this, will determine the time and efforts you have to put into the solution that works for you.
