Never have. I’m willing to try anything to learn.
Am I the only one who has noticed the node has not yet initialised? Check the picture, its in it’s DYNAMIC_VALUES phase
No, I didn’t notice that. That’s probably it.
Wake up the device by pushing and holding the action button on the Sensor. Directions below.
Waking up Multisensor 6.
In order to configure Multisensor 6, you must either (1) wake up Multisensor 6 using the below button press function, or (2) temporarily put your Multisensor 6 on USB power.
Press and hold Multisensor 6 Action button
Wait until the RGB LED turns into a Yellow/Orange Color
Release Multisensor 6 Action Button
The LED on Multisensor 6 will now rapidly blink its Yellow/Orange LED while it is in its awake state. You may send in any configurations or commands from your current gateway to configure your Multisensor 6.
- Tap the Action Button on Multisensor 6 to put Multisensor 6 back to sleep, or wait 10 minutes. (recommended to manually put it back to sleep to conserve battery life).
Go watch this video. You can learn a little about HABPanel by watching from the 6:55 mark. You need to install the HABPanel UI. See Screen shot below.
@Toneus I just woke up the MultiSensor and it’s still not working. I need to get back to this tomorrow after work. I really appreciate everyone’s help!
This is possible, but unless you are running the development zwave binding, you will need to use another software to heal the network (rebuild routes). The development binding is the only 2.x version that can currently do a heal. Best to do the inclusion through OH with the controller and device at their normal locations. This could be a reason for the issues you are having. Here’s some info from Chris, but in 2014 he was talking about the 1.x binding.
@162884 Have you issued the following on the PI so we can see what is happening when you are causing motion in front of the sensor?
This will keep a running output of the events log until you hit ‘ctrl c’ and will only read the last part of the log. Once you run it cover the sensor and uncover it to see if the things/items are triggering log entries. Since your light is working you can also test it out with tailf by turning the light on via paperUI to get an idea of what you will see happen.
Also the above tailf command is what is a code fence it is part of posting and keep things tidy along with some syntex highlighting (in some cases).
Also something else that is useful is leveraging commands like cat or more with grep
cat /var/log/openhab2/events.log | grep 2018-02-15
The above will spit out all the logs with that time stamp, which could be helpful to you if you wanted to look at the past events but limit the only a date/timestamp.
cat /var/log/openhab2/openhab.log | grep 2018-02-15 | grep 12:0
Spit out the same log but only match that date and then filter again to 12:00 through 12:09.
Thanks @anonymous.one! I will do this later today when I return from work and report back.
Yes you can. I have done it a couple of times myself.
Please note, however, that it is strongly recommended to have the device you are trying to include in very close proximity of the Zwave controller (USB stick), so that you are sure to have a direct link between the two and not going through the mesh, when doing inclusion.
For some devices it is convenient to bring them to the PC/PI hosting the controller, for others not so much (e.g. in-wall relays/dimmers, etc.). This is why I find the Aetotec stick a very nice product, since it has battery and can in fact be moved to the device for inclusion - if needed.
To add to this, you can set zwave into debug (log:set DEBUG org.openhab.binding.zwave), and grep for the node in a tail of openhab.log. Just remember to set zwave back to WARN when you’re done. This can be used real-time or for historical data (the -n option for tail), and will provide a lot more detailed info for troubleshooting the device.
tail -F -n5000 /var/log/openhab2/openhab.log | grep "NODE 2:"
You may want to double check the configuration parameters for the device (best done through Habmin). There is a setting which disables motion detection. Do you have any associations setup?
I respectfully disagree… why do you strongly recommend this? For older devices that only support low power inclusion, and to utilize the Security CC, being in close proximity to the controller would be required. For all other cases, it is best to do the opposite, and perform inclusion with the device and controller in their final locations. This is especially true for mains powered devices, so the routes are set properly.
Returned home from work and the motion sensor fired off the rule and the light turned on. What in the world? I went to bed last night and it wasn’t working. I’m glad it’s working but curious as to what fixed it.
The device wakes up multiple times and finished the initialization. Remember when I wanted you to force it to wake up?
Yep, that must be it. Thanks for all the help. Now off to my next opportunity in the Bindings forum.
Hmm… I am sure this has been stated in several manuals I have read, but looking closer at it now, this may have been for “older devices” as you point out. I see there is something called “network wide inclusion” that is supported by newer devices (I presume) and also by the OH2 binding, so I realize my statement may have been misleading - at best. Thanks for pointing this out!
This is not necessary. Just a restart of the Z-Wave binding will do the job. So just SSH into the Karaf console and enter
I have even automated this in my setup. When I did not get an update from the Z-Wave controller within the last 15 minutes, the binding will restart automatically.
That is smart! How did you do that?
All my Z-Wave items are in a group. Whenever the group receives an update a rule posts the timestamp of the last update to a DateTime item. All 15 minutes a cron rule checks if the state of the DateTime item is older than 15 minutes. If is is older than 15 minutes I restart the Z-Wave binding via the Exec binding where I call a batch script on the computer which logs on to Karaf console and executes the line
Thanks for the explanation!
Maybe a little beyond the capabilities of most users here.
A more robust solution would to have the binding itself monitor the status of it’s adapter, and release and re-engage the port accordingly.
I’m not using the PI, but I don’t think that matters. OpenHAB reports Exceptions when I remove my z-stick. It clearly knows when the stick is removed.
It would be nice if OpenHAB would support hot-plugging the stick, since that’s one of the primary use-cases when including new devices.