This is the description of the Shell API bindings for the NFC/RFID Bricklet. General information and technical specifications for the NFC/RFID Bricklet are summarized in its hardware description.
An installation guide for the Shell API bindings is part of their general description.
The example code below is Public Domain (CC0 1.0).
Download (example-scan-for-tags.sh)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | #!/bin/sh
# connects to localhost:4223 by default, use --host and --port to change it
# change to your UID
uid=hjw
echo "0" > /tmp/tf_sft_tt
# handle incoming state changed callbacks
tinkerforge dispatch nfc-rfid-bricklet $uid state-changed\
--execute "if [ {idle} ]
then
tt=\`cat /tmp/tf_sft_tt\`
if [ \$tt -eq 0 ]
then tt=1
elif [ \$tt -eq 1 ]
then tt=2
elif [ \$tt -eq 2 ]
then tt=0
fi
echo \"\$tt\" > /tmp/tf_sft_tt
tinkerforge call nfc-rfid-bricklet $uid request-tag-id \$tt
fi;
if [ {state} -eq 130 ]
then tinkerforge call nfc-rfid-bricklet $uid get-tag-id
fi" &
tinkerforge call nfc-rfid-bricklet $uid request-tag-id 0
|
Possible exit codes for all tinkerforge commands are:
The common options of the call and dispatch commands are documented here. The specific command structure is shown below.
Parameters: |
|
---|
The call command is used to call a function of the NFC/RFID Bricklet. It can take several options:
Parameters: |
|
---|
The dispatch command is used to dispatch a callback of the NFC/RFID Bricklet. It can take several options:
Parameters: |
|
---|
The <function> to be called can take different options depending of its kind. All functions can take the following options:
Getter functions can take the following options:
Setter functions can take the following options:
The --expect-response option for setter functions allows to detect timeouts and other error conditions calls of setters as well. The device will then send a response for this purpose. If this option is not given for a setter function then no response is send and errors are silently ignored, because they cannot be detected.
Parameters: |
|
---|
The <callback> to be dispatched can take several options:
Parameters: |
|
---|---|
Output: | no output |
To read or write a tag that is in proximity of the NFC/RFID Bricklet you first have to call this function with the expected tag type as parameter. It is no problem if you don't know the tag type. You can cycle through the available tag types until the tag gives an answer to the request.
Current the following tag types are supported:
After you call request-tag-id the NFC/RFID Bricklet will try to read the tag ID from the tag. After this process is done the state will change. You can either register the state-changed callback or you can poll get-state to find out about the state change.
If the state changes to RequestTagIDError it means that either there was no tag present or that the tag is of an incompatible type. If the state changes to RequestTagIDReady it means that a compatible tag was found and that the tag ID could be read out. You can now get the tag ID by calling get-tag-id.
If two tags are in the proximity of the NFC/RFID Bricklet, this function will cycle through the tags. To select a specific tag you have to call request-tag-id until the correct tag id is found.
In case of any Error state the selection is lost and you have to start again by calling request-tag-id.
The following symbols are available for this function:
Output: |
|
---|
Returns the tag type, tag ID and the length of the tag ID (4 or 7 bytes are possible length). This function can only be called if the NFC/RFID is currently in one of the Ready states. The returned ID is the ID that was saved through the last call of request-tag-id.
To get the tag ID of a tag the approach is as follows:
The following symbols are available for this function:
Output: |
|
---|
Returns the current state of the NFC/RFID Bricklet.
On startup the Bricklet will be in the Initialization state. The initialization will only take about 20ms. After that it changes to Idle.
The functions of this Bricklet can be called in the Idle state and all of the Ready and Error states.
Example: If you call request-page, the state will change to RequestPage until the reading of the page is finished. Then it will change to either RequestPageReady if it worked or to RequestPageError if it didn't. If the request worked you can get the page by calling get-page.
The same approach is used analogously for the other API functions.
Possible states are:
The following symbols are available for this function:
Parameters: |
|
---|---|
Output: | no output |
Mifare Classic tags use authentication. If you want to read from or write to a Mifare Classic page you have to authenticate it beforehand. Each page can be authenticated with two keys: A (key_number = 0) and B (key_number = 1). A new Mifare Classic tag that has not yet been written to can can be accessed with key A and the default key [0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF].
The approach to read or write a Mifare Classic page is as follows:
The following symbols are available for this function:
Parameters: |
|
---|---|
Output: | no output |
Writes 16 bytes starting from the given page. How many pages are written depends on the tag type. The page sizes are as follows:
The general approach for writing to a tag is as follows:
If you use a Mifare Classic tag you have to authenticate a page before you can write to it. See authenticate-mifare-classic-page.
Parameters: |
|
---|---|
Output: | no output |
Reads 16 bytes starting from the given page and stores them into a buffer. The buffer can then be read out with get-page. How many pages are read depends on the tag type. The page sizes are as follows:
The general approach for reading a tag is as follows:
If you use a Mifare Classic tag you have to authenticate a page before you can read it. See authenticate-mifare-classic-page.
Output: |
|
---|
Returns 16 bytes of data from an internal buffer. To fill the buffer with specific pages you have to call request-page beforehand.
Output: |
|
---|
Returns the UID, the UID where the Bricklet is connected to, the position, the hardware and firmware version as well as the device identifier.
The position can be 'a', 'b', 'c' or 'd'.
The device identifier numbers can be found here.
Callbacks can be used to receive time critical or recurring data from the device:
tinkerforge dispatch nfc-rfid-bricklet <uid> example
The available callbacks are described below.
Note
Using callbacks for recurring events is always preferred compared to using getters. It will use less USB bandwidth and the latency will be a lot better, since there is no round trip time.
Output: |
|
---|
This callback is called if the state of the NFC/RFID Bricklet changes. See get-state for more information about the possible states.
The following symbols are available for this function: