Yeah, I saw that last night as I was putzing with this. I took that code and ripped out the ST-specific things and ended up with something that could be imported but I get this error:
2018-07-06 08:32:22.681:errorgroovy.lang.MissingMethodException: No signature of method: dev1530850441002332493349.getRefreshCmds() is applicable for argument types: () values:  Possible solutions: addRefreshCmds(java.util.List) on line 1380 (off3)
I'm sure that my messing around inside the code likely didn't help I'm also on an unreleased firmware so that could be causing some issues as well. Either way, I'm making progress and excited by the community involvement around this!
Hey @JDogg016, haven’t heard from you in a while. Was curious if you got the new FW. I know you tackled a lot of the conversion issues, and I’d like to try to incorporate as many as possible into my new common code base. If you’d like to share your latest code version, I could compare it from your starting point to identify the changes. Hope all is well.
This got me to the point that, when combined with the Child Device driver you included in your documentation, I could create the 5 child devices but I had to leave off the properties map because it was causing this error:
2018-07-06 12:55:54.979:warnaddChildDevice failed: groovy.lang.MissingMethodException: No signature of method: dev15308996994941700326168.addChildDevice() is applicable for argument types: (java.lang.String, java.lang.String, org.codehaus.groovy.runtime.GStringImpl, null, java.util.LinkedHashMap) values: [erocm123, Switch Child Device, 06-ep5, null, [completedSetup:true, ...]]
The only real issue was that the child devices, along with the parent device, didn't actually do anything. I'm not sure if this has anything to do with the firmware I'm running but your 2.06 has almost everything working, except even with a set point it won't turn on the heater.
Let me know if I can provide any additional information.
My pleasure! FWIW, this code works well (enough) in HE with minimal exception. For some odd reason now I have to turn on switch 5 to turn on the pool heater as it is no longer controlled exclusively by temperature.
Thanks you @JDogg016 and @keithriley (and others) for your contributions to this forum (and the ST forum).
It looks like you got things working with Multiwave that nobody else has (at least not that I have seen). I have given up trying to get this to work with Vera. I'm coming over to Hubitat. I hope I can help in some way, and I hope Hubitat stays involved.
I doubt the issue was ever with the Vera platform itself, but rather the challenges we have faced with the undocumented nature of the Intermatic implementation. Sure, they document the basic Z wave capabilities, but there is so much more that they embedded into proprietary messaging that is necessary for an efficient interface. Luckily, most of that is now behind us and I have a good understanding of what it takes to make the PE 653 behave (In most cases).
Don’t get me wrong, I really like the Intermatic product and I applaud them for embracing an open communication standard like Z wave. I just wish they would have provided a bit more documentation and support for us users trying to use their controller from a remote device other than their handheld (which is the only thing they support).
Hopefully our successes will lead to greater sales of their product and an ever increasing user community. Welcome to habitat!
Circuit 5 is normally configured to control the heater. It provides the 24 VAC for the fireman's switch on most heaters. I'm not sure how you guys are using it with ST, but I use circuit 5 to control the heater with Vera. Was the logic you used before just automatically activating circuit 5 when certain temperature conditions were met?
I have heard that Intermatic has a newer version of the firmware (3.9) that gives Vera complete control of all features, but Intermatic is not releasing it to the public. As far as I know, there is not even a way to purchase it from them, but perhaps they are installing it for commercial applications?. That's the version Frank was promising that I was waiting for to make Vera work, but now it seems it may never be released.
I don't understand why firmware would be specific to a controller (like Vera), unless the firmware was working around limitations/design of the controller. You all seem to have found a way to work with the 3.4 version that is publicly available to do everything you need/want with ST and Hubitat. Is that correct? Is there anything that Intermatic isn't exposing that you need to make it fully functional?
I have the P5043ME expansion module, so my heater control is connected to that, and I use circuit five to control a spa light.
@CAL.hub, i’m guessing that you don’t have the expansion module, and your heater control is wired into circuit five. This should be automatically controlled by the 653 based on temperature, but the fact that you have to turn on the circuit five manually suggests to me that your configuration may have changed. Have you double checked that you have the Heater enabled? Check your 953.
@kmheid, the DTH has never had any special logic around circuit 5 or heater control, that’s why I can’t see why @CAL.hub would see any change in behavior with the new version.
To your other question, I am pretty happy with the v3.4 functionality now that I have reverse engineered the proprietary messaging. I sure hope they didn’t change any of that on v3.9.
I can't speak to the 3.9 firmware but the 3.7 firmware Frank Pomeroy gave me changed a TON on the Vera platform. The thermostat function started working like it does via the remote where the setpoint would actually activate switch 5 when the water temp was below the setpoint. The only problem I had with it is that Vera actually told me that they wouldn't support the Multiwave any longer, regardless of the firmware.
@kmheid - I emailed Frank a few weeks ago about sharing the 3.7 firmware with the community and I haven't heard back. He was adamant that I not share it last year though.
I was able to trace the remote and that’s how I figured out how to control the VSP properly, get air temperatures and receive push notifications, all via undocumented functions. I’m wondering if the 3.7 simply documented these functions? Or if it implemented Them in a standard Z wave format instead of proprietary?
Did Frank provide you any documentation with the firmware? That’s the thing I would be most interested in even more than the code itself.
Don't lose the 3.7 firmware; you may not be able to get it again.
Did Frank just sent you a file with the 3.7 firmware, or did you have to send your entire unit in so they could apply it? I saw someone say they had to send their unit in to get 3.9, but Intermatic won't do it anymore.
There is only a broad capability to inquire the command classes. However, it is likely that the new functionality is implemented simply as extensions to command classes that were already implemented. For example, the multi channel command class implements control over the five switches. That much which documented . I later learned that the multi channel commands were also used to control the VSP and pool/spa mode, but the channel numbers were unexpectedly high values. There is no way to deduce this from any information you can retrieve from the device.
However, even if they created extensions to the command classes for all the previously proprietary functions, I doubt they would De-implement the proprietary versions. This would just create more work for them to re- design the remote. As a result, it seems likely that the 3.7 May still work with the newest 3.0 DTH. I would at least give it a try before reverting back to 3.4