wiegand No UID in version 11

[drbios]

PROBLEM DESCRIPTION

A clear and concise description of what the problem is.
Wiegand Protocol problem NO UID in version tasmota 11 or 10.1, only works in tasmota 10 in 26bit not 34bit

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues
• Searched the problem in discussions
• Searched the problem in the docs
• Searched the problem in the chat
• Device used (e.g., Sonoff Basic): esp32 MH-ET LIVE MiniKit
• Tasmota binary firmware version number used: tasmota 10.0.1, tasmota 11.0
  • Pre-compiled
  • [X ] Self-compiled
• [] Flashing tools used: ESP-Flasher-Windows-x64
• Provide the output of command: Backlog Template; Module; GPIO 255:

  Configuration output here:
19:00:41.794 CMD: Backlog Template; Module; GPIO 255
19:00:41.795 SRC: WebConsole from 192.168.0.41
19:00:41.797 CMD: Grp 0, Cmnd 'BACKLOG', Idx 1, Len 26, Data 'Template; Module; GPIO 255'
19:00:41.828 SRC: Backlog
19:00:41.829 CMD: Grp 0, Cmnd 'TEMPLATE', Idx 1, Len 0, Data ''
19:00:41.840 MQT: stat/EMLL_62DE74/RESULT = {"NAME":"ESP32-DevKit","GPIO":[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,1,1,1,0,1,1,1,0,0,0,0,1,1,1,1,1,0,0,1],"FLAG":0,"BASE":1}
19:00:42.054 SRC: Backlog
19:00:42.055 CMD: Grp 0, Cmnd 'MODULE', Idx 1, Len 0, Data ''
19:00:42.065 MQT: stat/EMLL_62DE74/RESULT = {"Module":{"1":"ESP32-DevKit"}}
19:00:42.304 SRC: Backlog
19:00:42.305 CMD: Grp 0, Cmnd 'GPIO', Idx 1, Len 3, Data '255'
19:00:42.320 MQT: stat/EMLL_62DE74/RESULT = {"GPIO0":{"0":"None"},"GPIO1":{"0":"None"},"GPIO2":{"0":"None"},"GPIO3":{"0":"None"},"GPIO4":{"0":"None"},"GPIO5":{"6720":"SDCard CS"},"GPIO6":{"0":"None"},"GPIO7":{"0":"None"},"GPIO8":{"0":"None"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO11":{"0":"None"},"GPIO12":{"0":"None"},"GPIO13":{"0":"None"},"GPIO14":{"0":"None"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"},"GPIO17":{"0":"None"},"GPIO18":{"736":"SPI CLK1"},"GPIO19":{"832":"SSPI MISO"},"GPIO20":{"0":"None"},"GPIO21":{"6944":"Wiegand D1"},"GPIO22":{"6912":"Wiegand D0"},"GPIO23":{"704":"SPI MOSI1"},"GPIO24":{"0":"None"},"GPIO25":{"640":"I2C SDA1"},"GPIO26":{"0":"None"},"GPIO27":{"608":"I2C SCL1"},"GPIO32":{"0":"None"},"GPIO33":{"0":"None"},"GPIO34":{"0":"None"},"GPIO35":{"0":"None"},"GPIO36":{"0":"None"},"GPIO37":{"0":"None"},"GPIO38":{"0":"None"},"GPIO39":{"0":"None"}}

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

• Provide the output of this command: Status 0:

  STATUS 0 output here:
19:02:35.994 CMD: Status 0
19:02:35.995 SRC: WebConsole from 192.168.0.41
19:02:35.996 CMD: Grp 0, Cmnd 'STATUS', Idx 1, Len 1, Data '0'
19:02:36.004 MQT: stat/EMLL_62DE74/STATUS = {"Status":{"Module":1,"DeviceName":"Tasmota","FriendlyName":["Tasmota"],"Topic":"EMLL_62DE74","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0,"InfoRetain":0,"StateRetain":0}}
19:02:36.011 MQT: stat/EMLL_62DE74/STATUS1 = {"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"http://ota.tasmota.com/tasmota32/release/tasmota32.bin","RestartReason":"Vbat power on reset","Uptime":"0T00:13:23","StartupUTC":"2022-02-13T21:49:13","Sleep":50,"CfgHolder":4617,"BootCount":7,"BCResetTime":"2022-02-13T17:46:07","SaveCount":23}}
19:02:36.015 MQT: stat/EMLL_62DE74/STATUS2 = {"StatusFWR":{"Version":"11.0.0(tasmota)","BuildDateTime":"2022-02-13T20:35:34","Core":"2_0_2_2","SDK":"v4.4-3-g6afb23d90a","CpuFrequency":240,"Hardware":"ESP32-D0WDQ6","CR":"411/699"}}
19:02:36.019 MQT: stat/EMLL_62DE74/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":4,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["70324_iot_wc",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008009","2805C80001000600003C5A0A190000000000","00000080","00006000","00004400"]}}
19:02:36.032 MQT: stat/EMLL_62DE74/STATUS4 = {"StatusMEM":{"ProgramSize":1468,"Free":1856,"Heap":108,"StackLowMark":2,"PsrMax":0,"PsrFree":0,"ProgramFlashSize":4096,"FlashSize":4096,"FlashFrequency":40,"FlashMode":3,"Features":["00000809","97DAC7CF","001DA001","B7F7BFCF","05DA9FC0","E0360DC7","000840D2","24200000","0030482D"],"Drivers":"1,2,3,4,5,7,8,9,10,11,12,14,16,17,20,21,24,26,27,29,34,35,38,50,52,59","Sensors":"1,2,3,5,6,7,8,9,10,11,12,13,14,15,17,18,19,20,21,22,26,28,31,33,34,37,39,40,42,43,45,51,52,55,56,58,59,64,66,67,74,82,85,92,95,127"}}
19:02:36.045 MQT: stat/EMLL_62DE74/STATUS5 = {"StatusNET":{"Hostname":"EMLL-62DE74-7796","IPAddress":"192.168.0.70","Gateway":"192.168.0.1","Subnetmask":"255.255.255.0","DNSServer1":"8.8.8.8","DNSServer2":"8.8.4.4","Mac":"3C:71:BF:62:DE:74","Webserver":2,"HTTP_API":1,"WifiConfig":4,"WifiPower":17.0}}
19:02:36.050 MQT: stat/EMLL_62DE74/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.0.254","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_62DE74","MqttUser":"pi","MqttCount":1,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30,"SOCKET_TIMEOUT":4}}
19:02:36.056 MQT: stat/EMLL_62DE74/STATUS7 = {"StatusTIM":{"UTC":"2022-02-13T22:02:36","Local":"2022-02-13T19:02:36","StartDST":"2022-03-27T02:00:00","EndDST":"2022-10-30T03:00:00","Timezone":"-03:00","Sunrise":"07:16","Sunset":"20:35"}}
19:02:36.060 BRY: GC from 7751 to 4046 bytes, objects freed 11/39 (in 0 ms)
19:02:36.070 MQT: stat/EMLL_62DE74/STATUS10 = {"StatusSNS":{"Time":"2022-02-13T19:02:36","ESP32":{"Temperature":35.6},"TempUnit":"C"}}
19:02:36.075 BRY: GC from 4162 to 3841 bytes, objects freed 2/39 (in 0 ms)
19:02:36.080 MQT: stat/EMLL_62DE74/STATUS11 = {"StatusSTS":{"Time":"2022-02-13T19:02:36","Uptime":"0T00:13:23","UptimeSec":803,"Heap":110,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":21,"MqttCount":1,"Berry":{"HeapUsed":3,"Objects":39},"Wifi":{"AP":1,"SSId":"70324_iot_wc","BSSId":"68:FF:7B:32:AF:E8","Channel":11,"Mode":"11n","RSSI":98,"Signal":-51,"LinkCount":1,"Downtime":"0T00:00:03"}}}

• Set weblog to 4 and then, when you experience your issue, provide the output of the Console log:

  Console output here:
19:03:50.005 MQT: tele/EMLL_62DE74/SENSOR = {"Time":"2022-02-13T19:03:49","Wiegand":{"UID":lu,"Size":0}}

TO REPRODUCE

Steps to reproduce the behavior:
read a rfid card

EXPECTED BEHAVIOUR

A clear and concise description of what you expected to happen.
%prefix%/%topic%/SENSOR = {"Time":"2021-01-21T16:04:12","Wiegand":{"UID":7723428,"Size":26}}

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

ADDITIONAL CONTEXT

Add any other context about the problem here.
in version tasmota 10 when i use 26bit or 34bit protocol in the reader i receive a UID code for every user
in verion 10.0.1 or 11.0 UID=lu and size= a big number or some time to time just 0

(Please, remember to close the issue when the problem has been addressed)

[barbudor]

@arendst looks like you worked quite a lot on this one
It looks like the protocol might be sensitive to timings.
May be something changed when Espressif SDK was upgraded ?

[drbios]

@arendst looks like you worked quite a lot on this one It looks like the protocol might be sensitive to timings. May be something changed when Espressif SDK was upgraded ?

I don't Know ... maybe the author of the code may know more, the code is the same but you may Right about the SDK

[arendst]

Will add it to my list

[drbios]

Will add it to my list

Thank You very much Theo for all your amazing work , i know you can fix it :) best regards.

[arendst]

Verified to fail. Investigating...

Seeing lu must ring a bell as it is probably related to specifier %llu which might not be supported anymore in latest esp32 idf.

[arendst]

UPDATE:

We removed support for 64-bit numbers. I have to jump through loops to get it back. Hexadecimal does works now. Still thinking about a clean 64-bit decimal output.

[drbios]

UPDATE:

We removed support for 64-bit numbers. I have to jump through loops to get it back. Hexadecimal does works now. Still thinking about a clean 64-bit decimal output.

Thank you very, very much, I really appreciate your dedication and help in solving this kind of thing

[drbios]

UPDATE:

We removed support for 64-bit numbers. I have to jump through loops to get it back. Hexadecimal does works now. Still thinking about a clean 64-bit decimal output.

I just compiled the version with the fix you made, and it works fine. I can indicate the following:

1. If I put 34bit output in the reader, tasmota reads the card number that is registered and shows it without problems
2. If I put 26-bit output in the reader, tasmota receives a code different from the number assigned in the reader but different for each registered user, as it worked before.

both ways works without activating Setoption123

15:17:54.034 MQT: tele/EMLL_62DE74/SENSOR = {"Time":"2022-02-14T15:17:54","Wiegand":{"UID":688523312,"Size":34}}
15:14:31.921 MQT: tele/EMLL_62DE74/SENSOR = {"Time":"2022-02-14T15:14:31","Wiegand":{"UID":16770365,"Size":26}}

[arendst]

Pls try the same with so123 1 and report the json output.

[drbios]

Pls try the same with so123 1 and report the json output.

This are the codes in the reader

card1: 134210877
card2: 688523312

SetOption123=0

Reader 26bit output, tasmota received:
card1:
16:16:39.503 MQT: tele/EMLL_62DE74/SENSOR = {"Time":"2022-02-14T16:16:39","Wiegand":{"UID":16770365,"Size":26}}
(with UIDvar=Wiegand#UID, print %UIDvar% ... it give me this number 16770365.00)
card2:
16:16:00.520 MQT: tele/EMLL_62DE74/SENSOR = {"Time":"2022-02-14T16:16:00","Wiegand":{"UID":657456,"Size":26}}
(with UIDvar=Wiegand#UID, print %UIDvar% ... it give me this number 657456.00)

Reader set 34bit output, tasmota received:
card1:
16:18:30.724 MQT: tele/EMLL_62DE74/SENSOR = {"Time":"2022-02-14T16:18:30","Wiegand":{"UID":134210877,"Size":34}}
(with UIDvar=Wiegand#UID, print %UIDvar% ... it give me this number 134210880.00)
card2:
16:19:14.405 MQT: tele/EMLL_62DE74/SENSOR = {"Time":"2022-02-14T16:19:14","Wiegand":{"UID":688523312,"Size":34}}
(with UIDvar=Wiegand#UID, if i print %UIDvar% ... it give me this number 688523328.00)

SetOption123=1

Reader 26bit output, tasmota received:
card1:
16:29:07.150 MQT: tele/EMLL_62DE74/SENSOR = {"Time":"2022-02-14T16:29:07","Wiegand":{"UID":"FFE53Dh","Size":"1Ah"}}
(with UIDvar=Wiegand#UID, print %UIDvar% ... it give me this number FFE53Dh)
card2:
16:29:39.123 MQT: tele/EMLL_62DE74/SENSOR = {"Time":"2022-02-14T16:29:39","Wiegand":{"UID":"A0830h","Size":"1Ah"}}
(with UIDvar=Wiegand#UID, print %UIDvar% ... it give me this number A0830h)

Reader set 34bit output, tasmota received:
card1:
16:32:48.653 MQT: tele/EMLL_62DE74/SENSOR = {"Time":"2022-02-14T16:32:48","Wiegand":{"UID":"107FFE53Dh","Size":"22h"}}
(with UIDvar=Wiegand#UID, print %UIDvar% ... it give me this number 107FFE53Dh)
card2:
16:33:22.541 MQT: tele/EMLL_62DE74/SENSOR = {"Time":"2022-02-14T16:33:22","Wiegand":{"UID":"1290A0830h","Size":"22h"}}
(with UIDvar=Wiegand#UID, if i print %UIDvar% ... it give me this number 1290A0830h)

[arendst]

Thx. Nice test.

Using your two cards these are the known values:

card1: 134210877 = 0x7FFE53D = 27-bit code at least, 32-bit probably (0x07FFE53D)
card2: 688523312 = 0x290A0830 = 30-bit code at least, 32-bit probably (0x290A0830)

Setting wiegand to 26-bit mode will loose bits resulting in 24-bit data:

card1: 134210877 = 0x3FFE53D = 67102013 but you receive only 0xFFE53D = 24-bit = 16770365
card2: 688523312 = 0x10A0830 = 17434672 but you receive only 0x0A0830 = 24-bit = 657456

Setting wiegand to 34-bit mode should read all bits resulting in 32-bit data:

card1: 134210877 = 0x07FFE53D and you receive 134210877 in decimal mode but 0x107FFE53D in hex mode (leading 1)
card2: 688523312 = 0x290A0830 and you receive 688523312 in decimal mode but 0x1290A0830 in hex mode (leading 1)
The hex representation is apparently wrong by adding a leading 1. I will find a solution.

The next issue you encounter is the fact that rule variables cannot handle decimal numbers over 23-bit as numbers are converted to floating point values. So if you want to use rules switch to SO123 1 to use hexadecimal output which does work fine.

EDIT: I just dived into the wiegand protocol and see that what is called 26-bits in fact is 24-bit data, 1-bit parity and 1-bit checksum so the noticed 24-bit values are as expected.

[drbios]

Thx. Nice test.

Using your two cards these are the known values:

card1: 134210877 = 0x7FFE53D = 27-bit code at least, 32-bit probably (0x07FFE53D) card2: 688523312 = 0x290A0830 = 30-bit code at least, 32-bit probably (0x290A0830)

Setting wiegand to 26-bit mode will loose bits resulting in 24-bit data:

card1: 134210877 = 0x3FFE53D = 67102013 but you receive only 0xFFE53D = 24-bit = 16770365 card2: 688523312 = 0x10A0830 = 17434672 but you receive only 0x0A0830 = 24-bit = 657456

Setting wiegand to 34-bit mode should read all bits resulting in 32-bit data:

card1: 134210877 = 0x07FFE53D and you receive 134210877 in decimal mode but 0x107FFE53D in hex mode (leading 1) card2: 688523312 = 0x290A0830 and you receive 688523312 in decimal mode but 0x1290A0830 in hex mode (leading 1) The hex representation is apparently wrong by adding a leading 1. I will find a solution.

The next issue you encounter is the fact that rule variables cannot handle decimal numbers over 23-bit as numbers are converted to floating point values. So if you want to use rules switch to SO123 1 to use hexadecimal output which does work fine.

EDIT: I just dived into the wiegand protocol and see that what is called 26-bits in fact is 24-bit data, 1-bit parity and 1-bit checksum so the noticed 24-bit values are as expected.

Excellent explanation :D, so the answer, like many things in this cruel world is... use Hexadecimal numbers XD
infinite thanks for your time and help.

[arendst]

Latest change solves the extra bit in the hexadecimal presentation caused by wrong mapping of 34-bit value keeping parity bit into the value.

All observed issues should be fixed now.

Under the hood I see some opportunities for fixing other issues not relevant to the end result. In short, as the maximum data bit count is 32-bits, I'll rewrite all uint64_t code to uint32_t solving future presentation issues.

[drbios]

Latest change solves the extra bit in the hexadecimal presentation caused by wrong mapping of 34-bit value keeping parity bit into the value.

All observed issues should be fixed now.

Under the hood I see some opportunities for fixing other issues not relevant to the end result. In short, as the maximum data bit count is 32-bits, I'll rewrite all uint64_t code to uint32_t solving future presentation issues.

thank you very much theo, the great work and dedication is appreciated