Implemented new plugin "NFC Commands" by juehv · Pull Request #4655 · nightscout/AndroidAPS

juehv · 2026-03-30T18:56:04Z

The PR is related to
#4613

MilosKozak · 2026-03-31T10:01:30Z

From my point of view, this is very nice research project. But it's targeting just a few people, maybe. Nothing with mass usage. I keep this open for discussion.

juehv · 2026-03-31T14:00:42Z

Thanks for the quick response. I am not entirely sure what you mean by “research.” I understood it as suggesting that this feature has limited practical value, and I would disagree with that assessment.

For me, this plugin provides a real improvement in daily use. Being able to trigger a command by tapping an NFC tag at places like the shower or kitchen table is much more convenient than navigating through multiple menus each time.

More broadly, AndroidAPS already includes a number of optional features that are only relevant to smaller groups of users. That is part of its strength: users can configure it to fit their own needs and workflows. I see the NFC Commands plugin in the same category.

From an engineering perspective, the implementation is cleanly separated through the existing plugin system and follows the same command model and safeguards as closely as practical. In my view, it is a safe and maintainable addition.

Unfortunately, I do not have the time to actively promote the plugin outside the normal contribution process. If it is not accepted into the main repository, and later documented in Read the Docs, most users will likely never discover it, since many do not regularly follow issue discussions.

If there are specific technical, safety, or maintenance concerns, I would be happy to discuss them and improve the implementation where needed.

MilosKozak · 2026-03-31T18:32:25Z

That's why keeping this open for discussion. If there will be more people interested, I can change my mind ...

lightswitch2159 · 2026-03-31T22:01:16Z

A shower NFC tag to trigger a 30 min disconnect would be great, I often just don't trigger a disconnect due to it being annoying to do, or not thinking about it. Simply hitting a NFC tag in my bathroom would be huge.

xitation · 2026-04-01T10:10:25Z

I use NFC tags with Home Assistant already, the ability to trigger things in AAPS would be handy with tags around the house. Start the breakfast/meal pre-bolus or temp target with a tap would be ace, rather than using time based that becomes hard if you sleep in etc.

…_commands

juehv · 2026-04-04T14:32:29Z

I improved the UX a bit. Also, I added a branch for everybody to try the plugin based on AAPS 3.4.2.1 --> https://github.com/juehv/AndroidAPS/tree/patch-nfc

sonarqubecloud · 2026-04-04T14:32:46Z

Quality Gate passed

Issues
27 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.3% Duplication on New Code

See analysis details on SonarQube Cloud

Philoul · 2026-04-30T07:39:28Z

I have hundred of old FSL sensors (I had FSL v1 with a miaomiao transmitter a long time ago 😉)

All FSL sensors includes NFC communication.

Does your plugin work with this kind of NFC tag?

if yes you could have thousands of potential users for your plugin (it could be a simple way to re-use old sensors, FSL 2 also use NFC for activation...)

juehv · 2026-04-30T08:48:01Z

I have hundred of old FSL sensors (I had FSL v1 with a miaomiao transmitter a long time ago 😉)

All FSL sensors includes NFC communication.

Does your plugin work with this kind of NFC tag?
* if yes you could have thousands of potential users for your plugin (it could be a simple way to re-use old sensors, FSL 2 also use NFC for activation...)

This is a very interesting idea!
I don't know what kind of NFC tag the FSL 1/2/3 use. From the top of my head I remember that FSL1 was quite exotic at that time. I quickly tried on my FSL 3, but it's not working out of the box. Also I don't know if they are write-able at all (as they are not intended for that ... I could imagine that Abbot made them read-only).

I will definitely dig into that. But on the other hand, the set of 30 NTAGS in sticker size is around 5 EUR... So the question for a user is more "Does it relax my daily routine or not". And for me it's a game changer: I have one at my shower to disconnect pump, one at my kitchen table to set target eating soon and the same in my office on the door. Since I have them, I not only have to do less menu clicking, but also with the tags in my sight I forget it less often.

Philoul · 2026-04-30T09:27:51Z

I tried to install on my dev config to test your PR but it still requires a few updates:

a few merge conflicts on latest dev (easy to fix)
but preference management should be reworked
User Interface no more use fragment but compose code

For read only NFC tags, if you have a unique ID available for each tag, do you need write access?

what you store within the tag could be stored in preferences (i.e. json string with tag ID and associated commands) 🤔 (just personal thoughts 😉)

Philoul · 2026-04-30T10:01:45Z

I dive a bit on NFC tags (I build my first transmitter with an ESP32 for BT communication associated with a BM019 hardware for NFC communication 7 years ago...)
https://github.com/Philoul/LimitTer-ESP32/tree/master

Communication protocol of NFC 1 and 2 is ISO/IEC 15693

NFC 1 probably had write access (for most of them) but are no more used
NFC 2 has been fixed by Abbot to remove all write capabilities (and crypto layer added)

It could probably work if we limit communication to only read the UID of the FSL sensor and nothing else... (then everything should be stored on phone side associated with the UID)...

juehv · 2026-05-03T18:33:41Z

I dive a bit on NFC tags (I build my first transmitter with an ESP32 for BT communication associated with a BM019 hardware for NFC communication 7 years ago...) https://github.com/Philoul/LimitTer-ESP32/tree/master

Communication protocol of NFC 1 and 2 is ISO/IEC 15693
* NFC 1 probably had write access (for most of them) but are no more used

* NFC 2 has been fixed by Abbot to remove all write capabilities (and crypto layer added)
It could probably work if we limit communication to only read the UID of the FSL sensor and nothing else... (then everything should be stored on phone side associated with the UID)...

I agree this should work fine, but this is quite a bit less secure. At the moment I write a JWT that includes the ID of the token on the token. It has a limited lifetime which gets automatically renewed every now and then. That means I'm always 100% sure the token is placed and written by me, and no other person could change the command that is executed.

For me this feels quite secure (and safe in a consequence). I think it won't be too complicated to add a read-only option but it's hard to communicate non technical people the difference... Or do you think that's non of an issue?

juehv · 2026-05-03T18:36:18Z

I tried to install on my dev config to test your PR but it still requires a few updates:
* a few merge conflicts on latest dev (easy to fix)

* but preference management should be reworked

* User Interface no more use fragment but compose code
For read only NFC tags, if you have a unique ID available for each tag, do you need write access?
* what you store within the tag could be stored in preferences (i.e. json string with tag ID and associated commands) 🤔 (just personal thoughts 😉)

Ah yes, I saw the GUI is changing quite a bit. I developed the plugin before the last merge.

Baseline question is, will the plugin be merged or not. Because if I'm the only user I'd rather target the master branch, as I'm using the plugin every day.

Philoul · 2026-05-03T19:32:14Z

Baseline question is, will the plugin be merged or not. Because if I'm the only user I'd rather target the master branch, as I'm using the plugin every day.

All new features will now be targeted in v4.0 and following versions.
On current master (TBC by @MilosKozak ), I think only bug fix will be included.

You can of course continue to use it in your local version with v3, but your PR should be updated with V4 for a potential merge.

That means I'm always 100% sure the token is placed and written by me, and no other person could change the command that is executed.

Not sure to understand correctly the way it works currently, and security impact (better or worse) with a read only tag (if we keep the idea to re-use old FSL sensor) 🤯.

In your current solution, where are the commands associated to a tag? Within the tag or within AAPS?

My idea was to just read the NFC tag UID. That way it's 100% secure (to modify something a hacker should hack your phone, but nothing can be done on the tag 🤔)... Am I wrong ?

juehv · 2026-05-08T08:21:50Z

All new features will now be targeted in v4.0 and following versions. On current master (TBC by @MilosKozak ), I think only bug fix will be included.

You can of course continue to use it in your local version with v3, but your PR should be updated with V4 for a potential merge.

Ok thanks for clarification.

Not sure to understand correctly the way it works currently, and security impact (better or worse) with a read only tag (if we keep the idea to re-use old FSL sensor) 🤯.

In your current solution, where are the commands associated to a tag? Within the tag or within AAPS?
* My idea was to just read the NFC tag UID. That way it's 100% secure (to modify something a hacker should hack your phone, but nothing can be done on the tag 🤔)... Am I wrong ?

Currently the command is written on the tag as part of the JWT token. However, the phone manages a redundant database of the commands on the tags (but only for reference).

Changing to only reading the tag id and ignoring any content requires the command chain to be on the phone. If we consider the phone as "safe", both designs are equally secure (according to a security expert colleague of me).

If you think that provides a value to someone I would spend a weekend to change the implementation (along with some other items on my todo list). Would be great if you can check if that works well with the FSL1 tags.

Philoul · 2026-05-08T08:41:20Z

@juehv I just installed "NFC Tools" in my phone to scan my different old FSL sensors 😯(I'm really a rooky on this topic 😂)

with NFC Tools, I can read all my old FSL sensors, but I can't write anything on them
they all have a unique serial number

I now understand a bit better the standard way to use NFC tags (writing commands on tag), but information stored within NFC tags should not be "sensitive" on a safety/security point of view. For me it's not the case concerning an AAPS command (deliver bolus, stop loop, etc are in my mind very sensitive so they shouldn't be stored within tags).

I think that keeping every sensitive information within AAPS is probably easier (code simplified) and much more secure:

no need to implement a security layer concerning tags (password management for tags, read /write information within tag, crypto layer, lock tag as read only 🤔...)
a simple list of map of tag UID and associated commands can be stored (as a json string) within AAPS preferences
when you have several diabetic persons in the same family, each one can have their own commands for the same tag

Just my thoughts 😉

juehv · 2026-05-08T08:55:33Z

@juehv I just installed "NFC Tools" in my phone to scan my different old FSL sensors 😯(I'm really a rooky on this topic 😂)
* with NFC Tools, I can read all my old FSL sensors, but I can't write anything on them

* they all have a unique serial number
I now understand a bit better the standard way to use NFC tags (writing commands on tag), but information stored within NFC tags should not be "sensitive" on a safety/security point of view. For me it's not the case concerning an AAPS command (deliver bolus, stop loop, etc are in my mind very sensitive so they shouldn't be stored within tags).

I think that keeping every sensitive information within AAPS is probably easier (code simplified) and much more secure:
* no need to implement a security layer concerning tags (password management for tags, read /write information within tag, crypto layer, lock tag as read only 🤔...)

* a simple list of map of tag UID and associated commands can be stored (as a json string) within AAPS preferences

* when you have several diabetic persons in the same family, each one can have their own commands for the same tag
Just my thoughts 😉

Ok then let's do it. This weekend is already full but next week I have the time to do it. Although I still have to figure out how the new UI is working ... but I'll manage :D

I'll update the existing pull request as soon as I'm done.

xitation · 2026-05-13T12:17:38Z

Yeh I agree, from a security perspective the only think on the tag should be a unique identifier that AAPS can read to trigger an action / automation. All the logic on this should be within AAPS i'd say, but configurable on what the string/code/hex value is that is read from the tag. Then you could really use any tag that already has a readable value on it to trigger that automation without the need to write anything to a tag (unless you wanted too for some reason).

Ideally when setting up the automation you could tap the tag to read the value into the trigger field within that automation to make easy of use better?

…_commands # Conflicts: # app/src/main/kotlin/app/aaps/activities/MyPreferenceFragment.kt # app/src/main/kotlin/app/aaps/di/PluginsListModule.kt # implementation/src/main/kotlin/app/aaps/implementation/userEntry/UserEntryPresentationHelperImpl.kt # plugins/main/src/main/kotlin/app/aaps/plugins/main/di/PluginsModule.kt # ui/src/main/res/drawable/ic_nfc.xml

juehv · 2026-05-17T15:53:50Z

@Philoul I worked this weekend on the NFC Plugin and run into a potential issue:

What if FSL is used as glucose source and a new tag is scanned?

Android's passive NFC dispatch follows a strict priority chain:
NDEF_DISCOVERED > TECH_DISCOVERED > TAG_DISCOVERED.
Registering ACTION_TAG_DISCOVERED is safe, it only fires when no higher-priority app claimed the tag, so it cannot break CGM sensor reading by apps like LibreLink (which win via TECH_DISCOVERED).

Proposed approach (three layers):

Keep ACTION_NDEF_DISCOVERED + vnd.app.aaps.command for tags written by AAPS. The NDEF payload no longer carries the command — it only carries a tag ID that maps to a command stored on the phone. This preserves the tight dispatch (only AAPS-written tags trigger the activity) while moving the command definition off the physical tag.
Add ACTION_TAG_DISCOVERED as a fallback to support arbitrary tags (blank tags, finished Libre sensors, etc.) identified purely by UID. Caveat: if another app has a matching TECH_DISCOVERED filter for that tag type (e.g. LibreLink for NfcV sensors), it wins and AAPS does not receive the scan. This is intentional, we prefer that over breaking other services.
Foreground dispatch in the main UI (opt-in setting): when the user enables it and AAPS is in the foreground, the app registers NfcAdapter.enableForegroundDispatch() which has the highest priority and intercepts any tag before LibreLink. This allows scanning NfcV tags (finished Libre sensors) even with LibreLink installed, at the cost of requiring AAPS to be the active screen (and modification of main activity) -> less convenient, but functional.

What are your thoughts on this?

Philoul · 2026-05-17T19:34:34Z

I just tried your plugin on my dev phone:
Impossible to scan one of my old FSL to register it:

I move slowly the old libre on the back of my phone, but nothing is recognized...
If I hit the android button to switch to another app, I immediatly see an Android Popup to select either eDropletNFC, LibreLink or xDrip+ (AAPS is not proposed among the different apps)

Philoul · 2026-05-17T19:54:59Z

When I disabled NFC command from xDrip, it is no more proposed within the different Apps

The setting Enable NFC within AAPS doesn't change anything (I of course set it enabled), but AAPS is not proposed and NFC is not recognized...

See below a screenshot of NFC type from NFC Tools...

juehv · 2026-05-17T19:59:15Z

Yeah .. that's I did not implement the support for non NDEF tags yet 😅
I made the post to get your opinion if you find that an acceptable behavior.

But the UI migration is done and the UID only feature is in place for NDEF tags. So multiple user could use the same tag with different actions.

Philoul · 2026-05-17T20:35:34Z

Second test with a spare tag I have (from an old Arduino kit...)

Record worked as expected
I understood the setting (not here to record AAPS within Android as an NFC potential app, but here to allow or not command execution)

I have several little comments (UI improvement, code, ...) but I was able to test it and it worked as expected.

FSL users should probably also test it: Normally NFC is only used to start the sensor and not later, but I don't know if we can disable NFC to let AAPS use older tag without conflicts... And it could vary according to user configuration (juggluco, xDrip+ and LibreLink, ...)

…otification_spam Fix excessive Android Auto pop-ups from persistent notification

…_commands

…_TAG_DISCOVERED

sonarqubecloud · 2026-05-19T12:52:55Z

Quality Gate passed

Issues
9 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

juehv · 2026-05-19T12:53:17Z

@Philoul
Ok I think it's done! Maybe you can give it another try, I implemented it as described above and did some UI polishing. Let me know what you think :)

juehv mentioned this pull request Mar 30, 2026

[FEATURE REQUEST] NFC Commands similar to SMS Communicator #4613

Open

MilosKozak added the for_discussion label Mar 31, 2026

juehv force-pushed the patch-new-plugin-nfc_commands branch from 9eff6d5 to 76c8797 Compare April 3, 2026 12:08

juehv added 5 commits April 3, 2026 21:09

Merge remote-tracking branch 'upstream/dev' into patch-new-plugin-nfc…

8da7c52

…_commands

import NFC Plugin

a0668b9

cleaning up

b77fd03

improved test coverage

8ecd0cc

plugins/main: adapt NFC command tests

45c874b

juehv force-pushed the patch-new-plugin-nfc_commands branch from 76c8797 to 45c874b Compare April 4, 2026 14:29

migrate UI and merge upstream dev branch

3ade7b1

move from jwt to uid only

a2d2280

olorinmaia and others added 12 commits May 18, 2026 00:48

Reduce Android Auto notification pop-ups in persistent notification

f951493

Add content deduplication for Android Auto notification

9521415

Merge pull request nightscout#4837 from olorinmaia/fix_android_auto_n…

32d3b7a

…otification_spam Fix excessive Android Auto pop-ups from persistent notification

Merge remote-tracking branch 'upstream/dev' into patch-new-plugin-nfc…

18e2021

…_commands

app opens on tag scan

825e488

add feature to execute a command chain from menu without tag

950ef2d

extended nfc reaction to all possible nfc techs by subscribing ACTION…

6c97e1e

…_TAG_DISCOVERED

add foreground dispatch feature (opt-in) for generic tags

fdb9107

restored CLAUDE.md

2d7c4dc

generated basic documentation

1eb09e2

bugfixing, ui still crap

9211a47

bugfixing / ui ploish

9c40e54

Conversation

juehv commented Mar 30, 2026

Uh oh!

MilosKozak commented Mar 31, 2026

Uh oh!

juehv commented Mar 31, 2026

Uh oh!

MilosKozak commented Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lightswitch2159 commented Mar 31, 2026

Uh oh!

xitation commented Apr 1, 2026

Uh oh!

juehv commented Apr 4, 2026

Uh oh!

sonarqubecloud Bot commented Apr 4, 2026

Quality Gate passed

Uh oh!

Philoul commented Apr 30, 2026

Uh oh!

juehv commented Apr 30, 2026

Uh oh!

Philoul commented Apr 30, 2026

Uh oh!

Philoul commented Apr 30, 2026

Uh oh!

juehv commented May 3, 2026

Uh oh!

juehv commented May 3, 2026

Uh oh!

Philoul commented May 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

juehv commented May 8, 2026

Uh oh!

Philoul commented May 8, 2026

Uh oh!

juehv commented May 8, 2026

Uh oh!

xitation commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

juehv commented May 17, 2026

Uh oh!

Philoul commented May 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Philoul commented May 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

juehv commented May 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Philoul commented May 17, 2026

Uh oh!

sonarqubecloud Bot commented May 19, 2026

Quality Gate passed

Uh oh!

juehv commented May 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

MilosKozak commented Mar 31, 2026 •

edited

Loading

Philoul commented May 3, 2026 •

edited

Loading

xitation commented May 13, 2026 •

edited

Loading

Philoul commented May 17, 2026 •

edited

Loading

Philoul commented May 17, 2026 •

edited

Loading

juehv commented May 17, 2026 •

edited

Loading