Enerwave RSM2-Plus: child device not functioning

[drostocil]

On a new Hubitat C-7, the enerwave-rsm2-plus.src driver is not working. The log shows the switch action happening infinitely:

dev:4182020-08-06 11:11:59.569 pm debugParsed SwitchBinaryReport(value:0) to [['name':'switch', 'value':'off', 'type':'digital'], hubitat.device.HubMultiAction@ad6499]

In the def zwaveEvent(hubitat.zwave.commands.switchbinaryv1.SwitchBinaryReport cmd, ep=null) the ep will always be null, even when the action is invoked by a child element. That results in the code following the else path which makes a recursive call to SwitchBinaryReport.

I never see a call to def zwaveEvent(hubitat.zwave.commands.multichannelv3.MultiChannelCmdEncap cmd). Some quick googling indicates this version might be deprecated, but the documentation is not much help. This leads me to believe this is no longer supported?

I have been unsuccessful in my attempts to resolve this on my own.

[erocm123]

There are so many versions of this device and I don't use any of them anymore LOL.

Which version and which firmware do you have? I just posted an update to one of the drivers that should set a multi-channel association differently if you are using that version. You will have to exclude it and include it again though.

[drostocil]

I have the Enerwave RSM2-Plus (the driver you updated), and Hubitat is reporting its using firmware version 5.10.

I excluded and included the device with your latest update but am still seeing the same issue.

On a potentially related note, I noticed getCommandClassVersions is not being passed to zwave.parse on line 78 and cmd.encapsulatedCommand on line 171. I've updated that locally and it does affect the log output a bit, SwitchBinaryReport now has some additional values passed into it:

     `SwitchBinaryReport SwitchBinaryReport(value:255, targetValue:0, duration:0) - ep null`

[ellomdian]

I have the 5.12 version, fresh out of the box from Amazon, and I can confirm the same behavior. The child devices do not update successfully, and it feels like some kind of multicast issue. The switch status for the parent device toggles back and forth if you turn one on and leave one off.

[drostocil]

@ellomdian

I've commented out the def zwaveEvent(hubitat.zwave.commands.switchbinaryv1.SwitchBinaryReport cmd, ep=null) method and moved the logic to the childOn/childOff methods:

`def childOn(String dni) {
logging("childOn($dni)", 1)

ep = channelNumber(dni)

def cmds = []
cmds << new hubitat.device.HubAction(command(encap(zwave.switchBinaryV1.switchBinarySet(switchValue: 0xFF), channelNumber(dni))), hubitat.device.Protocol.ZWAVE)
cmds << new hubitat.device.HubAction(command(encap(zwave.switchBinaryV1.switchBinaryGet(), channelNumber(dni))), hubitat.device.Protocol.ZWAVE)

def childDevice = childDevices.find{it.deviceNetworkId == "$device.deviceNetworkId-ep$ep"}

if (childDevice)
    childDevice.sendEvent(name: "switch", value: "on")

cmds << createEvent([name: "switch", value: "on"])

cmds

}
`

`def childOff(String dni) {
logging("childOff($dni)", 1)

ep = channelNumber(dni)

def cmds = []
cmds << new hubitat.device.HubAction(command(encap(zwave.switchBinaryV1.switchBinarySet(switchValue: 0x00), ep)), hubitat.device.Protocol.ZWAVE)
cmds << new hubitat.device.HubAction(command(encap(zwave.switchBinaryV1.switchBinaryGet(), ep)), hubitat.device.Protocol.ZWAVE)

def childDevice = childDevices.find{it.deviceNetworkId == "$device.deviceNetworkId-ep$ep"}

if (childDevice)
    childDevice.sendEvent(name: "switch", value: "off")

cmds << createEvent([name: "switch", value: "on"])

cmds

}`

Clearly a short term hack, but at least the device behaves as expected now.

[ellomdian]

More elegant than my fix, I've been trying to tear apart the SwitchBinaryReport call all morning without a sniffer to better understand multicast.

Also, it's noticeably faster, so that's a win.

I'm brandy-new to Hubitat programming, but I'm curious if best-practice with their parent-child design is to load the logic for the switch status on the parent device or the child. It updates the child, but it runs on the parent?

Either way, this gets me through the day, thanks! Going to just dump this into my fork and come back to the driver if I get really bored.

[drostocil]

Glad that worked for you. I'm also new to Hubitat. I did not expect to be looking at device driver code!

Also, thanks @erocm123 for maintaining this extensive library.

[ellomdian]

If you have a C7, and if you're as new as I am I assume you do, there's apparently firmware issues with the zwave radio.

I'm going to hold off on any more zwave troubleshooting until the guys who do it for their day jobs are done with it ;)

[lgkahn]

not working fo rme in hubitat c7 i get this error.

dev:3282020-08-13 03:30:58.397 pm debugon()
dev:3282020-08-13 03:30:54.036 pm debugchildOn(34-ep2)
dev:3282020-08-13 03:30:53.314 pm debugchildOn(34-ep1)
dev:3282020-08-13 03:30:19.677 pm debugoff()
dev:3282020-08-13 03:30:18.266 pm errorjava.lang.NullPointerException: Cannot invoke method split() on null object on line 605 (childOff)
dev:3282020-08-13 03:30:18.235 pm debugchildOff(null)
dev:3282020-08-13 03:29:58.153 pm debugon()
dev:3282020-08-13 03:29:53.413 pm debugon()
dev:3282020-08-13 03:29:47.885 pm debugon()

[mgroeninger]

Hi,
I don't know much about zwave but I think I see two things that are creating problems in the driver.

First is that update_needed_settings() checks state.fw for the firmware version, which is never set. I added "state.fw = fw" to the VersionReport zwave event to fix that.

Second is that firmware 5.12 seems to report the version for class:0x60 as 4:
infoCommandClassReport- class:0x60, version:4

This means replumbing the hubitat.zwave.commands.multichannelv3.MultiChannelCmdEncap events and updating the command class version.

I put a multi-version gist of the file that is working for me at: https://gist.github.com/mgroeninger/30ed78ef55b3a4f2f503b834ae55f602

It's clunky and probably won't survive another firmware update, but it atleast works for me in 5.12.

Thanks!

[lgkahn]

i am not sure where this is coming from but i am using this driver for the switch in hubitat.. and dont worry about what firmware version.. it does not create child devices..   working fine for me..   https://github.com/lgkahn/hubitat/blob/master/zw15sm.groovey     ---- Original Message ---- From: "Matt Groeninger" <notifications@github.com> Sent: 1/17/2021 2:08:37 PM To: "erocm123/Hubitat" <Hubitat@noreply.github.com> Cc: "lgkahn" <kahn@lgk.com>, "Comment" <comment@noreply.github.com> Subject: Re: [erocm123/Hubitat] Enerwave RSM2-Plus: child device not functioning (#15) Hi, I don't know much about zwave but I think I see two things that are creating problems in the driver. First is that update_needed_settings() checks state.fw for the firmware version, which is never set. I added "state.fw = fw" to the VersionReport zwave event to fix that. Second is that firmware 5.12 seems to report the version for class:0x60 as 4: infoCommandClassReport- class:0x60, version:4 This means replumbing the hubitat.zwave.commands.multichannelv3.MultiChannelCmdEncap events and updating the command class version. I put a multi-version gist of the file that is working for me at: https://gist.github.com/mgroeninger/30ed78ef55b3a4f2f503b834ae55f602 It's clunky and probably won't survive another firmware update, but it atleast works for me in 5.12. Thanks! — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.