Unable to set up Aeotec MultiSensor 6

Setup, Configuration and Use Beginners
1

I’ve got an Aeotech MultiSensor 6 (ZW100-C) which is currently bound to a Z-Stick Gen 5 Z-Wave Plus USB Controller but I don’t believe the initialization is completing properly.

After leaving it on for a few hours (USB powered for now), the node status is still “ALIVE GET_CONFIGURATION” and the logs are full of errors like this:

2015-12-18 22:14:03.146 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 7: Unsupported command class ZWAVE_PLUS_INFO
2015-12-18 22:14:03.146 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 7: Unsupported command class ASSOCIATION_GROUP_INFO
2015-12-18 22:14:03.146 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 7: Unsupported command class POWERLEVEL
2015-12-18 22:14:03.149 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 7: Unsupported command class FIRMWARE_UPDATE_MD
2015-12-18 22:14:08.292 [ERROR] [WaveController$ZWaveSendThread] - NODE 255: Timeout while sending message. Requeueing - 2 attempts left!
2015-12-18 22:14:13.293 [ERROR] [WaveController$ZWaveSendThread] - NODE 7: Timeout while sending message. Requeueing - 2 attempts left!
2015-12-18 22:14:13.635 [WARN ] [b.z.i.p.s.SendDataMessageClass] - Node not found!
2015-12-18 22:14:14.471 [ERROR] [.DeleteReturnRouteMessageClass] - NODE 7: Delete return routes failed with error 0x1.
2015-12-18 22:14:18.294 [ERROR] [WaveController$ZWaveSendThread] - NODE 255: Timeout while sending message. Requeueing - 1 attempts left!
2015-12-18 22:14:19.532 [ERROR] [.DeleteReturnRouteMessageClass] - NODE 7: Delete return routes failed with error 0x1.
2015-12-18 22:14:23.295 [ERROR] [WaveController$ZWaveSendThread] - NODE 255: Timeout while sending message. Requeueing - 0 attempts left!
2015-12-18 22:14:24.491 [ERROR] [.DeleteReturnRouteMessageClass] - NODE 7: Delete return routes failed with error 0x1.
2015-12-18 22:14:28.296 [WARN ] [WaveController$ZWaveSendThread] - NODE 255: Too many retries. Discarding message: Message: class = DeleteReturnRoute (0x47), type = Request (0x00), payload = 07
2015-12-18 22:14:29.415 [ERROR] [.AssignReturnRouteMessageClass] - NODE 7: Assign return routes failed.
2015-12-18 22:15:25.123 [ERROR] [.AssignReturnRouteMessageClass] - NODE 7: Assign return routes failed.
2015-12-18 22:15:30.126 [ERROR] [WaveController$ZWaveSendThread] - NODE 7: Timeout while sending message. Requeueing - 1 attempts left!
2015-12-18 22:15:30.342 [WARN ] [b.z.i.p.s.SendDataMessageClass] - Node not found!
2015-12-18 22:15:31.328 [ERROR] [.AssignReturnRouteMessageClass] - NODE 7: Assign return routes failed.
2015-12-18 22:29:15.455 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 7: Unsupported command class ZWAVE_PLUS_INFO
2015-12-18 22:29:15.455 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 7: Unsupported command class ASSOCIATION_GROUP_INFO
2015-12-18 22:29:15.455 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 7: Unsupported command class POWERLEVEL
2015-12-18 22:29:15.456 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 7: Unsupported command class FIRMWARE_UPDATE_MD
2015-12-18 22:29:21.564 [ERROR] [WaveController$ZWaveSendThread] - NODE 7: Timeout while sending message. Requeueing - 0 attempts left!

The node is however reporting the device battery, temp, lux, humidity and PIR correctly.

Am using the latest 1.8.0-snapshot zwave binding. One other thing I’ve noticed is the node name in Habmin appears as ZW100-A, I’m assuming the differences to the ZW100-C are subtle (perhaps just regional differences - UK here), but could there be some other mismatches that are causing issues?

Not sure if there’s anything else I can include here, do let me know if I can provide anything else.

Thanks!

2

The unsupported command class errors are fine - I’ve got a gen 5 device and see the same. Can’t comment on the other errors.

If its usb/mains powered it should complete its configuration quite quickly. Could it be a range problem? How far from the controller is it/are there other nearby nodes?

3

Hi Rich

I have a Fibaro dimmer currently about a meter away, the controller is about 3 metres away from both. The sensor has been reporting updates hourly overnight (along with the same errors periodically), node status remains the same.

4

Please provide a debug log file and I’ll take a look.

5

Thanks Chris, want me to remove it from my network first?

6

First time I’ve ever tried to run openhab in debug mode, am getting this:
Launching the openHAB runtime in debug mode... ERROR: transport error 202: bind failed: Address already in use ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:750] FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197) Aborted (core dumped)

7

My bad, I have another service on my server using port 8001 … I’ll get a full debug log up later on today.

Cheers!

8

It looks like you might already have an instance of OH running, but that’s just a guess… Use ps or top to make sure there’s no other processes running (or task manager on windows).

9

Here is the debug log: http://danielhead.com/openhab.log

Some points to note:
I excluded > factory reset > included the sensor prior to running
The sensor is Node 8, Node 4 is a Fibaro Dimmer 2
At 14:01:22 I added the following to default.items

Number Sensor_LivingRoom_Battery "Sensor Living Room Battery [%s %%]" {zwave="8:command=battery"} Number Sensor_LivingRoom_Temperature "Living Room Temp [%.1f C]" <temperature> {zwave="8:0:command=sensor_multilevel,sensor_type=1"} Number Sensor_LivingRoom_Lux "Living Room Lux [%.0f Lux]" <lux> {zwave="8:command=sensor_multilevel,sensor_type=3"} Number Sensor_LivingRoom_Humidity "Living Room Humidity [%.0f %%]" <water> {zwave="8:command=sensor_multilevel,sensor_type=5"} Contact Sensor_LivingRoom_PIR "Living Room PIR" <pir> {zwave="8:command=sensor_binary,respond_to_basic=true"}

I’ve noticed [ApplicationCommandMessageClass:85 ] - Transaction not completed: node address inconsistent. appears pretty regularly.

Any help is much appreciated!

Thanks
Dan

10

This is perfectly normal - it always occurs when a message is sent from the device that the controller didn’t request. It’s not an error, just a debug message.

I’ll have a look at the log…

11

It looks fine to me - no problem at all. The device completed initialisation and appears to be working fine.

12

Thanks a lot for looking Chris, I’m not sure it is fine, Heal Status is now FAILED during UPDATEROUTESNEXT and Node Stage is now FAILED DONE.

I’ve updated the log file with the additional entries at the bottom. As you’ll see I’ve back to normal, I’ll go back to debug and update it again in a couple of hours.

Cheers
Dan

13

Ok - the log you first sent looked fine. It was completing the initialisation fine, which I thought was the problem you reported - sorry…

In the new log, it just looks like the device is timing out - ie not responding.

Have you always run this on USB power, or has it also run on batteries?

14

I’ve tried running it on both, it’s currently on batteries though, I’ve got it on debug mode now and OpenHAB received updates from the sensor without me waking it, then shortly after it was marked as dead again.

Have updated the log file again: http://danielhead.com/openhab.log

15

When you included it, was it included into the network using batteries, or USB. It MUST be done on batteries if you are using batteries - you can’t swap between batteries and USB. I suspect this is ok from what I see in the log, but it’s worth confirming.

16

OK, that’s interesting! I included on USB and switched to batteries after a short period of time. Thanks for pointing that out.

I’ll restart with batteries only.

17

This line -:

NODE 8: Is currently marked as failed by the controller!

is a problem. It means that the controller thinks the device is dead - so it’s not even an OH issue…

I might change my earlier statement that I think the device inclusion was ok. I don’t think I’ve seen the controller mark a battery device as failed, so I suspect it’s possible that maybe this was included on mains, and is now running batteries?

18

Thanks a lot Chris, you are quite right about the USB/battery inclusion.

The log file is not quite error free but everything seems to be working properly!

Cheers
Dan

19

Hi @chris,

Can you please tell me…?
Does aeotec multisensor 6 supported in openhab…?
Which openhab version supports this…device…?

Regards,
shrikant

20

It is working quite well for me in OpenHAB2