ZW100-A MultiSensor 6 and motion detection

For test purposes i changed the wakeup-period of the ZW100-A to 300.
Now everytime my device wakes up it sends a change of motion.

here is my item definition:
Contact Multi1_motion "Motion [MAP(]" { zwave="11:command=sensor_binary,respond_to_basic=true" }

on here is my rule-file:
rule Test2Alarm
Item Multi1_motion changed from CLOSED to OPEN then
logError("test ", Multi1_motion.toString())

pushover (Multi1_motion.toString())

my question is, do i have to turn off wakeup completely?
or do i have to change something else to only get a notification,
if a REAL motion was detected?


To turn wake up off you set it to 0. It should not be sending a motion detect when it wakes up though, which is a little weird.

Dear Chris,

have you had success with the motion detection? My sensor seems to always set motion detected to true if it is dark in the room. For test purpose I put it into a box and it set the value to un until I take the sensor out of the box…


Can’t remember what I did, but i think after a complete reset and re-include
everything worked as it should…

Also, set config parameter 101 to 241 to make sure all sensors are enabled.

Thanks. It seems to work for me now. I set parameter 5 to “Send Sensor Binary Report CC” and I use the channel “Binary Sensor”

I’m in this crazy OFF ON cycle on one of my MultSensors. Do we have any reliable info on why this is happening?

Debug logs are a wonderful source of reliable information :wink: . I would suggest to get the log and display it with the log viewer.

I’ve done that, I’m not finding anything other than it IS sending those additional events. Messaged you directly earlier today with a section of log. I was asking about the v1.8 database config.

Ok - sorry, I’ve not picked that one up yet (been a busy night sorting out some alarm issues).

I understand, I know you’re in high demand. I’m just hesitant to modify the v1.8 version.

From a quick look at the log it does look like the device is indeed sending these messages rather quickly (as you said). I don’t see that this is a database issue though, and I don’t think that change of the parameters is going to impact this (one appears to be related to the LED and the other is a temperature threshold (it also looks like the database is consistent for these parameters, so I think it’s correct).

So, not really sure why it’s doing this…

Just pasting in the log you sent for future reference -:

I had set the Motion Sensor reset timeout down to 60 seconds (240 default) for testing. There is a bug report on the v1.7 firmware that is related to reporting quickly.

Parameter 111-113 report interval bug

If sensors are reporting around 4 minutes, it is possible that the sensor may send the signals 4 times in a row causing the battery to be used rapidly (users who have done this have seen battery drain within 2 weeks). (bug)
Can be set to a minimum 240 seconds without the need to set the wakeup interval for faster reports (but is receptive to the bug above at reports <10 minute intervals)

I’ve reverted the Sensor to firmware v1.7, and now the Tamper and Motion Channels are available (issue with v1.8 db entry lack of Tamper Channel being defined). but the Motion (Alarm Report) continues as soon as the reset timeout expires it immediately reports motion again, and thus the Binary Report is triggered as well.

Going Crazy!

And now it works!? Mid day today, I removed the Sensor from the Controller and Re-added it. It now is Node 27. I Added the Thing through HABmin, still no joy through most of the evening. I Deleted it again and re-added it through PaperUI. I performed all of the Re-Linking as normal. NOW it works! I cannot tell what is different. There was a rather verbose section of logging that reported all of the configuration section. I have that log saved.

Still Going Crazy!

I guess there’s a bug in the device that was resolved with the full reset (ie the exclusion) - I guess so long as it’s working now.

I’d suggest if it happens again to speak to Aeon - their support manager (another Chris) is very responsive.