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.
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
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
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?
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 .
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.
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...
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"?