Generic Z-Wave Motion Sensors stopped working with 2.1.5

All of my Monoprice Generic Z-Wave Motion Sensors stopped working after upgrading to 2.1.5.121 (from 2.1.4.130). The Generic Z-Wave Motion/Temperature Sensors all continued to work.

I rolled back to 2.1.4.130 and they all started working again.


Which Monoprice sensor do you have? For what it's worth, I have one of the "plain" motion sensors (PID 1527) and it still works for me with the Generic Z-Wave Motion/Temperature driver. I don't have the 4-in-1 device (their other model) to see if that works for me.

The Motion/Temperature ones were still working - I have 4 of the ones that don't have Temperature (detected as just Generic Z-Wave Motion Sensor) - those stopped working. I think they were PID 10796

can you enable debug logging in the driver, then post the logs for the device after triggering a motion event?, thanks.

@mike.maxwell - I'll update the hub again this afternoon and post the logs for you. Thank you!

Mark

I meant from platform 2.1.4, this may tell me what's missing in 2.1.5...

ok - here ya go:

dev:422019-10-01 12:01:59.645 pm debugparsed 'zw device: 1E, command: 3003, payload: 00 , isMulticast: false' to []

dev:422019-10-01 12:01:59.640 pm infoMotion - Kitchen is inactive

dev:422019-10-01 12:02:39.089 pm debugparsed 'zw device: 1E, command: 3003, payload: FF , isMulticast: false' to []

dev:422019-10-01 12:02:39.082 pm infoMotion - Kitchen is active

Thanks @mike.maxwell

well so far at a loss on this, no changes in this driver or zwave in 2.1.5, if you wouldn't mind trying providing the same info on 2.1.5 when you have a chance, that would be great, thanks.

Here ya go Mike....This is with 2.1.5.123:

dev:422019-10-01 01:20:27.763 pm debugparsed 'zw device: 1E, command: 3003, payload: 00 , isMulticast: false' to []

dev:422019-10-01 01:20:27.744 pm debugSensorBinaryReport(sensorValue:0)

dev:422019-10-01 01:17:11.194 pm debugparsed 'zw device: 1E, command: 3003, payload: FF , isMulticast: false' to []

dev:422019-10-01 01:17:11.187 pm debugSensorBinaryReport(sensorValue:255)

dev:422019-10-01 01:16:49.775 pm warndescription logging is: true

dev:422019-10-01 01:16:49.773 pm warndebug logging is: true

I do not see the INFO messages in the log with 2.1.5.123...could this be why my rules aren't working?

Going to roll back to 2.1.4 - Thanks for looking into this @mike.maxwell - much appreciated.

Mark

1 Like

yes, that's why it's not working, but as of this moment I have no explanation for this...

@mike.maxwell, wasn't there a change in the Generic Zwave motion sensor driver in 2.1.5? You did SOMETHING to that so that it no longer gives me duplicate active/inactive reports with my Ecolink motion sensors (which is now working perfectly for me!) Perhaps that change is somehow causing his problem?

1 Like

yeah, I can't keep track of what's what, there's been reports of zooz 4 in 1 issues, and there weren't any changes to that driver...
The non reporting issue seems to be for the older non plus models...

I had a similar issue after upgrading to 2.1.5 but a day later I realized in 'Z-Wave Details' page that Z-Wave Status was mysteriously disabled. After enabling it everything worked fine again for me, anyway.

Thanks @zskwrel - I thought that shut off the Z-Wave radio altogether - Did all your Z-Wave devices stop working? I just have the 4 Motion Sensors (out of 8) that stopped.

Z-Wave Status (D) - Use the drop-down menu to enable or disable the Z-Wave radio. When you have selected the status you want, click update .

https://docs.hubitat.com/index.php?title=Z-Wave_Details

I too had my motions sensors stop working. So is this the fix or will there be a new firmware. I rolled it back to get them working again.

As far as I could recall, everything Z-Wave stopped working until I re-enabled that setting.

@zskwrel

I noticed that you're using "All Secure Z-Wave"

The general recommendation is to securely join only z-wave locks and garage door openers because it is my understanding that secure z-wave uses a lot more traffic than non-secure z-wave. And the additional traffic slows down the z-wave network.

It also does nothing but exacerbate what most consider excessive latency in zwave motion reporting to begin with...

On a good day with a perfect mesh it will add at least 60ms to the reporting latency...

On a bad day with a spotty mesh you'll never get the event...

1 Like

I agree, I'm curious though why this option is even available to users to select? Is there any use case at which you would recommend users have it set to "all secure zwave"?