ssieb/esphome_components

Wiegand issue: 26-bit card format vs facility code

Closed this issue · 2 comments

I've noticed that 26-bit H10301 card numbers are being reported without the facility code calculation. For example, a card that has facility code 1 and card code 11572 would be reported as 77108.

Looking at the raw bits, it seems like the FC bits and CC bits are all wrapped into one number. The first 8 bits (after the initial parity bit) should be treated separately, to ensure that only the next 16 bits should be calculated as the card code.

A good way of reporting the correct card format would be to use the FC:CC format which is quite common in the PACS industry, for example 001:11572 in the example above. Thoughts?

ssieb commented

Any readers I've used have not split out the facility code. All the cards and fobs I've seen don't have that distinction either. But I'll see about adding an option to publish in that format as well.

ssieb commented

You do realize that it's an arbitrary formatting of the data, right? It's the same bits either way. Are you trying to compare the resulting value against something else? Should the card code be 0-padded so the resulting string is always the same length? That's what the current 26-bit code does and all readers I've used do that too.