Z-Wave Multi Channel (PE653)


We do not currently handle mixing HubActions with String commands and HubAction delay does not work at all. I would recommend changing those lines using HubAction to just return a String instead.

ie this:

	def cmds =[
		new hubitat.device.HubAction("910005400102870301"),
		new hubitat.device.HubAction("910005400101830101"),
//		new hubitat.device.HubAction("91000541010100"),

becomes this:

	def cmds =[
//		"91000541010100",


@keithriley Just realized I did not reply to the prior thread personally to you so you may not have seen it.


FWIW, @CAL.hub, I just unlinked from SmartThings and switched my PE653 over to Hubitat.
Steps were:

  • delete all devices
  • navigate (I used the ios App):
    More icon > Home> Gear Icon > Z Wave Utilities > General Exclusion

or just search for 'smart things general exclusion'.

Then, it paired trivially!


@keithriley Hi, we've emailed a little bit - I've finally taken the plunge and moved over to Hubitat, with your 3.06 driver. I'm a professional software developer and while currently Groovy-ignorant, I'm looking forward to helping out here.

If you had even half an hour to give me a general tour, I can start helping out here. DM me if you'd like.

Thanks for all your great work here, I'm so glad to see the back side of SmartThings!


Thanks @chuck.schwer - I haven't seen a response from @keithriley yet, but if I understand correctly:

the refreshCmds should all be failing with them as HubActions?


The problem is the mix.. its returning an array with some being HubActions and some being Strings. For Zigbee and ZWave, the best way to do it is to use Strings for all the commands.


Makes sense, given how Groovy dispatches methods! I can make that change. Thanks!


Thank you. Did you also pair the the PE953 remote?


No - mine went mad and started sending spurious signals, so I took it out behind the woodshed and put it down. I've replaced it entirely with my phone and, once I get this working, Siri control!

I would expect you could pair it as a 'secondary controller' - or maybe even pair it to the Hubitat itself, and use it to control arbitrary scenes (I'm not sure). But I found it a clumsy control and decided not to bother.


Thanks @chuck.schwer - by standardizing on strings, I've gotten this to start working somewhat. It begins to report information and poll the 653 successfully.

I'm finding that even though I have the erocm123 / Switch Child Device installed (and used successfully by another device), I'm getting this, which occurs when the devObj is null.

dev:1292018-10-04 20:23:50.425:warnCME: CAN'T FIND CHILD DEVICE: 06-ep5:switch5
dev:1292018-10-04 20:23:50.406:warnCME: CAN'T FIND CHILD DEVICE: 06-ep4:switch4
dev:1292018-10-04 20:23:50.401:warnCME: CAN'T FIND CHILD DEVICE: 06-ep3:switch3
dev:1292018-10-04 20:23:50.395:warnCME: CAN'T FIND CHILD DEVICE: 06-ep2:switch2
dev:1292018-10-04 20:23:50.382:warnCME: CAN'T FIND CHILD DEVICE: 06-ep1:switch1

The first time I paired the iNovelli switch, I had to power cycle it a few times to get it to 'find' the child objects. But this time, that's not working. I'm going to keep banging at this code, hoping to understand it better, but I'd love any suggestions!

Update: I uncommented the code and forced it to run updated. I also updated the namespace for the erocm123 driver - it's now iNovelli in his repo. Success! Or at least they are created. Updates still fail in createMultipleEvents, saying no update is necessary.

I've realized I have firmware 3.3, which makes me apprehensive - am I doomed? Or worse, doomed to have to mail it to Intermatic?


@CAL.hub, I paired the PE953 remote. I am on version 3.4 of the firmware. I started trying to document exactly what I did, but there was some trial and error involved and I can't say exactly what steps ended up working. It was some variation of old procedures from the MiCasaVerde and ST forums. It was basically copying the config from the primary controller, but it wasn't exactly intuitive and took me a few attempts.
I'm sure you will figure it out. If you get stuck, I will do what I can to help. It is possible, and if I have to do it again, I will make sure I take good notes next time.


Thanks @chuck.schwer. I've made your suggested changes in a pull request at: Correct HubAction Strings & by tooluser · Pull Request #1 · HubitatCommunity/hubitat-zwavemultichannel-pe653 · GitHub

I've also started to make some other changes, like trying to switch to the new namespace for the child switches.

I'm currently not getting any child switches to work, though, and I'm wondering about the firmware. I'm on 3.3. Has anyone with v3.3 gotten this to work, even intermittently? I'm finding it reports the temperature and switch state, but never sends updates properly.

Here's the text of the PR as it is right now. I would love some commentary from anyone (eg @keithriley ) who knows what's going on!


The DTH is currently not working AFAICT. Take some advice from various people in the thread to attempt a fix.

Implementation Details

  • Per @chuck.schwer, don't mix String s and HubAction s. Standardize here on Strings.
    • (I'd love to constant-ize these strings, but I don't know what they mean)
  • Standardize logging by using log levels rather than conditionals
    • This may not be working, so I may introduce a _log method to DRY up that behavior
  • Make SmartThings/Hubitat condition code-based so no code need be commented out
  • May attempt to upgrade to new namespace for the child switches ( iNovelli )
  • Attempt to simplify child-creation code and move to initialize


Can you say more about why this is necessary for control? I've tried switching to all strings as suggested, and a number of things began working better, but I still can't set any values - I'm wondering if this is part of the reason, though I don't follow why.

With them there, I still see this same failure when clicking "On2". (Note I changed it to call setAndGet, so there are two commands.) The parameter in the setChanState value as generated is null, which seems wrong. (The command class for the set is is 32 (0x20), which the documentation says is for 'basic' - should this be (0x25), 37, for switch, like the get?)

dev:1302018-10-06 21:17:17.294:debug----- cmds: [
    MultiInstanceCmdEncap(command:1, commandClass:32, instance:2, parameter:[null]),
    MultiInstanceCmdEncap(command:2, commandClass:37, instance:2, parameter:[])
dev:1302018-10-06 21:17:17.292:trace----- getChanState command: MultiInstanceCmdEncap(command:2, commandClass:37, instance:2, parameter:[])
dev:1302018-10-06 21:17:17.285:debug+++++ getChanState(2)
dev:1302018-10-06 21:17:17.283:trace----- setChanState command: MultiInstanceCmdEncap(command:1, commandClass:32, instance:2, parameter:[null])
dev:1302018-10-06 21:17:17.281:trace+++++ setChanState(2, 255)


When I implement your device 3.07 I see this in the logs and I still cannot get the VSP to turn on.

[dev:257]( 09:06:31.374:errorgroovy.lang.MissingMethodException: No signature of method: hubitat.device.HubAction.startsWith() is applicable for argument types: (java.lang.String) values: [delay] (setVSPSpeed4)

[dev:257]( 09:06:31.231:debug<<<<< rspFlg=false dly:1500/1500 <<<<< Dev cmd: MultiInstanceCmdEncap(command:1, commandClass:37, instance:19, parameter:[255]) --> 6006250113FF, delay 1500 <<<<< HubAction: 910005400102870301, delay 1500 <<<<< HubAction: 910005400101830101

[dev:257]( 09:06:31.206:debug+++++ setVSPSpeedInternal() speed=4


Anything? I don't have the remote anymore so I rely solely on this implementation to run my pool pump and its been 2+ weeks.


Hi @JDogg016 - do you mean my 3.07a? I named a branch that, riffing off of Keith's, but it's very much in flux and not active anywhere (I thought!) as I bang on it. Or is there another 3.07?


Are you running this version? I dont see anything in the code that would create a HubAction:


So I have now installed that particular code. I see no error in the logs, however only on/off works. No other functions of the device (ie. VSP 1-4, on2/off2 etc...) seem to work. Update it does seem that the temperature reading of the pool works.****

Here are some logs.

[dev:257]( 07:30:22.565:debug<<<<< rspFlg=false dly:1500/1500 <<<<< Dev cmd: MultiInstanceCmdEncap(command:1, commandClass:32, instance:4, parameter:[null]) --> 6006200104NULL, 910005400102870301, 910005400101830101

[dev:257]( 07:30:22.547:trace----- setChanState command: MultiInstanceCmdEncap(command:1, commandClass:32, instance:4, parameter:[null])

[dev:257]( 07:30:22.495:trace+++++ setChanState(4, 255)

[dev:257]( 07:26:02.242:debug<<<<< rspFlg=false dly:1500/1500 <<<<< Dev cmd: MultiInstanceCmdEncap(command:1, commandClass:32, instance:4, parameter:[null]) --> 6006200104NULL, 910005400102870301, 910005400101830101

[dev:257]( 07:26:02.229:trace----- setChanState command: MultiInstanceCmdEncap(command:1, commandClass:32, instance:4, parameter:[null])

[dev:257]( 07:26:02.198:trace+++++ setChanState(4, 0)

[dev:257]( 07:24:59.948:debug<<<<< rspFlg=true dly:1500/1500 <<<<< Event: [name:airTempFreeze, value:81, unit:F, displayed:true, isStateChange:true] <<<<< Event: [name:airTempSolar, value:0, unit:F, displayed:true, isStateChange:true] <<<<< Event: [name:clock, value:14:28, displayed:false, descriptionText:PE653 Clock: 14:28]

[dev:257]( 07:24:59.897:warnCME: CAN'T FIND CHILD DEVICE: 38-ep6:poolSpaMode

[dev:257]( 07:24:59.894:debugcreateMultipleEvents: devObj = null

[dev:257]( 07:24:59.891:debug+++++ createMultipleEvents( endpoint:6, name:poolSpaMode, externalParm:0, myParm:off)

[dev:257]( 07:24:59.889:warnCME: CAN'T FIND CHILD DEVICE: 38-ep10:swVSP4

[dev:257]( 07:24:59.886:debugcreateMultipleEvents: devObj = null

[dev:257]( 07:24:59.883:debug+++++ createMultipleEvents( endpoint:10, name:swVSP4, externalParm:0, myParm:off)

[dev:257]( 07:24:59.881:warnCME: CAN'T FIND CHILD DEVICE: 38-ep9:swVSP3

[dev:257]( 07:24:59.878:debugcreateMultipleEvents: devObj = null

[dev:257]( 07:24:59.876:debug+++++ createMultipleEvents( endpoint:9, name:swVSP3, externalParm:0, myParm:off)

[dev:257]( 07:24:59.873:warnCME: CAN'T FIND CHILD DEVICE: 38-ep8:swVSP2

[dev:257]( 07:24:59.871:debugcreateMultipleEvents: devObj = null

[dev:257]( 07:24:59.868:debug+++++ createMultipleEvents( endpoint:8, name:swVSP2, externalParm:0, myParm:off)

[dev:257]( 07:24:59.865:warnCME: CAN'T FIND CHILD DEVICE: 38-ep7:swVSP1

[dev:257]( 07:24:59.863:debugcreateMultipleEvents: devObj = null

[dev:257]( 07:24:59.859:debug+++++ createMultipleEvents( endpoint:7, name:swVSP1, externalParm:0, myParm:off)

[dev:257]( 07:24:59.856:warnCME: CAN'T FIND CHILD DEVICE: 38-ep5:switch5

[dev:257]( 07:24:59.853:debugcreateMultipleEvents: devObj = null

[dev:257]( 07:24:59.850:debug+++++ createMultipleEvents( endpoint:5, name:switch5, externalParm:0, myParm:off)

[dev:257]( 07:24:59.847:warnCME: CAN'T FIND CHILD DEVICE: 38-ep4:switch4

[dev:257]( 07:24:59.845:debugcreateMultipleEvents: devObj = null

[dev:257]( 07:24:59.836:debug+++++ createMultipleEvents( endpoint:4, name:switch4, externalParm:255, myParm:on)

[dev:257]( 07:24:59.833:warnCME: CAN'T FIND CHILD DEVICE: 38-ep3:switch3

[dev:257]( 07:24:59.831:debugcreateMultipleEvents: devObj = null

[dev:257]( 07:24:59.829:debug+++++ createMultipleEvents( endpoint:3, name:switch3, externalParm:0, myParm:off)

[dev:257]( 07:24:59.826:warnCME: CAN'T FIND CHILD DEVICE: 38-ep2:switch2

[dev:257]( 07:24:59.823:debugcreateMultipleEvents: devObj = null

[dev:257]( 07:24:59.819:debug+++++ createMultipleEvents( endpoint:2, name:switch2, externalParm:0, myParm:off)

[dev:257]( 07:24:59.817:warnCME: CAN'T FIND CHILD DEVICE: 38-ep1:switch1

[dev:257]( 07:24:59.815:debugcreateMultipleEvents: devObj = null

[dev:257]( 07:24:59.803:debug+++++ createMultipleEvents( endpoint:1, name:switch1, externalParm:0, myParm:off)


@joshua, there is something going wrong in setChannelState. The log shows correct values coming into the function, but when it creates the multiinstanceCmdEncap, the parameter list is created as NULL. It should be either zero or 0xFF. I’m not looking at the code at the moment but something changed as this was working fine previously. When the cmd is “formatted” (AKA turned into a string) the null is placed in the resulting string and is certainly confusing the PE653. This is the root of the control problem.

The whole premise of the ST/HE model is to avoid commands as string constants as use the command classes instead. Unfortunately, there does not appear to be a command class method for ManufacturerProprietary, which is why I used HubAction (attempting to avoid string constants). If HE would add a method for this the code could be consistent.

I would also prefer to use conditional code as opposed to comments, but because the class names are different between ST and HE, it won’t even compile the code which would never be executed, thus the comment approach.

Thanks for your assistance on the HE side. I just haven’t any time lately.


I'm not sure I follow on this? You were still creating string constants, just wrapping them in HubActions.

I will put in a ticket for this to be added.

It's probably better to just permanently fork the code with a Hubitat version because it can get very messy attempting to keep one code base for both.