Can't configure the Aeotec MultiSensor 6

  • Platform information:
    • Hardware: x86-64 (Intel 64)/16GB RAM/512GB SSD
    • OS: Mac OS X Sierra (10.12.6)
    • Java Runtime Environment: Oracle JDK v. 1.8.0_161
    • openHAB version: 2.2.0

Hello community!

Today I firstly tried to use the openHAB 2 with the tiny setup (the Aeotec Z-Wave stick and the Aeotec MultiSensor 6).
After some tries I still didn’t manage to make the sensor work and decided to write a little post about my experience.

  1. I had successfully downloaded and started the openHAB 2.2.0

  2. I have chosen the standard setup and then Paper UI.

  3. I have successfully installed the Z-Wave binding.

  4. I have plugged in the Aeotec Z-Wave USB stick and successfully configured it, although I was not quite sure between /dev/tty.usbmodem1421 and /dev/cu.usbmodem1421 Serial ports (chose the tty one).

  5. I had immediately received a notification in Inbox section:

    What bothers me here is that the device is always displayed as “Unknown device” here no matter how long I wait. Is that the correct behavior?

  6. I added this device and went to the Configuration/Things section:

    As you can see, the device is still displayed as “Unknown device”, which is quite not what I expected.

  7. I decided to hit the CMD+R in order to check if this is the UI glitch and the device is in fact “known” and boom:

    I don’t see the device status no longer at all, even though the icon has changed from ‘D’ to ‘A’ for my motion sensor.

  8. After that I have changed my browser (Chrome) to Safari to check whether this happens in all browsers or just Chrome. I have found out that Safari would randomly display device status and randomly hide it from one CMD+R to another, while Chrome always hides these lines after CMR+R.
    Anyway, whenever I choose Control section and then get back to Configuration/Things, device status is always displayed fine in all browsers.

  9. All right then, what I did next is I decided to edit some settings (such as “Motion Sensor reset timeout”) for my MultiSensor PC, that I have just somehow added.
    And I simply couldn’t do that, because the “save” button is always disabled, and I just can’t hit it no matter what:

    In fact the button is enabled (displayed as a white tick) for the first 0.2 seconds, while settings are not yet loaded. As soon as they are loaded, the button goes disabled immediately and nothing can make it enabled again.
    I’ve checked out different browsers again - same picture everywhere. I have also checked out the configuration for the Z-Wave stick - it is always fine there, so the problem is only with MultiSensor configuring.
    I’ve also tried to tweak the page source code with Chrome’s “Inspect element” feature, enabled the button and successfully changed the Name and saved it.

  10. Then I decided to go on with default settings, since I can’t change them properly, and Linked and item to the binary sensor channel:

    I didn’t change default Item setting and left the Switch type there and the Door category.

  11. I went to the Control section and witnessed the following:

    As far as I know, the blank spot on the right must be filled with an on/off switch visual, but it is simply not there.
    Again, I’ve check the Safari rendering and… the switch is present here, but the overall layout looks completely broken now:

  12. At this point I decided to look into the openhab/userdata/logs/openhab.log and OMG, it is full of different horrible exceptions everywhere, such as

2018-02-10 23:43:04.695 [ERROR] [ersey.server.ServerRuntime$Responder] - An I/O error has occurred while writing a response message entity to the container output stream.

with huge stacktraces…

Let me end the story here. I’m just having a frustrating experience in that I’ve done very few simple things, but everything looks so deeply broken from the very beginning. I have no idea what to do and which path to choose in order to proceed with this and a lot more complex setup.
Thank you very much for you guidance.

Howdy @Ixanezis I can confirm for you that when a zwave device shows up it may take some time for it to become a known device. If the device has constant power (light switch, power outlet) it will figure it out; however battery operated devices (door/window sensors, motion sensors) the device doesn’t communicate as frequently to save on power. This is a feature/function of zwave tech not necessarily openHAB.

I always keep a battery operated device on the counter/table until I can get it to display its properties correctly in openHAB.

However if you take a gander at this post, it might help you with the multisensor 6 as there is an issue with one of the properties from my understand. Need help installing Aeotech Z-Stick Gen 5 on RPi The title is mis-leading, if you scroll through the posts you should be able to replicate the solution that was suggested.

How often does it usually take for them to connect?

I’ve had a similar problem with my battery operated sensors. I have several door sensors (Ecolink DWZWAVE2-ECO) that I can get connected easily into smart things but not into my RPI using the Aeotech Z-Stick.

Like Sergei it shows up as an unknown device. I’ve tried everything from taking the covers off so the light comes on, removing the battery, excluding them then re-including. Can’t get OH to recognize it. Smartthings has no problem though so it’s getting into the Z-wave network.

@DWildemuth the Ecolink looks similar the some monoprice door sensors I purchased. I found by opening the cover of the larger piece and push the spring repeatedly it will help force be discovered.

I can’t speak to smartthings, just that normal zwave devices on battery power don’t communicate until actions occur with the device, like a door being opened/closed.

Note that this issue was updated in the database a day or two ago, so it should be fixed if you’re using the latest snapshot. Alternatively you can use HABmin - that should work.

This isn’t quite right - in most cases these sort of events won’t allow the binding to communicate with the device. When the sensor sends a notification, it normally doesn’t send a wakeup notification to say that it can actually receive data. This is normally only done at predefined intervals (configured through the wakeup command). If it’s not configured, then you need to manually wake up the device (see the device manual for how to do this).

The system has finally approved me, so I could update my post and hopefully it looks more sane now, with images.
I can confirm for you that when a zwave device shows up it may take some time for it to become a known device.

Yeah, but the point was in that the device appears as Unknown in Inbox forever. At the same time, if I add it to the Things, it gets “known” immediately, if we leave the html rendering problems aside. This is a minor problem, but since we are building the best smart home ever, our system should also be smart and not generate strange situtations.

Note that this issue was updated in the database a day or two ago, so it should be fixed if you’re using the latest snapshot. Alternatively you can use HABmin - that should work.

I took the link from and downloaded the (latest?), unpacked it and made everything I did with the 2.2.0 version. I can say that the problem is exactly the same as it was with previous version:

Could you point me on the task or issue or topic where it has been discussed and maybe PR where it has been fixed so that I could get the sources, make sure I have the fix commited and run everything from sources? It would also be interesting for me to know what was the cause of the problem and how it had been fixed.

This was helpful. I had tried that before. But the big difference here was I left the stick plugged into the RPi (others had said to take it out and put in pairing mode).

The other thing that helped, and maybe it was specific to my case given I have two z-wave controllers on the mesh, was telling openhab to look for the specific node on the RPi to give wakeup signals too.

You can get the sources from Github -:

Maybe you have a different version of the device - I think this only existed for the 1.1 firmware though.

Did you also try HABmin as suggested - that should work fine.

It looks like the system hasn’t rebuilt since the mods were made to the database so I’ve just kicked off a rebuild.

Today I’ve downloaded the SNAPSHOT version again, and ran it, having the build #1210.
The Save button is no longer disabled, and there are indeed two Parameters #9: the Sleep State and Power Mode.
I’m a little confused with the UI possibility to change the Power Mode… It would make a little sense if that was a read-only parameter, but I can clearly choose it in UI.

What’s worse, even if I change nothing, and press “tick”, I have the Thing updated popup, followed by ERROR: 500 - Internal Server Error. This is also accompanied by

2018-02-12 22:49:30.806 [ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/zwave:device:f3a258b2:node2/config'
java.lang.NullPointerException: null
	at org.openhab.binding.zwave.handler.ZWaveThingHandler.handleConfigurationUpdate( [202:org.openhab.binding.zwave:]
	at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.updateConfiguration( [116:org.eclipse.smarthome.core.thing:]
	at []

in logs.

Did you also try HABmin as suggested - that should work fine.

Not yet. I haven’t seen any mention of it on pages, that way I prefer to stick with more… uhm… official and popular points of entry, which are at least cited somewhere on the tutorial pages. I have no idea why something less known or mentioned must be working better than something more popular, such as PaperUI.
But I think I must give it a try now.

They are defined as read-only already -:

This is fixed in the development version, but as you are sticking with the master, this isn’t currently available.

HABmin is official and in the documentation (I guess that’s what you mean by “tutorial”?).

However, since the original issue is resolved now, you probably don’t need to worry about that :wink: .

Yeah, so it looks like PaperUI wouldn’t respect those properties and still allow them to be modified.

This is fixed in the development version, but as you are sticking with the master, this isn’t currently available.

Since I’m not quite sure why is this only fixed in dev, not master, when is it going to be in master or how do I change to dev, I have decided to check out HABmin anyway.

And I’ve got to say that compared to the PaperUI it just works brilliant :). Most of the cases that I mentioned in my first post in this topic are simply not applicable there, because they just work fine, with no UI glitches. I have finally also managed to modify the MultiSensor configuration and make it work as expected.
I’m very happy about that and I hope to stay with HABmin from now on, thank you!

HABmin is official and in the documentation2 (I guess that’s what you mean by “tutorial”?).

Yeah, well, I haven’t reached to that page yet. Anyway, it just contains a few (outdated?) screenshots of the user interface, which could keep away some novices as me.
In practice, however, I find it far more stable and good-looking compared to the PaperUI.

I have one of these, didnt work correctly until i updated the sensors firmware, try that

I am running the snapshot version of OpenHAB2 with the 2.4 version Chris’ binding. I can confirm that you get the Error 500 when trying to update properties in the MultiSensor 6 and that binary update NEVER show up. I have updated my firmware as well on the MultiSensors to no avail.

Here is where it gets interesting - None of these issues exist in HABmin only in PaperUI. There is something in the PaperUI causing these issues. HABmin updates the properties and shows motion and taper alarms just fine.