NFC in farmOS Field Kit

Development
1

Wanted to start a forum post for talking about NFC in Field Kit.
See other relevant issues:

  • @mstenta you said there are some other issues you could link here?
  • …

After some quick hacking with Field Kit, I’m excited to say I got some initial support for reading NFC tags in the native farmOS field kit app! I accomplished this with the following:

  • adding cordova plugin add phonegap-nfc to the Field Kit app (this adds a line to package.json which includes the phonegap-nfc library
  • Created an “NFC” Field Module" with a main “view” that largely resembles this Cordova NFC Sample: https://github.com/c4software/vuejs-cordova-sample/blob/master/src/views/Nfc.vue
  • When the NFC view is mounted a Tag listener is created via nfc.addTagDiscoveredListener(). After this, NFC tags are registered within the app, rather than the Android System Default.
  • In the NFC view beforeDestroy nfc.remoteTagDiscoveredListener() removes the listener, and NFC events are handled by the system, not Field Kit.
  • Also, a good reference on Cordova NFC: Writing NFC Apps with Apache Cordova

The phonegap-nfc library should support Android and iOS, although I haven’t tested on iOS. Notably, it looks like one additional step is required in the code: (

iOS requires you to begin a session before scanning a NFC tag.
-
nfc.beginSession(success, failure);

I first tried using the Web NFC standard (Web NFC) but didn’t have any luck. As far as I can tell, this is only supported in Chrome and requires the #enable-webnfc flag which is disabled by default. Originally I thought the NFC web standard was not being supported (Web NFC API) but the link above and the Web-NFC GitHub show activity as of yesterday. This is promising and should be revisited to potentially bring support for NFC in the PWA version of Field Kit.

Some considerations for further development of NFC for Field Kit:

  • NFC support in Field Kit core would be idea. With this, tags could be “read” at anytime the app is open (and potentially trigger the opening of the Field Kit native app).
  • Creating a Field Kit NFC API could allow Field Modules to interface with NFC to read/write to tags themselves. Having an internal NFC API might simplify support for future web-nfc, too, because Field Kit core could detect 1) if it is running as PWA or Native and 2) detect if the device hardware supports NFC (via the web-nfc standard and phonegap-nfc library)
  • We need to brain storm how the NFC listeners will be structured in Field Kit core API - perhaps multiple listeners can be registered, so any Field Module that registers a listener could be used. Some info from the phonegap-nfc library:

Multiple listeners can be registered in JavaScript. e.g. addNdefListener, addTagDiscoveredListener, addMimeTypeListener.
…
On Android, only the most specific event will fire. If a Mime Media Tag is scanned, only the addMimeTypeListener callback is called and not the callback defined in addNdefListener. You can use the same event handler for multiple listeners.

  • This brings up the nfc.addMimeTypeListener (GitHub - chariotsolutions/phonegap-nfc: PhoneGap NFC Plugin) - Theoretically, tags could be written with a custom mimetime of application/farm_asset or application/farm_area, and be used to trigger specific mime-type listeners. This seems promising to me!

There also needs to be some thought into the UI

  • @jgaehring had an interesting idea where, when an NFC tag is read, a popup could display that allows the user to select how to handle the event - i.e. “View Asset”, “Create Observation for ___”, etc… and Field Modules could register these actions.
  • Other use cases might be more “background” where, when editing a log, if an asset tag is read, the asset should automatically be added to the log. Something similar could be done with areas.
  • There will need to be an interface for writing to NFC tags. Perhaps a core interface that allows writing standard farmOS mimetypes, as well as allowing Field Modules to write custom tags.

Use cases (feel free to add!!)

  • Create/read tags for farmOS assets (animals, equipment, etc)
  • Auto-add assets to logs
  • Create/read tags for farmOS areas
  • Auto-add areas to logs
  • An “action” to “Create Observation Log” when an asset or area tag is created
  • Create/read tags for managing inventories
  • An “action” to auto increment/decrement an inventory when a tag is read
  • An “action” to “Clock In” on an employee timesheet when a tag is read
  • … (please, add other ideas!)

In the meantime, I’m going to continue working on a draft NFC Field Module to explore this more. We specifically need to play with writing NFC tags and see if the mime-types will work as expected. I’ll publish my fork once I’m further along for development reference.

4 Likes
2

I can’t tell you how excited I am to see this start to take shape! :smiley:

Here are two related discussions:

That first one was actually the first feature request in the farmOS issue queue on Drupal.org I think. :slight_smile:

It was focused on QR codes, but I was thinking more generally about being able to tie IDs to assets/areas in other ways as well (RFID, barcodes, etc). The basic idea being that we could have different ways of assigning IDs to assets and then use those for quick look-ups in different contexts (Field Kit is the PERFECT place to do this).

2 Likes
3

This is great! And fantastic documentation @paul121!

Oh I like this! Does this relate to what you were talking about earlier how NFC tags can have an associated app name or identifier? Is that how the system knows what app to launch?

In my mind NFC tags are much more preferable to QR codes or barcodes. QR’s are write-once, you need a method of printing them, and they have to be able to endure the elements without fading or falling apart. NFC or RFID tags on the other hand are read/write and much more durable. They might be more costly (although I even wonder about that; Google barcodes printer prices if you’re curious), but I feel that these kinds of physical id’s are really best for long-term areas and assets anyways (like a field or a tractor, as opposed to a particular planting or bushel of product). So yea, lots of potential here!

3 Likes
4

Yea! I believe this is all controlled with Mime types (think like a content-type header in HTTP) - one such Mime type specifies an Android Application Record. Just saw this documented on the phonegap-nfc library here

val msg = NdefMessage(
        arrayOf(
                ...,
                NdefRecord.createApplicationRecord("com.example.android.beam")
        )
)

Then by modifying AndroidManifest.yml I think we can enable launching-your-android-application-when-scanning-a-tag

Yea - especially with long-term “things”. They can really provide an alternative method of inputting data to the phone, even. Rather than typing a value, you can have NFC tags nailed to the wall that you tap. I think this would make sense for certain repetitive workflows where typing slows things down. (Seeding in trays comes to mind)

1 Like
5

In my mind NFC tags are much more preferable to QR codes or barcodes.
…
They might be more costly

I think that’s the equation that will make the choice clear in each specific operation/use-case. Big difference between managing 100s of assets vs 1000s or 10,000s.

I intend to allow farmOS (server) to support any/all of the above. Maybe Field Kit only supports a sub-set, depending on demand… we can see what folks ask for.

6

In playing with trying to autolaunch Field Kit with a mime type of application/farmos I had to add an <intent-filter> to AndroidManifest.xml (from the docs)

  • The problem is that Cordova doesn’t provide a way to edit AndroidManifest.xml. I manually edited the file that is generated after running cordova platform add android and cordova build android at: platforms/android/app/src/main/AndroidManifest.xml and this worked.
  • It looks this might be possible with the cordova-custom-config plugin. Wanted to document this, haven’t tried. Tutorial here
2 Likes
7

Finished a draft of the NFC “Field Module” - the main chunk of NFC code is here in my fork.

  • Read a tag and display all records that are saved to a card.
  • Support for writing to cards, but I haven’t been able to fully test this…

Unfortuantely I have NXP MifareClassic cards, which use a proprietary format, and require that hardware has an NXP chip to interface with the cards. This is a well-known issue. Some older devices have the hardware required, but most newer devices do not. Interestingly enough, I can read from the cards - I just can’t write to them.

  • Something worth noting: I am able to write to these cards using the nfc-tools Android App on a Pixel 3. (I believe this app is doing something special to crack the NXP encryption). Anyways, I am able to create custom application/farmos records with that app and interface with them in Field Kit.

Now to find the best source of some compatible NFC cards… I do believe the writing functionality should work!

1 Like
8

A short demo of the writing functionality is here: https://drive.google.com/open?id=1OAFTZb7ftjtPC4HhFOLxkWsL0ERjQbF0

I bought NFC tags from GoToTags (Made in Spokane, WA!) - https://store.gototags.com/nfc/nfc-tags/
With these tags, you can specify the NFC Chip that is used. Most any of the NXP NTAG2XX chips will work! In general, the higher numbers have more memory than lower numbers. DON’T buy the get the Mifare Classic Chip

1 Like
9

This sounds like a really cool project and implementation. It would be very useful to track harvested products from the field to the sales point. Like what one would need for Global GAP.

3 Likes
10

I’m very excited by NFC & FarmOS. Has there been any progress on this?

2 Likes
11

Not trying to derail the thread or dissuade anyone from pursuing NFC, but I’d like to make counter-points to some of those presented here;

  • QR codes have the potential to be a lot more environmentally-friendly;
    • For some applications you can print them on regular paper - admittedly paper isn’t always the most environmentally-friendly thing, but I’m pretty confident it is way better than high-cardinality e-waste
    • If you have access to a low power laser etcher (like at a local maker-space), you can print them on bits of scrap wood
  • For other applications, a pretty good price-point can be hit with waterproof paper by optimizing the software for formatting many codes on a single page
  • You’re making a choice about whether QR codes are single use or not, it’s pretty trivial to add a layer of indirection where the final reference in the tag/code/link of the QR code is re-assignable

This is a pretty complicated cost trade-off. With something like a QR/bar code the hardware for reading/writing is ubiquitous and intuitive to humans whereas wireless electronic tags are opaque to humans and require dedicated hardware for reading/programming them.

3 Likes
12

Ok, ok, you got my wheels turning now, @Symbioquine.

I’m wondering now if there is some kind of reusable material that could be used, with no electronic parts, to “print” the QR code onto. I’m thinking about something that might be sensitive to heat, or a particular frequency of UV light, etc. It would just need two states, light and dark, which could then be used as binary data for the QR printer.

If such a thing exists, it could achieve most of our goals: waterproof, sunproof, durable, eco-friendly, etc. The remaining question would be cost and ubiquity, but again, I’m less concerned with ubiquity, b/c I think there are better signifiers that don’t require the creation of a new artifact to track (I have a whole theory about this which I won’t go into now). Long story short, I see physical tagging as sort of an edge scenario to begin with, so I don’t see cost and ubiquity as much of a barrier.

1 Like
13

Yeah, or an open version of https://www.meshtag.com/ so the scannable references could be trivially hand-written/carved/burned/etc…

4 Likes
14

Sorry, to get back to your original question, @sam_uk, I don’t think there’s been a lot of development here, but perhaps @paul121 would know better.

A major hurdle at this point is the reliance on native API’s, because NFC is not yet available through web browsers. We have experimented with these API’s via Cordova, which gives us access to the native API’s but at considerable cost. We’ve decided, at least for the time being, to direct our focus towards the progressive web app (PWA) for Field Kit, rather than the native iOS and Android releases. More info on that here:

2 Likes
15

Oh, that’s AWESOME!! Thanks, @Symbioquine!

1 Like
16

Not to beat a dead horse, but QR code scanning is already feasible in a PWA with something like qr-scanner - npm

Sure thing! I’m not convinced that service should be used as-is, but the idea is golden…

3 Likes
17

QR codes would certainly be better than nothing. Last time we tried FarmOS it didn’t work out as the data entry barrier/ time was just too high. It was easier and quicker to use paper records.

QR might cut it, but it’s still a bit fiddly.

Workflow something like;
Try to focus camera with muddy fingers, take the photo.
Try again, finally save the photo,
Add data.
Wipe the mud off the screen as best you can.

NFC seems like its potentially quicker and easier, but I understand it’s not technically easy. Is this the thing you’ve already tried? https://web.dev/nfc/

2 Likes
18

Thanks for sharing that! farmOS and especially Field Kit certainly need to be designed with these UX challenges at the forefront of the design constraints.

@jgaehring I think you are already probably thinking along these lines… What does a “Field First” UX design ethic for Field Kit look like?

2 Likes
19

Ok, I’ll give you the whole screed now… :stuck_out_tongue:

My reluctance to use QR codes, or any kind of physical tagging mechanism, comes from the belief that, in most cases, this adds a layer of “accidental complexity”, which we should try to eliminate by rethinking the problem we’re trying to solve.

A tag introduces a new physical artifact as a proxy to the actual physical entity you want to track. This is done with the presumption that the proxy will be easier to identify than the entity itself. However, it introduces the need, at some level, to keep track of two representations of the object, whereas before there was only one. It also requires that we create the tag in the first place (and maintain it, replicate it, etc, if it’s not sufficiently durable), affix it physically to the entity in some reliable fashion, and similarly link its digital identifier to the digital representation of the entity. All of this is preliminary to the task of reading the tag, and must be taken into account when evaluating costs and benefits.

Once again, this is all done in the service of identifying the original physical entity; we aren’t doing this because we care about tracking the tag itself, but what the tag represents. Ultimately, we are trying to link the digital representation of the entity (eg, a farmOS asset) to its physical reality. For that, we need some kind of signifier. The tag seems like an ideal and unambiguous signifier, because it has physical attributes which directly represent a digital identity, but again, there are tradeoffs.

I would argue that, in most cases, there are sufficient natural signifiers to identify an entity without the overhead of creating and maintaining a tag. And I’ll go a step further to argue that, in ideal circumstances, the best approach is to focus on how we track the digital entity, rather than the physical entity itself.

Think of these natural signifiers as context clues. Some good examples are the current time, the user’s geolocation, the identity of the user, visual information embedded in the environment or the entity itself. If you want to identify which crop you’re about to weed or harvest, you’re probably in geographic proximity to as many crops as you can count on one hand. If your device has you logged in, and the task has been assigned to you, it should be able to use your geolocation and the time on the clock to infer what task you’re about to do. Then, good UX should take over and provide the user with the most likely actions to perform on that task, like check off that the bed has been weeded, or provide a field for entering the number of crates harvested, with as few clicks/taps to get there as possible.

Ok, that’s low hanging fruit, and probably not somewhere you’d think to use tags anyways. So…

A bigger challenge is inventory items, or basically anything in a container, because these tend to be stacked or stored close together, which rules out geolocation almost immediately. It may not help to have the user id in these cases either, because there’s a good chance the user may be interacting with dozens if not hundreds of different containers of the same kind. They’re also probably hard to distinguish visually. I’m thinking here of seed trays in a greenhouse or bins in a walk-in cooler. So now we don’t really have natural signifiers to fall back on, what we do?

First, I’ll remind you that in these circumstances tagging also becomes that much harder, b/c you need to be able to produce, affix and assign tags to each and every item individually. Also take into account that tags in these kinds of scenarios are going to be fairly ephemeral, while the containers are reusable. So you are going to need to have a process for removing old tags from your bins or trays once you change them out, otherwise it will create confusion when you try to assign new tags to the bins.

This is where I would advocate for using more advanced reading technology, rather than writing technology.

OCR technology is quickly becoming ubiquitous and cheap, and I think is the right path forward for these scenarios. So instead of having to produce, affix and assign a tag to a container, you just use a grease pencil, or tape and sharpie. Using natural language to identify bins comes with the added benefit that it’s human-readable as well as machine-readable, so you don’t have to go to extra effort to mark a bin twice (once with pencil, once with a tag), or leave it to the next person to have to pull out their phone just to know whether its beets or onions in that freshly seeded tray. Probably most folks are already writing the names of stuff anyways.

There are lots of other scenarios which fall in between, and even scenarios where a tag might be warranted (tracking animals comes to mind). But I think the vast majority will fall into one of these two use cases.

One key to this approach is to always prefer lo-tech writes and hi-tech reads, rather than hi-tech writes and lo-tech reads. There is also a built in assumption that there will be robust planning and record-keeping so you can trace the life of an asset in data first, and use that to infer when and where an activity will occur. Now that can be a lot to ask, I admit, because no information system is infallible, but I think it’s the right solution we should be striving to reach.

</screed>

2 Likes
20

We did something a little different in the past, using a Cordova plugin, but the NFC Web API you link to above is what we would prefer to use. Problem is it’s not standard and only supported in Chrome Android:

2 Likes