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
1 Like
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…
1 Like
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!
1 Like
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.
@jcort try this:
external_components:
- source: github://ssieb/esphome@wiegand
components: [ wiegand ]
Thanks so much! Works like a dream
It has now been merged to dev, so it will be in the next release.
1 Like
Thank you so much! I can actually strongly recommend the aforementioned keypad/mifare reader, really affordable and seems to work like a charm!
Hi, I’ve gotten my esp device up and running with all of your various helpful tips through this sub. I can see in the esphome event log that a tag is read…it does say something about invalid parity. And doesn’t show up under a tag_scanned event either. Ant help?
Hi, I’m trying to use Olimex ESP32-POE with the Hikvision DS-K1108MK reader but I’m having trouble getting it to work. When I press a number or swipe a badge, I always receive random errors like this:
00:59:21 [D] [wiegand:116] received unknown 6-bit value: 1
01:02:00 [D] [wiegand:116] received unknown 5-bit value: 3
01:02:01 [D] [wiegand:116] received unknown 6-bit value: c
01:02:01 [D] [wiegand:116] received unknown 7-bit value: f
01:02:02 [D] [wiegand:116] received unknown 6-bit value: 18
01:02:03 [D] [wiegand:116] received unknown 6-bit value: 1b
01:02:03 [D] [wiegand:116] received unknown 6-bit value: 1e
01:02:05 [D] [wiegand:116] received unknown 6-bit value: 30
01:02:06 [D] [wiegand:116] received unknown 7-bit value: 63
01:02:07 [D] [wiegand:116] received unknown 7-bit value: 1f
01:02:08 [D] [wiegand:116] received unknown 7-bit value: 18
01:02:09 [D] [wiegand:116] received unknown 7-bit value: c
01:02:10 [D] [wiegand:116] received unknown 6-bit value: 3
01:02:14 [D] [wiegand:116] received unknown 61-bit value: 18c67ffe6f07e3f
01:02:17 [D] [wiegand:116] received unknown 58-bit value: ccdfff9bc0fc3f
01:02:18 [D] [wiegand:116] received unknown 58-bit value: 3199fff6787e3f
01:02:21 [D] [wiegand:116] received unknown 58-bit value: 2633fff3787e3f
Here is the ESPHome code I’m using:
substitutions:
devicename: keypad-ext
esphome:
name: keypad-ext
friendly_name: keypad-ext
platform: ESP32
board: esp32-poe
wifi:
networks:
- ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: "$devicename Hotspot"
password: !secret password
captive_portal:
web_server:
port: 80
logger:
api:
password: !secret password
ota:
password: !secret password
mqtt:
broker: !secret mqtt_server
username: !secret mqtt_username
password: !secret mqtt_password
on_message:
- topic: "keypad-ext/switch/keypad-ext_led_green/command"
payload: "on"
qos: 1
then:
- switch.turn_on: green
- topic: "keypad-ext/switch/keypad-ext_led_red/command"
payload: "on"
qos: 1
then:
- switch.turn_on: red
switch:
- platform: restart
name: "$devicename restart"
- platform: gpio
id: beeper
pin: GPIO16
name: "${devicename} Beeper"
restore_mode: ALWAYS_OFF
on_turn_on:
then:
- delay: 1s
- switch.turn_off: beeper
- platform: gpio
id: green
pin: GPIO32
name: "${devicename} Green"
restore_mode: ALWAYS_OFF
on_turn_on:
then:
- delay: 1s
- switch.turn_off: green
- platform: gpio
id: red
pin: GPIO13
name: "${devicename} Red"
on_turn_on:
then:
- delay: 1s
- switch.turn_off: red
wiegand:
- id: mykeypad
d0: GPIO5
d1: GPIO4
on_key:
- lambda: ESP_LOGI("KEY", "received key %d", x);
on_tag:
- lambda: ESP_LOGI("TAG", "received tag %s", x.c_str());
- mqtt.publish:
topic: -ext/tag
payload: !lambda 'return str_sprintf("%s", x.c_str());'
key_collector:
- id: pincode_reader
source_id: mykeypad
min_length: 4
max_length: 10
end_keys: "#"
end_key_required: false
back_keys: "*"
clear_keys: "#"
allowed_keys: "0123456789"
timeout: 5s
on_progress:
- logger.log:
format: "key%s"
args: [ 'x.c_str()']
- mqtt.publish:
topic: keypad-ext/key
payload: !lambda 'return str_sprintf("%s", x.c_str());'
I’m temporarily powering Olimex using a phone charger connected to the microUSB connector (I will use POE later), while Hikvision is powered by a 12V power supply and its GND is connected to the GND of Olimex. Where am I doing wrong? Thanks
I was able to get the keypad to work most of the time by changing the wiring of D0 to GPIO13 and D1 to GPIO15. If I press the keys quickly they are not recognized but if I press them slowly almost all of them are recognized. Instead the most serious problem is the one with tags that are almost never recognized (it works about once in 20). What could be the cause?
|01:29:57|[I]|[RAW:121]|received raw 36 bits, value 265fd63c7|
|01:29:57|[D]|[wiegand:116]|received unknown 36-bit value: 265fd63c7|
|01:30:06|[I]|[RAW:121]|received raw 36 bits, value 24bfd63c7|
|01:30:06|[D]|[wiegand:116]|received unknown 36-bit value: 24bfd63c7|
|01:30:11|[I]|[RAW:121]|received raw 36 bits, value 325fdb1c7|
|01:30:11|[D]|[wiegand:116]|received unknown 36-bit value: 325fdb1c7|
|01:30:18|[I]|[RAW:121]|received raw 34 bits, value 92feb1c7|
|01:30:18|[D]|[wiegand:082]|received 34-bit tag: 1233082595|
|01:30:18|[I]|[TAG:116]|received tag 1233082595|
|01:30:25|[I]|[RAW:121]|received raw 39 bits, value 1337fb71c7|
|01:30:25|[D]|[wiegand:116]|received unknown 39-bit value: 1337fb71c7|
|01:30:32|[I]|[RAW:121]|received raw 38 bits, value 92ffb638f|
|01:30:32|[D]|[wiegand:116]|received unknown 38-bit value: 92ffb638f|
|01:30:39|[I]|[RAW:121]|received raw 40 bits, value 265ffac78f|
|01:30:39|[D]|[wiegand:116]|received unknown 40-bit value: 265ffac78f|
|01:30:41|[I]|[RAW:121]|received raw 38 bits, value 997f5c78f|
|01:30:41|[D]|[wiegand:116]|received unknown 38-bit value: 997f5c78f|
|01:30:44|[I]|[RAW:121]|received raw 37 bits, value 497fb63c7|
|01:30:44|[D]|[wiegand:091]|received 37-bit tag: 9864851939|
|01:30:44|[W]|[wiegand:093]|invalid parity|
|01:30:46|[I]|[RAW:121]|received raw 35 bits, value 125fd63c7|
|01:30:46|[D]|[wiegand:116]|received unknown 35-bit value: 125fd63c7|
I don’t know if this information is useful: I can’t do the OTA update because i always get the error “Wrong Magic Byte”. If instead I download the BIN file I can flash it without any error with esptool:
roberto@archlinux ~ [2]> sudo esptool.py write_flash 0x0 '/home/roberto/Downloads/keypad-ext-factory (23).bin'
esptool.py v4.5.1
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting.........
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting.........
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision v3.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: xx:xx:Xx:xx:xx:xx
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x000e2fff...
Compressed 928304 bytes to 575776...
Wrote 928304 bytes (575776 compressed) at 0x00000000 in 50.7 seconds (effective 146.4 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...