If you’re lucky enough to have a swimming pool, well, you may not feel all that lucky. Pools are great to have on a hot summer day, but keeping them crystal clear and pH-balanced is a deep dive into tedium. Sure, there are existing systems out there. They cost a kiddie pool of cash and are usually limited to particular pool parts. Existing DIY solutions are almost as bad, and so [segalion] is making waves with a dumb, brand-agnostic pool automation system called Raspipool.
Sensors for pH, ORP, and temperature are immersed in pool water flowing through a bypass pipe that runs between the filter and the pump. The basic plan is to control the pumps and sensors with a web-enabled Raspberry Pi, and have the Pi send action and threshold notifications straight to [segalion]’s poolside lounge chair. Each piece is dedicated to a single task, which allows for easy customization and future expansion.
[segalion] is trying to get more people involved so that Raspipool can keep really make a splash. Be sure to check out the project wiki and let him know if you can help or have suggestions.
We’re glad [segalion] is building from the ground up, and doesn’t have to dive into some pre-existing mess of an automation system.
Been thinking of building a passive salt water chlorinator.
I’ve had nothing but bad luck with my Intex branded SWG. It would not work at all until I had about three times as much salt as I should have needed, and even then would need constant fiddling. I also had a bad plug connection to the plates overheat and melt things. I got a replacement during the warranty period, but it was just more constnat trouble.
In hindsight, I should have invested in something that automates chlorination doses via liquid. Maybe you’ll have better luck building one, but check out https://www.troublefreepool.com/threads/economics-of-saltwater-chlorine-generators.95581/ for a breakdown of the economics of SWGs.
Sorry that you’ve had bad luck. Our Hayward AQR15 SWG has been perfect for about 4 years now. Just have to make sure we clean (acid wash) the salt cell very regularly.
It will be interesting to see what happens when the power glitches and corrupts the uSD card while it was injecting the muriatic acid. Everyone seems to treat the RPI like a microcontroller.
+1 that!
When I think of these kinds of projects I immediately think that there should be a microcontroler between the RasPi and the device it’s controlling for safety’s sake. Then I usually think about it a bit further and decide the microcontroler can just do it all anyway so there is no real purpose for the RasPi!
A RasPi makes a better computer than a microcontroler. I might use a single RasPi to centralize control, logging and reporting for a household full of microcontroler based projects but never as the microcontroler itself. Too much can go wrong.
The only time I would put a RasPi into a project was if it needed some heavy computing such as a robot using opencv or something like that. Even then I’d stick a microcontroler between the Pi and the motors/heaters/acit pumps or whatever interfaces with the real world. The microcontroler would have limits programmed in to automatically turn things off if the Pi locks up or due to some sort of bug starts asking it to do crazy things.
This kind of design choice is the difference between houses that burn down and ones that do not.
I’ve used exactly this strategy with the Pi before (Coincidentally, it was for pool filter control!). Pi runs the web UI, AVR runs the dangerous stuff.
Mmm. I’d contemplate building this on e.g. an ESP32 (dual UART, as well as enough IO for the other sensors and relays). HASS on the Pi, by all means, but with specific instructions for the ESP, not “turn on bleach pump”, but rather “dispense 300ml bleach”, allowing the ESP to control the volume dispensed.
You could always place a “shield” on the Pi w/ a microcontroller receiving routine serial commands and defaulting to a safe condition in the event the Pi goes off the reservation.
+1
And beyond that, web enabled? poolside control? Why?
I hope the project does everything the creator wants, but to me automation means never having to think about it.
Simple (fairly bullet-proof) microcontrollers for each automated function is certainly how I’d approach it.
FYI leaving the pH probe in the tested sample all the time will destroy it…
Yes, that seems to be the reason for the OP saying that the probe will have a lifetime of 1-3 years. Would it be better to drain the pipe when it is not actively testing it?
I’m wondering why the OP was so specific about the bypass being the lowest part of the system, so that it never drains? I guess a powered sensor that is not in a sample (i.e in air) will also destroy itself?
I have solar panels on my roof, so have a substantial vertical drop in my piping. I wonder if inserting a vertical bypass in parallel with the drop, with a solenoid valve to flood or drain the pipe would be an option. The piping currently has a one-way valve on the up-side to allow the panels to drain when the pump stops. I suspect that having a similar valve on the down side, allowing the top valve to be closed, but the bottom one open, would allow the bypass pipe to drain and be filled with air, hopefully prolonging the lifetime of the sensors. You may need a level sensor above and below the ORP and pH sensors, though, to be sure that the water has either drained, or that the sensors are covered by water before turning them on, depending on their requirements.
Letting the probe dry out is even worse… At the very minimum, you’d have to immerse it back into the storage liquid (a clean solution of some salt).
Even better would be to periodically clean it with the manufacturer specified solution (different for different contaminants)
Ah, that’s good to know. I’ve never used these sorts of probes before, so have no idea.
Just make sure the probe you buy is meant for process streams rather than benchtop use. Liquid electrolyte probes quickly drift beyond usefulness, get fouled, or otherwise breakdown. Generally you want a gel/polymer based electrolyte but some expensive transistor based sensors exist.
With some additional work, this could be used to automate aquariums too.
My thoughts exactly, especially marine aquariums that need monitoring of pH, ORP, Ca, Temp. There are several manufactures out there that sell these control systems that I am sure have similar hardware.
It seems like (maybe with some slight modification) this would be useful for monitoring for fish tanks, too.
First of all, lot of thanks @Kristina for your great report. You write really well.
@Xeon and @Pete: I would like to has a control for SWG in this project. But with the actual project you can do that, now: you can connect the bleach injection relay to start/stop the SWC, and configure raspipool with “bleach concentration = 1.75%” and then aproximate the “gr of chlorine per hour” of your SWC with same “ml/min”.
@mike: Acid tank, tube injection and peristaltic pump, has to be in very safe position (not only far from the (IP65) box containing the RPI and circuits, but also far from the pump and other parts… My recommendation is to dilute the muriatic acid in half (for example to 10%) to extend the life of the peristatic pump.
@Philo of Zarquan: I cant find any reason why a microcontroller is safer than RPI. I have thought a lot about the decision to use an RPI instead of a microcontroller and I could talk a lot about it, but the simple summary can be found here https://github.com/segalion/raspipool/issues/1#issuecomment-530335050
@Rogan Dawes: Really, raspipool read the ORP, calculate de Free Chlorine, and calculate the ml bleach needed for your pool (depend on size pool, pH and bleach concentration), and turn on the pump the seconds needed to inject, and when to do it. The same with the muriatic acid. The system send to your mobile (pushbullet in project, but can be other like instagram, hangout, or whatever notification system suported by HA) all dayly injection neededed . Moreover, it take into account the tanks level remaining… notifying when in low levels.
@AKA the A: I think is the opposite: pH and ORP probes must always be wet. If they dry they spoil
@peterlarson233: absolute sure.
A Raspberry Pi is less safe and less accurate because it runs a complex multi-tasking operating system.
We are used to thinking of multi-purpose computers such as the ones we are communicating via right now and also Raspberry Pis as being capable of doing several things at a time. In actuality, at best (and this is being generous) in any given instant these devices can only do as many things at once as they have cores. They only appear to be doing more simultaneously because they are constantly switching between tasks so fast that you do not notice.
Why does this matter?
Your code tells the pump to start. Now it says to wait some amount of time after which it will stop the pump. But… the Raspberry Pi does not just patiently wait. It goes off and performs other tasks, checking in periodically to see if time is up. Even if running your code for this one project is the only thing you have this Pi doing it will go off and do other things because the Linux operating system it is running is very complex with all sorts of maintenance tasks that make sense in a personal computer or a server but not in a physical device controller such as this.
That is why it is inaccurate. Ask for it to wait exactly some amount of time before turning the pump off you will get that time plus some extra.
Don’t get me wrong. If the Pi isn’t doing anything else that extra wait might not be much. It might not be noticeable [most of the time]. But it is there and it is random.
So how can it be unsafe?
What if it during that wait one of those background tasks hits a bug that freezes or crashes the Pi? What if the SD card goes bad (they do that a lot).
Then your pump never shuts off!
Now look at what @Rogan Dawes suggested. The RasPi tells a microcontroller that it wants X milliliters of acid added to the pool. The Microcontroler decides how long it should run for and does so. It truly does only one thing at a time. You tell it to wait… it’s right there waiting. It doesn’t go off to work on some housekeeping chore. And with no OS involved it is far less complicated. You should be able to find and remove any important bugs in your development process.
What happens if your RasPi locks up or slows down while the pump is on? Nothing much. The microncontroler just finishes the job, stops the pump when it’s time. Of course if the Pi is in charge and it stops working there will be no new commands sent to the microcontroller. Nothing more happens until you restart it. But at least you didn’t just acidify your pool!
Once you are doing things this way however suddenly you realize… Why use the Pi to do anything at all? Take measurements, calculate chemicals, run pumps, sleep, repeat… A micro can handle that easy!
A Pi can still be useful if you want to collect data. It might be nice to see how the amounts of chemicals use vary over time. You can implement that by having the micro also send a message to the Pi as part of it’s loop. Then, if the Pi does go down all you are losing is information. Add some caching at the Micro and you don’t even lose that.
A Pi might also be good for creating your remote control interface. But then, it that’s all you want from the pie there are always ESPs.
Would some form of watch dog timer alleviate your (proper) concerns re RPi crashes ? The WDT resets the system to a safe condition, tries to reset the RPi and triggers some form of alert for the user.
+1 – well put. Micro is much more reliable than an OS., especially one running on an SD card and questionable power stability. How many people have had a PC blue-screen? Granted linux is more stable… Anyway, even with a micro, I’d still have a WDT enabled on the micro itself, in case you manage to have an ‘oops’ in your control code. If your micro has output to acid pump low on boot, even if you manage to hang your micro code in a loop or with some comms wait, it’ll reset to a safe state automatically. I’d trust an “arduino” with WDT 100x over a raspi, even if the raspi had some sort of WDT-ish thing (what happens if SD is corrupt, or other?).
Yes, drying the probe out is almost guaranteed destruction. However leaving it the test sample will not be good for it either, it has to be stored in the correct solution, or it’ll just drift off so bad it’ll no longer be useful.
There is actually a local company (proautomation.co) that has developed a battery operated floating system (PoolSense) that monitors the pool water and uses LoRa to relay the readings to a central location. Central location then calculates what needs to be done and sends a notification to the subscriber with instructions. So yes, this is a subscription based system. What’s interesting is that they reckon that the battery should last a minimum of 2 years (and I assume that implies the same for the sensors).
Cost of the device is ~$200, which is pretty good, compared to the costs of the sensors and EZO boards, etc, if purchased directly. Obviously, it is a lot simpler to drop a floater in the pool, than modify the plumbing to insert probes and other sensors. As a counterpoint, having to spend $200 every 2-3 years to buy an entire new device, rather than simply replacing the probes is not great.
I’d be really interested in seeing if I can also receive the LoRa messages send by these devices, and interpret their values myself.
Thanks for this reference.
Could be great to has something like this, open-source and free-cloud.
I have been thinking about to put a 15$ xiaomi mi-flora, to get temperature, TDS, water level and sun, just by bluetooth. Could be great something similar with pH and ORPand could be fantastic, as you didnt need plumb bypass…
@Philo of Zarquan: Thanks for the reflexion and explanation.
Obviously, an arduino or ESP can do probably most of things of automation.
About timing accurate, I think a RPI can compete with microprocesor in milliseconds-order frames, but I am agree with you that a RPI cannot be adecuate in microseconds-range (usually needed for signaling processing). But take into account that in a “pool automation system” you work with seconds-order (or even minutes-order), so for this task, a raspberry pi is, by far, more than enough. It doesnt matter that you stop the pump 1 or 2 seconds after you want, just becouse your cycles are probably in the hours-range.
About safey, its absolutely important that for an unplanned power outage all the system will be off. Thats why is important select the correct “Normally Position” of the relays, so for example, if you unplug the RPI, all relays will go off (main pump and preristaltic pumps). (this is only making proper electrical connection). In the process-startup system, all relays will be off. And I have been very careful in this aspect, so that when Home Assistant start, everything starts in the “safe” correct state. Obviously, if you power off the RPI in the middle of the cycle filter, and inyecting muriatic acid, when you start, the current cycle will be lost, but the system will know the cummulated time it has been filtered, and the cummulated time (and injected ml) of muriatic. Next cycle, it will meassure pH, ORP and temperature, and will calculate new cycles for filter and injection (if needed).
About the sd corrupt card, obviously there are a minimum risk. Thats why I recomend use good quality Sandisk. I have some of them (even with the first rpi-1) working for years 24×7 with zero errors. The only problem could be a power cut inside a bulk-write time (like bulk torrents downloading). In the pool enviroment a have been working with a RPI since 2016 (other project bassed on ‘pilight’) with “hundred” of sudden power outages due to a power leakage problem with an old pump, and with zero corrupt sd-card. About this project, HA has very low writing use, so its really difficult to get a damaged sd card here. Obviously, when a sd were heavy-corrupt, the greater problem will be that the RPI dont start at all, but you realize in a single day when you miss the daily report on the mobile.
About the last possibility, the ‘hang’ of system, I have been working with the ultra-secure raspbian for years, and I have found that Home Assistant (the software base of this system) ultra-stable, with zero ‘hang’ until now.
I have been very concerned about the safety in the design of the project. If you see the code, the system has maximum time for chemical injections, and block the relays if the limits are exceeded. It seems that in general, you are very concerned about the corruption of the SD, but in practice, in the automation of a swimming pool there are many more things that can go wrong (the relays can be damaged, or the pumps, or the power supply, or the engine, or have an obstruction in the pipes, or a break in the injection tubes, or the more than certain death of the pH or ORP probes, or their gradual degradation in the measures …). Even if you have an ultra secure microcontroller, you have to face all these problems (and more than I have surely not anticipated). Therefore, for me it is even more important than the automatic regulation, the notification system: the system must notify me of any anomaly: that the probe measures have too much variance, or that it has injected more than a certain amount in the last 48 hours, the temperature drops below 6ºC, etc. etc. etc.
I wouldn’t want to go further into the controversy if an RPI or a microcontroller. For me, they have weighed more the advantages of an RPI, especially the ease of implementation, versatility and future possibilities (such as a webcam, presence detectors, …) than the disadvantages.
But the automatisms and the way of handling can be valid to do similar things with a microcontroller (I have seen several very interesting similar projects with microcontrollers, usually with photon and/or node-red)
@MacAttack, @my2c: Do you know the RPI has a hardware WDT inside? With my old project (pilight based) I configurated it (but never were activated).