search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
21.97k stars 4.77k forks source link

Add support for NXP PN532 NFC RFID reader #2915

Closed ghost closed 5 years ago

ghost commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Would like the same functionality

timtimsson commented 6 years ago

PN532 - letscontrolit

gabrielklein commented 5 years ago

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

In particular:

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 commented 5 years ago

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 commented 5 years ago

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

andrethomas commented 5 years ago

Still on my to-do list ;)

dknubben commented 5 years ago

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

ozett commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

ozett commented 5 years ago

👍

gemu2015 commented 5 years ago

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

ozett commented 5 years ago

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

andrethomas commented 5 years ago

@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 commented 5 years ago

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

gemu2015 commented 5 years ago

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 <notifications@github.com mailto:notifications@github.com>:

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 commented 5 years ago

May it work better via SPI interface?

gemu2015 commented 5 years ago

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 <notifications@github.com mailto:notifications@github.com>:

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 commented 5 years ago

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

ozett commented 5 years ago

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

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 commented 5 years ago

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 notifications@github.com:

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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com:

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 commented 5 years ago

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 commented 5 years ago

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

Jason2866 commented 5 years ago

Will build a lock for my garage. Hardware already ordered

andrethomas commented 5 years ago

@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 commented 5 years ago

Closing as it is added.

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

gemu2015 commented 5 years ago

@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 <notifications@github.com mailto:notifications@github.com>:

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 commented 5 years ago

@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 commented 5 years ago

@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 <notifications@github.com mailto:notifications@github.com>:

@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 commented 5 years ago

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

andrethomas commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com:

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 commented 5 years ago

@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 commented 5 years ago

ok, made if conditional

ifdef LEARN_TAGS

Am 03.01.2019 um 11:25 schrieb ozett <notifications@github.com mailto:notifications@github.com>:

@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 commented 5 years ago

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

gemu2015 commented 5 years ago

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 <notifications@github.com mailto:notifications@github.com>:

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 commented 5 years ago

@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 commented 5 years ago

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