Aeotec Multisensor 6 - motion sensor not working

Thanks for the comprehensive reply, @Toneus. I’ll try out your suggestions.

Apologies for no response over last few days, was off the air for a short while.



Thanks @evansnp, glad to hear that it does work. Now all I have to do is get mine into the same state! :slight_smile:


Well, I think I’ve finally got to the bottom of why I cant see any motion sensor events or any tamper events on the Multisensor 6.

In summary, the ZwaveThingHandler which seems to be responsible for converting any alarms from the sensor itself, only ever switches alarm_burglar or binary_sensor to ON. It is never set to any other state. It is initialised to ON and only ever updated to the ON state when an alarm event is received via z-wave.

As I thought that this might be version-dependent, i.e. already fixed, I have done an apt-get update and an apt-get install openhab2 and retested however there appears to be no change.

Incidentally, I captured the attached screenshot showing two devices in the Control interface of PaperUI. Interestingly the Aeotec ZW112 Door sensor comes up with a “-” when it does not know the state of the device. That swiftly changes to “OPEN” or “CLOSED” when it is updated. The ZW100 Multisensor does not have anything against Burglar Alarm or Binary Sensor, there is no unknown state to be updated. Happy to supply this screengrab if it is of value.

I have captured debug logs however they are probably too big to put into this forum. @Toneus or anyone else, could you please advise who might be responsible for maintaining ZwaveThingHandler and I will happily share the logs and what I have done to get to this conclusion.

This doesn’t sound right, and sounds more like a device/configuration issue. It should set it’s own state back to Motion OFF. You could open an Issue on @chris Jackson’s Z-Wave database page, but something is not right. Did you upgrade your firmware on the device? What Firmware Version is on the device? My sensor is on FW v1.7. You can see which FW version by using the HABmin UI which can be enabled via the PaperUI or config file. In PaperUI, go to Add-ons / User Interfaces and Install it.


You can save your log locally, and then use the ZWave Log Viewer online. That will simplify the review and you may be able to take a screenshot of the offending sections.

Here are the main parameters for my Multisensor.

Yes @Toneus, I agree. It doesnt sound right So I’m struggling to believe what I am seeing in the logs.

The firmware on the device looks good, here are the attributes:


So in the log, the testing scenario followed was to include the Multisensor 6 at 14:49. At 15:09, the tamper was triggered by shaking the sensor then at 15:16, the motion detector was triggered. In both cases, the green LED on the front of the sensor did turn on to indicate that it had been triggered.

First, the initialisation (filtered for Node 38):

Then the tamper trigger:

Finally, the motion trigger:

Here is the current config:

Note that the motion sensor reset timeout was deliberately reduced to 60 seconds (at the suggestion of Aeon Labs) while testing.

Finally, a shot of how the things look in the Control tab of the PaperUI, note that there is no ON, OFF or dash (indeterminate) status for the Binary Sensor or Burglar Alarm:

Full logs are available for detailed analysis. I’d be very interested to find out why the apparently working sensor does not seem to be able to indicate any change of status into the OpenHAB 2 things and items.

Please note that I’m going to have limited time to do any more testing in the coming week due to other commitments however I should be back on the case after that.

I would suggest to try the development version which significantly changes the way the notification command class events are processed.

If it doesn’t work with that version then please post the logs again and I’ll have a look.

Many thanks @chris, have downloaded the JAR flle.

Could you advise where I can find the instructions to install this binding? I’m still getting up to speed with OpenHAB and the details of how to install and maintain it.

The first 6 or 8 messages in the thread above provide an overview. It’s also possible to install it from the marketplace.

If you are in contact with Aeon, then I would ask for the 1.7 firmware, revert and test. I have had to revert one of their LED Color lights with success. It’s worth a try to verify you don’t see a difference.

I would definitely take Chris up on his request.




Still not able to see any change to the Binary Sensor, Tamper Alarm or Motion Alarm fields for the Aeotec ZW100 Multisensor 6 however the logs do show these events may be being passed via the new version of the binding.

Note: everything on the Raspberry Pi 3 seems to have slowed significantly, browser loads take a long time, tail-ing the logs is very stop/start. It looks like the binding may be loading the Pi up significantly.

Could you advise if the implementation method below is correct? If not, what did I get wrong? Happy to correct and re-test.

Apologies @chris for the delay in getting around to this, have been off the net for a while. Hope you find all this information useful.

Method of implementation

  1. Deleted items then things for existing z-wave nodes, used PaperUI. Checked that they were also gone in Habmin
  2. Uninstalled the existing z-wave binding.
  3. Copied the above SNAPSHOT binding to the folder /usr/share/openhab2/addons
  4. Checked both Habmin and PaperUI and there was a z-wave binding in both, assume that this is the new 2.3.0 version (note: would be good if the version number was in the binding description that is visible in both PaperUI and Habmin).
  5. In PaperUI Inbox, scanned for things. The Razberry controller appeared first, added the serial port location (/dev/ttyACM0) and it came online.
  6. Re-scanned for other devices and after a few false starts, ended up with both the ZW100 Multisensor 6 and the ZW112 Door/Window 6 sensor as things.
  7. Checked parameters 3, 4 and 5 on Multisensor 6. These were set to 60 second timeout, most sensitive motion sensor and Binary Event for message type (see screenshot).
  8. Used Habmin to configure the channels / items.
  9. Checked in PaperUI items and all items are visible.
  10. Checked PaperUI Control and both the ZW100 and ZW112 were there. The ZW100 now has three alarm items – Binary Sensor, Tamper Alarm and Motion Alarm. None of which display state (see picture).
  11. Capture /var/log/openhab2/events.log and /var/log/openhab2/openhab.log. I have tried to run openhab.log through the log viewer but there seems to be some form of corruption that is making it unreadable.

Log files:

These are the attributes of the ZW100:

And here are the configuration parameters:

These are how the things look in PaperUI:

And they come up like this in the PaperUI Control screen:

Which version did you change to? Is this the master binding (installed through PaperUI) or is it the development version (ie the one with security). It looks like the master version - I just wanted to make sure that’s what you were expecting since above I recommended the development version and that’s not running here?

The log is not a debug log. You need to enable debug logging with the log:set debug org.openhab.binding.zwave command in Karaf. Without debug logging, the log won’t really show anything and this is likely the problem…

Good question, @chris, and I have to say I wasnt 100% sure myself. However a simple test of checking all bindings removied using the Add-ons screen in PaperUI then removing the org.openhab.zwave-2.3.0-SNAPSHOT file from the /usr/share/openhab2/addons folder showed that there were no bindings installed. Moving the SNAPSHOT file back into the /addons folder and the zwave binding showed up in the Configuration:Bindings screen in PaperUI. So I’m confident that the SNAPSHOT binding is the only one installed currently. Even though I cant see a version id in the narrative that describes the binding.
Next step will be to turn debug mode on for the logs and run through the device tests again. Then run them through the log viewer and see if I can capture some definitive data. I’m trying to fit this in around other activities so dont hold you breath, it may take a little while.

Good afternoon @chris, now that the version of the zwave binding confirmed as the SNAPSHOT version, onto the next steps…

Looking at the debug logs, it looks as if the motion and tamper alarms are now being seen by the zwave handler however they are not normally appearing in either /var/log/openhab2/events.log or openhab.log, unless the latter is set to debug.

The setup is little changed from that described above. The main differences are that I have had to delete and re-include both the Multisensor 6 and the Door/Window Sensor 6 more than once each. The Door/Window Sensor is useful and important as it reliably puts entries into the events.log, so I have been using it as a signpost, and a comparator, every time I trigger the motion and/or tamper alarms.

Now looking at the debug log, this shows the tamper alarm:

This shows both motion and tamper alarms:

And this one shows motion alarm only:

Apologies for the delay, its taken a while to get a clean set of examples. The devices themselves have not helped, I have had to reset and re-include both to get things working again.

The next step is to get them to do something useful, like trigger a rule. So I’ve been experimenting with this with absolutely no success whatsoever. Any input gladly received. Current rule text is:

In summary, if the door sensor is OPENed, then it should log an info message. If I can get that to work, I’ll change the comments and get it to sense the motion alarm status and/or get it to send a mail. Either action would be sufficient to prove that the Aeotec Multisensor 6 can be seen by OpenHAB.

Going back to my original question, I presume that items on the PaperUI Control screen have just not been instrumented to show the motion or the tamper alarms?

@RichardK, did you do a secure inclusion or not? If you wave your hand just in front of the sensor, do you see a green light or a blue light flashing shortly?
(Note, with the default settings, you should wait a few minutes to try again. There is a kind of delay built in, although you could reconfigure that)

Green light = insecure
Blue light = secure

I haven’t be able to have the secure sensor recognized in OH2 (neither 2.2.0, nor 2.3.0, nor 2.4.0 :face_with_raised_eyebrow:
When included insecure, it works pretty well (although configuration must be done manually, which is painfull)

@chris, is in the stable 2.3.0 security built in? And what about 2.4.0 ?

I’m running ZW100 Multisensor6 firmware version 1.11.

No - security is not included in 2.3 stable.

What do you mean? 2.4 should be built automatically as a snapshot now and should be available if you use the 2.4 snapshot runtime.

Thanks @chris for the fast reaction! :+1:

I meant: Is security included in 2.4.0?
(the version I downloaded at )

If not, what is the link to the development branch with the security built in?
I have seen many links in the forum but they are all old…

No - not quite yet…

If you go to the following link, the latest binding is always available from the link at the top of the thread -:

Hopefully in the next few weeks I will have this merged into 2.4 master.

1 Like

Hi @tonus
My Aeotec Multisensor 6 is included insecurely, I get a green flash from the LED when it senses motion.
Like you, I find that the device works pretty well (temperature, humidity, light level etc) once it has been successfully included however there are still no notifications for motion or tamper.
Meanwhile, I have got OpenHAB rules working pretty well and it is “in production” now, reacting to a door/window sensor and also turning on/off lights etc on a daily schedule. Just one or two more things to sort out and it is ready to take over from my old HA system.

Is that using the development binding? Please provide a debug log and I’ll have a look at what’s up.

No @chris, its still using the 2.2 production version. So the debug example I provided previously would still be relevant and I would expect the results to be unchanged.

I am intending to move to 2.3 shortly, I’ll retest at that point and provide updates.