Jmd. hat sich dem „Voodoo“ des RC522 angenommen und einen PR eingestellt:
dev ← mgoodfellow:rfid-wupa-presence
offen 07:27AM - 06 Jul 26 UTC
I've rebased onto current `dev` (`d4cffb0`) and added a second commit — plus cap… tured hard before/after evidence on a classic ESP32 (LOLIN D32 Pro) + RC522 clone. All timestamped serial traces below; each opens with the boot banner so the firmware revision is verifiable per run.
## A/B evidence, card sitting perfectly still for 10 minutes, `pauseIfRfidRemoved` on
| Firmware | `mfrc522Gain` | Spurious "RFID-tag removed" / 10 min |
|---|---|---|
| stock `dev` @ `d4cffb0` | 7 (default) | **20** — continuous pause/resume flapping for ~50 s, sub-second cycles |
| stock `dev` @ `d4cffb0` | 5 | 0 |
| this PR @ `8074410` | 7 (default) | **1** (single phantom at initial card contact — receiver saturation, see the tuning note in `docs/rfid-presence-detection.md`) |
| this PR @ `8074410` | 5 | **0** — plus 5/5 deliberate removal cycles all detected cleanly, pause on lift / resume on re-apply |
Two knock-on effects of the stock flapping worth highlighting, both in the traces:
1. **Flash wear** — every flap writes the play position to NVS (one
`Write '#...' to NVS` per spurious removal).
2. **The box deep-sleeps itself mid-playback** — the pause/resume races desync
the play/pause state, the inactivity timer arms while audio is audibly
playing, and 10 minutes later: `Going to deepsleep due to inactivity-timer...`
mid-track. On a kids' audiobook box this is "it turned itself off mid-story".
## Why the second commit (`Rfid: forget the last-seen tag when its assignment changes`) is part of this PR
The first commit fixes `lastValidcardId`'s lifetime (stock declares it inside
the task loop — uninitialised each iteration, so the "same card re-applied"
dedup effectively never fired). With the dedup *working*, a latent bug becomes
visible: re-assigning a tag in the web UI has no effect until reboot — the
re-applied card is short-circuited into play/pause and NVS is never re-read.
The existing guard (`Rfid_ResetOldRfid` on the assign path) is gated behind
`dontAcceptRfidTwice`, which `AudioPlayer.cpp` force-disables whenever
`pauseIfRfidRemoved` is on — i.e. unreachable in exactly the mode that needs it.
The second commit invalidates the reader's cache from every path that changes
what a tag means (WS + REST assign, mod-card, delete, NVS erase/restore, web-UI
play). Verified live in the same session, no reboot: card playing book A →
lifted → reassigned via `POST /rfid` to book B → re-applied → book B plays
immediately (`RFID-tag received` in the trace shows it reached the queue
instead of being deduped away).
Shipping the first commit without the second would hand every
`pauseIfRfidRemoved` user the reassign bug, so they travel together.
[trace-baseline-dev-d4cffb0.log](https://github.com/user-attachments/files/30085842/trace-baseline-dev-d4cffb0.log)
[trace-stock-dev-gain7.log](https://github.com/user-attachments/files/30085843/trace-stock-dev-gain7.log)
[trace-wupa-gain5.log](https://github.com/user-attachments/files/30085844/trace-wupa-gain5.log)
[trace-wupa-gain7.log](https://github.com/user-attachments/files/30085847/trace-wupa-gain7.log)
Ich selbst nutze weder den Reader, noch das Feature. Von daher wär’s schön, wenn das mal jmd. testen könnte, der/die das tut.
Noch was: Man kann das RC522-Gain inzwischen auch über das Webinterface bequem einstellen. Das ist per Default auf 7 gesetzt. Der PR-Ersteller meinte, dass er mit 5 bessere Erfahrungen gemacht habe. Hier ist die Frage, ob man darauf hinweist oder ob man den Default auf 5 reduziert.
1 „Gefällt mir“