Z-Wave Multi Channel (PE653)

[keithriley]

OK, this should be easy. The actual function requires an integer (whole number, no decimal places), but the way it is being called in your case is sending in a decimal typed number. That doesn't mean there have to BE any decimal digits (5.0). How are you calling the function? from RM? If so, be sure to choose "Number", not "Decimal" as the Parameter type.

The easiest way to try it out is just go into the HE console, select Devices, select your Pool Control device, then scroll down to the setLightColor button. Key in an integer right under the button (eg: 2), and click the button. In my case I see these lines in the logs (yours may look different as I am on a newer version of logging):

dev:52020-04-30 08:18:07.326 am traceblink() cmds=[MultiInstanceCmdEncap(command:1, commandClass:37, instance:3, parameter:[0]), delay 1000, MultiInstanceCmdEncap(command:1, commandClass:37, instance:3, parameter:[255]), delay 1000, MultiInstanceCmdEncap(command:1, commandClass:37, instance:3, parameter:[0]), delay 1000, MultiInstanceCmdEncap(command:1, commandClass:37, instance:3, parameter:[255])]

dev:52020-04-30 08:18:07.269 am trace+++++ blink switches=[3] cnt=2

dev:52020-04-30 08:18:07.260 am debug+++++ setLightColorInternal 2

Best of Luck!

[rickyturner]

That's so strange, though! I thought it looked like it was receiving a decimal rather than an integer--but no, the only way I've tried it is by doing exactly what you said, from the device. I typed 3 in the box and clocked set light color. Why would my device be passing a decimal instead of an integer? Ghost in the machine...

[keithriley]

Check the driver code around line 155. Looks like I updated the function prototype but not sure exactly when. See before and after:

	command "setLightColor", ["number"]

// command "setLightColor"

In the absence of the "number" declaration it may have defaulted to decimal. Try making that change.

[rickyturner]

Here's what I have, but it's at line 101 for me. I have version 3.1.2 here.

[rickyturner]

PROGRESS...

So, it seems it's something with the device driver. To test that, I created a simple app in RM to send the command when I push a button. First time I ran it, it successfully turned the light on and off multiple times and did not log an error, but it also didn't change the light color. --Too long between toggles.

So I went to the device, set the delay between commands from 1000 to 250. Ran my app again, and it successfully changed the color to the right selection! Then I tried to change the number a few times and had hit or miss results--mostly misses. I figured my delay was too short, so I bumped it up to 500 ms, but it would come on at some points during the change, so I figured it was maybe missing a command here and there, skipping a cycle, thus taking too long and allowing the light to set. --So I bumped it up to 750 with terrible results...then back down to 300 and it worked again.

So it seems I can probably fine tune the device delay to get this somewhat predictable, and build custom buttons to put on my Sharptools dashboard to change the light color, if nothing else.

But just to be clear: I can successfully invoke the command from rule machine, but the device controller itself seems to be passing an integer for whatever reason. If this is a bug I've helped you find, I'm glad to do my small part finding it.

Thank you as always for your attention and help.

[kmheid]

Thanks for your work on this Ricky and Keith! I would also love to get this working. It is line 101 in version 3.1.4a as well, and I am seeing the same problem. It is defined as
command "setLightColor", ["number"]
but I see the same exception in the log like it is trying to pass a decimal.
Line 1795 has
def List setLightColor(int col){ executeCommands(setLightColorInternal(col), true) }

[keithriley]

@kmheid, Thanks for the additional feedback. Seems I may have already worked on this. That line you referenced at 1795:

def List setLightColor(int col){ executeCommands(setLightColorInternal(col), true) }
is
def List setLightColor(col){ executeCommands(setLightColorInternal(col), true) }
in my code, which is more tolerant of multiple data types.

Double check this function as well as it may have also changed, especially that last line,
/** Light Color */
private List setLightColorInternal(col) {
log("DEBUG", "+++++ setLightColorInternal ${col}")
def cmds = []
sendEvent(name: "lightColor", value: "${col}", isStateChange: true, displayed: true, descriptionText: "Color set to ${col}")
getColorChgCmds("$col")
}

I think this may fix the issue using the HE console. This will not have any impact on the timing challenges described by @rickyturner however. I had similar challenges and also had to tweak the delay timing. This is frustrating because the driver does not really have direct control over the device. The driver can only submit commands and hope that they will be delivered to the device in rapid succession. The driver can insert delays to slow things down, but cannot ensure that additional delays are not inserted when the hub is busy multitasking other device responsibilities. The only truly reliable solutions would be if the PE653 directly supported "toggling" the lights (not likely) or if someone created an external device to do the toggling by sending it a single command, but there just aren't enough users to justify a product, other than a home-brew effort.

Although sometimes frustrating, I have overall been satisfied that, with some trial and error, I can get the lights where I want them, and find I don't change colors that often, Luckily they do remember their last color setting seemingly indefinitely, even when off for long periods.

[rickyturner]

This is great info, Keith, and again, thanks for the continued efforts and discussion on all this stuff.

As for a device that makes the magic happen: I'm very interested in something that would make this happen. I'm a hardware/electronic engineering tinkerer/hobbyist at heart, and I have big ideas about somehow making something with transistors, a 555 timer, some simple arduino code or something that could be stuffed inside my switchbox out there to make it happen quickly, and in hardware. --But with smart control. Or perhaps a shelly or sonoff or something...

At any rate, again, thanks for your help, and I'll keep an eye on this for the new version and stuff. And I'm still hoping to fins someone who could part with their Intermatic USB stick for a few days so I can upgrade to 3.4.

Thanks

EDIT: After a little bit of looking at my options, I'm now thinking of using a NodeMCU board for this. I could even use a bridge recitifer to get the 12VAC coming out of my light transformer to power the NodeMCU, which could control relays. THis could all be self contained in a tiny project box inside the transformer housing and just take REST commands to trigger pulses of any speed I want. If anyone is interested in helping/weighing in on this project, feel free to DM me, as it's kinda off topic for this particular thread (although it would really just be for us). The benefit here would be that commands could be sent and immediately change the bulb's color, as the NodeMCU could be programmed to flash the power in millisecond increments. --So we could potentially have dead-reliable and near-instant color change results. It's semi unnecessary, but then again, isn't all of this stuff? At the end of the day, it's a project to do.

[kmheid]

That does help @keithriley! That resolved the exceptions. It does change the color now, but not to what is set in the (HE console). I don't understand exactly what the code is doing, but I'm not sure mine is correct. If "getColorChgCmds" is supposed to translate the selected color to commands to send to the controller, mine is ignoring whatever is sent.
What does your getColorChgCmds method look like? Mine doesn't take any parameters, so it doesn't use the $col value.

/** Light Color */
private List setLightColorInternal(col) {
log("DEBUG", "+++++ setLightColorInternal ${col}")
def cmds = []
sendEvent(name: "lightColor", value: "${col}", isStateChange: true, displayed: true, descriptionText: "Color set to ${col}")
getColorChgCmds()
}

private List getColorChgCmds() {
def cmds = []
int blinkCnt = device.currentValue("lightColor").toInteger()
if (blinkCnt > 14) blinkCnt = 14;
if (state.lightCircuitsList) {
cmds.addAll(blink(state.lightCircuitsList, blinkCnt))
}
cmds
}

I tried fixing it myself and failed.

[keithriley]

@kmheid, the "set" function performs a sendEvent for lightColor which should immediately be reflected if that attribute is retrieved, such as in the start of the "getColor" (currentValue). You should also see that in the list of "current States" on the right side of the Device page for the Pool Control. See if that value changes when you do the set.

You are right that the result of the get is a List of commands, essentially X number of OFF then ON commands for the selected channel (where X is the selected color).

Feel free to post a log of calling the set.

[keithriley]

@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.

[rickyturner]

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!

[rickyturner]

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.

[keithriley]

@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.

[rickyturner]

@keithriley

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.

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.

[rickyturner]

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!

[keithriley]

@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?

[keithriley]

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

[rickyturner]

@keithriley

@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?

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.

[aarony]

Does anyone have the child switches working? I would love to get the VSP switches to work.