Tasmota: Add support for NXP PN532 NFC RFID reader

[markcarline]

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?

[markcarline]

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.

[markcarline]

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...

[markcarline]

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.

[Damontir]

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

[andrethomas]

Still on my to-do list ;)

[smittna]

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 <[email protected] [e-mail]>:

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 https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-450768065, 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 <[email protected] [e-mail]>:

May it work better via SPI interface?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-450899895, or mute the thread https://github.com/notifications/unsubscribe-auth/ALG4Y4BrpdQ7_G4NLUEjeRgx9oAsNqcfks5u_NWagaJpZM4UbCVH.

[Jason2866]

Is clock stretch related to this?
https://github.com/esp8266/Arduino/issues/5528
https://github.com/esp8266/Arduino/pull/5489

[ozett]

i had similar problems back in 2016 with espeasy and the pn532 rfid-readers. as i am no coder, the developer "martinus" fixed it (as far as i remember) with some tweaks on the i2c driver/code.
there were problems with reading and first the reset pin was necessary

• [ ] may you look here for i2c here

• [ ] i2c clock-streching on esp8266 core v2. explicit here

• [ ] but there were some forum hints, which said:
  run the reader from 5V, not 3.3V here

• [ ] other hints said:
  get a distance between esp8266 and the pn532-board here

developer "martinus said he patched the esp-core for clock streching back in 2016 to fix bus errors

nd it seems that there's I2C clock stretching going on with more than the usual delay, approx. 250 uSecs

And I also found out that the Arduino ESP core does not seem to support clock stretching for more than 100 uSec. (mentioned as a comment inside the library). So we seem to have found the root cause for these bus resets...

I2C Clock stretching beyond Arduino ESP Core limits.

Just to prove this theory, I decided to patch the ESP core I2C library to allow for up to 1 mSec clock stretching, uploaded the same sketch again and started the tag robot for the next run.

This morning results after approx. 14 hours run:

817 tag movements
2450 tag reads
162140 reader checks
0 bus errors (!)

maybe patching core v2. is obsolete in 2019...(??)
sorry, i am no coder..maybe this helps developers..

[gemu2015]

thanks for the hints. i will stick a while with i2c it looks more stable now. otherwise i will switch to serial.

Am 02.01.2019 um 17:06 schrieb ozett [e-mail]:

i had similar problems [back in 2016] (https://www.letscontrolit.com/forum/viewtopic.php?f=4&t=502 https://www.letscontrolit.com/forum/viewtopic.php?f=4&t=502) with espeasy and the pn532 rfid-readers.
as i am no coder,
the developer "martinus" fixed it (as far as i remember) with [some tweaks] (https://www.letscontrolit.com/forum/viewtopic.php?p=2802#p2802 https://www.letscontrolit.com/forum/viewtopic.php?p=2802#p2802) on the i2c driver/code.
there were problems with reading and first the [reset pin] (https://www.letscontrolit.com/forum/viewtopic.php?p=7842#p7842 https://www.letscontrolit.com/forum/viewtopic.php?p=7842#p7842) was necessary

may you look here for i2c here https://github.com/esp8266/Arduino/blob/master/cores/esp8266/core_esp8266_si2c.c
i2c clock-streching on esp8266 core v2. explicit [here]
(https://www.letscontrolit.com/forum/viewtopic.php?p=3659#p3659 https://www.letscontrolit.com/forum/viewtopic.php?p=3659#p3659)

but there were some forum hints, which said:
run the reader from 5V, not 3.3V here https://www.letscontrolit.com/forum/viewtopic.php?f=6&t=3854&p=34097&hilit=PN532#p34097
other hints said:
get a distance between esp8266 and the pn532-board [here] (https://www.letscontrolit.com/forum/viewtopic.php?p=7868#p7868 https://www.letscontrolit.com/forum/viewtopic.php?p=7868#p7868)

developer "martinus [said] (https://www.letscontrolit.com/forum/viewtopic.php?p=3659#p3659 https://www.letscontrolit.com/forum/viewtopic.php?p=3659#p3659) he patched the esp-core for clock streching back in 2016 to fix bus errors

nd it seems that there's I2C clock stretching going on with more than the usual delay, approx. 250 uSecs

And I also found out that the Arduino ESP core does not seem to support clock stretching for more than 100 uSec. (mentioned as a comment inside the library). So we seem to have found the root cause for these bus resets...

I2C Clock stretching beyond Arduino ESP Core limits.

Just to prove this theory, I decided to patch the ESP core I2C library to allow for up to 1 mSec clock stretching, uploaded the same sketch again and started the tag robot for the next run.

This morning results after approx. 14 hours run:

817 tag movements
2450 tag reads
162140 reader checks
0 bus errors (!)
maybe patching core v2. is obsolete in 2019...
sorry, i am no coder..maybe this helps developers..

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-450904271, or mute the thread https://github.com/notifications/unsubscribe-auth/ALG4YxvyHRUkCZm7R2cdjyFP4_cPG03Tks5u_NkYgaJpZM4UbCVH.

[ozett]

i have it running with espeasy since 2016.
as long as i wire the reset-line everthings is fine.
but i would like to switch to tasmota with my pn532 and my wiegand readers

(for wiegand see simple explantion here i will post links to some code in the request-thread, which is somehow strange closed "as duplicate" of the pn532, but the wiegand is not i2c, i guess. I have Wiegang-NFC (and also fingerprint) also working since 2016 without hassle. wiegand is "only" prococol, pn532 is "only" protocol on i2c (?).
Overall i would like to switch to tasmota with all my devices).

[gemu2015]

ok a preliminary stand alone version is ready

current Sensor93 cmds:

==========================
add tag => a r m t r=relay number, m=mode 0=off, 1=on, 2=toggle,3=pulse with t milliseconds
waits for tag and adds it

example: type sensor93 a 1 2 0 in console, then apply tag

adds a tag to toggle relay1

==========================

delete index => d i i=index from 1 to N (currently 10)
immediately deletes stored tag index

example: type sensor93 d 1 in console, this immediately deletes tag nr 1 from the list

==========================

delete tag => D
waits for tag and deletes it

example: type sensor93 D in console, apply tag deletes this tag from the list

==========================

show index entry => s i i=index from 1 to N (currently 10)
display tag UID , relaynumber, mode and time

example: type sensor93 s 1 in console show index 1 of tag table

tags added to the list report via MQTT via their index, not their UID, while tags not in list report via UID

Am 02.01.2019 um 17:17 schrieb ozett [e-mail]:

i have it running with espeasy since 2016.
as long as i wire the reset-line everthings is fine.
but i would like to switch to tasmota with my pn532 and my wiegand readers

(for wiegand i will post linkt to code in the request-thread, which is some closed "as duplicate" of the pn532, but the wiegand is not i2c, i guess. I have Wiegang-nfc (and fingerprint) also working since 2016 without hassle, but would also like to switch to tasmota with all my devices)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-450907569, or mute the thread https://github.com/notifications/unsubscribe-auth/ALG4YyTYH-WZtOijbvo6BN6PRzeaN_THks5u_NurgaJpZM4UbCVH.

[andrethomas]

PR for the inclusive driver has been made here https://github.com/arendst/Sonoff-Tasmota/pull/4791

@gemu2015 - I found the reason why your driver stops working after some time.

In your code when you do not find a tag you need to begin and end transmission to release the I2C bus otherwise it gets kept low after some time by the PN532 and you will find error 4 on i2cscan... so basically the PN532 is holding the I2C bus busy.

Have a look at my PN532_readPassiveTargetID and you will see I added

Wire.beginTransmission(PN532_I2C_ADDRESS);
Wire.endTransmission();

before returning false for PN532_readPassiveTargetID on line 265.

I love the tag learning ideas you got going btw :)

[arendst]

Ordered hardware and find out what I should do with it using latest driver from @andrethomas

[Jason2866]

Will build a lock for my garage. Hardware already ordered

[andrethomas]

@arendst Will be keeping an eye on what you add to the driver after you find out what you are going to do with it :)

[ascillato2]

Closing as it is added.

Thanks everyone for sharing their ideas :+1: Good job!!!

[gemu2015]

@andrethomas https://github.com/andrethomas

thanks for your hints. i wanted to have all interface options open, but i clearly prefer your driver!!!

i will switch to your driver and add my "learning" options as i always prefer autonomous IOT devices especially with locks.

i developed key and rfid based locks 20 years ago with pic controllers and assembly language. i use several of these old devices and want to replace them now.

but for locks it is mandatory not to compromise UDIDs or remote control of the lock itself unless we have an extremely secure web interface. (which we will not have on tasmota)

Am 02.01.2019 um 21:16 schrieb Andre Thomas <[email protected] [e-mail]>:

PR for the inclusive driver has been made here #4791 https://github.com/arendst/Sonoff-Tasmota/pull/4791
@gemu2015 https://github.com/gemu2015 - I found the reason why your driver stops working after some time.

In your code when you do not find a tag you need to begin and end transmission to release the I2C bus otherwise it gets kept low after some time by the PN532 and you will find error 4 on i2cscan... so basically the PN532 is holding the I2C bus busy.

Have a look at my PN532_readPassiveTargetID and you will see I added

Wire.beginTransmission(PN532_I2C_ADDRESS);
Wire.endTransmission();
before returning false for PN532_readPassiveTargetID on line 265.

I love the tag learning ideas you got going btw :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-450972474, or mute the thread https://github.com/notifications/unsubscribe-auth/ALG4Y6FZpHSGjuxxBtMxvlPRCOIJ5G44ks5u_ROegaJpZM4UbCVH.

[andrethomas]

@gemu2015 I think the learning function is a good idea especially in a localised use case where (1) you do not want the uid to be transmitted over mqtt and (2) you have a stand-alone lock scenario.

I think if we can find a way to store custom driver information in flash without having to have it within the Settings structure it could be useful as adding it to the Settings structure as we currently do for most device configuration it consumes ram which is unnecessary for these kinds of use cases.

@arendst Any inputs on how we can use flash storage outside of ram based Settings structure in a reliable way? :)

[gemu2015]

@andrethomas https://github.com/andrethomas a non ram based settings structure would be fine. dont know if that is doable.

i definitely want my locks being autonomous, if the server fails i want to get in anyhow. reporting the activity and status of the lock however is a nice feature.

i have pushed your modified driver so you can check the (preliminary) learning feature. (the settings.h is modified also)

Am 03.01.2019 um 09:48 schrieb Andre Thomas <[email protected] [e-mail]>:

@gemu2015 https://github.com/gemu2015 I think the learning function is a good idea especially in a localised use case where (1) you do not want the uid to be transmitted over mqtt and (2) you have a stand-alone lock scenario.

I think if we can find a way to store custom driver information in flash without having to have it within the Settings structure it could be useful as adding it to the Settings structure as we currently do for most device configuration it consumes ram which is unnecessary for these kinds of use cases.

@arendst https://github.com/arendst Any inputs on how we can use flash storage outside of ram based Settings structure in a reliable way? :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-451083380, or mute the thread https://github.com/notifications/unsubscribe-auth/ALG4Y-Q7n54ae4mw_bpb3bFhjvdg5aVEks5u_cPjgaJpZM4UbCVH.

[arendst]

U haven't looked at it but how about using rules to save or act on a rfid

[andrethomas]

a non ram based settings structure would be fine. dont know if that is doable.

It is doable - Question is if and how @arendst would allow the implementation.

Unlike the Settings structure it will only be written to when new uid's are added or old ones are removed so it can most likely be a fixed offset from end of SPI flash for a particular driver's requirements.

So basically you can still have an array of uid data, only that it will be read into ram one at a time for comparison - this increases the number of uid's that can be stored and reduces the ram requirement for the functionality.

struct RFID {
  uint8_t uid[7];
  uint8_t len;
  uint8_t relay;
  uint8_t mode;
  uint16_t time;
};

But we need to define some form of standard to handle this kind of data management.

[andrethomas]

U haven't looked at it but how about using rules to save or act on a rfid

That is what I currently do...

11:37:33 CMD: rule
11:37:33 MQT: stat/sonoff/RESULT = {"Rule1":"ON","Once":"OFF","StopOnError":"OFF","Free":466,"Rules":"on event#PN532=94D8FC5F do power toggle endon"}
11:37:35 MQT: tele/sonoff/SENSOR = {"Time":"2019-01-03T11:37:35","PN532":{"UID":"94D8FC5F"}}
11:37:35 MQT: stat/sonoff/RESULT = {"Event":"Done"}
11:37:35 RUL: EVENT#PN532=94D8FC5F performs "power toggle"
11:37:35 MQT: stat/sonoff/RESULT = {"POWER":"ON"}
11:37:35 MQT: stat/sonoff/POWER = ON
11:37:42 MQT: tele/sonoff/SENSOR = {"Time":"2019-01-03T11:37:42","PN532":{"UID":"94D8FC5F"}}
11:37:42 MQT: stat/sonoff/RESULT = {"Event":"Done"}
11:37:43 RUL: EVENT#PN532=94D8FC5F performs "power toggle"
11:37:43 MQT: stat/sonoff/RESULT = {"POWER":"OFF"}
11:37:43 MQT: stat/sonoff/POWER = OFF

[gemu2015]

that is nice, but doesnt solve the problem of exposing the UID. i send only a fake UID when tag is learned.

i use a hardware switch for locking the configuration, this switch should later also lock the relays and the possibly web interface as a whole so that only mqtt activity is transmitted and no manipulation possible

Am 03.01.2019 um 10:38 schrieb Andre Thomas [e-mail]:

U haven't looked at it but how about using rules to save or act on a rfid

That is what I currently do...

11:37:33 CMD: rule
11:37:33 MQT: stat/sonoff/RESULT = {"Rule1":"ON","Once":"OFF","StopOnError":"OFF","Free":466,"Rules":"on event#PN532=94D8FC5F do power toggle endon"}
11:37:35 MQT: tele/sonoff/SENSOR = {"Time":"2019-01-03T11:37:35","PN532":{"UID":"94D8FC5F"}}
11:37:35 MQT: stat/sonoff/RESULT = {"Event":"Done"}
11:37:35 RUL: EVENT#PN532=94D8FC5F performs "power toggle"
11:37:35 MQT: stat/sonoff/RESULT = {"POWER":"ON"}
11:37:35 MQT: stat/sonoff/POWER = ON
11:37:42 MQT: tele/sonoff/SENSOR = {"Time":"2019-01-03T11:37:42","PN532":{"UID":"94D8FC5F"}}
11:37:42 MQT: stat/sonoff/RESULT = {"Event":"Done"}
11:37:43 RUL: EVENT#PN532=94D8FC5F performs "power toggle"
11:37:43 MQT: stat/sonoff/RESULT = {"POWER":"OFF"}
11:37:43 MQT: stat/sonoff/POWER = OFF
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-451093867, or mute the thread https://github.com/notifications/unsubscribe-auth/ALG4YwEk2EZQJbC6AFQiYlAbV2_eLTAGks5u_c-fgaJpZM4UbCVH.

[ozett]

@gemu2015

as i have no concerns with my whole IOT-house-security,
or wifi-security in special,
i would like to transmit the UID from the reader to my node-red.
without any difficulties like with fake-UID or anythin else.

plain-text as it is normal in tasmota and that would be fine for me.

i rely on my wifi-encryption and on the mqtt-encrytion with tls.

for your concerns, maybe you code an option to activate ("Very secure") and than your fake-UID an other stuff gets active and maybe than you disable the whole Web-interface? (and only rely afterwards on secured mqtt?)

[gemu2015]

ok, made if conditional

ifdef LEARN_TAGS

Am 03.01.2019 um 11:25 schrieb ozett <[email protected] [e-mail]>:

@gemu2015 https://github.com/gemu2015
as i have no concerns with my whole IOT-house-security,
or wifi-security in special,
i would like to transmit the UID from the reader to my node-red.
without any difficulties like with fake-UID or anythin else.

plain-text as it is normal in tasmota and that would be fine for me.

i rely on my wifi-encryption and on the mqtt-encrytion with tls.

for your concerns, maybe you code an option to activate ("Very secure") and than your fake-UID an other stuff gets active and maybe than you disable the whole Web-interface? (and only rely afterwards on secured mqtt?)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-451104707, or mute the thread https://github.com/notifications/unsubscribe-auth/ALG4YyqOWcET9TCs6BAQCQQNli4yQsrjks5u_dqWgaJpZM4UbCVH.

[simonbove]

I would also like to have UID plain text transmitted through mqtt 😊

[gemu2015]

just for the non coders =>

this is the default behavior also in the "learning" version. the learning options just uses some more memory.

this default behavior is already implemented in the published tasmota version

Am 03.01.2019 um 12:57 schrieb simonbove <[email protected] [e-mail]>:

I would also like to have UID plain text transmitted through mqtt 😊

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-451123613, or mute the thread https://github.com/notifications/unsubscribe-auth/ALG4Y29_0yktSesuWAypi2Hl6ToXmkyBks5u_fAqgaJpZM4UbCVH.

[gemu2015]

@andrethomas https://github.com/andrethomas
while after a power cycle or a restart via the webui the reader always came up correctly, after reflashing it often hanged and could only be reanimated by a power cycle.
can you confirm this ? (i use a wemos-d1 for development)
probably we need a reset pin toggle here like others reported with espeasy.

[andrethomas]

@gemu2015 Thx for the information - will see if I can reproduce and fix it :)

[arendst]

I'm starting to investigate if the EEPROM function can be used to save non-settings info. It will be a challenge as currently the settings area is within the arduino core EEPROM area but using a kind of mask I guess I can make it work for up to about 500 bytes.

Question arising is what is the normal size of a RFID UID? Can it always be handled by a uint32_t so up to 8 hex digits? Is it a problem if it is forced to only 8 digits?

[gemu2015]

currently the struct is 12 bytes

struct RFID {
uint8_t uid[7];
uint8_t len;
uint8_t relay;
uint8_t mode;
uint16_t time;
};

we can squeeze a bit, but the uid is either 4 or 7 bytes, therefore we need the length info, as we have only 2 length this is only 1 bit

length 1 bit
relay 3 bits
mode 2 bits
time depends on what you want for pulse time

result is 9-10 bytes

Am 04.01.2019 um 12:14 schrieb Theo Arends <[email protected] [e-mail]>:

I'm starting to investigate if the EEPROM function can be used to save non-settings info. It will be a challenge as currently the settings area is within the arduino core EEPROM area but using a kind of mask I guess I can make it work for up to about 500 bytes.

Question arising is what is the normal size of a RFID UID? Can it always be handled by a uint32_t so up to 8 hex digits? Is it a problem if it is forced to only 8 digits?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-451417142, or mute the thread https://github.com/notifications/unsubscribe-auth/ALG4YzBYOVawpIAJ-cS1Ed1eRDA1pyVDks5u_zemgaJpZM4UbCVH.

[arendst]

OK. How about linking the UID to a switch. In that case the switch settings like pulsetime can be used and do not need to be configured again for RFID.

So like I did with the TM1638 switches just map up to eight RFID UID's to a switch number. In that case the location of the UID within the stored RFID array dictates the switch number. All other dependencies are controlled by normal switch handling.

[gemu2015]

why not it may be ok.

however the pulse function is only needed to replace a remote control or pushbutton eg. at a garage door. we may only need a fixed pulse time there and then it would fit into 8 bytes.

Am 04.01.2019 um 12:27 schrieb Theo Arends [e-mail]:

OK. How about linking the UID to a switch. In that case the switch settings like pulsetime can be used and do not need to be configured again for RFID.

So like I did with the TM1638 switches just map up to eight RFID UID's to a switch number. In that case the location of the UID within the stored RFID array dictates the switch number. All other dependencies are controlled by normal switch handling.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-451419500, or mute the thread https://github.com/notifications/unsubscribe-auth/ALG4Y2ULg9dDF5WYVoS4XYoD8uz4odkPks5u_zqLgaJpZM4UbCVH.

[gemu2015]

think of we can have many keys for the same relay that would not work with a fixed relation to switches

Am 04.01.2019 um 12:27 schrieb Theo Arends [e-mail]:

OK. How about linking the UID to a switch. In that case the switch settings like pulsetime can be used and do not need to be configured again for RFID.

So like I did with the TM1638 switches just map up to eight RFID UID's to a switch number. In that case the location of the UID within the stored RFID array dictates the switch number. All other dependencies are controlled by normal switch handling.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-451419500, or mute the thread https://github.com/notifications/unsubscribe-auth/ALG4Y2ULg9dDF5WYVoS4XYoD8uz4odkPks5u_zqLgaJpZM4UbCVH.

[arendst]

You're right.

[andrethomas]

@gemu2015 I could reproduce within 10 OTA's on the current driver.

After making changes proposed in PR https://github.com/arendst/Sonoff-Tasmota/pull/4815 I could not reproduce after 20 OTA's

[arendst]

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.

[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 <[email protected] [e-mail]>:

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 https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-451471248, 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 <[email protected] [e-mail]>:

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 https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-451677714, 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 [e-mail]:

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 https://github.com/arendst/Sonoff-Tasmota/issues/2915#issuecomment-451680223, 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 https://github.com/arendst/Sonoff-Tasmota/pull/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 https://github.com/arendst/Sonoff-Tasmota/pull/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.