Aeotec Multisensor 6 - motion sensor not working

@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 https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/lastStableBuild/org.openhab.binding%24org.openhab.binding.zwave/artifact/org.openhab.binding/org.openhab.binding.zwave/2.4.0-SNAPSHOT/org.openhab.binding.zwave-2.4.0-SNAPSHOT.jar )

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.

Cheers,

Richard

Ok, this is quite old then. If you plan to move, I would strongly suggest to use the development version. You can find this by searching for Zwave security. If you wait a few weeks hopefully it will be merged into 2.4 snapshot…

Apologies, @chris, I’ve just re-read my testing notes from above and wanted to clarify my words. I am still using the SNAPSHOT binding as per 4th April update however the rest of my OH2 installation is version 2.2. I will be upgrading the whole OH2 installation to 2.3 shortly and will be happy to re-test at that point.

Much water has passed under the bridge and I’m using a lot more of the functionality of OH2, including rules triggered by both items and events, development of dashboards and panels, a much wider range of bindings, integration with OpenHAB Cloud and the OH Android app, comprehensive sitemaps and items from files rather than PaperUI. So everything is very different to when I started. I’m still learning and still count myself as a newbie as there is still much experimenting going on!

Thanks for your help

Richdard

Hi @RichardK, yes, insecurely it does work with me too.

But securely (using the development binding from last week it is not recognized. I can see some Zwave command going over the line, but no recognition from the Multisensor, reporting “Unknown device…”

I’m using the binding version 2.3.0.201805192224, using list in Karaf, downloaded from the website from @Chris last friday.

This is what I get, it is node 59.
It has been included using other software, because OH2 does not seem to trigger the Zwave initialization (something I have to dive in, but I’ll do that later), and this is what I get once I restart OH2:

2018-06-03 22:07:31.610 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 59: Node found
2018-06-03 22:07:31.611 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 60: Node found
2018-06-03 22:07:31.613 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller using Controller API
2018-06-03 22:07:31.614 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller is Primary Controller
2018-06-03 22:07:31.616 [INFO ] [age.SerialApiGetInitDataMessageClass] - ------------Number of Nodes Found Registered to ZWave Controller------------
2018-06-03 22:07:31.617 [INFO ] [age.SerialApiGetInitDataMessageClass] - # Nodes = 5
2018-06-03 22:07:31.618 [INFO ] [age.SerialApiGetInitDataMessageClass] - ----------------------------------------------------------------------------
2018-06-03 22:07:31.619 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 7: Transaction COMPLETED
2018-06-03 22:07:31.623 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveInitializationStateEvent
2018-06-03 22:07:31.627 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveInitializationStateEvent
2018-06-03 22:07:31.629 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 1: Init node thread start
2018-06-03 22:07:31.630 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveInitializationStateEvent
2018-06-03 22:07:31.633 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 43: Init node thread start
2018-06-03 22:07:31.635 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveInitializationStateEvent
2018-06-03 22:07:31.635 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 44: Init node thread start
2018-06-03 22:07:31.648 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveInitializationStateEvent
2018-06-03 22:07:31.652 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 7: TransactionAdvance ST: DONE
2018-06-03 22:07:31.653 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 7: TransactionAdvance WT: null {}
2018-06-03 22:07:31.652 [DEBUG] [ve.internal.protocol.ZWaveController] - Starting waiting for init threads
2018-06-03 22:07:31.656 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 7: TransactionAdvance RX: Message: class=SerialApiGetInitData[2], type=Response[1], dest=255, callback=0, payload=06 08 1D 01 00 00 00 00 0C 00 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 00 
2018-06-03 22:07:31.650 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 60: Init node thread start
2018-06-03 22:07:31.658 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 7: TransactionAdvance TO: DONE
2018-06-03 22:07:31.648 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 59: Init node thread start
2018-06-03 22:07:31.662 [DEBUG] [ve.internal.protocol.ZWaveController] - Waiting for init thread Node_1_init
2018-06-03 22:07:31.664 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: Response processed after 141ms
2018-06-03 22:07:31.670 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: TID 7: Transaction completed
2018-06-03 22:07:31.672 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: notifyTransactionResponse TID:7 DONE
2018-06-03 22:07:31.676 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2018-06-03 22:07:31.677 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-06-03 22:07:31.678 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
2018-06-03 22:07:31.680 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
2018-06-03 22:07:31.681 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
2018-06-03 22:07:31.682 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
2018-06-03 22:07:31.936 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 43: Serializing from file /var/lib/openhab2/zwave/network_c9f152e0__node_43.xml
2018-06-03 22:07:31.936 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 1: Serializing from file /var/lib/openhab2/zwave/network_c9f152e0__node_1.xml
2018-06-03 22:07:31.937 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 44: Serializing from file /var/lib/openhab2/zwave/network_c9f152e0__node_44.xml
2018-06-03 22:07:31.937 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 59: Serializing from file /var/lib/openhab2/zwave/network_c9f152e0__node_59.xml
2018-06-03 22:07:31.939 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 44: Error serializing from file: file does not exist.
2018-06-03 22:07:31.939 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 60: Serializing from file /var/lib/openhab2/zwave/network_c9f152e0__node_60.xml
2018-06-03 22:07:31.941 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 59: Error serializing from file: file does not exist.
2018-06-03 22:07:31.942 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 60: Error serializing from file: file does not exist.
2018-06-03 22:07:31.968 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 44: Starting initialisation from EMPTYNODE
2018-06-03 22:07:31.968 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 60: Starting initialisation from EMPTYNODE
2018-06-03 22:07:31.968 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 59: Starting initialisation from EMPTYNODE
2018-06-03 22:07:31.980 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 1: Restore from config: Ok.
2018-06-03 22:07:31.982 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 60: Init node thread finished
2018-06-03 22:07:31.982 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 59: Init node thread finished
2018-06-03 22:07:31.985 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 44: Init node thread finished
2018-06-03 22:07:31.985 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 59: Node advancer - advancing to IDENTIFY_NO

Can you supply a debug log so we can see what is happening? My guess is maybe it’s not woken up, and it won’t initialise, and therefore won’t show the device type, until this happens.

Thanks for your very quick reply!

I’m pretty sure I woken up the device, by activating the sensor using the button, and by making sure it sees motion. The blue LED is flashing, making sure the sensor is awake.

What is the best way to transfer the log file to you?

If it’s using security then I’d suggest to open a ticket on my website - you can attach large files there and it’s secure. Note that you need to register otherwise you wont see the ticket menu.

My Multisensor 6 act the very same way. In PaperUI Control, Binary, Motion and Alarm are “empty”.
But they´re are working fine though. I use the Binary in a rule to activate a light, and it works like a charm…

2018-06-06 22:16:23.802 [vent.ItemStateChangedEvent] - ZWaveNode5ZW100MultiSensor6_BinarySensor changed from OFF to ON
2018-06-06 22:16:24.096 [vent.ItemStateChangedEvent] - ZWaveNode5ZW100MultiSensor6_MotionAlarm changed from OFF to ON
2018-06-06 22:17:01.024 [vent.ItemStateChangedEvent] - ZWaveNode5ZW100MultiSensor6_BinarySensor changed from ON to OFF
2018-06-06 22:17:01.321 [vent.ItemStateChangedEvent] - ZWaveNode5ZW100MultiSensor6_MotionAlarm changed from ON to OFF

The error is that the authentication is failing. Have you restarted something and lost the key that was used when including the device in the first place - that’s the normal reason for the loss of secure communications.

From here, if you have lost the key, you will need to factory reset the device (maybe excluding it will also work) and the re-include it again.

I should add that the same error exists for your Zipato bulb, so I think it’s highly likely that the key changed and therefore you can’t communicate with any secure device that was included with the old key… There’s no way back from this if you don’t have the key used for inclusion.

Hmmm… did so many experiments so things might be mixed up. That is a good idea. I’ll try that.
Thanks for the fast answer!!!:+1:

After that input from @Kim_Andersen and @tonus, here is an update from me.

So @Kim_Andersen is correct, rules work. Even though there is nothing in either the event.log or openhab.log to say that something has happened, rules fire and work as expected for motion and tamper. I did have to wakeup the Multisensor at one point to get it work but, when that was done all worked fine. Interestingly, the binary sensor rules do not work.

Setting debug on and then looking in the log, the events are there.

Time	Node	Entry
16:31:28.687	42	
RX REQ ApplicationCommandHandler WAKE_UP_NOTIFICATION
16:31:28.761	42	
Node is AWAKE
16:31:29.811	42	
TX REQ SendData 25 WAKE_UP_NO_MORE_INFORMATION  ACK AUTO_ROUTE EXPLORE
16:31:29.816		
RX ACK
16:31:29.825	42	
RX RES SendData 25 ACCEPTED BY CONTROLLER
16:31:34.906		
TX REQ SendDataAbort
16:31:34.911		
RX ACK
16:31:37.258	42	
RX REQ SendData 25 NO ACK after 7447ms
16:31:46.950	42	
Node is ASLEEP
16:33:14.052	40	
RX REQ ApplicationCommandHandler CONFIGURATION_REPORT PARAM_9 size=2
16:33:14.584	40	
RX REQ ApplicationCommandHandler SENSOR_BINARY_REPORT=255
16:33:14.635	40	
STATE UPDATE zwave:device:fa226f4b:node40:sensor_binary ON [OnOffType]
16:33:15.316	40	
RX REQ ApplicationCommandHandler ALARM_REPORT V1 UNKNOWN[00] V1LEVEL=0 HOME_SECURITY EVENT=8
16:33:15.357	40	
RX REQ ApplicationCommandHandler ALARM_REPORT V1 UNKNOWN[00] V1LEVEL=0 HOME_SECURITY EVENT=8
16:33:15.393	40	
STATE UPDATE zwave:device:fa226f4b:node40:alarm_motion ON [OnOffType]
16:33:15.454	40	
STATE UPDATE zwave:device:fa226f4b:node40:alarm_motion ON [OnOffType]
16:33:15.654	40	
RX REQ ApplicationCommandHandler SENSOR_MULTI_LEVEL_REPORT TEMPERATURE=34
16:33:15.715	40	
STATE UPDATE zwave:device:fa226f4b:node40:sensor_temperature 23.6 [DecimalType]
16:33:16.064	40	
RX REQ ApplicationCommandHandler SENSOR_MULTI_LEVEL_REPORT RELATIVE_HUMIDITY=1
16:33:16.119	40	
STATE UPDATE zwave:device:fa226f4b:node40:sensor_relhumidity 53 [DecimalType]
16:33:16.844	40	
RX REQ ApplicationCommandHandler BATTERY_REPORT 100%
16:33:16.904	40	
STATE UPDATE zwave:device:fa226f4b:node40:battery-level 100 [DecimalType]
16:33:16.905	40	
RX REQ ApplicationCommandHandler SENSOR_MULTI_LEVEL_REPORT LUMINANCE=10
16:33:17.035	40	
STATE UPDATE zwave:device:fa226f4b:node40:sensor_luminance 42 [DecimalType]
16:33:17.042	40	
RX REQ ApplicationCommandHandler SENSOR_MULTI_LEVEL_REPORT ULTRAVIOLET=1
16:33:17.128	40	
STATE UPDATE zwave:device:fa226f4b:node40:sensor_ultraviolet 0 [DecimalType]
16:33:32.356	40	
RX REQ ApplicationCommandHandler ALARM_REPORT V1 UNKNOWN[00] V1LEVEL=0 HOME_SECURITY EVENT=3
16:33:32.423	40	
STATE UPDATE zwave:device:fa226f4b:node40:alarm_tamper ON [OnOffType]
16:33:32.580	40	
RX REQ ApplicationCommandHandler ALARM_REPORT V1 UNKNOWN[00] V1LEVEL=0 HOME_SECURITY EVENT=3
16:33:32.629	40	
STATE UPDATE zwave:device:fa226f4b:node40:alarm_tamper ON [OnOffType]
16:34:54.697	40	
RX REQ ApplicationCommandHandler SENSOR_BINARY_REPORT=0
16:34:54.752	40	
STATE UPDATE zwave:device:fa226f4b:node40:sensor_binary OFF [OnOffType]
16:34:54.920	40	
RX REQ ApplicationCommandHandler ALARM_REPORT V1 UNKNOWN[00] V1LEVEL=0 HOME_SECURITY EVENT=0
16:34:54.965	40	
STATE UPDATE zwave:device:fa226f4b:node40:alarm_tamper OFF [OnOffType]
16:34:54.971	40	
STATE UPDATE zwave:device:fa226f4b:node40:alarm_motion OFF [OnOffType]
16:34:58.615	40	
RX REQ ApplicationCommandHandler SENSOR_BINARY_REPORT=255
16:34:58.669	40	
STATE UPDATE zwave:device:fa226f4b:node40:sensor_binary ON [OnOffType]
16:34:58.838	40	
RX REQ ApplicationCommandHandler ALARM_REPORT V1 UNKNOWN[00] V1LEVEL=0 HOME_SECURITY EVENT=8
16:34:58.887	40	
STATE UPDATE zwave:device:fa226f4b:node40:alarm_motion ON [OnOffType]
16:35:58.697	40	
RX REQ ApplicationCommandHandler SENSOR_BINARY_REPORT=0
16:35:58.753	40	
STATE UPDATE zwave:device:fa226f4b:node40:sensor_binary OFF [OnOffType]
16:35:58.918	40	
RX REQ ApplicationCommandHandler ALARM_REPORT V1 UNKNOWN[00] V1LEVEL=0 HOME_SECURITY EVENT=0
16:35:58.965	40	
STATE UPDATE zwave:device:fa226f4b:node40:alarm_tamper OFF [OnOffType]
16:35:58.971	40	
STATE UPDATE zwave:device:fa226f4b:node40:alarm_motion OFF [OnOffType]
16:36:09.381	40	
RX REQ ApplicationCommandHandler SENSOR_BINARY_REPORT=255
16:36:09.444	40	
STATE UPDATE zwave:device:fa226f4b:node40:sensor_binary ON [OnOffType]
16:36:09.603	40	
RX REQ ApplicationCommandHandler ALARM_REPORT V1 UNKNOWN[00] V1LEVEL=0 HOME_SECURITY EVENT=8
16:36:09.659	40	
STATE UPDATE zwave:device:fa226f4b:node40:alarm_motion ON [OnOffType]
16:37:09.952	40	
RX REQ ApplicationCommandHandler SENSOR_BINARY_REPORT=0
16:37:10.021	40	
STATE UPDATE zwave:device:fa226f4b:node40:sensor_binary OFF [OnOffType]
16:37:10.180	40	
RX REQ ApplicationCommandHandler ALARM_REPORT V1 UNKNOWN[00] V1LEVEL=0 HOME_SECURITY EVENT=0
16:37:10.221	40	
STATE UPDATE zwave:device:fa226f4b:node40:alarm_tamper OFF [OnOffType]
16:37:10.229	40	
STATE UPDATE zwave:device:fa226f4b:node40:alarm_motion OFF [OnOffType]
your code goes here

I can provide the raw extract or even the whole raw openhab.log if you wish.

As mentioned above, nothing has changed to my basic OpenHAB2 setup between my 4th April message and now. I’m still running the same SNAP version of the zwave binding, still on version 2.2 of OpenHAB. So my plan, if this works for you, is to wait the few weeks until 2.4 is available and then upgrade and retest at that point, with a known and known–good version. How does that work for you? Plus in the meantime, you have the input above if this is of value to you.

Correction to my last: after checking my syntax and starting to use the correct name for the binary sensor, it also works and triggers rules as well.

Mea culpa!

I don’t think this is a binding issue - the sensor_binary channel is being updated -:

STATE UPDATE zwave:device:fa226f4b:node40:sensor_binary OFF [OnOffType]
STATE UPDATE zwave:device:fa226f4b:node40:sensor_binary ON [OnOffType]

Maybe you have the wrong item type, or something - I’m not sure, but it does seem that the ZWave side is working ok.