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.
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
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
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
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…
I can try that myself tonight, maybe I’ll get this to work myself 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?
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.
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
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):
perl fhem.pl fhem.cfg
2017.01.05 10:21:37 3: ZWave got config for schlagelink/minikeypad.xml from ./FHEM/lib/openzwave_deviceconfig.xml.gz
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
5 1 8fd7c20d412002800000
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
Regards, Christian
Thanks. It’s FHEM not supporting AddNode for my controller . 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.