Hi, nice work.
maybe it’s an idea to use transistors instead of relays for led control to reduce size?
it’s possible to use a D1 mini breadboard shield
https://a.aliexpress.com/_EItBGaD
and make following circuit on it.
probably the pull-up isn’t needed if the wiegand module has an internal pullup.
I got my hikvision ds-K1101MK working 
I was wondering if this is a secure way to disarm an alarm with an NFC tag.
Is it just sending the batch ID? If so, isn’t that readable for any NFC reader and not protected against cloning?
If you leave your fob where somebody can clone it, yup, it’s not a secure way to disarm your alarm. Mine is on my car keys, and never leaves my pocket until I return home.
Yes u have a point.
I have my keypad working but the individual keystrokes are registered as tag_scanned on the event bus.
Is there an easy solution to form a pincode with it?
Maybe start an automation when i press the ‘*’ key? But then i cant use the tag_scanned event in the conditions section to scheck a sequence.
The guy who wrote the custom component is an absolute hero!
He has a component for what you requested - here is how i do it:
wiegand:
- id: reader
d0: 25
d1: 27
on_tag:
- lambda: ESP_LOGD("TEST", "xreceived tag %s", x.c_str());
- lambda: id(handle_input).execute(("CARD:" + x).c_str());
#on_key:
# - lambda: ESP_LOGD("TEST", "received key %d", x);
key_collector:
- id: pin_reader
source_id: reader
min_length: 4
max_length: 8
end_keys: "#"
end_key_required: true # default is false
back_keys: "*"
timeout: 5s
allowed_keys: "0123456789" # if not included, then any otherwise unused keys will be allowed
on_result:
- logger.log:
format: "input result: '%s', started by '%c', ended by '%c'"
args: [ 'x.c_str()', 'start', 'end' ]
- lambda: id(handle_input).execute(("PIN:" + x).c_str());
only one thing - right now this seems broken due to a compile error - that would be the fix:
Hi
In the log I see the read RFID TAG. But it doesn’t arrive in IOBroker ESPHOME Device. In the MQTT device I only see the message in the debug. How do I get the TAG in the ESPHomeDevice
external_components:
source:
type: git
url: https://github.com/ssieb/custom_components
components: [wiegand, key_provider]
wiegand:
- id: reader
d0: D1
d1: D2
on_tag:
- lambda: ESP_LOGD("TEST", "received tag %s", x.c_str());
on_key:
- lambda: ESP_LOGD("TEST", "received key %d", x);
ESPHOME Log
[17:25:53][V][wiegand.text_sensor:048]: received 26-bit value: 22efc4e
[17:25:53][D][wiegand.text_sensor:051]: received 26-bit tag: 1539623
[17:25:53][D][TEST:145]: received tag 1539623
MQTT Device debug
[0;36m[D][TEST:145]: received tag 1539623 [0m
I tried it like this and it works
text_sensor:
- platform: template
name: "RFID Tag"
id: rfid_tag
wiegand:
- id: reader
d0: D1
d1: D2
on_tag:
- lambda: ESP_LOGD("TEST", "received tag %s", x.c_str());
- text_sensor.template.publish:
id: rfid_tag
state: !lambda 'return x;'
on_key:
- lambda: ESP_LOGD("TEST", "received key %d", x);
Unfortunately, an update of the TAG (text_sensor) is sent every 60 seconds. The update_interval of the text_sensor cannot be deactivated and therefore IOBrocker gets the TAG sent every 60 seconds
I designed a little PCB to easily connect a wiegand keypad with a wemos D1 mini.
I tested it with a hikvision DS-K1101MK and works perfectly. Maybe others will work also.
I only havent tested the tamper contact input properly, because i made a mistake in my first design.
If somebody has some ideas, suggestions or improvements, i would love to hear them.
ESP home configuration
sensor:
- platform: custom
lambda: |-
auto wiegand = new WiegandReader(D6, D5);
App.register_component(wiegand);
return {wiegand};
sensors:
name: "Alarm panel 1"
on_value:
then:
- homeassistant.tag_scanned: !lambda |-
char buf[16];
sprintf(buf, "%.0f", x);
std::string s = buf;
return s;
switch:
- platform: gpio
pin: D1
name: "Alarm panel 1 red led"
- platform: gpio
pin: D2
name: "Alarm panel 1 blue led"
- platform: gpio
pin: D3
name: "Alarm panel 1 beeper"
binary_sensor:
- platform: gpio
pin: D8
name: "AlarmPanel_tamper"
filters:
- delayed_on: 10ms
Got the core sseib componenets working well with a Hikvision K1108mk RFID with keypad. I am using the key provider to process keys in node-red as the key collector component does not play nice with the keypad. Keys “*” provides an input back of “10” and “#” of “11”. As such the key collector considers this a “1”.
For this keypad the red led is always on, you can connect the red/green/buzzer lines directly to GPIOs to send a logic signal high to operate the leds/buzzer (unlike other rfid reads where the signal is sent to ground). The hardware firmware must take over on signal input as it will react in a predetermined way on each input.
Red led will pulse three times on one input, Green led will hold for about 2 seconds and buzzer pulse for 100ms. It is possible through software to keep pulsing the green and buzzer for continued output as desired.
Quick flow hacked up below that mainly uses switches and joins to track inputs over the tag_scanned event. Only successful keypad inputs or tag ids will pass.
Also, the keypad has a dip switch that allows “encryption” but no outputs would be sent when this mode was activated. Maybe my rfid tags are not compatible, more to test here. Might be that it is only available when the keypad is in OSDP RS-485 mode. In anycase someone could just jump the half meter fence…
Hey folks,
thanks to this thread and the nice work & hints here I got my Wiegand Reader working with an ESP8622 (nodemcu) and can now use access control via HA.
At start I used this implementation for esphome, which was working, but I thaught the implementation of ssieb seems to be more recent, so I switched to that one.
Working also fine, but the first one had a sensor, which showed the tags wihthin HA.
I’m sure it’s possible to create such a sensor with ssieb’s module as well, but I do have kind of a head block on how the yaml should look like. Any ideas how to pass the tag into a sensor?
(To be clear, I receive the rfid chips and keystroke pins as tag in HA and can use it. The sensor is just an added value, more a nice to have thing 
)
I’m using a reader from Sebury (sTouch ISO). It has a doorbell button, which is connected to my chime and is working as well. I noticed that pressing the doorbell button also sends a Wiegand response, (18-bit, value 2006e), so I adapted the wiegand.cpp file from ssieb and checked for that 18-bit value, where I’m now sending a “doorbell” tag to HA. If anyone is interesseted in the changed code, I’m happy to share it.
That allows me to send a push notification to our phones, informing about someone has pressed to doorbell and is waiting outside.
In the callback action from that push message I can control my door opener and let the person in.
I’m planning to install cameras around the house in the upcoming summer, so next step is to send a live stream with the push notification.
Also on my todo list is to evaluate the performace and stability of the ESP8622. Since it’s connected via WiFi, I’m not 100% convinced if it’s stable enough.
So I’m considering to change the controller to a ESP32 with PoE capability. Most probably that’s going to be the one from Olimex.
Does anyone have already experience with this microcontroller?
I assume it will work with Wiegand, just not sure about the pins to use yet.
Cheers!
Another hint/consideration:
The tag number, read from the Wiegand reader is posted as “plain” number to HA to create the tag.
Meaning, if your fob has the ID 12345678, then a tag 12345678 will be created in HA.
If you like me use a reader, which also has a keypad, and you also use the keypad integration of ssieb as in the examples above, then there might be a potential security flaw:
In case someone can read your fob and get it’s ID, he would be able to type that ID (= plain number) at the keypad and get access, since the number tag in HA will trigger the allowed actions.
To mitigate that, I edited the wiegand.cpp and added a textstring, i.e. “rfid”, before the fob ID.
That means, if I now scan the fob, it will appear not as 12345678 rather then rfid12345678.
If someone reads out my fob and type 12345678 in the keypad, he won’t get access, since the leading rfid part is missing and can’t be typed with the keypad, which only allows numbers.
Of course that might be a very unlikely scenario, but anyway, it’s not a big deal, adding the leading characters in the code and it levels up the security a little bit 
Is.this adoptable to 32 bit cards?
I’ve tried to make this work but mu fob is 32bit and the wiegand.ccp file decodes only 26 and 34 bits.
So my question is how i can alter the wieland.ccp to cope with 32.bits. tryed to alter the 34 bits but it can’t correctly calculate parity.
I have the same problem, how could it be solved? since every time the Tag is sent, the automation is activated, and it should only be when reading the card
I couldn’t find any specifications for any other bit lengths. If you have a reference, I can add it. Otherwise, you can use the raw trigger.
The wiegand component is now integrated in esphome, so you shouldn’t be using my repo any more. I will remove it from my repo in the near future to avoid confusion.
Bit of an ESPHome noob here…
Can I add this integration into a Konnected alarm board running ESPHome?
Thanks
Just figured this info would be appreciated, I’ve been running a PN532 NFC/RFID reader in a 3d printer case for around 2 years now. Tags got sent to HomeAssistant through ESPhome, compared against known values in NodeRed (managing keys is a bit of a pain, a good UI would be awesome), and would open my Zwave lock if there was a match.
Worked great, but decided I also wanted a keypad, so started looking into the Wiegand protocol. Today the KR602M keypad/RFID reader (so the MiFare verison, which you want if you also want to be able to use your phone etc) arrived, hooked it up to ESPhome and is working great! (non-afiliate link https://nl.aliexpress.com/item/4000404630544.html)
The only downside is that keypresses are not registered as Keypresses by the Wiegand protocal, but rather raw bytes. I need to figure out how to put in a translation table to translate them into key presses so the key collector can do his work, tips are appreciated.
This is the log of sequential pressing 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, esc, ent
[13:00:26][I][RAW:043]: received raw 8 bits, value e1
[13:00:26][D][wiegand:106]: received unknown 8-bit value: e1
[13:00:27][I][RAW:043]: received raw 8 bits, value d2
[13:00:27][D][wiegand:106]: received unknown 8-bit value: d2
[13:00:27][I][RAW:043]: received raw 8 bits, value c3
[13:00:27][D][wiegand:106]: received unknown 8-bit value: c3
[13:00:28][I][RAW:043]: received raw 8 bits, value b4
[13:00:28][D][wiegand:106]: received unknown 8-bit value: b4
[13:00:28][I][RAW:043]: received raw 8 bits, value a5
[13:00:28][D][wiegand:106]: received unknown 8-bit value: a5
[13:00:29][I][RAW:043]: received raw 8 bits, value 96
[13:00:29][D][wiegand:106]: received unknown 8-bit value: 96
[13:00:29][I][RAW:043]: received raw 8 bits, value 87
[13:00:29][D][wiegand:106]: received unknown 8-bit value: 87
[13:00:29][I][RAW:043]: received raw 8 bits, value 78
[13:00:29][D][wiegand:106]: received unknown 8-bit value: 78
[13:00:30][I][RAW:043]: received raw 8 bits, value 69
[13:00:30][D][wiegand:106]: received unknown 8-bit value: 69
[13:00:30][I][RAW:043]: received raw 8 bits, value f0
[13:00:30][D][wiegand:106]: received unknown 8-bit value: f0
[13:00:30][I][RAW:043]: received raw 8 bits, value 5a
[13:00:30][D][wiegand:106]: received unknown 8-bit value: 5a
[13:00:31][I][RAW:043]: received raw 8 bits, value 4b
[13:00:31][D][wiegand:106]: received unknown 8-bit value: 4b
I also considered the Olimex POE, I see no reason why they won’t work, there’s just a WROOM module on them so pins 4 and 5 for instance should be fine, if ever in doubt, this overview gives you a great overview of which pins are ok to use for what. There’s only a few which you want to avoid: ESP32 Pinout Reference: Which GPIO pins should you use? | Random Nerd Tutorials
I ultimately decided against the Olimex, because I also want to supply the RFID/keypad with power through POE (for cleanliness in wiring but also since my switches and servers are on a big USP so in case of power failure everything will stay running for around an hour). So I have a WT32-ETH01 (cheapest esp32 with ethernet) and am using a splitter that splits POE ethernet into Ethernet and a 12V connector. The 12V supplies my keypad but also (through a 12V-5V buck converter) supplies the ESP32.
That’s interesting. It’s combining the usual 4 bits of the key with the 4-bit inverse to make 8 bits. I’ll see about adding that option.
