Aeotec Multisensor 6 - motion sensor not working

The motion sensor and tamper functions on the Multisensor do not work. The temperature, luminance, UV, humidity and battery functions all appear to be reporting as expected.

I’m running OH2 on RPi 3 with a Razberry zwave interface board. On top of Raspbian Linux.

Looking at events.log, the binary_sensor and the alarm_burglar turn on when the device powers up, when the battery is installed, but from that point no further notification is seen.

When I wave my hand in front of the sensor or shake it, the green light on the front of the device comes on, indicating that it has been triggered.

I’ve been through the other threads in the community, including the one by @scurrier03 about how to set up the device plus @chris and others that discuss the device and its limitations. I have excluded it and re-included it several times to no effect. Including restarting the device and rebooting the RPi several times.

I’m reasonably technical, just dont have the knowledge of how to view and interpret the zwave communications. Any pointers in this direction would be appreciated.

A side issue is that this is calling into doubt my use of the RPi plus OH2 as a low-power automation appliance however I’m sure that fundamentally this is the right approach. Any corroboration about the validity of RPi plus OH2 would be appreciated!

Hi Richard. I’ve been using a RPi 3, Razberry, and OH for over a year now, and can confirm that it’s rock solid.
I too have an Aeotec M6, and it works as expected, and is delivering motion detection updates thus:

2018-03-08 09:52:18.563 [vent.ItemStateChangedEvent] - ZWaveNode20ZW100MultiSensor6_BinarySensor changed from ON to OFF

2018-03-08 09:52:18.785 [vent.ItemStateChangedEvent] - MultiSensor6_AlarmBurglar changed from ON to OFF

2018-03-08 09:53:06.210 [vent.ItemStateChangedEvent] - ZWaveNode20ZW100MultiSensor6_BinarySensor changed from OFF to ON

2018-03-08 09:53:06.433 [vent.ItemStateChangedEvent] - MultiSensor6_AlarmBurglar changed from OFF to ON

I did have an issue with battery performance, but a firmware update cured this.

Richard, I have exactly the same observation here for some time now.
The PIR sensor was working before and for some days/weeks, it doesn’t.
The green LED is on when doing some movement.
PIR is reported as OFF all the time (I have a rule that is triggered by the update).
I have another sensor that works fine.
Could this be a hardware defect?

The Motionsensor 6 has a timeout when on battery. I think the default is 4 minutes. So you will get an initial motion reported, then you have to wait 4 minutes before it will sense and report the next motion. This is normal and expected. Check parameter 3: Motion Sensor reset timeout

Is this what you are seeing?

My Motionsensor6 is USB-powered.
The Sensor reset timeout is at 4 minutes, but I see no “on/active” at all.

First off, have you dropped the sensor? I had this misfortune once and the sensor was misbehaving. I had to open the device and realign a part or two. Is the plastic dome misaligned in any way?

Next, I would make sure that the Channel is correctly mapped. Are you defining yoru configuration in item files or one of the UIs?

Create a new test item in an item file.

Switch  Kitchen_Motion          "Kitchen Motion"
Switch  Kitchen_Tamper          "Kitchen Tamper"

Then map that new items to the Channels as well.

image

Tail your events log looking for these items.

Did you by chance reduce the sensitivity too much? Parameter 4

If none of these things help, then I would Delete the item from PaperUI. I would delete the zwave node#.xml file for the device. I would clear the cache and temp files

rm /var/lib/openhab2/zwave/<your_node>.xml

Stop the Openhab service

sudo rm -rf /var/lib/openhab2/cache/*
sudo rm -rf /var/lib/openhab2/tmp/*

Restart Openhab

The device should still be known by your controller, so re-import it from your inbox. After clearing the cache and tmp, the device should reinitialize clean. You might have to wake it up multiple times, or use the button on the back to put it in awake mode.
https://aeotec.freshdesk.com/support/solutions/articles/6000057073-multisensor-6-user-guide-
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).

If none of this helps, you can turn on DEBUG logging in the openhab console.

ssh -p 8101 openhab@localhost

Default password is habopen

At the command prompt you can tail the log.

log:tail

And you can enable DEBUG logging on ZWave.
http://www.cd-jackson.com/index.php/openhab/5-zwave-debugging-openhab

log:set debug org.openhab.binding.zwave

Thanks for the tips, I will have a look.

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.

Cheers

R

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

R

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.

image

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:

2018-03-17_1408_Multisensor_6_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.

Cheers!

Feedback
org.openhab.binding.zwave-2.3.0-SNAPSHOT

Summary

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: https://www.dropbox.com/sh/jea8f881dpqfu6k/AAB-bVtHv_r4bfvkjLN5JgNoa?dl=0

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.
R

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?