Intermatic PE653RC MultiWave Z-wave Pool/Spa/Home Control

[Silentcossack]

Hi, I'm back. I've spent some time trying to figure out a way to have some interaction between this spa controller, the remote that came with it and Homeseer. They just don't like each other enough. So while messing around, I managed to wipe out my network a couple of times, but here's where I am today:

I put the pe953 (the remote control that came with the spa controller) as the primary controller on my network. Homeseer is the secondary controller. This way at least, I can still use the remote to have full control over all the spa functions and use Homeseer's api calls to monitor the spa temperature and trigger relay 1 on and off. Still borderline useless, but best I can get.

I tried to use the homeseer thermostat plugin api to try and set the setpoint on the pe653 with no luck. As mentioned above, the plugin has issues with this thermostat, so I used the api. I was able to get further - I changed the mode to heat (from off) and was able to set the heat setpoint to whatever temperature I want. Homeseer UI's confirm these new settings. All good, right? Wrong! For some odd reason, the pe953 handheld does not reflect the new setpoint temperature and still displays the old setpoint. Changing the setpoint on the pe953 remote changes the spa controller, but does not get reflected in Homesee. So either homeseer does not actually change the setpoint on pe653 or it is not the heat setpoint value that I"m supposed to be setting on pe653 but some other variable that might not be available through the thermostat api.

This is probably as far as I can get on my own. I'll be happy to try other stuff if somebody has ideas.

[Rick Tinker]

You can have any controller be primary or secondary, and use either controller (while it is primary) to add nodes to the network. Switching back and forth between primary and secondary is done through replication, which you can do from the Manage Z-Wave Controller page.

In trying to make things simple, HomeSeer (just like the controller that came with the pool control) adds an association from any node that supports association, back to HomeSeer. This is for status notifications. So, you can add the node with the controller that came with the pool system, and then switch the primary back to HomeSeer and that will work fine. You can even add it with HomeSeer, and then add the associations yourself manually so that BOTH HomeSeer and the pool/spa controller get the notifications from the other node. Associations do not have to be issued from a primary controller.

So, what it seems like is happening with the changes not showing up in both places is this: For one thing, you are getting associations set up from the source node to the pool controller OR HomeSeer, but never both. If you set up the association to both, then both should get updated. However, to prevent Z-Wave "loops", a node does not send a status update when it is controlled through Z-Wave. Thus, if HomeSeer sends a setpoint to the device, then HomeSeer will update its knowledge of what the setpoint is, but even if the pool/spa controller is associated with the other controller, it will not get an update because it was changed with a Z-Wave command. This is why in HomeSeer, we have polling - it allows for HomeSeer to "ask" a device periodically what its status is automatically.

So, while the thermostat functionality in HomeSeer is not set up to represent this device properly in the UI, it sounds like you are able to control it OK with script commands, and so with this knowledge of associations and things perhaps you will be able to get it set up and working the way you want.

Note: There is an action in events called "Z-Wave Action" which has an action type of "Poll Node" - it allows you to poll a node at an interval that you specify (by the triggering of the event) - it may be helpful.

[Silentcossack]

Hi Rick, thanks a million for replying and following up with ideas. I really appreciate it. You can imagine that's its tough being a consumer between two companies where you are told by both that it's the other one that's not up to par. The truth is probably in between as usual, so I appreciate the extra attention both you and Intermatic are providing me with this issue.

As I mentioned, I've been a developer for years and now mainly develop home projects. I wrote a fully custom UI for my house and have automated many things, some of them through Zwave, using Homeseer. I'm not afraid to try things that some regular customers might not want to. So I welcome all ideas.

You are correct, I was able to transfer primary controller status from pe953 back to homeseer with no issues. pe953 still sees the spa and is able to control. Homeseer still shows the same stuff as before, including temp.

I'm not convinced that my setheat commands are actually going to the spa receiver. I say that because even if it is just an issue with a "status refresh" as I believe you indicate, then the poll device command should resolve that in Homeseer. For example, on the pe953 the setpoint shows as 50F. I raise it to 60F. From then on, it says 60F on the pe953. Then I poll the device (like 5 times) from homeseer. Retrieving heat set point from api returns 0C (32F), not 60F. If I use the API to set the heat point from Homeseer to something like 35C (95F), then Homeseer ui shows 35C from then on. Using API to read back the heat set point returns correctly 35C. However, going back to the pe953 remote, it still shows the old 60F. So it's as if Homeseer remembers the setting internally, but the device never actually changes it's setpoint.

Also, I managed to wipe out the spa devices from homeseer's ui and do the "rescan devices (full)" command, the status for the spa thermostat resets to off mode, instead of heat, with a setpoint of 0C. So if the set heatpoint command actually went to the device, shouldn't the mode remain heat and setpoint be 35C?

Finally, another strange thing that started happening is that as mentioned, the spa has a root device, with child devices (see above). The child devices show up as type "z wave switch binary", which is correct (though I cannot trigger them as inidcated above). The weird thing is that that status string for 2 of the binary switches shows up as a temperature, instead of the expected on/off status. The termperature does not match the spa temperature, and the two switches have a different temperature between them as well = very strange. I posted a screen shot here:
http://www.box.com/s/usyh2ql9h2s4mp4274q9

Not sure if the problem is just associations or if the communication is off somehow?

Cheers.

[Rick Tinker]

After learning about the device and how it was created, I am not denying that it is our fault in this case. Of course, having been inundated with devices that don't give ANY consideration to a controller like HomeSeer, it is unusual that we are the ones at fault, but it does happen. It is because we do not support a relatively new (new to being used, that is) command class that does associations to sub-instances of a node. In this case, there are 5 relay devices, and normally we set up an association to HomeSeer to get status information, and we can control the instance devices without any problem. Here, I suspect that HomeSeer can control these devices (turn them on/off) but the device cannot report to HomeSeer because it does not support that command class. Thus, let's say relay 3 was turned on - in the first place, HomeSeer would not be notified because it could not set up the association to it because of that command class not being supported. If it did get a notification, HomeSeer would see it coming from the main node number of the device, and would not be able to know which instance (relay 3) that it came from. So, operate any of the 5 relays and if there is ANY notification going on or status being updated, it is probably with the one non-instance device regardless of which relay changed.

So we can handle the various instances (multi-channel) for the different switch binary devices, but we cannot set up the associations to them.

[Silentcossack]

What I'm observing is a slight variation on what you've described. I am able to get the status in Homeseer from these sub-nodes, but I cannot control them by using Homeseer. So if I use the pe953 to turn on relay 5, and doing a poll in Homeseer, I see relay 5 status turn on in Homeseer. However, if I use Homeseer to turn on relay 4 let's say, then it is always relay 1 that turns on, on the actual device. This seems to indicate that Homeseer can get the proper status for sub-nodes, but not control them, as the command always goes to the root node (or first node, not sure exactly).

Do you still believe that this will get addressed in HS3? Any chance of an update in HS2 somewhere down the road?

Thanks.

[Rick Tinker]

Do you still believe that this will get addressed in HS3?

Definitely. We have to support the command classes that are at issue with this device right now.

Any chance of an update in HS2 somewhere down the road?

Definitely... NOT. HS2 is stable enough that we are trying to cease all development on it so we can focus on getting HS3 out. We do not intend to support both products, so HS2 will only get critical fixes/updates until such time as HS3 is well on its own two feet.

[Silentcossack]

Hi. Now that it sounds like you guys are fairly close to a beta of HS3, can you please confirm if this device will work in it?

Do you need an alpha/beta tester? I would imagine not too many people have this thing lying around.

Thanks.

[rjh]

Probably not the initial version. I don't have a date for this right now.

Hi. Now that it sounds like you guys are fairly close to a beta of HS3, can you please confirm if this device will work in it?

Do you need an alpha/beta tester? I would imagine not too many people have this thing lying around.

Thanks.

[Silentcossack]

I see a bunch of updates to HS2, including multisensor support in update 2.5.0.58. Is there any chance that this will also solve my problem in this thread?
Thanks.

[Silentcossack]

Hi, is there any news on supporting this device? HS3 seems to never be coming out and I still can't do anything in HS2.

Appreciate any updates.

Thanks.

[Rick Tinker]

HS3 is currently in the hands of 3rd party developers so they can update plug-ins.

[Silentcossack]

Hi Rick. I'm confused. If you read a little higher, you wrote: "We have to support the command classes that are at issue with this device right now." This sounds like the device is using proper standard zwave classes that Homeseer currently does not support. Why would a third party develop a plugin for this device, if it's using standard zwave that Homeseer doesn't know yet? Should this not be something that the Homeseer develops, rather than a third party?

[Rick Tinker]

The first thing you wrote was that HS3 seems to never be coming out, and I was pointing out that it is currently in the hands of 3rd party plug-in developers, so it is in an early stage of the release process.

[gearyt]

Just trying to get status on this thread as I am interested in installing one of these in my SpA as I rebuild it.. Come on HS3 !!!

[gearyt]

OK.. Another bites the dust..I ordered one with the idea that HS3 would solve any issues...
It would have cost me almost as much to repair the existing controller as to purchase this new one..

Thanks for another place to spend my $$