@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
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.
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.
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.
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!
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:
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.
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.
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.
