Justin, I'm still on ST (v3.05) so I can't test your scenario, but I'm confused about how your system is controlling temps. I don't recall: do you have/use a PE953 remote?
I use ST (and will soon use HE) to set the temp. From that point, it's the PE653 that controls my heater. If the temp goes above the setpoint, then the heater turns off using the basic functionality of the PE653. Where your scenario confuses me is the control point for turning off the heater. Is it the PE653 or HE? Does your PE953 show the setpoint correctly? If that's the case, at least in my system, then how it gets set (either by the PE953 or St or HE) doesn't matter; the PE653 should be controlling the heater.
Yeah, command MultiInstanceCmdEncap doesn't exist in the multichannelv3 class in the ZWave spec
Your choices are:
hubitat.zwave.commands.multichannelv3.MultiChannelCmdEncap
or
hubitat.zwave.commands.multiinstancev1.MultiInstanceCmdEncap
and if that command really does work in another environment, it's a bobo...
I just published version 3.0.6 of the DTH that makes the temperature change events visible. There are three separate events (Water, Freeze, Solar). You should be able to subscribe to these in a SmartApp or include them in your RM logic.
Also, hopefully this time I got all the Hubitat conversions right. Let me know. Here it is:
@mike.maxwell, I can't argue with you there. Funny that ST even allows that. That one was easy. I do have two other ongoing compatibility issues/question though:
Why did HE choose to use different naming for the zwave classes? In other words, why use "hubitat." rather than "physicalgraph."? It seems arbitrary and prevent pure source compatibility with ST. You are SO close...
When you implemented the addChildDevice method, why implement different parameters than ST? In my DTH I have to alternately comment in/out the following lines. Perhaps you can guide me to a compatible common implementation?
// SmartThings
addChildDevice("erocm123", "Switch Child Device", dni, null,
[completedSetup: true, label: name,
isComponent: false, componentName: "ep${childNo}", componentLabel: "Switch ${childNo}"])
//Hubitat
// addChildDevice("erocm123", "Switch Child Device", dni,
// [isComponent: false, name: "ep${childNo}", label: "Switch ${childNo}"])
Don't get me wrong, I love what you guys are doing, I just don;t get why you stopped at 99.9% compatibility?
2572018-09-22 17:57:19.068:errorgroovy.lang.MissingMethodException: No signature of method: hubitat.device.HubAction.startsWith() is applicable for argument types: (java.lang.String) values: [delay] (on5)
i believe there's a bug in the delayBetween statement.
In the last update we check the last command that exists in a series of Z-Wave commands, if it starts with "delay ", we remove it, since no command follows, it just ties up the thread.
If the entire command string can be dumped to live log before it's returned it should be easy to verify this.
@mike.maxwell, I understand your explanation of the optimization, but I don’t get the connection to the “missingMethod” exception being thrown. Near as I can tell, this occurs after the command has returned and is somewhere in Hubitat while parsing the command list. I would think this code should protect itself from the type mismatch that seems to be occurring.
The only thing the slightest bit unusual I can think of in my command list is that I include HubAction commands directly in order to create the ManufacturerProprietary command class, which is required to control this device.
@JDogg016, one thing that Mike might prefer is to add another debug statement near the end of delayBetween that just dumps the actual response list (in addition to the formatted debug that we have now). If that is not clear let me know and I can give you the actual code and location to insert it.
I did purchase a Hubitat and have it fired up but have not yet moved my PE653 over to it.
Keith, when you do move it, it would be a great help to me if you will document the unpair/pair steps. I've still not recovered from the trauma of pairing the PE653/PE953 to ST for years ago. Thank you!
@JDogg016, Scroll all the way to the bottom of the DTH and insert the [log.debug "delayBetween=$evts"] line where you see it below (9 lines from the bottom):
if (evts) {
if (debugLevel >= "0") {
log.debug "<<<<< rspFlg=${responseFlg} dly:$dly/${DELAY}${evtStr}${devStr}"
}
log.debug "delayBetween=$evts"
evts
} else {
if (debugLevel > "5") {
log.debug "<<<<< rspFlg=${responseFlg} dly:$dly/${DELAY} No Commands or Events"
}
null
}
}
