@rickyturner that all makes sense but the one thing I'm puzzled about is your mention of 12VAC light transformer. My Pentair lights are 110V. I have them wired from a ground fault outlet inside my controller panel out through channels 3 & 5. I probably misunderstood something here.
1 Like
They make both in pretty much all pool lights.
On my pool, my light has always been run off a 12VAC transformer like this. 110 out of the PE653, 12V out of the transformer to the pool light.
Also, just to update on what I mentioned there: I've decided to go with a Shelly. Reason being:
I can run the Shelly off the 110 in the transformer housing, and switch the 12v, since the Shelly relay is isolated. Also, the Shelly is designed to flash Tasmota easily, and as luck would have it, Tasmota ALREADY HAS built-in blink commands, for which you can set .1 second increments and blink counts. No custom coding necessary...you just send it a http request with the correct arguments in it, and it runs the code it already has in hardware!
So, it'll be set up to be auto on when power is received, and I'll send a GET request that says "blink 5 times for .1 seconds," and it will do that and automatically return to "on", and I'll be in "America" mode in .5 seconds!
I've already set up a 14-way virtual button for it in Hubitat and custom rules and a custom dashboard to run them in Sharptools. I'm currently writing the Rule Machine apps in HE to temporarily setLightColor() in the pool controller, but as soon as I get my Shellys in, I'll switch over the actions to send HTTP commands. Love a good project!
By the way, Keith, I've discovered a bug in the way the setLightColor stuff is working within the device, if you want to know about it. Not sure if this is the right place to post such things, but here's what I've found:
When you send a "setLightColor" command through RM, it actually runs the sequence for the LAST command that was sent, not the current one.
For example: I've set up 2 actions with no triggers, just so I can click the "Run Actions" button inside the app. One action is "setLightColor(1)" and the other is "setLightColor(2)".
I can reproduce the following over and over:
If I run the action setLightColor(1), it will turn the Light off and on x number of times (x depending on whether I last selected 1 or 2)
If I then run the action setLightColor(2), it will turn the light off and one ONCE
If I then run the action setLightColor(1), it will turn the light off and one TWICE
If I then run the action setLightColor(2), it will turn the light off and one ONCE
If I then run the action `setLightColor(2) again, it will turn the light off and one TWICE
I hope this makes it clear what I'm saying. The command to set the light color is actually setting it to what you selected last time. Again, I have confirmed this isn't due to any of my other devices or variables or apps I've made, because I've stripped it down to just the single action, and it's predictably one command behind every time.
@rickyturner, thanks for all the feedback. I'll be following your progress on the Shelly board. I see the PE653 Z-Wave "blink" as a hack of last resort, that is fragile but can be made to work in the absence of something better. I may follow your lead and will stay tuned.
Thank-you also for testing the setLightColor function. Your test results make it clear that the sendMessage is setting the state variable asynchronously and therefore the code should not rely on being able to retrieve the currentValue immediately. I will adjust the code to overcome this issue in a future release.
1 Like
That's awesome. And yep--this is actually what I thought was happening with my RM4 app...I've created a "pool color mode" global variable, and I'm using one app to change it based on my button device. Then another app is using "variable changes" as its trigger, and using the variable as the argument in "setLightColor()". --And I was thinking maybe, since that app was sitting there with the last value in it UNTIL it changes, maybe once it changed, it was sending the old value. But you can clearly see in the logs it wasn't doing that, and was sending the correct, changed one. But I still double checked without my apps to make sure.
Once again, though, I just want to reiterate how much I appreciate how long you've been so hands-on with this project. It's great to see. --And I will definitely be sharing my results with my Shelly and SharpTools, etc. I'm very proud and excited about what I have already. Once I get that Shelly rocking, it's gonna be super slick. 
1 Like
Quick update on the Shelly situation:
I got my Shelly in and flashed to tasmota tonight.
Got my RM rule set up:
I had previously, over the weekend, set up a custom dashboard on Sharptools:
--And everything is working beautifully! All I have to do now is wire the Shelly into my Transformer box. The transformer housing has a roomy box in the bottom where 110 comes in, and you have 12V, 13V, or 14V AC out. I will run my Shelly off the 110 coming in and switch the 12V out, and this badboy will be working!
In case anyone wants to know exactly what I have going here:
In Hubitat, I have:
- A virtual button with 14 buttons
- A global variable called IntellibriteColor
- A virtual omni sensor called Pool Light Mode (optional--just feeds a variable to SharpTools)
- A RM Buttoncontroller rule that sets the IntellibriteColor global variable and the omni sensor to whatever button was pushed on the virtual button (ex: pushing button 11 sets IntellibriteColor = 11, Pool Light Mode = Solid White)
- A RM rule (screenshot above) that is triggered by the global variable (IntellibriteColor) changing, and sends an http GET command to the Shelly telling it to set the BlinkCount to %IntellibriteColor%, and to blink the relay.
In SharpTools, I have:
- A dashboard (screenshot above) with 12 modes. Those mode buttons are SharpTools rules that simply send a "push" command to the virtual switch in Hubitat, with the appropriate button #. This allows me to have only ONE device in Hubitat and Sharptools, but to pass 12 (really 14, but I'm not using 2 of them) discrete commands.
- A hero attribute tile for the "Pool Color Mode" virtual omni sensor in Hubitat. This sensor has a custom attribute that I set with a string via one of my rules when a button is pressed. This attribute displays the name of the currently/last selected mode on my SharpTools dashboard
The end result:
I push America mode in my Sharptools dashboard>Sharptools "sends PUSH button 5" on my Hubitat virtual switch>The ButtonController app sets "IntellibriteColor" global variable to 5, and variable in "Pool Light Mode" to "America Mode">Sharptools displays Current selection: "America Mode" via hero attribute tile for Hubitat's "Pool Light Mode" device>Global variable changing to 5 triggers http GET request to the Shelly, telling it to blink the relay 5 times, which turns the light to America mode.
My relay timing is current set to .2 seconds, so switching to America mode should take a little more than 1 second (which is way faster than Hubitat and the PE653 could have managed, and even faster than the ludicrously overpriced Intellibrite Controller does it, from the reviews I've read). But if it ends up needing to be fine tuned, the timing of the blinks can be easily changed via a simple command sent to the Shelly, which is persistent until it is changed again.
The great thing here is that the relay blinks are being controlled directly on-chip by the ESP8266, so the hub overhead is minimal, and the blinks are dead reliable. And, a Shelly costing about $10 gets me the functionality of the Intellibrite controller for about $240 off! 
2 Likes
@rickyturner Thanks for all the details. This is very exciting. Now that you've connected all the pieces together, can you reflect on how this might be adapted to an installation (like mine) with 110V lights?
Hello PE653 Community. I know it's been quite a long time but I have a new Device Handler available. I have partnered with @Joshua to share the repository he created in the Hubitat Community on GitHub. This release combines the best of the work he has done with several significant new enhancements and some bug fixes. You can read more here and on GitHub:
Child Thermostats!
Repository: HubitatCommunity/hubitat-zwavemultichannel-pe653 · Tag: v4.0.0 · Commit: 83b032b · Released by: tooluser and KeithR26
- Added support for 2 Child Thermostat devices.
This allows a pool and spa to be treated as two separate thermostats, each with their own setpoint (desired temperature). This feature is entirely optional. If you wish to take advantage of this feature you will need to create a "New Driver" in the HE console and upload the separate Child Thermostat Driver code and save it.
After both the main Driver and the Thermostat Driver code is updated, go to the Pool Control Device page and click the Recreate Children Button on the Device page.
Following the installation you should see the Pool and Spa thermostat child devices in the Component Devices list at the very bottom of the Pool Control's Device Page.
I use the HE Dashboard and so I added two thermostat tiles and linked them to the 2 child devices. Since the PE653 has two independent temperature controls, emulating 2 thermostats makes sense, but there is only one "current temperature" sensor, which of course is measuring the temperature of whatever water is passing through the equipment at the moment.
This will depend entirely on what mode the system is in: Pool vs Spa. Consequently it is not possible to know the temperature of the Pool when in Spa mode. I considered remembering the "last known temperature" of the non-operating mode, but this could be minutes, hours or even days old, so would almost always be misleading.
I elected to instead report "unknown" as the current thermostat temperature for the non-operating mode. Of course if you don't have both a pool AND a Spa, simply ignore the other thermostat.
Log volume: I have seen many complaints about the high log volume and experienced my own frustration trying to weed through them so I tuned what is logged in Low versus High Debug Mode. I think the compromise is good. You can certainly run with Debug Level to Off, but I leave mine at Low all the time and find it comforting to see the occasional messages coming from the Poll() commands sent by HE, which by the way seems much more reliable and consistent nowadays.
—
This release has 2 assets:
- Source code (zip)
- Source code (tar.gz)
Visit the release page to download them.
As always I recommend backing up your current handler source so you can easily revert if necessary. I look forward to hearing your feedback, questions or comments.
Stay Safe
Absolutely! So, in your case, it would be even simpler! --Because you would just be switching your 110. The Shelly 1 has dry contacts on the relay, which allows you to switch any separate power source. That's ideal for me, because I have to switch 12VAC. In your case, a $5 Sonoff Basic, or a Shelly 2.5, or any other Tasmota-flashable smart relay that switches its mains power would work perfectly!
If you ran the 110 out of your PE653 light circuit into a Sonoff basic and wired your light to the output of the Sonoff, it would just be a smart relay in between. You set your sonoff relay to be on by default when power is restored. After that, everything I've set up would work exactly the same!
Disclaimer: I say Sonoff Basic above, but I personally am not a fan. Never had any luck, but I think I got a bad batch. They would work fine powered by 3.3v, but when I had them powered by mains power, the WiFi connection was so flaky, it would either take 5 minutes to connect or never connect at all. YMMV. Some people swear by them. I swore off of them. I don't think, though, at that price point, Sonoff devices are known for their QC.
Does anyone have the child switches working? I would love to get the VSP switches to work.
@aarony They work perfectly for me. If I may suggest that you try the new 4.0 version, and if it still does not work for you I can review some logs to troubleshoot it.
Another quick update, I shot a quick video showing the Shelly doing its thing.
I got home after dark, so wiring it to my transformer will have to wait until tomorrow, but this was a pretty satisfying test for me tonight, figured I'd share.
4.0 worked! Thanks a ton!
@JDogg016 Version 4.0 is now available and it certainly addresses your second point. It would be helpful to see if you continue to see the unresponsive issue. Even if you do, it will be much easier to triage it on the new version, considering the more conservative logging profile.
We have one set of positive feedback already (in addition to my own)...
@CAL.hub, did you ever go any further with the schedule functions? I'm in a more active period right now so if you have any questions or want to experiment, it's a great time.
Hope you are doing well. Take care.
@ethelredkent It's a shame it has become so difficult to upgrade the pool controller software. Given that you are not the only one out there stuck on 3.1, that many people had success on Vera with v3.1, and that the driver is certainly capable of being sensitive to what version of firmware the controller is on, I think it's worth putting some effort there.
In other words, if you're game, I'm willing to work with you to see if we can make the current version work better on v3.1. If so, by all means, take care to save a copy of what you have if its working, but give 4.0 a try, exercise it a bit, and send me logs of things that don't work.
@mike.maxwell, I wanted to check in to see if the Manufacturer Proprietary command class was ever added? This would allow me to clean up a lot of hard coded junk in my device handler. If not, anything you can do to bump it up the list a bit?
@jpoeppelman1, I didn't see that anyone ever replied to your question. Did you ever pursue a pool controller. This forum is home base for a community supported driver that has been very successful for a pretty significant group of users. I use mine every day and there are about a dozen consistent users. The code is maintained by two of us (@keithriley and @joshua). No, it's not Hubitat supported but there are a ton of very successful community supported integrations our there. That is what is so cool about Hubitat. Let me know where you are with this.
Hi, Keith. Very sheepishly, I have to admit I still have my PE953/653 still on ST with your handler. Your recent activity here has me thinking of switching (it's the only non-cloud device still on ST).
Hi Keith,
Thanks very much for the offer. Yes, I would like to have another bash at this.
I was thinking of switching the pool back to Vera but coincidentally my Vera Plus died just 2 days ago and is no longer an option. I was running both controllers, for different tasks, so now I am forced to complete my planned transition to Hubitat. What was scaring me the most about the move was the migrating of my DSC alarm system. Amazingly, this turned out to be trivial (once I had figured out the password),
Right now the pool system is disconnected so I will need to go back figure out how to set it up again all over again. I should be able to do this blindfolded by now but after a full year my old brain cells have already reset and I will have to relearn the whole thing again.
Hopefully, by the end of this week, I will be back up to speed and able to communicate intelligibly.
Cheers Bruce
