2018-05-15 11:34:15.573 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 19: Using Scheme0 Network Key for Key Exchange since we are in inclusion mode.
2018-05-15 11:34:16.217 [INFO ] [alization.ZWaveNodeInitStageAdvancer] - NODE 19: SECURITY_INC State=COMPLETE
2018-05-15 11:34:21.072 [INFO ] [ommandclass.ZWaveVersionCommandClass] - NODE 19: Command Class COMMAND_CLASS_BASIC has version 0!
Security is showing a green check mark now.
But when I try sending a 0 or a 255 to the Barrier State, here’s what I’m getting:
2018-05-15 11:45:26.272 [WARN ] [pse.smarthome.core.items.GenericItem] - failed notifying listener 'org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleEngineImpl@1e66405' about state update of item GarageDoor1_Switch: null
java.lang.NullPointerException: null
at org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleTriggerManager.internalGetChangeRules(RuleTriggerManager.java:336) [136:org.eclipse.smarthome.model.rule.runtime:0.10.0.201805141751]
at org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleTriggerManager.internalGetRules(RuleTriggerManager.java:427) [136:org.eclipse.smarthome.model.rule.runtime:0.10.0.201805141751]
at org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleTriggerManager.getRules(RuleTriggerManager.java:198) [136:org.eclipse.smarthome.model.rule.runtime:0.10.0.201805141751]
at org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleEngineImpl.stateChanged(RuleEngineImpl.java:202) [136:org.eclipse.smarthome.model.rule.runtime:0.10.0.201805141751]
at org.eclipse.smarthome.core.items.GenericItem$1.run(GenericItem.java:251) [101:org.eclipse.smarthome.core:0.10.0.201805141751]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Any ideas? The switch is obviously not opening and closing either.
Wondering if it’s an issue with the current OpenHab2 Snapshot I’m running (updated to it yesterday). I created a simple rule to log an info line to the log file when flipping a switch, and I get that same error I posted above… Not even related to any item…
Just updated to the latest openhab2, and will try again…
Yep, latest snapshot is yielding different results.
Everything is working now… Found two more issues after updating OpenHab, and now the door works as expected (freaked the wife out since she was at home, and I was at work, lol).
Hello,
I’m very new to openHAB, and am coming from a Vera. I have 2 of the NGD00Z-4 Garage Door Controllers that I’m trying to setup. I’ve read through a number of posts, which seem to contain piecemeal information on this. Is there a how-to for getting this setup from start to finish somewhere? It seems like it should be much easier than what it appears to be. Thanks
It is also used to control the garage door, by sending 255 (open) and 0 (close). You should setup a Switch Item that you can set to ON or OFF through a rule, based on the barrier_state, and to control the door. I have two NGD00Zs, and this is an example of how I used them in the Rules DSL…
I haven’t looked at this for a while, as I now use JSR223-Jython, but I could provide my current working example, if it could be of use.
I had also added the alarm_raw channel, but as of yet, I have not seen it report anything. The Z-Wave spec says that it would be used for safety report, like if the door closed on a car or something.
As I understand, the last 2 lines in my 2CarDoor.items file have the switch and the position indicator, am I wrong?
Switch 2car_Grg_Dr "2-Car Garage Door [MAP(garagedoor.map):%s]" <garagedoor> (gGarageDoor,gSleep_Security)
Number 2car_Grg_Dr_Psn "2-Car Garage Door Position [MAP(garagedoor.map):%s]" <garagedoor> (gGarageDoor,gSleep_Security) {channel="zwave:device:01FFFFFF-FFFF-FFFF-FFFF-160118150928:node6:barrier_state"}
Do I not have the barrier state linked properly? I’m only seeing a NaN in the paperui.
Your Channel looks odd. Confirm it in Paper UI> Configuration> Things> your opener, and verify the Chanel you have configured matches. If it does, you’ll need to enabled debug logging for the zwave binding and see why the door is not reporting.
Wait a second… your Items start with a number… I’m pretty sure you can’t do that!
Nope…
You should be seeing errors in VS Code, on OH startup, or after saving the file.
I’m considering getting one of these devices. Before I pull the trigger, I’m interested in anyone who can weigh in on the long-term reliability. A number of Amazon reviews complain about the device failing after a number of months. I’m curious if anyone here has had a similar experience.
Thanks for the reply. I was unable to reply last night due to new user forum rules. Sorry for the double post, I was initially posting for one problem, that then merged into the same problem. I didn’t see any errors with the number or character but changed them all anyway. Still no luck.
default.sitemap
sitemap default label="AH Home" {
Frame {
Text label="Two Car Garage" icon="house" {
Default item=twoCar_Grg_Pwr
Default item=twoCar_Grg_Lts
Switch item=twoCar_Grg_Dr
Text item=twoCar_Grg_Dr_Psn
}
}
}
And my updated twoCarDoor.items:
Switch twoCar_Grg_Pwr "Two Car Door Power" <poweroutlet> (Garage, gPower) {channel="zwave:device:01FFFFFF-FFFF-FFFF-FFFF-160118150928:node5:switch_binary1"}
Switch twoCar_Grg_Lts "Two Car Lights" <light> (Garage, gPower) {channel="zwave:device:01FFFFFF-FFFF-FFFF-FFFF-160118150928:node5:switch_binary2"}
Switch twoCar_Grg_Dr "Two Car Garage Door [MAP(garagedoor.map):%s]" <garagedoor> (gGarageDoor,gSleep_Security)
Number twoCar_Grg_Dr_Psn "Two Car Garage Door Position [MAP(garagedoor.map):%s]" <garagedoor> (gGarageDoor,gSleep_Security) {channel="zwave:device:01FFFFFF-FFFF-FFFF-FFFF-160118150928:node6:barrier_state"}
Do the other zwave items that you’ve listed work? This should eliminate the odd ChannelUID.
Could you be more specific . Does the barrier_state Item change values when the door is manually operated, and does the door open/close when sending 255/0 to barrier_state? You could quickly test this in Karaf…
smarthome:send twoCar_Grg_Dr_Psn 255
I have used one of these for about 3 years, and another for about 1.5. The only issue I’ve had was with losing security keys (device no longer responds and Habmin shows red check, and restarting does not help), which all of my secure devices seem to occasionally do. This might be a binding issue… still trying to track it down. They’ve worked well for me.
Your Items look good then. And looking back in the other thread, this shows the device is securely included. There is an odd message in alarm raw though (BARRIER_ERROR_UL_REQUIREMENT…), which is kind of cool, since this shows the device will actually use that channel… and I’ve never seen anything come out of it.
How is the device hooked up to the garage door opener, and which one are you using? I’m thinking OH is setup OK, but that you’re not connected properly to the opener. Another possibility, is that you include the device close to the controller, but since mounting it, you are out of range of the controller or another device with beaming.
That error you saw is now gone since my SmartStick+ reconfigured itself after a reboot or two after the SNAPSHOT upgrade. That’s when I started to get the new nodes with the bajillion Fs.
I don’t totally remember how it is exactly connected to the opener. I have been using this controller with a micasa verde for the past 2yrs or so, and haven’t changed any of the controller connections since switching it to OH. It’s within range of the controller ( <20’ away) and surrounded by other relays that are now connected. I’m fairly convinced that I’m doing something wrong as I’m not a programmer type at all, but I just can’t seem to figure out what.
OK, then it must be hooked up right too. But this…
… I don’t understand, so lets’s go back to secure inclusion, because it sounds like you may have needed to include it again. What do you see in Habmin> Configuration> Things> the device> Attributes?
BTW, this is definitely not a normal amount of hassle when setting up OH… so hang in there!
Nah… that looks like it’s still securely included. But I think I understand your issue now, which I should have noticed in your other screenshot. The device is reporting that this is a Z-Wave Plus device. Here is mine…
The device db includes the Type:ID for your device, in the same entry as the non-plus version. We may need to make a new entry for the plus version. @chris may have a thought on this, but he goes to bed early (UK).
Just for kicks, what do you have under associations?