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.
No, he didnāt provide any documentation at all but from conversations with him it sounded like it converted them from proprietary to standard.
Is there a way to query the 653 to see what commands it responds to? If not, I may just fall back to 3.4 and try and make progress there.
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
I've been messing around with the 3.0 DTH and my main issue revolves around the creation of the child devices, as mentioned previously. I can get them created if I change this line:
addChildDevice("erocm123", "Switch Child Device", dni, null, [completedSetup: true, label: "${name}",
isComponent: false, componentName: "ep${childNo}", componentLabel: "Switch ${childNo}"])
to this:
addChildDevice("erocm123", "Switch Child Device", dni, null)Otherwise I get this error:
addChildDevice failed: groovy.lang.MissingMethodException: No signature of method: dev1531023368173126233545.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, 07-ep5, null, [label:Switch 5]]Given my lack of experience with groovy, any help would be appreciated.
@kmheid - I have the iboot file from Frank. I also have a Windows XP 32bit VM that I created specifically for updating the Multiwave so it's not a huge problem to go back and forth.
Give this a try:
addChildDevice("erocm123", "Switch Child Device", dni, [isComponent: false, name: "ep${childNo}", label: "Switch ${childNo}"])
Here is the documentation regarding Hubitat's implementation of Composite Device Drivers. You should be able to make some minor tweaks to the original code to make it work with Hubitat.
I had a cell phone number for Frank, so tried it: "The customer you are calling is not accepting calls.".
Checked with the Intermatic folks and they confirmed Frank is retired (cell phone was company-issued). They also were adamant that v3.7 or v3.9 were specialized firmwares for apartment installations and to stay on v3.4. I pressed - hard - for any documentation on Z-Wave commands but came up empty.
That did seem to resolve the issue I was running into creating the child devices but commands still don't seem to be working. I tried turning on switch 3, which is my pool light, and get this in the logs:
2018-07-09 10:24:17.485:debug<<<<< rspFlg=false dly:1000/1000 <<<<< HubAction: MultiInstanceCmdEncap(command:1, commandClass:37, instance:16, parameter:[255]), delay 1000 <<<<< Dev cmd: MultiInstanceCmdEncap(command:1, commandClass:37, instance:16, parameter:[255]) --> 6006102501FF <<<<< HubAction: VersionGet(), delay 1000 <<<<< Dev cmd: VersionGet() --> 8611 <<<<< HubAction: delay 1000, delay 1000 <<<<< HubAction: 8611, 8611 <<<<< HubAction: ManufacturerSpecificGet(), delay 1000 <<<<< Dev cmd: ManufacturerSpecificGet() --> 7204 <<<<< HubAction: delay 1000, delay 1000 <<<<< HubAction: 7204, 7204
[dev:177]2018-07-09 10:24:17.483:tracel -> 7204
[dev:177]2018-07-09 10:24:17.482:tracel -> delay 1000
[dev:177]2018-07-09 10:24:17.481:tracel -> ManufacturerSpecificGet()
[dev:177]2018-07-09 10:24:17.480:tracel -> 8611
[dev:177]2018-07-09 10:24:17.479:tracel -> delay 1000
[dev:177]2018-07-09 10:24:17.477:tracel -> VersionGet()
[dev:177]2018-07-09 10:24:17.475:tracel -> MultiInstanceCmdEncap(command:1, commandClass:37, instance:16, parameter:[255])
[dev:177]2018-07-09 10:24:17.474:debug<<<<< rspFlg=false dly:1000/1000 <<<<< HubAction: VersionGet(), delay 1000 <<<<< Dev cmd: VersionGet() --> 8611 <<<<< HubAction: ManufacturerSpecificGet(), delay 1000 <<<<< Dev cmd: ManufacturerSpecificGet() --> 7204
[dev:177]2018-07-09 10:24:17.472:tracel -> ManufacturerSpecificGet()
[dev:177]2018-07-09 10:24:17.471:tracel -> VersionGet()
[dev:177]2018-07-09 10:24:17.469:debug+++++ refresh() DTH:Ver 3.00 state.Versioninfo=Versions: Firmware v3.7 DTH: Ver 2.06 zWaveLibraryType: 6 zWaveProtocol: v2.78
[dev:177]2018-07-09 10:24:17.462:debug+++++ setChanState(16, 255)
[dev:177]2018-07-09 10:24:17.458:debug+++++ setVSPSpeedInternal() speed=1
[dev:177]2018-07-09 10:24:17.453:debug+++++ cmdFromChild: childNo:7 val:255
[dev:177]2018-07-09 10:24:17.452:debugchildOn called in parent: dni=07-ep3 channelNumber(dni)=7@CAL.hub, you got a more complete answer than me (I just emailed). The response they sent me when I asked if there was any way to get the 3.9 firmware was "Unfortunately that software will not be released. We apologize for any inconvenience."
That makes me think they are just going to kill the product line. What a waste. At least @keithriley has managed to work around the 3.4 firmware limitations for ST, and it sounds like you all are close to getting Hubitat working equally as well. Purchasing a Hubitat is worth it to me just to get this thing working properly. I can't wait to try it.
Thereās something very odd going on in the very bottom line of the trace. It does confirm that you are activating switch three, note āEP3ā , but for some reason itās parsing out the 07 instead of the three, which leads it to believe you pressed the VSP1 switch. Iāll take a look at that sometime tomorrow to see whatās going on.
More than likey the cose was written for behome247's product line to give them the features they wanted. Not sure if there are issues with that aspect. Behome247 has a customized vera product they use for their property management portfolio. This is prolly why Vera will no longer support the standalone product.
@magicshot that makes a lot of sense. I had seen mention of Intermatic's work for behome247 before, but never took the time to see what it was. Thank you for connecting the dots.
I have heard that 3.9 works very well with Vera, but it had to be applied in the factory and is impossible to get now that Frank is gone. Without it (or someone with enough knowledge to work with 3.4), I guess the PE653 will never work properly with Vera or behome247. Shame.
@CAL.hub, could do me a favor and take pictures of each of the configuration screens on you remote? Be sure to get all the sun screens on the 5043 and the heater. There is some difference between yours and mine as your 653 is being sent the same command as me but itās being ignored.
Just out of curiosity, iām Located in Orlando. Where are you?
I'll try to get the screen pics to you this morning, but it might be later today.
I'm in Winter Springs. Are you far?
I'm in Windermere near MK. Probably about 35 min drive. Small World. Maybe I could come by with my Sniffer and capture some ZWave traces...
I'd be happy to host you here. Any way at all that I can be useful to the project. (I'm friends with the Windermere mayor. But most people that the USPS calls "Windermere" aren't actually in the corporate City limits of Windermere.)
Here are some pics of my PE953 configuration screens.
I really don't see why Hubitat Groovy would act differently, but give this a try. Find this function and remove the "-":
private channelNumber(String dni) {
dni.split("-ep")[-1] as Integer
change to:
dni.split("-ep")[1] as Integer
See if that changes the behavior. This line was picking up a 7 when it should have gotten the 3.
Good afternoon. At what point do you want me to start testing your new device?
I tried this and it seemed to fix the 3/7 mix-up but the child devices still don't actually do anything.
I downgraded to 3.4 FW so that I could test like for like. I reverted to the 2.06 driver and that seems to work, although I can't turn on switch 5 for some reason. I might need to completely reset the config on my 653 after downgrading, which I didn't do.
@JMack89427, Would you put some new traces for me please?
Are you using the same modified code as @JDogg016? I believe he was achieving device control. Is yours working OK from the device directly, but only the child devices are nonfunctional? Or not achieving any control at all? If one is working and the other is not, please put the traces of both. Thank you.
Download the Hubitat app
