Thank you for the info seems to be working
1 Like
If I started over and installed the previous version. Joined the 'spare' MS6, let it sit for a couple mins to acquire all the values....
Then install v1.7 of the driver. If I then clicked Configure, indeed, I was able to reproduce. It's strictly an upgrade phenomenon.
I moved one line of code from here to there and it fixed it. So I'll push it to github as a 'patch' if nothing else comes up in a day or so. 
1 Like
Does enabling selective reporting mean that if temperature changes 2 tenths of a degree a report will be sent despite what the interval report is set to? That’s what I think/thought it means but doesn’t seem to be working that way for me. I figured temp change amount would throw a report automatically
Thanks for that was driving myself crazy user error of course.
@csteele Hey,
I've been using your driver but had some issues with the LEDoptions.
I set them to 'fully disable' but the bedroom sensor (and all others in fact) kept beeping at me throughout the night.
Checked your driver and checked the specsheet and you set 'fully disabled' to a value of 2 but the spec sheet (for firmware 1.13) only lists 0 (fully enable) and 1 (fully disable) as values (on motion detection). ?
Not sure if you fixed this already in 1.7 (using 1.6) but just wanted to give you a heads up.
I've modified your driver extensively so don't want to update but figured I'd share this bit in case it hadn't been noticed yet by yourself (I hate that it auto-hides the 'extra' options so I removed that from the driver code)
thanks..
v1.10 of the spec shows the 3rd option.
Didn't exist prior, might not exist in v1.13, but certainly, is no longer documented with a 3rd option.
The choices in the driver were created for v1.10 and seem correct.
The choices for v1.13 are 'subjective', for sure.
The docs alter where: "pir is triggered" is found. I'm not sure I want to split those hairs. 
I think I'll change the words so that "1" is picked more often than not.
I'll also work to add "Never Hide Preferences" option:
1 Like
Cool.
I guess the 'most correct' thing to do would be to make the driver firmware agnostic by exposing only the options/availability of the firmware loaded on the specific device it's driving... but ofc that sounds like a lot of hassle haha!
I like the permanent preference selection idea.
On another note, I cant seem to get the LED status to update on any of mine. I have five of them and I just updated all of them to firmware 1.13
Even when they are all set to the same settings I have one that reports the PIR with motion and the other 4 do not. It doesnt matter what I set the LED preference to on the device page, nothing seems to change the behavior.
I figured it out.
Looks like you need to add the "as int" to that parameter, must be to ambiguous, after changing the driver that option is updating properly.
zwave.configurationV1.configurationSet(parameterNumber: 81, size: 1, configurationValue: [ledOptions as int]),
Oddly enough when I look at the logs before and after the code change they show the exact same value being sent.
2020-06-18 12:04:46.375 am debugSending Z-wave command: ConfigurationSet(configurationValue:[0], defaultValue:false, parameterNumber:81, reserved11:0, size:1)
What I observed when changing the value was that Fully enabled was turning the led green when motion was triggered and when the timeout was done, When disable for motion was selected the led never came on. Selecting disable fully resulted in no change from the current state it was previously in. So a 2 in version 1.13 doesn't appear to be valid.
Does the LED do anything different in the earlier firmware versions?
do you by chance have the extracted firmware for this? It'd be great if you did.
I’m not home but will check later. I probably do.
The latest firmware I have is v1.13 and yes it's extracted. What are you looking for?
you can also find the firmware here:
Does anyone know how to reset the tamper status on the Aeotec Multisensor 6? Does it reset after a given amount of time? I have mine running of USB and it seems to stay in "detected" status forever...
In the Smarthings driver it seems that you can clear the tamper status but neither the built in or the @csteele's driver have that option.
Tamper can't be cleared or reset. The Aeon spec shows the word "tamper" in one place...
..as a Notification.
@ericm driver over on ST doesn't actually clear the tamper ON the Multisensor, it just clears it on the hub when you click the button.
1 Like
Thanks - it looked like it was “stuck” for me, but I just toggled drivers (from yours to built in and then back) and now it appears to clear the tamper notification after some time (don’t know exactly how long) 
For "my driver" it's 100% at the behest of the Multisensor itself. It sends that "Home Security" notification packet and if the value is 0x00 then BOTH are reset/cleared.
Let's imagine changing the battery.. the Multisensor would probably see Motion followed by Tamper... then after putting the Multisensor back where it lives, it would send a 0x00 to say both motion and tamper have cleared after the motion timeout. Because the one 'cleared' event covers both motion and tamper, tamper can't clear til motion has ceased for the timeout duration.
1 Like
Makes sense now - the sensor is in a fairly high traffic area and that would explain why the tamper is cleared after different (at what appeared to be random) intervals.
Hi all,
I'm having a few issues with my zwave mesh (every device stops responding about twice a day and they only start responding when I shutdown and restart HE), and today I noticed the below error in my Logs on my Aeotec MS6 which uses the built in driver at exactly the same time as all my zwave devices stopped responding. Does anybody know what the below error could imply (and how I could fix it)?
errororg.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'null' with class 'null' to class 'short'. Try 'java.lang.Short' instead (parse)
