My NEW Pool Automation Controller

[jonpcar]

This is a work in progress…I will be updating this first post with some of my latest progress. Normally, I post projects after I have completed 90% of it. This is not the case with this automation project. This thread will be kind of like a pool-build thread, with updates when I get the time: concerns, successes, and failures.

What I am hoping is that I get some additional ideas from folks on these boards about enhancements, changes, possibilities. The great thing about this project is: as long as it holds my interest…it will never be done. I can envision making enhancements and changes for a long time into the future. That can be both a “good” and a “bad” thing.

Major Posts Below:
1) Background
2) Pump Control
3) Scheduling
4) User Interface Part 1
5) User Interface Part 2
6) Sensor Inputs and Control Outputs Plan
7) Sensor Read Code
8) Pool Controller Board
9) Why So Many Pressure Sensors?
10) Stenner Pump Hardware Control
11) Stenner Pump Software
12) Valve Control Relays
13) Milone eTape Update (NEW 7/25/2020)

 

[ajw22]

 

[jdlangley1]

Wish I could add my kids to automation so they pick up their toys after playing in the pool!!!

 

[Arizonarob]

 

[jonpcar]

This is a work in progress…I will be updating the first post with some of my latest progress, and through additional posts. Normally, I post projects after I have completed 90% of it. This is not the case with this automation project. This thread will be kind of like a pool-build thread, with updates when I get the time: concerns, successes, and failures.

What I am hoping is that I get some additional ideas from folks on these boards about enhancements, changes, possibilities. The great thing about this project is: as long as it holds my interest…it will never be done. I can envision making enhancements and changes for a long time into the future. That can be both a “good” and a “bad” thing.

1) Some Background

My wife and I are empty-nesters and in 2014 or so had not really used our pool in any appreciable amount for the previous 10 years. It was a “no-landscaping eyesore” in our backyard (all had slowly died off), and truthfully it was a PITA to maintain for no gain. In 2014 we took on a DIY pool remodel (link in my signature) and were very happy how it turned out. It got us swimming (some) again, but it wasn’t until last year we saw how much our 3-year old grandson loved the water that we really started enjoying our pool again. That same daughter had twins last year and our son has one on the way, so we will be swimming again for a while.

I actually didn’t officially start using the TFP method until Spring 2018, and have been very happy with the results; but I don’t think I will ever be happy with the doldrums of maintaining a pool…yeah, I know, that doesn’t go hand-in-hand with TFP methodology.

When my pool got extremely warm last year 95F, I decided I was going to try and automate my aerator, to cool down the pool some in early morning hours. Well that project is not even started yet, but “looking at it to see what it would take” was the trigger for a host of projects that led me directly to this automation attempt.

Included in that journey…protecting my pool equipment:

Retractable, Removable Pool Equipment Cover / Sun Shade / Protection

Adding a stenner pump and chlorine tank…recently expanded to include an acid tank:

Stenner installation with buried tank for AZ heat

And this marathon thread (don’t even try to read it) where I discovered more than I thought I ever could know about my In-Floor-Cleaning-System (IFCS)…and am still going at it. For a few days, this particular thread was titled "How I lost $1000s by not turning one valve in my pool system"...haha, and it was true!

Optimize Your In-Floor Cleaning Effectiveness and Efficiency

It was during some of those IFCS experiments in that last thread that I realized I had some shortcomings in my pool, especially with my Ecommand4 automation control. So I started thinking…and thinking…and thinking about what I wanted to change. Im still thinking about it.

My Personal Background (or… if you want to try something like this, what might be helpful?)

I grew up playing with Radio Shack electronic kits and that probably led me to becoming an electrical engineer. I’ve been retired for a while; however, since my pre-college years I have not really “played with electronics. “ I designed microcontrollers at Intel and so that has given be a good understanding of what is possible with arduinos, raspberry pi’s, and a host of other modern controllers. They are waaaaayyyy beyond what I worked on…especially with the software support.

As far as software, I did assembly language programming and something called HDL (Hardware Description Language). I have not had other higher level languages (well Fortran 35 years ago in a school class, and Basic on my Commodore64, haha). But those experiences have given me a background to understanding the principles of C++/java programming. Those with ZERO programming background would probably struggle with a project such as this.

Truthfully, what finally made me decide to go for this was a pool thread by another “tinkerer” who has less experience than I have and went all out. What I like about that thread is that he posts successes and failures…I have learned much from reading his updates, THANKS Brennon. I’ve linked to this thread before:
Automated Pool Controller

Finally, here is something to consider that I posted in a previous automation thread on these boards:

I think most of these [pool automation] projects are tackled by people who just love to tinker. Many, but not all, have a background in either software or electronics hardware, sometimes both (I envy those, haha). As talked about early in the thread, the “hardware” is always cheaper, but the time commitment is what usually disqualifies those who pursue these: many of these projects fail to reach launch.

Lots of other issues besides cost/time should be considered as well: safety, reliability, transferability (house sale) are among those. So, despite costs and limitations of commercial systems, they are the ONLY real option for 99% of pool owners who desireneed advanced automation.

Pool Controller Project Outline

This project will eventually be a pool controller for my swimming pool. It is very specific to my pool, but others may find parts of it useful in doing a similar project. I have obtained inspiration from many other pool projects that have been posted on the web, including some here on TFP. Special thanks to Zack, an awesome programmer (and not that bad of a son-in-law, too) who jump started me on ALL aspects of this program and who probably would have finished the entire project if he had a couple more days to spend on it, haha. Truthfully, there are sections of code in the Android app that I have not deciphered yet.

There will be a rather slow rollout of this project because almost everything is new to me, AND I am not in a rush.

The project will consist of these parts:

1. an android app to control pool operation that directly communicates with the Particle Photon. This is designed with Android Studio and is written in Java.
2. a hardware implementation that includes the Photon, relays, sensors, and supporting chips/components that will interface directly to my swimming pool hardware (pump, valves, sensors)
3. a Google Sheets interface to the Photon that will allow me to log, store, and graph all desired data
4. Photon firmware that will implement: all hardware functionality, interfaces to the Android App, and interfaces to the Google spreadsheet.

My goal is to have a completely self contained system that can operate my pool pump/valves for weeks without WiFi, not that it is necessary but in order to be self contained and not dependent on Wifi/internet. All scheduling will be maintained and implemented on the Photon itself (beside chemicals testing/maintenance). Scheduling will include the ability to schedule for all four seasons.

In addition I want it to (with WiFi available):

1. collect and store data (temps, psi’s, Watts, gpm, chem injections, chem readings)
2. send updates, warnings, alerts about the system status
3. allow manual operations including overrides of existing schedule for pump/valves, lights, chemicals, waterfall, tbd
4. everything (within reason) accessible-controllable via phone app

Some of these goals have already changed since I originally posted this on Github. I have made a BUNCH of progress...but that’s it for now.

 

[jmusits]

Can you add a link to your github repository?

 

[jonpcar]

Can you add a link to your github repository?

Nothing really there yet (except the description), but I do plan on uploading code, etc. eventually. GitHub is new to me and I haven’t exactly figured it out NOR exactly what I should be archiving there. I have a lot of in-progress “stuff” and haven’t yet committed it to the check out/check in version control of github.

Anyway, here is the link:

GitHub - jonpcar/Pool-Controller: Pool Controller based on a Particle IO Photon

Pool Controller based on a Particle IO Photon. Contribute to jonpcar/Pool-Controller development by creating an account on GitHub.

github.com

 

[dschlic1]

A suggestion. Let all of the control be in the Particle Photon. Just use the Andriod app to change setpoints etc and read status data. Also a local, non phone interface would also be nice.

 

[jonpcar]

A suggestion. Let all of the control be in the Particle Photon. Just use the Andriod app to change setpoints etc and read status data. Also a local, non phone interface would also be nice.

Thanks, dschlic...that is the plan as far as the photon. The phone app will inject overrides (ex: run the waterfall for 2 hours, inject X oz of chlorine, run the IFCS for 4 hours), but all the control/flow will reside on the photon. When an override expires, the schedule that exists on the photon will resume. The phone app actually "extracts" the Photon's schedule to display it. The Photon has the only "master" copy.

The Photon has a built-in flashable EEPROM table so that local "setpoints" and "alarm points" can be permanently stored. Eventually, the phone app will be able to update those setpoints.

Letting the Photon control everything is my goal...we will see how that works once (if) I advance to a stage with chemical dosing (haha, that is one of my future goals).

A non-phone app would be great but will be secondary, so much to do currently. My wife and I do a lot of travelling (without WIFI access) and that has been a driver for this first step. Once everything is to my satisfaction, I will dedicate a cheap android tablet (that will run a version of the phone app) to the patio/pool area so that control can be accomplished locally without a phone.

 

[jonpcar]

2) PUMP CONTROL

So the first thing I tackled when I decided to do this automation project was to make sure I could fully control my pump. I have a lot of things in mind, but scheduling is the obvious one.

My current Ecommand4 allows me to effectively run three primary schedules (pool high rpm, pool low rpm, spa high rpm). Yes there are a few things you can do with some of the aux relays, but really not that worthwhile.

For a Hayward EcoStar, the site listed below was one of the first to document the Hayward RS485 protocol. I really only needed to control the pump, I have no other Hayward equipment.

Controlling the Hayward Ecostar Pump

There is similar work that exists for other Hayward pumps and for most Pentair equipment…actually much more advanced in that case.

The RS485 protocol is very messy/busy with a “controller” actually controlling it: like my Ecommand4 or an Intellicenter. There are packets of information being routed around everywhere and sometimes to nowhere. Everything simplifies when you take out the controller.

I send a command (via the RS485 bus) for the pump to run at X rpm, it sends a status back saying I’m running at X rpm and am using Y watts. That’s the only traffic. Unfortunately, there is a little kink, at least for Hayward pumps.

Probably as some kind of fail-safe, Hayward requires a “controller” to command the pump to run at X rpm EVERY 1.5 seconds or so. If not, the pump STOPS. That’s a burden that must be carried by any home-brew pool controller. It’s not bad, but you have to be aware.

Thus, my first Photon program was a simple one (although with the learning curve, I still didn’t get it working for 2 weeks). The program accepted an rpm value from the web, relayed it to the pump, and captured the pump status….over and over. I had my Photon out at my pool pump for a few days directly controlling the pump speed without my Ecommand4.

As it turns out, I probably won’t use/need the full gambit of being able to set the rpm of my pump to ANY value, but that comes later.

------------------------------------------
NOTE: to drive the RS485 bus from the serial port of an Arduino, raspberry pi, photon, esp8266, etc. you need a device like the following…here is what I used, but you can get them much cheaper on eBay, especially if you can wait for shipping from China. If anyone is interested in the hookup or the protocol to do this, let me know.

Amazon.com: DROK TTL to RS485 Adapter Module 485 to TTL Signal Single Chip Serial Port Level Converter 3.3V 5V Board with RXD, TXD Indicator Lights: Home Audio & Theater

 

[jonpcar]

Over the next week or so, I am going to try to “catch up” to where I am actually at in this project.

3) Scheduling

So the first big issue for the photon software was scheduling. What do I need and/or want in my pool controller scheduling ability? It is a task that will take considerable photon resources to monitor and update. Here are some things I listed:

1) Full schedule resides on photon
2) Schedule is a yearly schedule, not just a weekly
3) Ability to schedule: pump/valves/lights/ chemical injections/other features
4) Schedule is easily updateable/changeable from user interface
5) OneShot scheduled actions?? Decided NO…don’t seem to be that useful for me…
6) Anything I missing? I am planning to recode all of this…

The existing implementation combined the first three goals but not the 4th, as I had not even started thinking about my user interface to the photon hardware. I had ideas, but no plans and no real knowledge either. NOTE: At this time, I am leaning against spending energy implementing that 4th item, it’s cool but the payback is very low, especially once I “fine tune” my year round schedule.

The resulting schedule structure was coded into a fairly tight database that resides in the Photon’s limited, changeable, permanent, user memory (flash memory…it will stay there even if the device loses power).

Through the implementation process, I’ve already decided to simplify. I will never schedule lights ; I am cheapskate as far as electrical usage…it’s OUT. I am taking out chemical injection scheduling. I will replace it with some TBD method that will have an injection target per day/week/month/season. Experimenting with timing of injections is where I plan to spend some time tinkering in the future, but they will probably not be “scheduled” in the traditional sense.

We are down to pump/valves, and I consider those one and the same. I don’t fully understand the top-of-the-line pool controllers; but it makes no intuitive sense to me why people have to go through hoops to get their pump set to a particular rpm AND change any or all valve positions (if desired) for every pump schedule line item.

So here is what I currently am planning. It is a redo of the code I have implemented which needed to be changed anyway; thanks to my son-in-law, I HAVE decided on a user interface to the pool controller:

1) Each Pump/Valve item can be scheduled for any combination of days of week AND months of year
2) Each Pump/Valve item can be scheduled to start at any minute of the day (may change)
3) Each Pump/Valve item can set the pump RPM to any “legal” value (or keep the same)
4) Each Pump/Valve item can set the valves to any “legal” position. Legal valve positions for my pool are pretty simple:

• Skimming-Filtering wall return w/ skimmer suction
• In-Floor-Cleaning-System return w/bottom drain suction
• Waterfall return, don’t care suction
• Aerator return, don’t care suction (not yet implemented)
• FUTURE: possible solar heating

Originally I planned on 64 schedule items...I won't need anywhere close to that and will allow 32. That’s it in a nutshell! So the redo of my schedule software on the photon has become simpler. Hopefully I haven’t lost any necessary or valuable options with the changes I'm planning. If you think of something I’m missing, or should consider, please let me know.

 

[jonpcar]

4) User Interface (Part 1)

So I started this pool controller project in Nov of ’18, late last year. I have worked on it part time (maybe 10-12 hours a week) because we were caring (full-time+) for our twin grandsons through May of this year. But during Christmas of ’18 came a game changer: our 2nd daughter and son-in-law (Zack, who is a programmer at Google) visited for a bit longer than a week during the holidays.

He doesn’t get a lot of vacation and so I wasn’t going to ask for help…but I did ask him some questions that got him interested. He is a tinkerer, too, and dabbles in many different projects. Before I knew it, he jumped in to help me out. Over the course of his “vacation”, he probably spent 3 days full-time on my project (mostly late night, even when I was too tired to participate, ex: “watching”)…my daughter was pretty irritated with me…sorry, but not really haha.

About this time I was trying to figure out a user interface to my pool controller. He correctly diagnosed my search/indecision as ANALYSIS PARALYSIS, a term I surprisingly had never heard until then…and he was probably 100% correct. I tend to think about things longer than I actually work on them.

Over the course of the next day or so, we (he ) went through a gambit of possibilities: Samsung Smarthings, Blynk, google spreadsheets (yes this is a “thing”, and I actually wanted this before the ultimate solution), Home Assistant, ITTT, mqtt, and a couple others as well as various combinations of these. I still had Home Assistant running on a raspberry pi in my closet (now doing nothing) until I unplugged it about a month ago. It was the most promising of these options, but it seems there is not a “free” way to fully use it remotely AND securely.

None of these quite provided a solution I wanted and what Zack thought I needed. He then presented to me an option that I would NEVER have considered even a possibility…”let’s build an android app as the user interface”. I was ALL IN.

Zack promptly went into implementation mode and I…….watched.....not really understanding much of anything but getting vague glimpses of what it entailed. The day before he was leaving, he walked me through what he had done:

My new Pool Controller android app could log into my particle.io account and it could talk to my photon. The photon code it talked to was simply “dummy” code that responded to the phone app and contained nothing really specific for my pool controller. But it provided all the basic examples for what I needed to do. The android app could:

• Ask to see variables located in the photon code (used to get status)
• Request the photon to run a function given a set of parameters (used to send commands)
• “Subscribe” to the photon’s published strings (wide open, used mostly to log status/alerts though)

Oh, and Zack also setup the framework for my photon to “publish” information directly into a Google Sheets spreadsheet. He set that up in about 2 hours, something I know I wouldn’t have accomplished in less than a couple of weeks.

In any case, below are two screenshots that show what I could "do" with the phone app at the time. The first shows a screenshot of a function call to the photon that accepted parameters, in this case showing a command that will set the pump to 20% max rpm (690rpm) for an hour to the wall returns. The phone app really knows nothing about what it is sending...the photon code needs to implement, interpret, and execute any function "calls". Also is a screenshot of a status request from the phone app that returned (fake) values for various pool parameters, displayed in a gauge format, because Zack knew I wanted "gadgets", haha.

As you will see, these building block examples enabled me to expand the control/status aspects of the phone app to get closer to where I really want to be.

 

[Arizonarob]

Pool temp 102?

Did they build your pool on top of a buried volcano Jon?

 

[jonpcar]

Pool temp 102?

Did they build your pool on top of a buried volcano Jon?

I knew I could count on you to comment on that, haha. Doesn't it feel like that sometimes in August? Yeah, all those initial status items were updated with random values from a "possible" (I hope not in this case) range. So, the photon was responding to the pool app with made-up numbers. There were no temperature sensors installed at that point (or any other sensors for that matter).

 

[mguzzy]

This looks like a cool project.. I'm chiming in so I can get the alerts.. My background is in IT so I am interested in the automation and system integration too! I might even be able to throw in a suggestion or two.. but for now it looks like a well thought out platform!

 

[jonpcar]

.. My background is in IT so I am interested in the automation and system integration too! I might even be able to throw in a suggestion or two.. but for now it looks like a well thought out platform!

I would love to have ANY and ALL feedback...this really is all new to me.

I am working on updates today and am trying to get caught up so that I can just post when I actually have done something new. So far, this is all the "old stuff". But, I really AM hoping that I get feedback from members of TFP...

This looks like a cool project..

It's about to get way "cooler", haha. My vision is probably going to have to be scaled back...but we will see.

 

[jonpcar]

5) User Interface (Part 2)

So after Christmas, I was determined to figure out Android Studios/Java so that I could start to make the changes to get where I wanted to be with the User Interface. I didn’t want to forget the small amount that I had absorbed watching Zack implement the skeleton. It took me more than a week before I could even compile and load (onto my phone) the existing code that he had created. It took me a month before I could make a small change successfully and get it installed my phone.

But I was enjoying this…it was not only cool, it was a LOT of fun!

I literally spent the next 3 ½ months (Jan, Feb, Mar, Apr of this year, 2019) fooling around with Android Studio and still know a tiny fraction of what can be done with it. I realize I am not good at any of it but I have gotten better. Also, my attempts to “add features” has helped me to zero-in on set of features that I really want to support in my Pool Controller, and in the User Interface.

All of the “coding” done on the photon at this time was simply to test the phone app. I was actually doing nothing to advance the photon as my actual pool controller. In fact, I only recently got back to coding the pool controller itself in the photon firmware, with a boatload of change requirements to the work I have already done.

So here are a few screen shots at where I have left the android app. It is not near completion but it gives you some ideas about where this is headed. I’m a visual kind of guy and like to have as much information available to me on any given screen.

Status on the screens is updated automatically by grabbing the latest data set from the photon when ( 1) the screen is entered (2) on request from the user using a swipe, or (3) whenever the phone app sends a command to the photon, which then reflects the latest status as the photon’s response to that command. For example, a “turn on the waterfall command” would update the status to show the actual rpm/time remaining/status of the waterfall as seen from the photon's point-of-view.

The idea of the first screenshot is to have a HOME screen where major pool status is easily view-able. The LED status lights will give indications of where there may be issues. Green = OK, Yellow=warning, Red=attention required. None of those status indicators or gauges is set in stone.

In addition, I wanted to have any pool features readily available so that they could be easily activated (waterfall, lights). I know it’s very busy, and I might end up separating the status from the commands in the final implementation.

This second screenshot shows an example of the app’s chemicals tab. I am not married to ORP…eventually I might try it but I still need to find out more about it. Notice the buttons in the upper right where I can enter/view chemical testing data (which in turn sends it to the photon and on to the google spreadsheet). That’s a feature I think I am going to really like because I hate the doldrums of recording chemical results.

Once again, all these numbers are provided to the android app by the photon, but it is only placeholder data until the photon firmware can supply real numbers, which I am working on now.

Finally, here is a third shot of the chemical entry popup. Along with the chemical values entered, the date and time are also recorded and saved with the data on the photon and the google spreadsheet. I can finally get rid of my random index cards which I never really use or look at anyway.

There is still a LOT of work to be done on the phone app, especially once I determine (or not) what can really be supported inside the photon “pool controller” firmware and pool sensors that I am installing. I haven’t touched the Android app for almost a month and a half now. I’ve turned my attention to the sensors….

 

[mguzzy]

That is a very impressive GUI on the phone app... is it skinnable ... if so I want the LCARS theme? Sorry its the geek in me.

 

[MyAZPool]

Hi Jon,
WOW!!! You are making some seriously nice progress on this. Looks fabulous.
Watch out Pentair. You got some dangerous competition coming up on your six. In fact, I think you are just blew right by them as I carefully study your outstanding dashboards.. I really like the use of your icons. Very nice!!!!
Still looking forward to checking out those waterfalls. ...
r.

 

[cmc0619]

This GUI is GORGEOUS!

User Interface (Part 2)

So after Christmas, I was determined to figure out Android Studios/Java so that I could start to make the changes to get where I wanted to be with the User Interface. I didn’t want to forget the small amount that I had absorbed watching Zack implement the skeleton. It took me more than a week before I could even compile and load (onto my phone) the existing code that he had created. It took me a month before I could make a small change successfully and get it installed my phone.

But I was enjoying this…it was not only cool, it was a LOT of fun!

I literally spent the next 3 ½ months (Jan, Feb, Mar, Apr of this year, 2019) fooling around with Android Studio and still know a tiny fraction of what can be done with it. I realize I am not good at any of it but I have gotten better. Also, my attempts to “add features” has helped me to zero-in on set of features that I really want to support in my Pool Controller, and in the User Interface.

All of the “coding” done on the photon at this time was simply to test the phone app. I was actually doing nothing to advance the photon as my actual pool controller. In fact, I only recently got back to coding the pool controller itself in the photon firmware, with a boatload of change requirements to the work I have already done.

So here are a few screen shots at where I have left the android app. It is not near completion but it gives you some ideas about where this is headed. I’m a visual kind of guy and like to have as much information available to me on any given screen.

Status on the screens is updated automatically by grabbing the latest data set from the photon when ( 1) the screen is entered (2) on request from the user using a swipe, or (3) whenever the phone app sends a command to the photon, which then reflects the latest status as the photon’s response to that command. For example, a “turn on the waterfall command” would update the status to show the actual rpm/time remaining/status of the waterfall as seen from the photon's point-of-view.

The idea of the first screenshot is to have a HOME screen where major pool status is easily view-able. The LED status lights will give indications of where there may be issues. Green = OK, Yellow=warning, Red=attention required. None of those status indicators or gauges is set in stone.

In addition, I wanted to have any pool features readily available so that they could be easily activated (waterfall, lights). I know it’s very busy, and I might end up separating the status from the commands in the final implementation.

This second screenshot shows an example of the app’s chemicals tab. I am not married to ORP…eventually I might try it but I still need to find out more about it. Notice the buttons in the upper right where I can enter/view chemical testing data (which in turn sends it to the photon and on to the google spreadsheet). That’s a feature I think I am going to really like because I hate the doldrums of recording chemical results.

Once again, all these numbers are provided to the android app by the photon, but it is only placeholder data until the photon firmware can supply real numbers, which I am working on now.

Finally, here is a third shot of the chemical entry popup. Along with the chemical values entered, the date and time are also recorded and saved with the data on the photon and the google spreadsheet. I can finally get rid of my random index cards which I never really use or look at anyway.

There is still a LOT of work to be done on the phone app, especially once I determine (or not) what can really be supported inside the photon “pool controller” firmware and pool sensors that I am installing. I haven’t touched the Android app for almost a month and a half now. I’ve turned my attention to the sensors….