WTRFID Mini Keypad RFID/Z-Wave

It also looks like this is already fixed in OH2 since OH2 correctly detects it as 10 bytes…

I’ll take a look at OH1 implementation.

I just had another look at the manual. When the device doesn’t recognize the RFID tag it sends a USER_CODE_REPORT, consisting of User ID 0, UID status 0 and the actual tag code. So it would be 1 byte for the User ID, 1 byte for the UID status, and 10 bytes for the code = 12 bytes.
As I saw in your code the size for “case USER_CODE_REPORT” is limited to USER_CODE_MAX_LENGTH, which is 10 and not 12.

            case USER_CODE_REPORT:
                int id = serialMessage.getMessagePayloadByte(offset + 1);
                UserIdStatusType status = UserIdStatusType
                        .getDoorLockStateType(serialMessage.getMessagePayloadByte(offset + 2));
                logger.debug("NODE {}: USER_CODE_REPORT {} is {}", getNode().getNodeId(), id, status);
                String code = "";
                int size = serialMessage.getMessagePayload().length - 5;
                if (size > USER_CODE_MAX_LENGTH) {
                    logger.debug("NODE {}: UserCode({}) length is too long ({} bytes)", getNode().getNodeId(), id,
                            size);
                    size = USER_CODE_MAX_LENGTH;
                }

Shouldn’t there be a USER_CODE_REPORT_MAX_LENGTH = 12 for this?

Christian

That’s fine - that’s the same format as all user code reports, so nothing different…[quote=“DocFraggle, post:22, topic:19014”]
Shouldn’t there be a USER_CODE_REPORT_MAX_LENGTH = 12 for this?
[/quote]

No - 10 bytes is the maximum allowed for the user code (as already discussed). The other 2 bytes are not part of the user code.

Clearly something is wrong with the calculation - it’s fixed in the latest code but I need to look at the old code to work to fix it there.

Hi Chris,

I hope you don’t get annoyed :wink:

I did a little debugging myself and added the actual “serialMessage”-content to the debug log in line 110 (ZWaveUserCodeCommandClass.java)

logger.debug("NODE {}: USER_CODE_REPORT {} is {}: {}", getNode().getNodeId(), id, status, serialMessage);

After triggering the USER_CODE_REPORT with the RFID token currently unknown to the keypad this was logged:

... Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 1C 0E 63 03 00 00 8F D8 C3 0D 01 20 02 80 00 00

The payload has a total length of 17 bytes. But in line 112 you subtract only 5 bytes from the payload length:

int size = serialMessage.getMessagePayload().length - 5;

17 - 5 = 12, I guess this should be

int size = serialMessage.getMessagePayload().length - 7;

then, right? I tried it with the above code, built and installed the jar, it seems to work that way.

Happy new year!
Christian

Not at all - I’m trying to work through some other code so have been avoiding the forum so I can get on without distractions :wink:

Absolutely. As said earlier, this is fixed in the later development of OH2. IF you want to produce a PR to solve it in the master, that would be great.

Thanks.

Hi Chris,

now that this problem is solved, I’ve got some other questions. I’ve been searching the forum and the web for 2 days, but didn’t find a solution yet…

As you maybe saw in the manual, the process for setting the “Home” or “Away” state is pressing the corresponding button, entering the configured PIN and hitting the “Enter” key.

The keypad determines whether the PIN was correct, and if so, sends a message via the AlarmCommandClass:

19:07:58.056 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 1C 0A 71 05 00 FF 00 FF 06 05 01 01 
19:07:58.056 [TRACE] [ve.internal.protocol.ZWaveController] - Incoming Message type = REQUEST
19:07:58.056 [TRACE] [ssage.ApplicationCommandMessageClass] - Handle Message Application Command Request
19:07:58.056 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 28: Application Command Request (ALIVE:DONE)
19:07:58.056 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 28: Starting initialisation from DONE
19:07:58.056 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@20618958 already registered
19:07:58.056 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 28: Incoming command class ALARM
19:07:58.056 [TRACE] [ssage.ApplicationCommandMessageClass] - NODE 28: Found Command Class ALARM, passing to handleApplicationCommandRequest
19:07:58.056 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 28: Received ALARM command V2
19:07:58.056 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 28: Process NOTIFICATION_REPORT V2
19:07:58.056 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 28: NOTIFICATION report - 0 = 255, event=5, status=255
19:07:58.056 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 28: Alarm Type = ACCESS_CONTROL (0)
19:07:58.056 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
19:07:58.056 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 28: Got an event from Z-Wave network: ZWaveAlarmValueEvent
19:07:58.056 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 28: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
19:07:58.056 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
19:07:58.056 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
19:07:58.056 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 5, type OnOffType
19:07:58.056 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 28: Updating channel state zwave:device:bb4d2b80:node28:alarm_access to ON [OnOffType]

The event is 5 for “Away” and 6 for “Home”. The last action is the update of the alarm_access channel.

Big introduction, but here is the first question: how can I determine (via rule), if the event was 5 or 6 after the alarm_access channel was updated?

The second question: the keypad comes with a RFID chip. As long as it’s not registerd with the keypad, it sends the RFID’s hex-code via USER_CODE_REPORT, but currently it’s only possible to enter digits into the user code fields via Habmin. What would be the easiest way to set one of the user codes to the RFID code?

Thanks a lot in advance,
Christian

1 Like

We should be able to add a channel of type notification_access_control which should be a Number and it should be updated with the event number. It will need type=ACCESS_CONTROL in the channel configuration in the database.

I can (probably) change it so we can add hex digits - to be clear though - this is still ASCII though right? ie it’s not expecting this to be converted into binary? I’ll take a look at this to see if it’s simple - if not it might need to wait a week or two…

1 Like

I can try that myself tonight, maybe I’ll get this to work myself :slight_smile: Is this oly done in the xml file?

This is the hex code:

8F D8 C3 0D 01 20 02 80 00 00

Most of them aren’t ASCII characters, I checked the ASCII table…

Yep. If you want to add this to the database then just export the XML for testing…

Oh dear - that might be a problem. If I understand the standard, it’s meant to be ASCII -:

Minimum code length is 4 and maximum 10 ASCII digits.

Hmm… I guess they try to bend the standard to get the RFID code into the keypad…
According to the manual they suggest that the controller, when presented with an unknown RFID token, searches for an empty UID and inserts the RFID code.

But that would only make sense if some kind of usercode-inclusion is activated by the user, otherwise anybody could register a new RFID token…

Is there any way to send the USER_CODE_SET command with payload to a specific node manually, maybe via Karaf?

1 Like

No - but the problem is not that simple. Since the standard is for ASCII - the binding is doing certain checks on the code.

I’ll check this with Sigma.

1 Like

Hi all,

I was able to get the notification_access_control channel up and running, Chris is helping me to add it to the database later today.

The alarm_access channel will be replaced by the notification_access_control channel. If you enter a correct code or place a registered RFID token in front of the keypad this channel gets updated: event “5” for “Away”, event “6” for “Home”. Afterwards you will be able to use this in a rule of some kind.

Home:

Away:

Concerning the registration of the RFID token: until we find a solution I had to cheat on openHAB and used FHEM for this process (I hope it’s ok to mention here)… but at least I have been successful, now I can use both the code and the RFID token to un-/lock the keypad!
If someone is interested in a small how-to I can post a walk-through here (or you have a look here if you want to figure it out yourself - it’s in German)

Regards, Christian

1 Like

I’m really interested. I just got the device yesterday and I’m really struggling how to add the RFID in OH2. Any help would be great. As I read the discussion I have to wait for a new definition for this device. Is that correct.

Yes, the database change is still waiting for approval.

OK, here’s what I did (on a CentOS 6 machine):

  • shut down openHAB2
  1. download the FHEM package: Home of FHEM
  2. extract the archive
  3. run “make install”, FHEM will be installed in /opt/fhem
  4. before running FHEM I had to install some additional packages: perl-Device-SerialPort, perl-Crypt-Rijndael and usbutils
  5. start FHEM:
perl fhem.pl fhem.cfg
  1. click on “Everything”, there you should see your Zwave Controller “ZWDongle_0”, click on it
  2. at the bottom of the ZWDongle_0 page you should see the “nodeList” with all your Zwave nodes, named “UNKNOWN_1”, “UNKNOWN_2” and so on
  3. remove the back cover of your keypad
  4. at the top of the ZWDongle_0 page you can see two rows, one with a “set” button and one with a “get” button and some dropdowns. In the “set” row, choose “addNode” and “nwOn” and click the “set” button
  5. activate the inclusion mode of your keypad by holding the tamper lever for one second and then releasing it. FHEM writes some logfiles in /opt/fhem/log, there you should see an entry like
2017.01.05 10:21:37 3: ZWave got config for schlagelink/minikeypad.xml from ./FHEM/lib/openzwave_deviceconfig.xml.gz
  • wake up the keypad multiple times in order to initialize it in FHEM. The keypad creates it’s own logfile, so you can have a look what’s happening there (/opt/fhem/log/ZWave_ENTRY_CONTROL_29-2017.log in my case)
  1. now it’s getting interesting :slight_smile: press the “Home” or “Away” button on your keypad, wait for the LED to turn on, and put your RFID token in front of it. The log file should show something like
2017-01-04_19:07:48 ZWave_ENTRY_CONTROL_29 wakeup: notification
2017-01-04_19:08:37 ZWave_ENTRY_CONTROL_29 userCode: id 0 status 0 code 8fd7c20d412002800000
  • this is your RFID’s usercode, now you can store it on the keypad: go back to you browser, when you click on “Everything” you should see your keypad Zwave node, click on it to open the configuration page
  • again, you see a “set” and a “get” row. Choose “userCode” in the “set” row, and enter something like this in the textfield at the end:
5 1 8fd7c20d412002800000
  • where 5 is the usercode id, 1 is the status (activated) and the RFID’s usercode. Click on “set” to execute the command
  • now you can test it, you should see something like this in the log:
2017-01-04_19:09:31 ZWave_ENTRY_CONTROL_29 alarm: AccessControl: Keypad Unlock Operation, arg 0105
2017-01-04_19:09:32 ZWave_ENTRY_CONTROL_29 wakeup: notification
2017-01-04_19:09:39 ZWave_ENTRY_CONTROL_29 alarm: AccessControl: Keypad Lock Operation, arg 0105
2017-01-04_19:09:39 ZWave_ENTRY_CONTROL_29 wakeup: notification

That’s it, shut down FHEM, start openHAB2 again, and you’re done :slight_smile:

Regards, Christian

3 Likes

Thanks. It’s FHEM not supporting AddNode for my controller :frowning: . I think I have to wait for adding the correct usercodes is supported in OH2. Is it possible to enter just the numeric code for the keypad into OH2? I can live without the RFID for now.

O dear… yes, you can enter the digits via Habmin

Christian

The initial response from Sigma on this is -:

We are aware that some RFID tag readers have adopted this non-compliant approach which goes against the specification.

I’ve asked them if this means they are going to update the standard or if these devices are considered incompatible/non-standard devices… We’ll see - hopefully they plan to update the standard.

Is it a matter of filling the code 1234 in one of the usercode and wait for the new definition or is there more to it?

It’s not currently possible to set a binary code - fullstop. The binding doesn’t support this since the standard says it’s not allowed.

If you just want to set a normal user code like 1234, that’s no problem with the current binding.