search

erocm123 / Hubitat

52 stars 61 forks source link

Enerwave RSM2-Plus: child device not functioning #15

Open drostocil opened 4 years ago

drostocil commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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.