Yes. In order to identify the device OH needs 3 pieces of information from the device that are only obtained by full discovery. Here is a HABmin example from my system, shoring those numbers.
I have found something
I was typing benext_tagreader_00_000 instead i see in the doc it has to be benext_tagreader500_00_000
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/1122?layout=openhab2new
I add the thing in a file
Bridge zwave:serial_zstick:controller “ZWave Controller” [ port=“COM3”, controller_softreset=“false”, controller_master=“true”, heal_enable=“true” ]
{
Thing benext_tagreader500_00_000 node9 “Keypad” [ zwave_class_basic=“BASIC_TYPE_ROUTING_SLAVE”, zwave_class_generic=“GENERIC_TYPE_ENTRY_CONTROL”, zwave_frequent=“false”, zwave_version=“1.4”, zwave_listening=“false”, zwave_deviceid=“512”, zwave_routing=“true”, zwave_beaming=“true”, zwave_class_specific=“SPECIFIC_TYPE_SECURE_KEYPAD”, node_id=9, zwave_manufacturer=“138”, zwave_devicetype=“7” ]
}
Now i am getting this
But it is still in REQUEST_NIF, what does that mean?
In HABMIN
OpenHAB has requested a Node Information Frame from the device and has not yet received all of the NIF.
I found this quote from the Zensys documentation on another forum.
When the Include Initiator in a node is activated it will issue a node information frame. This frame is part of the Z-Wave protocol, and specifies the capabilities of the node. These capabilities announced include the node type, whether the node is able to repeat frames, and other protocol relevant issues. The node information frame also contains the Home ID and the Node ID.
It is possible for the application to ask for the Node Information Frame from all nodes in the network and hence enabling any node to acquire information regarding any other nodes features in the network at any given time.
so i just sit and wait?
On some of my cheap Chinese battery powered motion sensors I have tried a few things.
Sometimes removing the battery for 10 seconds, reinserting it and waking up the device repeatedly worked.
Other times I have needed to attempt to exclude the device, factory reset it and include into the network again, repeatedly waking it up. You need to delete the old thing and may end up with a failed node on your network controller.
1 Like
thank you for your input and time spend!
I appreciate it very much
hey, I have done a reset to factory settings and guess what
It’s alive, alive!!!
you need some more info for the thing in de database?
1 Like
It looks to me it is already in the database. I just checked & the entry looks pretty complete to me.
1 Like
Where do i put the usercodes? I found in this topic this–>
2. Registering User Codes (via habmin, PaperUI doesn’t support it)
Initially I thought this would be a straight forward task, but it was not!
I was simply trying to add e.g 1234 for a UserID with label “1” or “test”.
Nothing happened after punching HOME+1234+ENTER.
But in my habmin i do not see a place to put some codes???
Hello,
Sorry to jump on this old topic, but did you find the way to register the user code in habmin?
I’m not able to find the user code’s field in the configuration part of the device.
Probably a stupid question, but what does the first switch do?
The only “action” I get from the keypad is that the alarm (raw), which changes between {"type":"0","value":"0"} and {"type":"0","value":"255"}, when I use Home and Away with registered code…
Otherwise, I am having trouble registering even the RFID token that came with the keypad, because the Z-wave logs show its “COMMAND_CLASS_USER_CODE” as “8F 9C 09 36 8D 50 01 04 00 00”, which does not correspond to a number…
Should it matter, I have an older version, with firmware 0.28 - it does not even use security…
@chris Hi Chris, we were in contact on including the WTRFID in OpenHab2.4 - well documented in this thread… 
Now I have migrated to OpenHab 3.1 and doing good progress so far, apart from this nice little RFID bitch…
Since I migrated my Zwave network 1:1 the controller does see the RFID pad, but please see what happens once I try to authenticate with one of my RFID chips:
2021-09-12 23:04:11.323 [ERROR] [internal.JSONResponseExceptionMapper] - Unexpected exception occurred while processing REST request.
java.lang.NullPointerException: null
at org.openhab.binding.zwave.internal.ZWaveConfigProvider.getConfigDescription(ZWaveConfigProvider.java:303) ~[?:?]
at org.openhab.core.config.core.ConfigDescriptionRegistry.fillFromProviders(ConfigDescriptionRegistry.java:206) ~[?:?]
at org.openhab.core.config.core.ConfigDescriptionRegistry.getConfigDescription(ConfigDescriptionRegistry.java:174) ~[?:?]
at org.openhab.core.io.rest.core.internal.config.ConfigDescriptionResource.getByURI(ConfigDescriptionResource.java:122) ~[?:?]
at jdk.internal.reflect.GeneratedMethodAccessor171.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.4.3]
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.4.3]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.4.3]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.4.3]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.4.3]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.4.3]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:222) ~[bundleFile:3.4.3]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) ~[bundleFile:3.1.0]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273) ~[bundleFile:3.4.3]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:791) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550) ~[bundleFile:9.4.40.v20210413]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1435) ~[bundleFile:9.4.40.v20210413]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:294) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1350) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.40.v20210413]
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:82) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:383) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:882) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1036) [bundleFile:9.4.40.v20210413]
at java.lang.Thread.run(Thread.java:834) [?:?]
This block is repeated multiple times in the log.
Do you have any idea?
Kind regards
Bodo
Sorry - not really. There is maybe something being passed from the UI to the binding that the binding doesn’t like, but from this I can’t tell what the problem is - I’d need to see the information that is being passed.
Ups, something being passed from the UI? At least it is not me doing that, I guess. Was quickly thinking about the registration of User ID in habmin in openHab2.4 - if this could have any interference here, but I assume those IDs were registered and stored in the device itself rather than in any UI layer…
However, I just realized, that OpenHab 3.1 reports that the device is still in init. Could this cause such an issue?
Ok, maybe not the UI then, but it’s a configuration issue it seems, and it looks like it’s the REST interface that is experiencing the problem. Again, I can’t really tell what’s happening - I can just say that it is a configuration issue, and it seems to be in the REST interface (ie Jetty).
No problem. I am anyhow ready to get rid of “old” stuff… reducing complexity. Maybe I will deprecate the WTRFID… Let’s see.
Good night
Bodo