Aeotec Z-wave multisensor 6 (ZW100-A) v1.10

I’m trying to figure out why my Aeotec multisensor is not working in openhab. When I add it as a thing, it shows up as an “Unknown device”.

The sensor is running version 1.10 of the firmware. I updated to that firmware before I ever added the device to openhab. After some troubleshooting, I noticed that support for this firmware was added 6 days ago ( To get support for the latest firmware I’ve updated to openhab 2.3.0-SNAPSHOT (by running runtime/bin/update 2.3.0-SNAPSHOT).

As far as I could tell, this should work, but for some reason it’s not.
I’m new to openhab, and not too familiar with the inner workings of the z-wave binding.

First off, is this working for anyone else?

I’m guessing for some reason my device is not matching the identifying information in the DB. How do I see what the device is sending out for identification, and what in the DB should I compare it to?

Any other suggestions how to troubleshoot this?


Have you woken it up? During the initialization of a battery device (assuming it’s not plugged in) you may need to wake it repeatedly. There are several of us that use this device in our systems.

Push the dot on the back, that should trigger it to wake up.

I’ll try that. The device shows up, but it shows up as “Unknown device”.

Are you using the latest firmware on the sensor (v1.10)?


So, what are the steps? Do I keep waking it up before I add it as a thing, or after?

Is that all it says, or does it have some numbers after this? If that’s all, then it probably just needs waking up. If it has some other numbers etc after the unknown label, then it might mean the database needs updating.

This is how it shows up after I add it as a thing:
Z-Wave Node 48 ONLINE
Unknown Device

I tried to wake it up, before after and during creating the thing. Did not seem to make a difference.

Does it have a string of characters after it like the following?

Z-Wave Node 31 (015D:6100:6100:1.1)

No, it did not.

I just removed the batteries, and plugged it in to USB power. Now it’s being recognized.

Thanks for your help, and being so responsive. It’s amazing for an open source community. I don’t think I could have gotten this quick answers from professional support.

Right, it likes to go to sleep. Also there is a nice little feature that if you first power it off of usb because you want to play with it at the bench, then it will configure it for wall power not batteries and vis a versa. There are several postings about that little monster in the forums. Once they settle in, they are great little devices. Note that once PIR activated, they will not reset until the timeout expires (~4 min). Take your time and they will do great for you. They take 20 minutes or so to initialize and report the sensors.

Waking up Multisensor 6.

In order to configure Multisensor 6, you must either (1) wake up Multisensor 6 using the below button press function, or (2) temporarily put your Multisensor 6 on USB power.

  1. Press and hold Multisensor 6 Action button

  2. Wait until the RGB LED turns into a Yellow/Orange Color

  3. Release Multisensor 6 Action Button

The LED on Multisensor 6 will now rapidly blink its Yellow/Orange LED while it is in its awake state. You may send in any configurations or commands from your current gateway to configure your Multisensor 6.

  1. Tap the Action Button on Multisensor 6 to put Multisensor 6 back to sleep, or wait 10 minutes. (recommended to manually put it back to sleep to conserve battery life).

Here is some motion detection fun to get you started. Note that I have a globabl NightState that is set with another rule.

var Timer myTimer_KT_Motion = null
val int timeoutMinutes = 5

rule "Kitchen Motion Detection"


   Item Motion_1 changed to ON


   logDebug("KTMotion", "Motion detected in the Kitchen")

//   if ( NightState.state==OFF ) {
   if ( NightState.state==ON && Lt_FR_Table.state==OFF ) {

      if ( myTimer_KT_Motion==null ) {

         logInfo("KTMotion", "Motion detected in the Kitchen turning on lights for {} minutes.", timeoutMinutes)

         myTimer_KT_Motion = createTimer(now.plusMinutes(timeoutMinutes), [|
         logInfo("KTMotion", "Timer expired turning off lights")
         myTimer_KT_Motion = null
      else {
         logInfo("KTMotion", "Motion detected in Kitchen rescheduling timer, adding {} minutes.", timeoutMinutes )

Awesome. That was the next thing that I was going to look at.

Out of curiosity, why are you not using the motion off event to shut the lights off. That’s what I used with my previous controller (mostly because it was not as flexible as this). The timeoutMinutes variable in your code would be equivalent of the “Motion Sensor reset timeout” property on the sensor.

I think that the Timer approach give flexibility to set to a duration longer than the reset. I do recall that I could get into a state where if the timer was shorter than the motion sensor that the lights would go out and not be triggered properly. So without thinking about this too much I’m trying to avoid a race condition. Plus I started with an example of code too, so other smart people figured this out originally.

I have 9 of these, all rules relaying on the sensors sending OFF. I have never experienced a missing OFF event so that approach is robust.

Would you please share and describe what you mean by sending OFF?

This multisensor doesn’t actually send an OFF when motion stops. It sends OFF after a predetermined timeout occurs. It is parameter 3, Motion Sensor Timeout Reset. Default: 240 seconds. So it’s not reporting when motion stops, it simply waits 4 minutes and then reports Motion OFF. So from from a programming and action standpoint you have a decision. Is 4 minutes your desired timeout, or longer, or shorter. Where you have issues is if you want a shorter timeout (assume 3 minutes), then you have a non sensing window of 1 minute in a default configuration. You can drop the timeout to 180 to match, but what if you still have motion in the room at 3 min 1 second and you are switching lights off of the Motion state. The lights will turn off on you until motion is triggered again. If you go with a longer Timer than Motion timeout, then you have a buffer of time that the sensor has to realize there is still motion. Then the timer is reset for another interval. Two ways to approach this problem, I think using the sensor motion state as your switch is not a perfect scenario.

I’m simply saying that I don’t use other timers than the one in the sensor controlled by param3: Motion Sensor reset timeout.
Shortest setting I use is the default 240s=4min. Longest I have is 1200s=20min. (no detection in the shower :slight_smile: ).
This timeout equals the time the sensor waits after the lasts detected motion, until it sends an OFF event.

I have never experienced cases were the lights are not turned off.

Sample item:

Switch GarageMovement { channel = "zwave:device:f180343d:node51:sensor_binary" }

Sample rule:

rule "MotionGarage"
        Item GarageMovement changed

        logInfo("Motion", "GarageMovement.state=" + GarageMovement.state)
        if (GarageMovement.state==ON) {
            GarageMotionTimeOn.postUpdate( + " (" + + ")")        	
            sendCommand(BuildInGarageLight, ON)
        } else {
            GarageMotionTimeOff.postUpdate( + " (" + + ")")        	
            sendCommand(BuildInGarageLight, OFF)        	

I have no doubt that the lights if triggered by the motion (OFF), that they will indeed turn off as expected. However, your understanding of the timeout appears to be incorrect. And even the manual vaguely words this part. Good news is you can test this very easily. I would suggest a short timeout like a minute for your testing though to save time.

The timeout does not start counting from last motion sensed. The timeout immediately begins counting from the moment of first motion activation. So if you have a timeout set to 1 minute, and you trigger the motion detection. The clock will immediately begin a countdown. You can dance around like a monkey for up to 59 seconds, but if you stop prior to 1 minute the Motion OFF will be sent at the end of initial 1 minute.

What I have tried to do is eliminate the short lag between timeout and next motion sensed. So using a timer set to a interval longer than the motion timeout allows for the device to sense and reset without the short lights off monent.

That is strange.
I have worked in my garage for hours without the lights going off, so in my experience, every movement restarts the timer.
One setting I change though is param5:

Could that be what does the trick?

I doubt it is parameter 5. But then again, I don’t fully understand the standard/difference. I believe it is simply which channel you’re listening to, and what the sent command is. They both seem to trigger at the same time in my world.

This difference may just be in the way that the sensor behaves when under battery vs. usb power.

Difference between usb and battery power and recommendations multisensor 6 ZW100

In my testing, I used the following item and rule to create a countdown timer that I surfaced as an Number in HABPanel. You need to set your var count = to the seconds that your motion timeout is set to. Then you can monitor the countdown and the Motion state. If your countdown timer expires long before the Motion is set to OFF, then you are seeing something different than I.


Number  Kitchen_Countdown       "Kitchen Countdown Timer [%d]"


rule "Countdown1"
    Item Kitchen_Motion changed to ON
    var count = 60
    while(count >= 0) {
        count = count - 1

All my sensors are on USB power.