Add support for NXP PN532 NFC RFID reader

[ghost]

Have you look for this feature in other issues and in the wiki?
Yes

Is your feature request related to a problem? Please describe.
Support for NFC RFID reader NXP PN532 as per:
https://www.adafruit.com/product/364
On I2C address 0x48

**Describe the solution you'd like **
Device is selectable / dectected

Describe alternatives you've considered
Can't see any thing else

Additional context
Add any other context or screenshots about the feature request here.

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

[Frogmore42]

But, what do you expect to do with it?
What use case do you envision for this, or it is it just good enough that Tasmota can see there is an NFC reader there?

[ghost]

It will be good if it recognised the device and was able to read the serial number off the RFID tag but then sent into mqtt broker for custom automations.

Ok ?

Btw - I've looked at ESPEasy and ESPurna and I'm really liking Tasmota - seems so much better

[andrethomas]

Should be possible in theory - you'd need to use one of the input pins for the IRQ from the PN532 and then read the card data over I2C - I'm uncertain on how this will impact on the way other I2C devices (mostly sensors) are polled in a cyclic fashion and perhaps not as frequently as you'd need for the PN532 data to be received in a timeous manner.

That said, it may be easier to just use a standalone esp8266 to send the data to your mqtt server but let's see if others have comments on how to implement?

I have a PN532 somewhere but it's not the same as the one from adafruit but I guess its just the protocol that needs to work.

[ghost]

Ok brill! Thanks.

This is the cheap eBay one I've just ordered...

https://rover.ebay.com/rover/0/0/0?mpre=https%3A%2F%2Fwww.ebay.co.uk%2Fulk%2Fitm%2F152819843755

[andrethomas]

Looks like one of the ones I have somewhere... let me know when you get it and look at the implementation from https://github.com/adafruit/Adafruit-PN532/blob/master/examples/iso14443a_uid/iso14443a_uid.pde with specific reference to

// Or use this line for a breakout or shield with an I2C connection:
//Adafruit_PN532 nfc(PN532_IRQ, PN532_RESET);

Looks like you need to use the reset pin during initialisation also...

[ghost]

Ok thanks. My unit turned up, I need to solder the pins and get a basic connection going (as per your link which seems to use I2C) and I might even test it via ESPEasy but would sooner use Tasmota ;) cheers

Edit: I found this hookup example with example code using I2C which I thought I would add if it helps:

http://rdiot.tistory.com/173

[Snipercaine]

I'm also hoping to use Tasmota on a D1mini or NodeMCU with the RF522 reader to read the card ID and send an MQTT message.
I'll be struggling with a home-made Arduino sketch in the meantime.

[simonbove]

Would like the same functionality

[timtimsson]

PN532 - letscontrolit

[gabrielklein]

I like the idea.... it would be great to support a subset of NDEF messages (NFC).

In particular:

• Raw data => send a message using MQTT
• http: or https => directly call a url (get or post) => usefull for quick simple api calls

It means you can write data on a rfid card using an android application, and "program" cards to send messages like "toggle light 15", "pause VLC application", etc...

As an example if I have on a card "LIGHT1/TOGGLE ON", the mqtt message ON will be sent on channel "/sonoff/xxx/yyy/LIGHT1/TOGGLE"

[Eina61]

I would love RFID functionality on a Tasmota device - except I am using Weigand protocol.
I have an existing Weigand system but I find the WiFi connection to be very unstable whereas all my Tasmota units connections are rock solid all the time.

[robrec]

would also love this function. Especial with the sonoff SV, this would be so awesome....

[andrethomas]

Still on my to-do list ;)

[dknubben]

Here is a good working solution:
https://github.com/esprfid/esp-rfid
(RC522, PN532, Wiegand, RDM6300 and MQTT support)

[ozett]

if anybody get to work on the code, may consider also wiegand-input.
if have it running with espeasy, but would love to see it also on tasmota.
(there a more details in the espeasy-forum, if needed, but is an easy thing)

[Jason2866]

To get it working nice with Tasmota SPI interface has to be used.
Since SPI is not (yet) there. It needs some more time.

[andrethomas]

SPI is available... also software SPI is used in xdsp_05_epaper_29.ino so should be pretty easy to integrate from a working PN532 sketch.

[ozett]

maybe some pattern for a motivated coder?

PN532:
https://github.com/letscontrolit/ESPEasy/blob/mega/src/_P017_PN532.ino

Wiegand:
https://github.com/letscontrolit/ESPEasy/blob/f53a9533a4be9a790abf47d54fd2409e4ebe31fe/src/_P008_RFID.ino

[andrethomas]

@ozett
Will look at it after the festivities are over :)

[ozett]

👍

[gemu2015]

i have an initial i2c version working on my universal branch. you may give it a try.
https://github.com/gemu2015/Sonoff-Tasmota

[ozett]

🆒 (cool!)
i will grab some wemos-d1 and some spare-reader and will see how it goes.
i come back with report ..

[andrethomas]

@gemu2015 works perfectly just copying the sensor ino file and the library over.

Just needs to be cleaned up a little to remove the serial prints etc and then it can be PR'd to here I guess.

[andrethomas]

On second thought I think I will continue with a self-contained driver...

[gemu2015]

this is work in progress, sending the tag id is just the first thing, in the end it MUST be "self contained" what i have in mind ist the following: depending on a locking hardware switch, the driver can enter a "configuration mode" where we can learn a number of tags and their operation mode eg. toggle or pulse a relais here we also may lock the remote switching of a relais, so that it can only be activated by the tag. but there are still issues with the reader. it sometimes becomes unresponsive and can only be woken by a power cycle. this is not acceptable and i think of toggling the reset pin at startup. the main problem is that the driver has no polling mode, it just waits for a tag forever. i simply did set the timeout to 200 ms so that the driver returns with a timeout error. i also tried a kind of multitasking by recursive calling the main loop, but this also has issues. we probably have to rewrite the driver for real polling of the device

…

Am 02.01.2019 um 01:24 schrieb Andre Thomas ***@***.*** ***@***.***>>: On second thought I think I will continue with a self-contained driver... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2915 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALG4Yyf8onjtevgYblb3JwOEdu6j7icAks5u-_xOgaJpZM4UbCVH>.

[Jason2866]

May it work better via SPI interface?

[gemu2015]

we have 3 options: I2C, SPI and serial through hardware abstraction we have the very same api, so also no polling. May be i will try serial interface. (only 2 lines instead of 4) however i2c now worked for several hours with no issues. (after enabling clock stretching)

…

Am 02.01.2019 um 16:51 schrieb Jason2866 ***@***.*** ***@***.***>>: May it work better via SPI interface? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2915 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALG4Y4BrpdQ7_G4NLUEjeRgx9oAsNqcfks5u_NWagaJpZM4UbCVH>.

[gemu2015]

thanks for implementing! i squeezed the TAG struct to 8 bytes per tag, so i will claim 80 bytes for now. i made a new branch from the current development and added the eeprom support to pn532 for the first approach i simply copied the whole struct to ram on init and back on saving a tag. it works!

…

Am 04.01.2019 um 16:14 schrieb Theo Arends ***@***.*** ***@***.***>>: I did add eeprom function support for test purposes. As it uses the same flash page as the settings it allows for up to flashpage size (4096) - settings size (3584) - margin (4) = 508 bytes. The EEPROM data is stored at the end of the page so future settings area growth are being tackled as long as you keep the eeprom area as small as possible. As eeprom functions are global within Tasmota only one user can actually use it with chance of being corrupted by another user. All EEPROM functions are supported where the function calls equal the original library calls but instead of calling EEPROM.begin(20) you need to call EepromBegin(20). Search settings.ino for correct syntax. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2915 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALG4Y1irCAXSKDep0vHD537QyrsO06Woks5u_2_jgaJpZM4UbCVH>.

[gemu2015]

@andrethomas <https://github.com/andrethomas> thanks for the reflash fix! however there are side effects. since FUNC_SAVE_BEFORE_RESTART is misleading because it is called whenever settings are saved, saving vars stops the driver. either @arendst <https://github.com/arendst> introduces a real FUNC_SAVE_BEFORE_RESTART and new FUNC_SAVE_VARS or we have to use a reset toggle. i would like to avoid using a reset but there are other issues sometimes the pn532 stops working with the clock line being low while there is still activity on the data line! this indicates that the pn532 pulls the clock line low. can a slave i2c device pull the clock low? btw i changed the learning driver for tag access to the eeprom driver. this was coding fun but doesnt solve any memory problems. a real eeprom would do that, but the esp has only a flash and therefore emulates an eeprom with ram backup as needed for flash. i think the eeprom support in ESP Arduino is only for porting AVR programs easier. as the space in the settings area gets low the whole settings method should probably be changed in the future. (eg conditional defines) another remark: i changed the polling interval to 250 ms because the polling uses about 75 ms. the timeout of 10 ms per PN532_readResponse is not working as expected.

[andrethomas]

we have to use a reset toggle.

Resetting the PN532 does not bring the I2C functionality back to life so it must be the ESP which is holding the I2C bus low (which does not make sense after a soft restart), or the reset pin on the PN532 is only for SPI functionality - idk for sure.

FUNC_SAVE_BEFORE_RESTART

Only happens for me on restart or restart after OTA.

I have not tested if it is called when saving VAR's but it should not be - Will test later during the day.

i changed the polling interval to 250 ms

Also done this already in the current codebase. I have not seen problems with the 10ms timeout but I do get problems with it < 6 which is why I left it on 10.

[gemu2015]

i had frequent hangs which i did not have with my old version. the ic pulled the clock down (proven by desoldering scl => esp generates clocks)

after enabling clock stretching i did not have any more hangs
https://circuitpython.readthedocs.io/projects/pn532/en/latest/examples.html
and also the data sheet says that the pn532 needs clock stretching in i2c mode.

Wire.setClockStretchLimit(1000);

[andrethomas]

I'll need to tackle it with a logic analyzer as I cannot reproduce the timeout anymore.

If it needs to be changed when transacting with the PN532 then it may need to be reverted after the I2C transaction is done as to not impair other connected I2C devices.

[gemu2015]

from the theory it should not affect other i2c devices. e.g. the sgp30 enables clock stretching and i use it for month together with others on the same i2c bus. other devices simply do not stretch the clock cycle. (hold down scl) without it i get a block after 10-30 tag accesses with stretching i get no blocks any more. but if you are in doubt we can switch it on only for the pn532

…

Am 05.01.2019 um 19:05 schrieb Andre Thomas ***@***.*** ***@***.***>>: I'll need to tackle it with a logic analyzer as I cannot reproduce the timeout anymore. If it needs to be changed when transacting with the PN532 then it may need to be reverted after the I2C transaction is done as to not impair other connected I2C devices. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2915 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALG4Y_4bEK5KN7RJANaRCI5RNxpORRJpks5vAOlagaJpZM4UbCVH>.

[andrethomas]

In the Tasmota codebase it is only done in the CCS811 afaik... but yes, in theory, it cannot break anything else.

[gemu2015]

yes i meant the ccs811 not the sgp30 (i use both in different devices)

…

Am 05.01.2019 um 19:39 schrieb Andre Thomas ***@***.***>: In the Tasmota codebase it is only done in the CCS811 afaik... but yes, in theory, it cannot break anything else. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2915 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALG4Y_ht6ftk7RuD6Ksc_FUq0sWgwUJEks5vAPFzgaJpZM4UbCVH>.

[andrethomas]

Cool. Let me hook it up to a logic analyzer so I can back the change with confidence... just to satisfy my pedantic nature :)

[andrethomas]

PR #4832 made to enable Wire.setClockStretchLimit(1000); in line with datasheet Table 12.25 (Timing for the I2C interface)

[qingz2004]

I tried to use a rule with PN532.
I write it the same way as other sensors, but it does not work.

rule1 on PN532#UID=1234ABCD do power toggle endon

While this works.

rule1 on EVENT#PN532=1234ABCD do power toggle endon

I don't know the why.

[ozett]

looks like second verson for rule is coded this way ...

sprintf(command,"event PN532=%s",uids);

https://github.com/gemu2015/Sonoff-Tasmota/blob/png532/sonoff/xsns_40_pn532_i2c.ino#L416

--- i looked up the wiki for rule-definition:
both syntax version should be somehow possible according to wiki :

dont know, if on version2 the UID is within syntax of wiki,
but looks like a good and understandble syntax

[gemu2015]

@andrethomas

btw your hex formatter doesnt work properly. it suppresses the leading zeros of each hex nibble

[andrethomas]

@qingz2004 @ozett

rule1 on PN532#UID=1234ABCD do power toggle endon

Will not work because the driver does not publish telemetry like a sensor - It has no callback to collect the telemetry data because usually by the time telemetry data is collected it is too late to act on a card that was present 300 seconds ago.

So the telemetry is generated immediately and sent over MQTT but the local device cannot do anything with it - This is only intended for home automation purposes.

This is why the event was added - To enable action on the device and as was shown above the correct way to capture it currently is

rule1 on EVENT#PN532=1234ABCD do power toggle endon

The short answer is that events are handled differently to immediate telemetry messages and differently to telemetry data collected for teleperiod.

@gemu2015 Thx, unintentional feature :) Fixed with PR #4842

[qingz2004]

@andrethomas Got it. Thanks!

[qingz2004]

Possible to support write or copy?

[andrethomas]

@qingz2004 It is possible but not necessary for Tasmota to have this functionality.

[qingz2004]

Understand. Read only is good enough for home automation.

[qingz2004]

Can we read more info from the tag besides the UID? I try to use my android phone to emulate a tag, the UID is different each time. So I can't use the UID for judgement.

[andrethomas]

@qingz2004

It depends...

Mifare Classic compatible card (the one with 4 bytes uid, i.e. "AABBCCDD") requires authentication with a known key to read the data block. These are the most commonly used cards and although they could have factory default key of 0xFFFFFFFFFFFF I find mine to not respond to that.

The Mifare Ultralight card (the one with 7 bytes uid i.e. "AABBCCDDEEFFAA") does not seem to require authentication but are less commonly found... I do not have one so I cannot confirm this.

Maybe @arendst will explore this when he receives his module board but I'm inclined to think the UID is fine for automation purposes.

[ozett]

Can we read more info from the tag besides the UID? I try to use my android phone to emulate a tag, the UID is different each time. So I can't use the UID for judgement.

think the random UID happens because of android implementation:
https://stackoverflow.com/questions/27239473/get-static-nfc-tag-id-with-hce-mode

i have seen that with the nfc/rfid-function of the german passport
i commented it on a RFID-youtube-video

Unique Identifier (UID, [ISO 14443] Typ A) ==> gets ==>
Pseudo-Unique PICC Identifier (PUPI, [ISO 14443] Typ B)

beim deutschen personalausweis wird immer einer ander ID erzeugt beim auslesen. eine sicherheitsfunktion: 
"Entsprechend dem korrekten Verhalten eines RFID-Tags benötigt auch der nPA-Chip einen Unique Identifier zur Adressierung im Feld des Lesegeräts. 
Um eine Identifizierung des Nutzers schon auf RFID-Ebene zu verhindern (Tracking) 
„wird der Unique Identifier (UID, [ISO 14443] Typ A) bzw. der Pseudo-Unique PICC Identifier (PUPI, [ISO 14443] Typ B) 
des Chips bei jeder Aktivierung des Chips zufällig erzeugt“ ([TR-03127], S. 8).  
aus. "https://sar.informatik.hu-berlin.de/research/publications/SAR-PR-2011-09/diplomarbeit-mj-print_.pdf", S.27 
 -- spannende Funktion. müsste man mal untersuchen

(german language original)

[gemu2015]

just as an info: i can write to all of my (blank classic) cards with the default key
there are also UID writeable cards, cloning is a matter of seconds, so don't rely just on UID for very secure locks

[gemu2015]

@andrethomas
may be you can not write to your cards because the write block routine is defective in the pn532 GitHub drivers. i discovered the bug and implemented block read and write commands, format NDEF and write NDEF records. don't know if we have a use for that in Tasmota,

[ozett]

discovered the bug and implemented block read and write commands, format NDEF and write NDEF records. don't know if we have a use for that in Tasmota,

since 2016 i rely with my nfc/rfid-door opener only on the UID. everythings fine with this.
Because there have been no other attractive solutions for makers around.
but it would be somehow more than "nice" to brand all my own tags/keys only for only my own doors with a encrypted secret on the tags (but this could raise the ususal "what is really secure/secret" discussion, and maybe out of scope for tasmota itself?
i personally would love to see it... 👍

[andrethomas]

@gemu2015

i discovered the bug and implemented block read and write commands, format NDEF and write NDEF records. don't know if we have a use for that in Tasmota,

Worth checking out, thanks :)

[qingz2004]

PN532 HSU mode does not work with core 2.3.0. I have to use core 2.4.2.