Aeon Labs 4-in-1 multi sensor Gen 5 does not connect properly?

[Frode Fuglestad]

I got a Aeon Labs Z-Wave USB Stick (Series 2) and a Aeon Labs 4-in-1 sensor device connected to a Raspberry Pi 2, running openHAB 1.6.2.

Z-Wave binding addon is version 1.7.0.201502202333.

The USB Stick has always been green once i first got it working due to some permission issue.

I have included the sensor while it was running on batteries, never operated it powered by USB.

The sensor has never been more than maximum 7-8 meters away from the gateway.

Was hoping that someone got any ideas where to start looking to troubleshoot?

I can mention that openhab is unable to create dev/zwave/xml files for the nodes.

[Chris Jackson]

The log looks fine, but it’s just not received anything from the device - have you woken the device up? To wake the device, hold down the little button on the back for a second or two - this will wake it up and the binding will then configure it (hopefully :) ).

[Frode Fuglestad]

Thanks for the quick reply Chris. I have tried to perform a wakeup exactly like you write here before, without any success. But this time it worked! Woho :)

Awesome. Now I can finally proceed with my in-wall dimmer to turn on/off light based on motion.

[Frode Fuglestad]

One issue that seems to persist is that the permissions to create node xml files causes the sensor to end up "gray" unconfigured each time i restart openhab, and therefor I also have to press the button to wake it up each time. 

Any ideas of how to correct the permission thing?

I am running openhab with the openhab:openhab user/group from the apt-get installation guide for linux as stated in the steps in the wiki.

[Chris Jackson]

This is normal, and it should be ok. When you restart OH, the device will show grey - however, hopefully when OH initialised the device earlier, it set the wakeup period, so now the device should wake up at some stage and reconfigure. This shouldn’t stop if sending notifications…

To check this, have a look in the Wakeup configuration in HABmin - it should show node=1 and hopefully a wakeup period?

[Frode Fuglestad]

Restarted the Pi/openHAB.

The node 5 is grey, and has been for over an hour.

Is that also normal?

All of the properties/assosiation group details that where listed earlier is also not visible in habmin anymore.

[Chris Jackson]

Is that also normal?

It depends on the setting in the wakeup command class. The binding doesn't change this, and I don't know what the default is (if it's set to 0, then the binding will use 1 hour, but if it defaults to another value, then it won't change it).

For me, I set all mine to 1 hour, so it should mostly wake up after 1 hour. Some people set this value to 1 day, and others use 6 hours... So, it's normal that it will take this amount of time before the node goes green again...

Chris 

[Frode Fuglestad]

OK..

I'm not sure what to set the various configuration parameters to. Last time I changed them, they stopped reporting/being visible in my group with the items.

Currently it looks like this (not working):

This is my item file:

Group gMotion

Number sensor_1_temp "Temperature [%.1f °C]" <temperature> (gMotion) {zwave="5:command=sensor_multilevel,sensor_type=1"}

Number sensor_1_humidity "Humidity   [%.0f %%]" <water> (gMotion) {zwave="5:command=sensor_multilevel,sensor_type=5"}

Number sensor_1_luminance "Luminance    [%.0f Lux]" <sun> (gMotion) {zwave="5:command=sensor_multilevel,sensor_type=3"}

Contact sensor_1_motion "Motion [MAP(motion.map):%s]" <pir> (gMotion) {zwave="5:command=sensor_binary,respond_to_basic=true"}

Number sensor_1_battery "Battery [%s %%]" (gMotion) {zwave="5:command=battery"}

Do I have to factory reset the device to get it back to default setup?

[Chris Jackson]

The problem is the wakeup interval is not set - it should be set automatically, but it’s not happened for some reason. So, to fix this, change the “Wakeup Interval” to some number - I’d personally recommend 3600 (1 hour) which means the device reports its status every hour, and allows the binding to communicate with it (note that this doesn’t stop the sensor sending updates, or alarms whenever it wants - it’s a separate thing). You can use a smaller number, but the smaller you use, the less battery life you’ll get.

Once you’ve changed this, press the button on the back of the sensor for a few seconds. This will wake the sensor up, and (hopefully!) HABmin will set the wakeup interval.

Note that the yellow background means that HABmin is waiting for the device to wake up before it sends the data - the data is currently in a queue until the device wakes...

[Frode Fuglestad]

I set the wake up interval and have tried several times to wake up the device by pushing the black button for a few second (tried 2,3,4,5 seconds)

The configuration settings stays "yellow"/unconfigured and I do not get the proper feedback in the log that the device is waken up and configured.

Added a new z-wave log file..

Should I attempt to exclude the device from the z-stick and re-include it, or are there other tricks?

[Chris Jackson]

It looks like node 5 is working fine. It’s completed initialising a couple of times over the past couple of days, so I think it’s ok. There is an issue to resolve though - the wakeup interval is not set. I think I need to change the concept on how I set this since it’s still a problem for many people and it needs to be automated…

Anyway, in HABmin, go to the Wakeup Configuration folder in node 5 and change the wakeup interval to 1800. The background will probably go yellow - then go to the device and click the little button again to wake it up. If it wakes up, then the background should go white, and with luck, everything will be ok in future.

[Frode Fuglestad]

Unfortunately it does not seem to go that well..

I changed the wakeup interval to 1800 and clicked the button for 2-3 seconds (with several attempts)

This is the latest activity in the log file below, you can see that i changed the wakeup interval. Node has been grey since my attempts, and is not reporting any data on the configured items.

2015-04-25 13:42:07.604 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:353]- Network Monitor: No nodes to ping!

2015-04-25 13:43:37.607 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:353]- Network Monitor: No nodes to ping!

2015-04-25 13:45:07.612 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:353]- Network Monitor: No nodes to ping!

2015-04-25 13:46:15.974 DEBUG o.o.b.z.i.c.ZWaveConfiguration[:1049]- doSet domain 'nodes/node5/wakeup/Interval' to '1800'

2015-04-25 13:46:16.136 DEBUG o.o.b.z.i.c.ZWaveConfiguration[:1134]- NODE 5: Set wakeup interval to '1800'

2015-04-25 13:46:16.140 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:441]- NODE 5: Creating new message for application command WAKE_UP_INTERVAL_SET to 1800

2015-04-25 13:46:16.142 DEBUG o.o.b.z.i.p.SerialMessage[:109]- NODE 5: Creating empty message of class = SendData (0x13), type = Request (0x00)

2015-04-25 13:46:16.144 DEBUG o.o.b.z.i.p.SerialMessage[:233]- Assembled message buffer = 01 0D 00 13 05 06 84 04 00 07 08 01 00 00 6C 

2015-04-25 13:46:16.146 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:453]- NODE 5: Sending REQUEST Message = 01 0D 00 13 05 06 84 04 00 07 08 01 00 00 6C 

2015-04-25 13:46:16.147 DEBUG o.o.b.z.i.p.ZWaveController[:957]- Callback ID = 23

2015-04-25 13:46:16.149 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:237]- NODE 5: Putting message SendData in wakeup queue.

2015-04-25 13:46:16.151 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:249]- NODE 5: Creating new message for application command WAKE_UP_INTERVAL_GET

2015-04-25 13:46:16.152 DEBUG o.o.b.z.i.p.SerialMessage[:109]- NODE 5: Creating empty message of class = SendData (0x13), type = Request (0x00)

2015-04-25 13:46:16.154 DEBUG o.o.b.z.i.p.ZWaveController[:957]- Callback ID = 24

2015-04-25 13:46:16.156 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:237]- NODE 5: Putting message SendData in wakeup queue.

2015-04-25 13:46:20.859 DEBUG o.o.b.z.i.c.ZWaveConfiguration[:1049]- doSet domain 'nodes/node5/wakeup/Interval' to '1800'

2015-04-25 13:46:21.118 DEBUG o.o.b.z.i.c.ZWaveConfiguration[:1134]- NODE 5: Set wakeup interval to '1800'

2015-04-25 13:46:21.120 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:441]- NODE 5: Creating new message for application command WAKE_UP_INTERVAL_SET to 1800

2015-04-25 13:46:21.121 DEBUG o.o.b.z.i.p.SerialMessage[:109]- NODE 5: Creating empty message of class = SendData (0x13), type = Request (0x00)

2015-04-25 13:46:21.123 DEBUG o.o.b.z.i.p.SerialMessage[:233]- Assembled message buffer = 01 0D 00 13 05 06 84 04 00 07 08 01 00 00 6C 

2015-04-25 13:46:21.125 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:453]- NODE 5: Sending REQUEST Message = 01 0D 00 13 05 06 84 04 00 07 08 01 00 00 6C 

2015-04-25 13:46:21.126 DEBUG o.o.b.z.i.p.ZWaveController[:957]- Callback ID = 25

2015-04-25 13:46:21.128 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:233]- NODE 5: Message already on the wake-up queue. Removing original.

2015-04-25 13:46:21.129 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:237]- NODE 5: Putting message SendData in wakeup queue.

2015-04-25 13:46:21.131 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:249]- NODE 5: Creating new message for application command WAKE_UP_INTERVAL_GET

2015-04-25 13:46:21.132 DEBUG o.o.b.z.i.p.SerialMessage[:109]- NODE 5: Creating empty message of class = SendData (0x13), type = Request (0x00)

2015-04-25 13:46:21.134 DEBUG o.o.b.z.i.p.ZWaveController[:957]- Callback ID = 26

2015-04-25 13:46:21.135 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:233]- NODE 5: Message already on the wake-up queue. Removing original.

2015-04-25 13:46:21.136 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:237]- NODE 5: Putting message SendData in wakeup queue.

2015-04-25 13:46:37.616 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:353]- Network Monitor: No nodes to ping!

2015-04-25 13:48:07.621 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:353]- Network Monitor: No nodes to ping!

2015-04-25 13:49:37.626 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:353]- Network Monitor: No nodes to ping!

2015-04-25 13:51:07.630 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:353]- Network Monitor: No nodes to ping!

2015-04-25 13:52:37.635 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:353]- Network Monitor: No nodes to ping!

2015-04-25 13:54:07.640 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:353]- Network Monitor: No nodes to ping!

2015-04-25 13:55:37.644 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:353]- Network Monitor: No nodes to ping!

2015-04-25 13:57:07.649 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:353]- Network Monitor: No nodes to ping!

2015-04-25 13:58:37.654 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:353]- Network Monitor: No nodes to ping!

[Chris Jackson]

Again, it’s still not woken up - I don’t know why. If I remember correctly, the red led on the sensor (near the switch) flashes when it wakes up - maybe have a look at that. Another option might be to remove the batteries and put them back in as I think the sensor might stay awake for 10 minutes after power up (I’m not sure if that’s a configuration option though).

Is the sensor quite close to the controller?

[Frode Fuglestad]

The sensor has usually been placed between 5-8 meters from the controller which are behind indoor drywalls.

Its currently not mounted with a "permanent" position, I'll mount it if it starts behaving :)

I woke it up by re-inserting batteries followed by a click on the black button.

Items are now receiving data, but the temperature is way off (displays 0.3 celsius, should be closer to 23-24).

Added a new log file displaying the latest activity. 

[Chris Jackson]

Great - at least it’s working (for the most part!). This sensor seems to be harder to wake up….

> Items are now receiving data, but the temperature is way off (displays 0.3 celsius, should be closer to 23-24).

This might be the sensor bug that exists on the previous versions of the sensors - I thought this had been fixed as mine didn’t seem to do it. It can be fixed by not requesting the temperature - I need to update the database to stop these requests…

You should configure the parameters so that it sends the temperature (and other sensors) automatically - polling a battery sensor in zwave is not really very useful.

Cheers
Chris

[Frode Fuglestad]

I found this manual useful: http://www.smarthus.info/support/manuals/zw_sikkerhet/aeotec_multisensor_tech.pdf

Triple click seems to be the trick to quickly wake it up.

Has anyone suggested to add an advanced or alternative way for configuring devices that require "special treatment" like some versions of this device and perhaps others z-wave devices?

Imagine if there was a "Advanced" tab that included options to set "do not request temperature" and a if/else check in the z-wave binding addon that read from these? Correct me if I'm way off here, it was just a logic way of looking at a solution. 

[Chris Jackson]

This is the manual for the old version (Gen 4). By the title of your message (Gen 5) I gave you instructions for the Gen 5 which is a 3 second push on the button (according to my manual at least). The Gen 4 is 3 quick presses - sorry for the confusion…

Every sensor/device has this sort of thing. You really need to read the manual as it explains how to set it up. I’ve been adding more automation to the setup over the past few months, and hopefully will add more in OH2.

Cheers
Chris

[Frode Fuglestad]

Ofcourse, thanks Chris.

Regarding the incorrect reading from the temperature data, is there anything I can configure or were you able to change some of the code to prevent the "bug"?

I am also not getting any events on the motion detector..

Frode

[Frode Fuglestad]

Would there be any improvements on this part for v1.7 RC1?

Frode

[Chris Jackson]

I’ve just created an update to disable polling on this sensor, so that ought to stop the fault. I’ll merge it tonight, but it’s worth noting that you would need to remove the XML file for this to be reconfigured.

Cheers
Chris

[Frode Fuglestad]

Thanks Chris for your efforts :) 

I will report back the results as soon as I get the new build and find some spare time.

Have a colleague running the exact same model, he is facing identical issues, so he will will test afterwards too.

Regards

Frode

[Frode Fuglestad]

Adding the URL of the updated JAR to make it easy to find:

org.openhab.binding.zwave-1.7.0-SNAPSHOT.jar

Build date: 08-May-2015 07:18:46

[Frode Fuglestad]

Sorry to bug you again Chris, but I have looked around and have been unable to locate the xml file to remove.

Is it a node xml generated specifically for the 4in1 device?

I can't seem to find the path where these could be stored.

My openhab webapps are located in /usr/share/openhab/webapps

And configuration files are located in /etc/openhab/configurations

Regards,
Frode

[Chris Jackson]

Hi Frode,
The file is in the openhab/etc/zwave folder - it will be called nodeXX.xml where XX is the node number…

Cheers
Chris

[Frode Fuglestad]

Hi Chris,

I do not seem to have this directory.. 

Got these lines in the z-wave log:

2015-05-08 23:47:25.427 DEBUG o.o.b.z.i.p.i.ZWaveNodeSerializer[:64]- Creating directory etc/zwave

2015-05-08 23:47:25.462 DEBUG o.o.b.z.i.p.i.ZWaveNodeSerializer[:107]- NODE 5: Serializing to file etc/zwave/node5.xml

2015-05-08 23:47:25.464 ERROR o.o.b.z.i.p.i.ZWaveNodeSerializer[:114]- NODE 5: Error serializing to file: etc/zwave/node5.xml (No such file or directory)

Do you know where it should have created the directory?

I got two openhab directories as I mentioned, one of them got a symlinked etc folder "/usr/share/openhab/etc" points to: "/etc/openhab/jetty/etc"

[Chris Jackson]

Which-ever one has the zwave folder under it I guess :)

To be honest, I’m not sure. It’s normally at the same level as the configuration folder. So if you’re in the folder that has the configuration folder, and there’s an etc folder, it should be there, but I’m not 100% sure. I think someone has also mentioned the jetty one as well… Presumably one of them though has a zwave folder?

(sorry - not so useful I know - you could try a search for the file - nodeXX.xml)?

Chris

[Marcel Erkel]

Hi Frode,

The most likely cause is that the user running OpenHAB does not have write access to the etc directory. I'm not sure which of the three (/etc/openhab, /etc/openhab/jetty/etc or /usr/share/openhab/etc) will be used since I'm not familiar with this type of installation.

Can you do an ls -ld on these directories to see what permissions are set on these directories and whether or not the user running OpenHAB can actually write in those directories?
May be also do a ps -ef | grep openhab to list the running OpenHAB instance. The first column should show the user running OpenHAB.

Cheers,
Marcel

[Frode Fuglestad]

Hi Marcel,

Thanks for pointing me into the right direction.

Permissions:

pi@pihab /usr/share/openhab $ ls -ld

drwxr-xr-x 7 openhab openhab 4096 May  4 20:53 .

------

pi@pihab /etc/openhab/jetty/etc $ sudo ls -ld

drwxr-xr-x 2 root root 4096 Mar  7 17:19 .

-------

pi@pihab /usr/share/openhab/etc $ sudo ls -ld

drwxr-xr-x 2 root root 4096 Mar  7 17:19 .

I could try to change the ownership for the two folders marked red, since the processes run as openhab..

Running processes:

pi@pihab /usr/share/openhab $ sudo ps -ef | grep openhab

openhab   5741     1 11 00:09 ?        00:55:23 /usr/bin/java -Dlogback.configurationFile=/etc/openhab/logback.xml -Dosgi.clean=true -Declipse.ignoreApp=true -Dosgi.noShutdown=true -Djetty.port=8080 -Dopenhab.configfile=/etc/openhab/configurationsopenhab.cfg -Dopenhab.configdir=/etc/openhab/configurations -Dopenhab.logdir=/var/log/openhab -Djetty.home=/usr/share/openhab -Djetty.port.ssl=8443 -Djetty.config=/etc/openhab/jetty -Djetty.logs=/var/log/openhab -Djetty.rundir=/usr/share/openhab -Dfelix.fileinstall.dir=/usr/share/openhab/addons -Djava.library.path=/usr/share/openhab/lib -Djava.security.auth.login.config=/etc/openhab/login.conf -Dorg.quartz.properties=/etc/openhab/quartz.properties -Dequinox.ds.block_timeout=240000 -Dequinox.scr.waitTimeOnBlock=60000 -Dfelix.fileinstall.active.level=4 -Djava.awt.headless=true -jar /usr/share/openhab/server/plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar -configuration /var/lib/openhab/workspace -data /var/lib/openhab/workspace -console 5555

pi       10018  9989  0 08:01 pts/1    00:00:00 grep --color=auto openhab

Regards,
Frode

[Marcel Erkel]

Hi Frode,

It seems it's a bit more complicated. And what makes it even more complex is that things will change between your current (v.1.6.2 ?) installation and the upcoming OpenHAB 1.7.

You could add the following to the /etc/default/openhab file:

JAVA_ARGS=-Dsmarthome.userdata=/var/lib/openHAB/

This is the directory that will be used in 1.7. You probably need to create the /var/lib/openHAB directory and make the openhab user and group the owner of this directory.

Cheers,
Marcel

[Chris Jackson]

If someone raises an issue on the OH issue tracker, I’ll add an action into the binding so that there’s a button added in HABmin to reinitialise the device (and hence delete the XML). It’s not right to ask users to delete files embedded in the system…

Chris

[Frode Fuglestad]

Hi Marcel, Chris

The permission to create xml nodes where solved by giving ownership to openhab on the following path (I installed openhab on a Raspberry Pi using the apt-get installation instructions at the github wiki):

sudo chown -R openhab:openhab /usr/share/openhab/etc/zwave/

I now have two xml nodes, one for the controller and one for the 4-in-1 device.

Still not getting proper data from temperature, and motion is never reported as open.

From events.log: 2015-05-09 12:48:19 - sensor_1_motion state updated to CLOSED

Can't find any warnings or errors related to either temperate always being reported incorrectly to 0.2 degrees, and motion that never trigger.

This is how motion reporting is configured: (Basic set gives same result as Sensor binary report)

There are changes in temperature values being reported:

2015-05-04 23:47:35 - sensor_1_temp state updated to 0.233
2015-05-09 12:48:20 - sensor_1_temp state updated to 0.215

My item file has been posted earlier in this topic.

Chris, sounds like a good plan to add a dedicated button for the action to reinitialise devices.

Marcel, for v1.7 there seems to be a few changes that should be added to the installation instructions on the github wiki, atleast below the release notes section "Updating the openHAB runtime 1.6 to 1.7"

Regards,
Frode