Unable to communicate with Hikvision DS-K1108AMK or Hikvision DS-K1107AMK

[pawpro]

Describe the bug Unable to receive any response from Hikvision PD hardware.

Expected behaviour Even though not all technical details are known to me I expected to be able to establish communication over OSDP to Hikvision keypads/readers.

Observed behavior When trying to initalize/emulate a Control Panel to communicate with a hardware RS-485/OSDP reader/keypad "osdp: CP: INFO : PD not online" is reported and "osdp: CP: ERROR: Response timeout for CMD(60)" is reported in response to sending commands.

Additional context I am using Python 3.9.2 and libosdp v2.2.0. I have purchased multiple readers such as Hikvision DS-K1108AMK and Hikvision DS-K1107AMK (three in total). I have used several RS485 to RS323/UART modules (from various brands) across a PC, MAC and raspberry PI (RS485 CAN HAT for Raspberry Pi). The PDs are configured in RS485 mode (and report RS485 offline error as expected in case of problems). I have tried all baud rates, range of addresses including broadcast (devices set to address 1 connected one at the time only). The devices are connected through ~ 40 cm wires bundled from factory.

This is a third time I am attempting this project over the last 6 months and I am exactly where I started... (only Wiegand mode works). Any hints or ideas much appreciated.

[pawpro]

I've found some language in one of the documents online that suggests the Hikvision DS-K1107/8 devices implement two protocols (in addition to Wiegand): RS-485 (private Hikvision version) and OSDP. It is unclear whether it is necessary to use Hikvision Door Controller to set the device into OSDP mode and if there is any auto detection or how that might work.

Another explanation is that the devices have been provisioned with an SCBK from Hikvision and without a way to put them into an installation mode the only way would be to use Hikvision hardware (such as DS-K2601) to reconfigure the PDs.

If anyone knows more please let me know

[sidcha]

There isn't much to work with in this thread, so I'll just try my best. And I'm going to assuming you have ruled out possible wiring/converter issues.

Do you happen to have a scope or a logic analyser(the cheap USB ones) lying around? It would help to know if there are any signs of life. Nevertheless, you should compile LibOSDP with PACKET_TRACE enabled on the CP side (along with log level set to LOG_DEBUG) so it dumps what it thought it received.

[..] purchased multiple readers such as Hikvision DS-K1108AMK

It is a long shot, but have you explored options of getting in touch with manufacturer/seller? I know they might not have the best support but the dealer/sales person some times have a lot of additional resources like reference implementation and SDKs.

In any case, can you point me to specific model and spec sheet please.

[..] and report RS485 offline error as expected in case of problems

How does the PD report this?

I've found some language in one of the documents online that suggests the Hikvision DS-K1107/8 devices implement two protocols (in addition to Wiegand)

There is usually a physical method to switch between operational modes. I've seen DIP switches at the back of the PD (or inside if it can be unscrewed) that allows users to set the protocol. There is also the infamous config RFID cards provided by the manufacturer which you can present to the PD soon after boot to put it in specific modes. HID for instance takes this route to set the readers to install_mode.

Another explanation is that the devices have been provisioned with an SCBK

This is is very unlikely. Even if that were the case (you don't have any evidence to point to this) only SC should fail with clear message indicating that the PD is not in install_mode and it has a SCBK set.

[pawpro]

@sidcha Thank you so much for taking the time to engage with this slightly tangental to libOSDP issue.

Debugging: I have, within my limited skills, closely followed the traces of both UART and corresponding rs-485 lines. I am able to reliably observe and capture a single repeating trace generated by the CP. I am confident this trace comes from the CP (e.g. when PD is not wired) that I do not see any response whatsoever from the readers (one connected at the time). My limited understanding of libOSDP and osdp itself makes me feel somewhat helpless in confidently devising a test in which I can e.g. send a single packet that I know an OSDP compliant device would have to respond to (regardless of its state and settings: even if the response would otherwise not be useful). So far all three new readers and for all intents and purposes are OSDP dead (if I recall they do pull RS-485B up when powered "up" but only with correct DIP switch config: more below). I have the osdp debug flag set but am yet to recompile osdp with PACKET_TRACE. I have not felt yet the need to understand the packets better (I haven't seen any).

Getting in touch with manufacturer: I tried to contact Hikvision hardware support but my experience as an individual is to say the least scary. In all cases they hang up (if I manage to get someone on the call) or they dont reply to emails or the contact form submissions fail with page not found. The sellers I bought these from are small fish and I have not tried exploring their relationship with HIK but I expect they have none. Truth be told I see no incentive for the manufacturer to help me.

OSDP errors: According to the troubleshooting section of the PD Manual page 8, Table 4-2 "Description of LED Switch": "Flashing Red" stands for "For RS-485 protocol: Registering failed or card reader is offline.". The reader boots, beeps to indicate end of boor sequence, goes solid red (normal state) for few seconds and then starts flashing red. Both models behave exactly the same.

DIP switches: The only method of configuration currently available to me is the DIP switches. The second and final one I am aware of is through a Door Controller from HIK and their software (used more for provisioning and integration with their ecosystem). There are 8 bits to set. The configuration is explained on page 4 of the manual section "3.1 DIP Switch Description". It is identical to both models I have. The first 4 bits allow setting an Address. Bit 5 allows switching between Mifare payload to read, Bit 6. 0 is for rs-485 and 1 is for Wiegand, 7. for Wiegand bit-length, 8. for rs-485 resistor. Needless to say only with bit 6 set to 0 do the readers go into the red flashing mode. WIth it set to 1 (Wiegand) the readers stay in normal mode displaying red led always on. There are no other hidden buttons. I could not find any references to configuration cards in case of HIK. The only two options are DIP switches and their Door Controller.

SCBK speculation: Again due to my lack of experience I am struggling to explain the lack of response of the readers. My misunderstanding of the protocol led me to believe perhaps if pre-provisioned key would not match the PD would not respond at all.

At this point my focus was trying to get any sort of CP's acknowledgement by the physical PDs. I have gone through a lot of hardware trying to control things. Including running the entire setup from batteries to provide as clean power as possible. To accomplish seeing any response from them would be a true breakthrough.

[sidcha]

How do you know if they are OSDP readers to begin with?

I have a few reasons to suspect they aren't:

1. OSPD PDs don't have a way to be in a "Registering failed or card reader is offline" state (for that matter, they don't maintain as much state; see osdp_pd.c for how simple it is compared to osdp_cp.c).
2. The spec document is reasonably well made and does not have one mention of OSDP in it. At the end of the doc there is a QR code (speaking of shitty user interfaces :P) on the doc that points to a scary looking command document which points to some custom protocol.
3. The address is 4 bit and they spec calls it RS485 address (PD addresses are 7 bits and called so).

[..] devising a test in which I can e.g. send a single packet that I know an OSDP compliant device would have to respond to (regardless of its state and settings: even if the response would otherwise not be useful).

This part is already taken care by LibOSDP. The CP will set POLL/ID commands which have to be supported by all readers. The question is if we are using the right baud rate. But I guess you tried all possible baud rates so that is ruled out.

[pawpro]

The reasons to believe these models support OSDP: "Support RS-485, Wiegand (W26, W34), and OSDP protocol" stated on product pages and data sheet

I cannot find it now but have seen some released notes for Door Controller (from 2018?) that shown a screenshot showing RS-485 protocol selection dropdown allowing to select "Private" or "OSDP protocol".

I understand why the mention of PD knowing it is not "registered" and signalling this back with the red led concerns you.

I know this is not much.

[sidcha]

Okay, sleeping over this for a few more days, the only other explanation that I can come up with is this: the PD at power on is set to the custom RS-485 protocol and a suitable CP has to send some commands to configure it to start operating in OSDP mode.

Any thoughts on that?

[pawpro]

I think I found something that is beginning to sound like maybe my readers are running old firmware:

From release notes from a firmware upgrade:

K1107/08 Series:
1.  Support OSDP protocol. When connect to controller, card reader will automatically choose using private RS485 or standard OSDP according to controller’s protocol.

I think I'll have to buy the controller and try to upgrade firmware/play a bit more. The firmware release notes are from 2019 but maybe this is it. Worst case scenario I may be able to observe the native behaviour.

[pawpro]

I purchased the door controller and found some further things out.

1. Two of my readers are actually DS-K1107MK not DS-K1107AMK. The MK software does not support OSDP... AMK one does. These readers do not respond and go "offline" when protocol is changed to OSDP (from private).
2. The DS-K1108AMK does respond and behave slightly differently when switching between private protocol and OSDP in the door controller.
3. When sniffing the rs-485 bus I can see different communication scheme between the two modes however it is not legible.

I am trying to confirm/validate/understand more about the OSDP mode it runs in and how to use it with libOSDP. Any suggestions/examples how to do this? How to ascertain which baud rate etc. it uses? Again I can see the controller talking to it and the reader responding in OSDP mode. If the communication is just encoded I should be able to write a simple python script to decode it. Any ideas?

[sidcha]

Hm, you could use those inexpensive logic analyser to capture the packets and try to figure out OSDP packer boundaries (starts with 0x53). Another option is to write a python script running on a raspberry pi to read the bus and print all the data you see.

As to baud rate detection, you can just try all possible values (there are only few) and see the stuff on wire makes sense in any one of them.

[sidcha]

I'm closing this issue since there is no pending action here. Nevertheless, you can continue communicating about this issue here (I'll still be notified).