Software / API Bindings / MQTT / API Referenz und Beispiele / Bricklets / NFC Bricklet

MQTT - NFC Bricklet¶

Dies ist die Beschreibung der MQTT API Bindings für das NFC Bricklet. Allgemeine Informationen über die Funktionen und technischen Spezifikationen des NFC Bricklet sind in dessen Hardware Beschreibung zusammengefasst.

Eine Installationanleitung für die MQTT API Bindings ist Teil deren allgemeine Beschreibung.

Beispiele¶

Der folgende Beispielcode ist Public Domain (CC0 1.0).

Scan For Tags¶

Download (example-scan-for-tags.txt)

# Change XYZ to the UID of your NFC Bricklet

setup:
    # Handle incoming reader state changed callbacks
    subscribe to tinkerforge/callback/nfc_bricklet/XYZ/reader_state_changed
        if a message is received
            # message contains the current state as int with symbols and idle as bool

            if state == "RequestTagIDReady"
                subscribe to tinkerforge/response/nfc_bricklet/XYZ/reader_get_tag_id
                    if a message is received
                        # message contains tag_type and tag_id
                        print tag_type and tag_id
                    endif
                endsubscribe
                publish '' to tinkerforge/response/nfc_bricklet/XYZ/reader_get_tag_id
            endif

            if idle
                publish '' to tinkerforge/request/nfc_bricklet/XYZ/reader_request_tag_id
            endif
        endif
    endsubscribe

    publish '{"register": true}' to tinkerforge/register/nfc_bricklet/XYZ/reader_state_changed # Register reader_state_changed callback

    # Enable reader mode
    publish '{"mode": "reader"}' to tinkerforge/request/nfc_bricklet/XYZ/set_mode

API¶

Alle veröffentlichten Payloads an die und von den MQTT-Bindings sind im JSON Format.

Falls ein Fehler auftritt, veröffentlichen die Bindings ein JSON-Objekt, das die Fehlermeldung als _ERROR-Member enthält. Das Objekt wird auf dem zugehörigen Antwort-Topic veröffentlicht: .../response/... für .../request/... und .../callback/... für .../register/....

Grundfunktionen¶

request/nfc_bricklet/<UID>/set_mode¶

Anfrage:	mode – Typ: int, Wertebereich: Siehe Symbole, Standardwert: 0
Antwort:	keine Antwort

Setzt den Modus. Das NFC Bricklet unterstützt vier Modi:

Off (Aus)
Card Emulation (Cardemu): Emuliert einen Tag für andere Reader
Peer to Peer (P2P): Datenaustausch mit anderen Readern
Reader: Liest und schreibt Tags
Simple: Liest automatisch Tag-IDs

Wenn der Modus geändert wird, dann rekonfiguriert das Bricklet die Hardware für den gewählten Modus. Daher können immer nur die dem Modus zugehörigen Funktionen verwendet werden. Es können also im Reader Modus nur die Reader Funktionen verwendet werden.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für mode:

"off" = 0
"cardemu" = 1
"p2p" = 2
"reader" = 3
"simple" = 4

request/nfc_bricklet/<UID>/get_mode¶

Anfrage:	keine Nutzdaten
Antwort:	mode – Typ: int, Wertebereich: Siehe Symbole, Standardwert: 0

Gibt den aktuellen Modus zurück, wie von request/nfc_bricklet/<UID>/set_mode gesetzt.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für mode:

"off" = 0
"cardemu" = 1
"p2p" = 2
"reader" = 3
"simple" = 4

request/nfc_bricklet/<UID>/reader_request_tag_id¶

Anfrage:	keine Nutzdaten
Antwort:	keine Antwort

Um ein Tag welches sich in der nähe des NFC Bricklets befindet zu lesen oder zu schreiben muss zuerst diese Funktion mit dem erwarteten Tag Typ aufgerufen werden. Es ist kein Problem wenn der Typ nicht bekannt ist. Es ist möglich die verfügbaren Tag Typen einfach nacheinander durchzutesten bis das Tag antwortet.

Aktuell werden die folgenden Tag Typen unterstützt:

Mifare Classic
NFC Forum Type 1
NFC Forum Type 2
NFC Forum Type 3
NFC Forum Type 4
NFC Forum Type 5

Beim Aufruf von request/nfc_bricklet/<UID>/reader_request_tag_id versucht das NFC Bricklet die Tag ID eines Tags auszulesen. Nachdem dieser Prozess beendet ist ändert sich der Zustand des Bricklets. Es ist möglich den register/nfc_bricklet/<UID>/reader_state_changed Callback zu registrieren oder den Zustand über request/nfc_bricklet/<UID>/reader_get_state zu pollen.

Wenn der Zustand auf ReaderRequestTagIDError wechselt ist ein Fehler aufgetreten. Dies bedeutet, dass entweder kein Tag oder kein Tag vom passenden Typ gefunden werden konnte. Wenn der Zustand auf ReaderRequestTagIDReady wechselt ist ein kompatibles Tag gefunden worden und die Tag ID wurde gespeichert. Die Tag ID kann nun über request/nfc_bricklet/<UID>/reader_get_tag_id ausgelesen werden.

Wenn sich zwei Tags gleichzeitig in der Nähe des NFC Bricklets befinden werden diese nacheinander ausgelesen. Um ein spezifisches Tag zu selektieren muss request/nfc_bricklet/<UID>/reader_request_tag_id so lange aufgerufen werden bis das korrekte Tag gefunden wurde.

Falls sich das NFC Bricklet in einem der ReaderError Zustände befindet ist die Selektion aufgehoben und request/nfc_bricklet/<UID>/reader_request_tag_id muss erneut aufgerufen werden.

request/nfc_bricklet/<UID>/reader_get_tag_id¶

Anfrage:	keine Nutzdaten
Antwort:	tag_type – Typ: int, Wertebereich: Siehe Symbole tag_id – Typ: [int, ...], Länge: variabel, Wertebereich: [0 bis 255]

Gibt den Tag Typ und die Tag ID zurück. Diese Funktion kann nur aufgerufen werden wenn sich das Bricklet gerade in einem der ReaderReady-Zustände befindet. Die zurückgegebene tag ID ist die letzte tag ID die durch einen Aufruf von request/nfc_bricklet/<UID>/reader_request_tag_id gefunden wurde.

Der Ansatz um die Tag ID eines Tags zu bekommen sieht wie folgt aus:

Rufe request/nfc_bricklet/<UID>/reader_request_tag_id auf
Warte auf einen Zustandswechsel auf ReaderRequestTagIDReady (siehe request/nfc_bricklet/<UID>/reader_get_state oder register/nfc_bricklet/<UID>/reader_state_changed Callback)
Rufe request/nfc_bricklet/<UID>/reader_get_tag_id auf

Die folgenden Symbole sind für diese Funktion verfügbar:

Für tag_type:

"mifare_classic" = 0
"type1" = 1
"type2" = 2
"type3" = 3
"type4" = 4
"type5" = 5

request/nfc_bricklet/<UID>/reader_get_state¶

Anfrage:	keine Nutzdaten
Antwort:	state – Typ: int, Wertebereich: Siehe Symbole idle – Typ: bool

Gibt den aktuellen Reader Zustand des NFC Bricklets aus.

Während der Startphase ist der Zustand ReaderInitialization. Die Initialisierung dauert etwa 20ms. Danach ändert sich der Zustand zu ReaderIdle.

Das Bricklet wird auch neu initialisiert wenn der Modus geändert wird, siehe request/nfc_bricklet/<UID>/set_mode.

Die Funktionen dieses Bricklets können aufgerufen werden wenn der Zustand entweder ReaderIdle ist oder einer der ReaderReady oder ReaderError-Zustände erreicht wurde.

Beispiel: Wenn request/nfc_bricklet/<UID>/reader_request_page aufgerufen wird, ändert sich der Zustand zu ReaderRequestPage solange der Leseprozess noch nicht abgeschlossen ist. Danach ändert sich der Zustand zu ReaderRequestPageReady wenn das Lesen funktioniert hat oder zu ReaderRequestPageError wenn nicht. Wenn die Anfrage erfolgreich war kann die Page mit request/nfc_bricklet/<UID>/reader_read_page abgerufen werden.

Der gleiche Ansatz kann analog für andere API Funktionen verwendet werden.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für state:

"initialization" = 0
"idle" = 128
"error" = 192
"request_tag_id" = 2
"request_tag_id_ready" = 130
"request_tag_id_error" = 194
"authenticate_mifare_classic_page" = 3
"authenticate_mifare_classic_page_ready" = 131
"authenticate_mifare_classic_page_error" = 195
"write_page" = 4
"write_page_ready" = 132
"write_page_error" = 196
"request_page" = 5
"request_page_ready" = 133
"request_page_error" = 197
"write_ndef" = 6
"write_ndef_ready" = 134
"write_ndef_error" = 198
"request_ndef" = 7
"request_ndef_ready" = 135
"request_ndef_error" = 199

request/nfc_bricklet/<UID>/reader_write_ndef¶

Anfrage:	ndef – Typ: [int, ...], Länge: variabel, Wertebereich: [0 bis 255]
Antwort:	keine Antwort

Schreibt NDEF formatierte Daten.

Diese Funktion unterstützt aktuell NFC Forum Type 2, 4, 5 und Mifare Classic.

Der Ansatz um eine NDEF Nachricht zu schreiben sieht wie folgt aus:

Rufe request/nfc_bricklet/<UID>/reader_request_tag_id auf
Warte auf einen Zustandswechsel auf ReaderRequestTagIDReady (siehe request/nfc_bricklet/<UID>/reader_get_state oder register/nfc_bricklet/<UID>/reader_state_changed Callback)
Wenn mit einem bestimmten Tag gearbeitet werden soll, dann rufe request/nfc_bricklet/<UID>/reader_get_tag_id auf und überprüfe, ob der erwartete Tag gefunden wurde, wenn er nicht gefunden wurde mit Schritt 1 fortfahren
Rufe request/nfc_bricklet/<UID>/reader_write_ndef mit der zu schreibenden NDEF Nachricht auf
Warte auf einen Zustandswechsel auf ReaderWriteNDEFReady (siehe request/nfc_bricklet/<UID>/reader_get_state oder register/nfc_bricklet/<UID>/reader_state_changed Callback)

request/nfc_bricklet/<UID>/reader_request_ndef¶

Anfrage:	keine Nutzdaten
Antwort:	keine Antwort

Liest NDEF formatierten Daten von einem Tag.

Diese Funktion unterstützt aktuell NFC Forum Type 1, 2, 3, 4, 5 and Mifare Classic.

Der Ansatz um eine NDEF Nachricht zu lesen sieht wie folgt aus:

Rufe request/nfc_bricklet/<UID>/reader_request_tag_id auf
Warte auf einen Zustandswechsel auf ReaderRequestTagIDReady (siehe request/nfc_bricklet/<UID>/reader_get_state oder register/nfc_bricklet/<UID>/reader_state_changed Callback)
Wenn mit einem bestimmten Tag gearbeitet werden soll, dann rufe request/nfc_bricklet/<UID>/reader_get_tag_id auf und überprüfe, ob der erwartete Tag gefunden wurde, wenn er nicht gefunden wurde mit Schritt 1 fortfahren
Rufe request/nfc_bricklet/<UID>/reader_request_ndef auf
Warte auf einen Zustandswechsel auf ReaderRequestNDEFReady (siehe request/nfc_bricklet/<UID>/reader_get_state oder register/nfc_bricklet/<UID>/reader_state_changed Callback)
Rufe request/nfc_bricklet/<UID>/reader_read_ndef auf um die gespeicherte NDEF Nachricht abzufragen

request/nfc_bricklet/<UID>/reader_read_ndef¶

Anfrage:	keine Nutzdaten
Antwort:	ndef – Typ: [int, ...], Länge: variabel, Wertebereich: [0 bis 255]

Gibt NDEF Daten aus einem internen Buffer zurück. Der Buffer kann zuvor mit einer NDEF Nachricht über einen Aufruf von request/nfc_bricklet/<UID>/reader_request_ndef gefüllt werden.

request/nfc_bricklet/<UID>/reader_authenticate_mifare_classic_page¶

Anfrage:	page – Typ: int, Wertebereich: [0 bis 2¹⁶ - 1] key_number – Typ: int, Wertebereich: Siehe Symbole key – Typ: [int, ...], Länge: 6, Wertebereich: [0 bis 255]
Antwort:	keine Antwort

Mifare Classic Tags nutzen Authentifizierung. Wenn eine Page eines Mifare Classic Tags gelesen oder geschrieben werden soll muss diese zuvor authentifiziert werden. Jede Page kann mit zwei Schlüsseln, A (key_number = 0) und B (key_number = 1), authentifiziert werden. Ein neuer Mifare Classic Tag welches noch nicht beschrieben wurde kann über Schlüssel A mit dem Standardschlüssel [0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF] genutzt werden.

Der Ansatz um eine Mifare Classic Page zu lesen oder zu schreiben sieht wie folgt aus:

Rufe request/nfc_bricklet/<UID>/reader_request_tag_id auf
Warte auf einen Zustandswechsel auf ReaderRequestTagIDReady (siehe request/nfc_bricklet/<UID>/reader_get_state oder register/nfc_bricklet/<UID>/reader_state_changed Callback)
Wenn mit einem bestimmten Tag gearbeitet werden soll, dann rufe request/nfc_bricklet/<UID>/reader_get_tag_id auf und überprüfe, ob der erwartete Tag gefunden wurde, wenn er nicht gefunden wurde mit Schritt 1 fortfahren
Rufe request/nfc_bricklet/<UID>/reader_authenticate_mifare_classic_page mit Page und Schlüssel für die Page auf
Warte auf einen Zustandswechsel auf ReaderAuthenticatingMifareClassicPageReady (siehe request/nfc_bricklet/<UID>/reader_get_state oder register/nfc_bricklet/<UID>/reader_state_changed Callback)
Rufe request/nfc_bricklet/<UID>/reader_request_page oder request/nfc_bricklet/<UID>/reader_write_page zum Lesen/Schreiben einer Page auf

Die Authentifizierung bezieht sich immer auf einen ganzen Sektor (4 Pages).

Die folgenden Symbole sind für diese Funktion verfügbar:

Für key_number:

"a" = 0
"b" = 1

request/nfc_bricklet/<UID>/reader_write_page¶

Anfrage:	page – Typ: int, Wertebereich: Siehe Symbole data – Typ: [int, ...], Länge: variabel, Wertebereich: [0 bis 255]
Antwort:	keine Antwort

Schreibt maximal 8192 Bytes beginnend von der übergebenen Page. Wie viele Pages dadurch geschrieben werden hängt vom Typ des Tags ab. Die Pagegrößen verhalten sich wie folgt:

Mifare Classic Pagegröße: 16 byte
NFC Forum Type 1 Pagegröße: 8 byte
NFC Forum Type 2 Pagegröße: 4 byte
NFC Forum Type 3 Pagegröße: 16 byte
NFC Forum Type 4: Keine Pages, Page = Dateiwahl (CC oder NDEF, siehe unten)
NFC Forum Type 5 Pagegröße: 4 byte

Der generelle Ansatz zum Schreiben eines Tags sieht wie folgt aus:

Rufe request/nfc_bricklet/<UID>/reader_request_tag_id auf
Warte auf einen Zustandswechsel auf RequestTagIDReady (siehe request/nfc_bricklet/<UID>/reader_get_state oder register/nfc_bricklet/<UID>/reader_state_changed callback)
Wenn mit einem bestimmten Tag gearbeitet werden soll, dann rufe request/nfc_bricklet/<UID>/reader_get_tag_id auf und überprüfe, ob der erwartete Tag gefunden wurde, wenn er nicht gefunden wurde mit Schritt 1 fortfahren
Rufe request/nfc_bricklet/<UID>/reader_write_page mit der Page sowie den zu schreibenden Daten auf
Warte auf einen Zustandswechsel auf ReaderWritePageReady (siehe request/nfc_bricklet/<UID>/reader_get_state oder register/nfc_bricklet/<UID>/reader_state_changed Callback)

Wenn ein Mifare Classic Tag verwendet wird muss die Page authentifiziert werden bevor sie geschrieben werden kann. Siehe request/nfc_bricklet/<UID>/reader_authenticate_mifare_classic_page.

NFC Forum Type 4 Tags sind nicht in Pages organisiert sondern Dateien. Wir unterstützten aktuell zwei Dateien: Capability Container (CC) und NDEF.

Setze Page auf 3 um CC zu wählen und auf 4 um NDEF zu wählen.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für page:

"type4_capability_container" = 3
"type4_ndef" = 4

request/nfc_bricklet/<UID>/reader_request_page¶

Anfrage:	page – Typ: int, Wertebereich: Siehe Symbole length – Typ: int, Wertebereich: [0 bis 2¹³]
Antwort:	keine Antwort

Liest maximal 8192 Bytes beginnend von der übergebenen Page und speichert sie in einem Buffer. Dieser Buffer kann mit request/nfc_bricklet/<UID>/reader_read_page ausgelesen werden. Wie viele Pages dadurch gelesen werden hängt vom Typ des Tags ab. Die Pagegrößen verhalten sich wie folgt:

Mifare Classic Pagegröße: 16 byte
NFC Forum Type 1 Pagegröße: 8 byte
NFC Forum Type 2 Pagegröße: 4 byte
NFC Forum Type 3 Pagegröße: 16 byte
NFC Forum Type 4: Keine Pages, Page = Dateiwahl (CC oder NDEF, siehe unten)
NFC Forum Type 5 Pagegröße: 4 byte

Der generelle Ansatz zum Lesen eines Tags sieht wie folgt aus:

Rufe request/nfc_bricklet/<UID>/reader_request_tag_id auf
Warte auf einen Zustandswechsel auf RequestTagIDReady (siehe request/nfc_bricklet/<UID>/reader_get_state oder register/nfc_bricklet/<UID>/reader_state_changed Callback)
Wenn mit einem bestimmten Tag gearbeitet werden soll, dann rufe request/nfc_bricklet/<UID>/reader_get_tag_id auf und überprüfe, ob der erwartete Tag gefunden wurde, wenn er nicht gefunden wurde mit Schritt 1 fortfahren
Rufe request/nfc_bricklet/<UID>/reader_request_page mit der zu lesenden Page auf
Warte auf einen Zustandswechsel auf ReaderRequestPageReady (siehe request/nfc_bricklet/<UID>/reader_get_state oder register/nfc_bricklet/<UID>/reader_state_changed Callback)
Rufe request/nfc_bricklet/<UID>/reader_read_page auf um die gespeicherte Page abzufragen

Wenn ein Mifare Classic Tag verwendet wird muss die Page authentifiziert werden bevor sie gelesen werden kann. Siehe request/nfc_bricklet/<UID>/reader_authenticate_mifare_classic_page.

NFC Forum Type 4 Tags sind nicht in Pages organisiert sondern Dateien. Wir unterstützten aktuell zwei Dateien: Capability Container (CC) und NDEF.

Setze Page auf 3 um CC zu wählen und auf 4 um NDEF zu wählen.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für page:

"type4_capability_container" = 3
"type4_ndef" = 4

request/nfc_bricklet/<UID>/reader_read_page¶

Anfrage:	keine Nutzdaten
Antwort:	data – Typ: [int, ...], Länge: variabel, Wertebereich: [0 bis 255]

Gibt Daten aus einem internen Buffer zurück. Der Buffer kann zuvor mit spezifischen Pages über einen Aufruf von request/nfc_bricklet/<UID>/reader_request_page gefüllt werden.

request/nfc_bricklet/<UID>/cardemu_get_state¶

Anfrage:	keine Nutzdaten
Antwort:	state – Typ: int, Wertebereich: Siehe Symbole idle – Typ: bool

Gibt den aktuellen Cardemu-Zustand des NFC Bricklets aus.

Während der Startphase ist der Zustand CardemuInitialization. Die Initialisierung dauert etwa 20ms. Danach ändert sich der Zustand zu CardmeuIdle.

Das Bricklet wird auch neu initialisiert wenn der Modus geändert wird, siehe request/nfc_bricklet/<UID>/set_mode.

Die Funktionen dieses Bricklets können aufgerufen werden wenn der Zustand entweder CardemuIdle ist oder einer der CardemuReady oder CardemuError-Zustände erreicht wurde.

Beispiel: Wenn request/nfc_bricklet/<UID>/cardemu_start_discovery aufgerufen wird, änder sich der Zustand zu CardemuDiscover solange der Discover-Prozess noch nicht abgeschlossen ist. Danach ändert sich der Zustand zu CardemuDiscoverReady wenn der Discover-Prozess funktioniert hat oder zu CardemuDiscoverError wenn nicht.

Der gleiche Ansatz kann analog für andere API Funktionen verwendet werden.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für state:

"initialization" = 0
"idle" = 128
"error" = 192
"discover" = 2
"discover_ready" = 130
"discover_error" = 194
"transfer_ndef" = 3
"transfer_ndef_ready" = 131
"transfer_ndef_error" = 195

request/nfc_bricklet/<UID>/cardemu_start_discovery¶

Anfrage:	keine Nutzdaten
Antwort:	keine Antwort

Startet den Discovery Prozess. Wenn diese Funktion aufgerufen wird während ein NFC Lesegerät sich in Reichweite befindet, dann wechselt der Cardemu Zustand von CardemuDiscovery nach CardemuDiscoveryReady.

Falls kein NFC Lesegerät gefunden werden kann oder während des Discovery Prozesses ein Fehler auftritt dann wechselt der Cardemu Zustand zu CardemuDiscoveryReady. In diesem Fall muss der Discovery Prozess.

Wenn der Cardemu Zustand zu CardemuDiscoveryReady wechselt kann eine NDEF Nachricht mittels request/nfc_bricklet/<UID>/cardemu_write_ndef und request/nfc_bricklet/<UID>/cardemu_start_transfer übertragen werden.

request/nfc_bricklet/<UID>/cardemu_write_ndef¶

Anfrage:	ndef – Typ: [int, ...], Länge: variabel, Wertebereich: [0 bis 255]
Antwort:	keine Antwort

Schreibt eine NDEF Nachricht die an einen NFC Peer übertragen werden soll.

Die maximale NDEF Nachrichtengröße im Cardemu-Modus beträgt 255 Byte.

Diese Funktion kann im Cardemu-Modus jederzeit aufgerufen werden. Der interne Buffer wird nicht überschrieben solange diese Funktion nicht erneut aufgerufen oder der Modus nicht gewechselt wird.

request/nfc_bricklet/<UID>/cardemu_start_transfer¶

Anfrage:	transfer – Typ: int, Wertebereich: Siehe Symbole
Antwort:	keine Antwort

Der Transfer einer NDEF Nachricht kann im Cardemu-Zustand CardemuDiscoveryReady gestartet werden.

Bevor ein Schreib-Transfer gestartet werden kann muss zuerst die zu übertragenden NDEF Nachricht mittels request/nfc_bricklet/<UID>/cardemu_write_ndef geschrieben werden.

Nach einem Aufruf dieser Funktion ändert sich der Cardemu-Zustand zu CardemuTransferNDEF. Danach ändert sich der P2P Zustand zu CardemuTransferNDEFReady wenn der Transfer erfolgreich war oder zu CardemuTransferNDEFError falls nicht.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für transfer:

"abort" = 0
"write" = 1

request/nfc_bricklet/<UID>/p2p_get_state¶

Anfrage:	keine Nutzdaten
Antwort:	state – Typ: int, Wertebereich: Siehe Symbole idle – Typ: bool

Gibt den aktuellen P2P-Zustand des NFC Bricklets aus.

Während der Startphase ist der Zustand P2PInitialization. Die Initialisierung dauert etwa 20ms. Danach ändert sich der Zustand zu P2PIdle.

Das Bricklet wird auch neu Initialisiert wenn der Modus geändert wird, siehe request/nfc_bricklet/<UID>/set_mode.

Die Funktionen dieses Bricklets können aufgerufen werden wenn der Zustand entweder P2PIdle ist oder einer der P2PReady oder P2PError-Zustände erreicht wurde.

Beispiel: Wenn request/nfc_bricklet/<UID>/p2p_start_discovery aufgerufen wird, änder sich der Zustand zu P2PDiscover solange der Discover-Prozess noch nicht abgeschlossen ist. Danach ändert sich der Zustand zu P2PDiscoverReady wenn der Discover-Prozess funktioniert hat oder zu P2PDiscoverError wenn nicht.

Der gleiche Ansatz kann analog für andere API Funktionen verwendet werden.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für state:

"initialization" = 0
"idle" = 128
"error" = 192
"discover" = 2
"discover_ready" = 130
"discover_error" = 194
"transfer_ndef" = 3
"transfer_ndef_ready" = 131
"transfer_ndef_error" = 195

request/nfc_bricklet/<UID>/p2p_start_discovery¶

Anfrage:	keine Nutzdaten
Antwort:	keine Antwort

Startet den Discovery Prozess. Wenn diese Funktion aufgerufen wird während ein anderes NFC P2P fähiges Gerät sich in Reichweite befindet, dann wechselt der P2P Zustand von P2PDiscovery nach P2PDiscoveryReady.

Falls kein NFC P2P fähiges Gerät gefunden werden kann oder während des Discovery Prozesses ein Fehler auftritt dann wechselt der P2P Zustand zu P2PDiscoveryError. In diesem Fall muss der Discovery Prozess.

Wenn der P2P Zustand zu P2PDiscoveryReady wechselt kann eine NDEF Nachricht mittels request/nfc_bricklet/<UID>/p2p_write_ndef und request/nfc_bricklet/<UID>/p2p_start_transfer übertragen werden.

request/nfc_bricklet/<UID>/p2p_write_ndef¶

Anfrage:	ndef – Typ: [int, ...], Länge: variabel, Wertebereich: [0 bis 255]
Antwort:	keine Antwort

Schreibt eine NDEF Nachricht die an einen NFC Peer übertragen werden soll.

Die maximale NDEF Nachrichtengröße für P2P Übertragungen beträgt 255 Byte.

Diese Funktion kann im P2P-Modus jederzeit aufgerufen werden. Der interne Buffer wird nicht überschrieben solange diese Funktion nicht erneut aufgerufen, der Modus nicht gewechselt oder über P2P eine NDEF Nachricht gelesen wird.

request/nfc_bricklet/<UID>/p2p_start_transfer¶

Anfrage:	transfer – Typ: int, Wertebereich: Siehe Symbole
Antwort:	keine Antwort

Der Transfer einer NDEF Nachricht kann im P2P Zustand P2PDiscoveryReady gestartet werden.

Bevor ein Schreib-Transfer gestartet werden kann muss zuerst die zu übertragenden NDEF Nachricht mittels request/nfc_bricklet/<UID>/p2p_write_ndef geschrieben werden.

Nach einem Aufruf dieser Funktion ändert sich der P2P Zustand zu P2PTransferNDEF. Danach ändert sich der P2P Zustand zu P2PTransferNDEFReady wenn der Transfer erfolgreich war oder zu P2PTransferNDEFError falls nicht.

Ein Schreib-Transfer ist danach abgeschlossen. Bei einem Lese-Transfer kann jetzt die vom NFC Peer geschriebene NDEF Nachricht mittels request/nfc_bricklet/<UID>/p2p_read_ndef ausgelesen werden.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für transfer:

"abort" = 0
"write" = 1
"read" = 2

request/nfc_bricklet/<UID>/p2p_read_ndef¶

Anfrage:	keine Nutzdaten
Antwort:	ndef – Typ: [int, ...], Länge: variabel, Wertebereich: [0 bis 255]

Gibt die NDEF Nachricht zurück, die von einem NFC Peer im P2P Modus geschrieben wurde.

Die NDEF Nachricht ist bereit sobald sich nach einem request/nfc_bricklet/<UID>/p2p_start_transfer Aufruf mit einem Lese-Transfer der P2P Zustand zu P2PTransferNDEFReady ändert.

request/nfc_bricklet/<UID>/simple_get_tag_id¶

Anfrage:	index – Typ: int, Wertebereich: [0 bis 7]
Antwort:	tag_type – Typ: int, Wertebereich: Siehe Symbole tag_id – Typ: [int, ...], Länge: variabel, Wertebereich: [0 bis 255] last_seen – Typ: int, Einheit: 1 ms, Wertebereich: [0 bis 2³² - 1]

Gibt den Tag Typ und die Tag ID des Simple-Mode sortiert nach last_seen für den gegebenen Index zurück.

Bis zu acht Tags werden gespeichert.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für tag_type:

"mifare_classic" = 0
"type1" = 1
"type2" = 2
"type3" = 3
"type4" = 4
"type5" = 5

Neu in Version 2.0.6 (Plugin).

request/nfc_bricklet/<UID>/cardemu_set_tag_id¶

Anfrage:	tag_id_length – Typ: int, Wertebereich: [0 bis 7] tag_id_data – Typ: [int, ...], Länge: 7, Wertebereich: [0 bis 255]
Antwort:	keine Antwort

Setzt die Tag ID für den Caremu-Modus. Die Tag ID kann entweder eine Länge von 4 oder von 7 haben.

Wrid die Länge auf 0 gesetzt, nutzt das Bricklet eine zufällige Tag ID (Default).

Neu in Version 2.1.0 (Plugin).

request/nfc_bricklet/<UID>/cardemu_get_tag_id¶

Anfrage:	keine Nutzdaten
Antwort:	tag_id_length – Typ: int, Wertebereich: [0 bis 7] tag_id_data – Typ: [int, ...], Länge: 7, Wertebereich: [0 bis 255]

Gibt die Tag ID und Länge zurück, wie von request/nfc_bricklet/<UID>/cardemu_set_tag_id gesetzt.

Neu in Version 2.1.0 (Plugin).

Fortgeschrittene Funktionen¶

request/nfc_bricklet/<UID>/set_detection_led_config¶

Anfrage:	config – Typ: int, Wertebereich: Siehe Symbole, Standardwert: 3
Antwort:	keine Antwort

Setzt die Konfiguration der Kommunikations-LED. Standardmäßig zeigt die LED ob eine Karte/ein Lesegerät detektiert wurde.

Die LED kann auch permanent an/aus gestellt werden oder einen Herzschlag anzeigen.

Wenn das Bricklet sich im Bootloadermodus befindet ist die LED aus.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für config:

"off" = 0
"on" = 1
"show_heartbeat" = 2
"show_detection" = 3

request/nfc_bricklet/<UID>/get_detection_led_config¶

Anfrage:	keine Nutzdaten
Antwort:	config – Typ: int, Wertebereich: Siehe Symbole, Standardwert: 3

Gibt die Konfiguration zurück, wie von request/nfc_bricklet/<UID>/set_detection_led_config gesetzt.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für config:

"off" = 0
"on" = 1
"show_heartbeat" = 2
"show_detection" = 3

request/nfc_bricklet/<UID>/set_maximum_timeout¶

Anfrage:	timeout – Typ: int, Einheit: 1 ms, Wertebereich: [0 bis 2¹⁶ - 1], Standardwert: 2000
Antwort:	keine Antwort

Setzt den maximalen Timeout.

Dies ist das globale Maximum für die internen State-Timeouts. Der korrekte Timeout hängt vom verwendeten Tag Typ ab. Zum Beispiel: Wenn ein Typ 2 Tag verwendet wird und herausgefunden werden soll ob der Tag in Reichweite des Bricklets ist, muss request/nfc_bricklet/<UID>/reader_request_tag_id aufgerufen werden. Der State wechselt dann entweder auf Ready oder Error (Tag gefunden/nicht gefunden).

Mit den Standardeinstellungen dauert dies ca. 2-3 Sekunden. Wenn man das maximale Timeout auf 100ms setzt reduziert sich diese zeit auf ~150-200ms. Für Typ 2 funktioniert das auch noch mit einem Timeout von 20ms (Ein Typ 2 Tag antwortet für gewöhnlich innerhalb von 10ms). Ein Typ 4 Tag benötigte bis zu 500ms in unsren Tests.

Wenn eine schnelle reaktionszeit benötigt wird, kann das Timeout entsprechend verrigert werden einen guten Wert kann man per Trial-and-Error für einen spezfiischen Tag-Typ ermitteln.

Standardmäßig nutzen wir einen sehr konservativen Timeout um sicher zu stellen das alle Tags definitiv funktionieren.

Neu in Version 2.0.1 (Plugin).

request/nfc_bricklet/<UID>/get_maximum_timeout¶

Anfrage:	keine Nutzdaten
Antwort:	timeout – Typ: int, Einheit: 1 ms, Wertebereich: [0 bis 2¹⁶ - 1], Standardwert: 2000

Gibt das Timeout zurück, wie von request/nfc_bricklet/<UID>/set_maximum_timeout gesetzt.

Neu in Version 2.0.1 (Plugin).

request/nfc_bricklet/<UID>/get_spitfp_error_count¶

Anfrage:	keine Nutzdaten
Antwort:	error_count_ack_checksum – Typ: int, Wertebereich: [0 bis 2³² - 1] error_count_message_checksum – Typ: int, Wertebereich: [0 bis 2³² - 1] error_count_frame – Typ: int, Wertebereich: [0 bis 2³² - 1] error_count_overflow – Typ: int, Wertebereich: [0 bis 2³² - 1]

Gibt die Anzahl der Fehler die während der Kommunikation zwischen Brick und Bricklet aufgetreten sind zurück.

Die Fehler sind aufgeteilt in

ACK-Checksummen Fehler,
Message-Checksummen Fehler,
Framing Fehler und
Overflow Fehler.

Die Fehlerzähler sind für Fehler die auf der Seite des Bricklets auftreten. Jedes Brick hat eine ähnliche Funktion welche die Fehler auf Brickseite ausgibt.

request/nfc_bricklet/<UID>/set_status_led_config¶

Anfrage:	config – Typ: int, Wertebereich: Siehe Symbole, Standardwert: 3
Antwort:	keine Antwort

Setzt die Konfiguration der Status-LED. Standardmäßig zeigt die LED die Kommunikationsdatenmenge an. Sie blinkt einmal auf pro 10 empfangenen Datenpaketen zwischen Brick und Bricklet.

Die LED kann auch permanent an/aus gestellt werden oder einen Herzschlag anzeigen.

Wenn das Bricklet sich im Bootlodermodus befindet ist die LED aus.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für config:

"off" = 0
"on" = 1
"show_heartbeat" = 2
"show_status" = 3

request/nfc_bricklet/<UID>/get_status_led_config¶

Anfrage:	keine Nutzdaten
Antwort:	config – Typ: int, Wertebereich: Siehe Symbole, Standardwert: 3

Gibt die Konfiguration zurück, wie von request/nfc_bricklet/<UID>/set_status_led_config gesetzt.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für config:

"off" = 0
"on" = 1
"show_heartbeat" = 2
"show_status" = 3

request/nfc_bricklet/<UID>/get_chip_temperature¶

Anfrage:	keine Nutzdaten
Antwort:	temperature – Typ: int, Einheit: 1 °C, Wertebereich: [-2¹⁵ bis 2¹⁵ - 1]

Gibt die Temperatur, gemessen im Mikrocontroller, aus. Der Rückgabewert ist nicht die Umgebungstemperatur.

Die Temperatur ist lediglich proportional zur echten Temperatur und hat eine hohe Ungenauigkeit. Daher beschränkt sich der praktische Nutzen auf die Indikation von Temperaturveränderungen.

request/nfc_bricklet/<UID>/reset¶

Anfrage:	keine Nutzdaten
Antwort:	keine Antwort

Ein Aufruf dieser Funktion setzt das Bricklet zurück. Nach einem Neustart sind alle Konfiguration verloren.

Nach dem Zurücksetzen ist es notwendig neue Objekte zu erzeugen, Funktionsaufrufe auf bestehenden führen zu undefiniertem Verhalten.

request/nfc_bricklet/<UID>/get_identity¶

Anfrage:

keine Nutzdaten

Antwort:

uid – Typ: string, Länge: bis zu 8
connected_uid – Typ: string, Länge: bis zu 8
position – Typ: char, Wertebereich: ["a" bis "h", "z"]
hardware_version – Typ: [int, ...], Länge: 3

0: major – Typ: int, Wertebereich: [0 bis 255]
1: minor – Typ: int, Wertebereich: [0 bis 255]
2: revision – Typ: int, Wertebereich: [0 bis 255]

firmware_version – Typ: [int, ...], Länge: 3

0: major – Typ: int, Wertebereich: [0 bis 255]
1: minor – Typ: int, Wertebereich: [0 bis 255]
2: revision – Typ: int, Wertebereich: [0 bis 255]

device_identifier – Typ: int, Wertebereich: [0 bis 2¹⁶ - 1]
_display_name – Typ: string

Gibt die UID, die UID zu der das Bricklet verbunden ist, die Position, die Hard- und Firmware Version sowie den Device Identifier zurück.

Die Position ist 'a', 'b', 'c', 'd', 'e', 'f', 'g' oder 'h' (Bricklet Anschluss). Ein Bricklet hinter einem Isolator Bricklet ist immer an Position 'z'.

Eine Liste der Device Identifier Werte ist hier zu finden. Falls die symbolische Ausgabe nicht deaktiviert wurde, wird der Device Identifier auf den entsprechenden Namen im Format, welches die Topics verwenden, abgebildet.

Der Display Name enthält den Anzeigenamen des NFC.

Callbacks¶

Callbacks können registriert werden um zeitkritische oder wiederkehrende Daten vom Gerät zu erhalten. Die Registrierung kann mit dem entsprechenden .../register/...-Topic und einem optionalen Suffix durchgeführt werden. Mit diesem Suffix kann das Callback später deregistriert werden.

Bemerkung

Callbacks für wiederkehrende Ereignisse zu verwenden ist immer zu bevorzugen gegenüber der Verwendung von Abfragen. Es wird weniger USB-Bandbreite benutzt und die Latenz ist erheblich geringer, da es keine Paketumlaufzeit gibt.

register/nfc_bricklet/<UID>/reader_state_changed¶

Registrierungsanfrage:	register – Typ: bool
Callback-Antwort:	state – Typ: int, Wertebereich: Siehe Symbole idle – Typ: bool

Ein Callback für dieses Event kann durch Senden des Payloads "true" an das .../register/nfc_bricklet/<UID>/reader_state_changed[/<SUFFIX>]-Topic hinzugefügt werden. Ein hinzugefügtes Callback kann durch Senden des Payloads "false" an das selbe Topic wieder entfernt werden. Um mehrere (De-)Registrierungen zu unterstützen, z.B. um Nachrichten filtern zu können, kann ein optionaler Suffix verwendet werden.

Wenn das Callback ausgelöst wird, wird dessen Payload für jeden Suffix auf dem entsprechenden .../callback/nfc_bricklet/<UID>/reader_state_changed[/<SUFFIX>]-Topic veröffentlicht.

Dieser Callback wird ausgelöst, wenn der Reader-Zustand des NFC Bricklets sich verändert. Siehe request/nfc_bricklet/<UID>/reader_get_state für mehr Informationen über die möglichen Zustände des Bricklets.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für state:

"initialization" = 0
"idle" = 128
"error" = 192
"request_tag_id" = 2
"request_tag_id_ready" = 130
"request_tag_id_error" = 194
"authenticate_mifare_classic_page" = 3
"authenticate_mifare_classic_page_ready" = 131
"authenticate_mifare_classic_page_error" = 195
"write_page" = 4
"write_page_ready" = 132
"write_page_error" = 196
"request_page" = 5
"request_page_ready" = 133
"request_page_error" = 197
"write_ndef" = 6
"write_ndef_ready" = 134
"write_ndef_error" = 198
"request_ndef" = 7
"request_ndef_ready" = 135
"request_ndef_error" = 199

register/nfc_bricklet/<UID>/cardemu_state_changed¶

Registrierungsanfrage:	register – Typ: bool
Callback-Antwort:	state – Typ: int, Wertebereich: Siehe Symbole idle – Typ: bool

Ein Callback für dieses Event kann durch Senden des Payloads "true" an das .../register/nfc_bricklet/<UID>/cardemu_state_changed[/<SUFFIX>]-Topic hinzugefügt werden. Ein hinzugefügtes Callback kann durch Senden des Payloads "false" an das selbe Topic wieder entfernt werden. Um mehrere (De-)Registrierungen zu unterstützen, z.B. um Nachrichten filtern zu können, kann ein optionaler Suffix verwendet werden.

Wenn das Callback ausgelöst wird, wird dessen Payload für jeden Suffix auf dem entsprechenden .../callback/nfc_bricklet/<UID>/cardemu_state_changed[/<SUFFIX>]-Topic veröffentlicht.

Dieser Callback wird ausgelöst, wenn der Cardemu-Zustand des NFC Bricklets sich verändert. Siehe request/nfc_bricklet/<UID>/cardemu_get_state für mehr Informationen über die möglichen Zustände des Bricklets.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für state:

"initialization" = 0
"idle" = 128
"error" = 192
"discover" = 2
"discover_ready" = 130
"discover_error" = 194
"transfer_ndef" = 3
"transfer_ndef_ready" = 131
"transfer_ndef_error" = 195

register/nfc_bricklet/<UID>/p2p_state_changed¶

Registrierungsanfrage:	register – Typ: bool
Callback-Antwort:	state – Typ: int, Wertebereich: Siehe Symbole idle – Typ: bool

Ein Callback für dieses Event kann durch Senden des Payloads "true" an das .../register/nfc_bricklet/<UID>/p2p_state_changed[/<SUFFIX>]-Topic hinzugefügt werden. Ein hinzugefügtes Callback kann durch Senden des Payloads "false" an das selbe Topic wieder entfernt werden. Um mehrere (De-)Registrierungen zu unterstützen, z.B. um Nachrichten filtern zu können, kann ein optionaler Suffix verwendet werden.

Wenn das Callback ausgelöst wird, wird dessen Payload für jeden Suffix auf dem entsprechenden .../callback/nfc_bricklet/<UID>/p2p_state_changed[/<SUFFIX>]-Topic veröffentlicht.

Dieser Callback wird ausgelöst, wenn der P2P-Zustand des NFC Bricklets sich verändert. Siehe request/nfc_bricklet/<UID>/p2p_get_state für mehr Informationen über die möglichen Zustände des Bricklets.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für state:

"initialization" = 0
"idle" = 128
"error" = 192
"discover" = 2
"discover_ready" = 130
"discover_error" = 194
"transfer_ndef" = 3
"transfer_ndef_ready" = 131
"transfer_ndef_error" = 195

Interne Funktionen¶

Interne Funktionen werden für Wartungsaufgaben, wie zum Beispiel das Flashen einer neuen Firmware oder das Ändern der UID eines Bricklets, verwendet. Diese Aufgaben sollten mit Brick Viewer durchgeführt werden, anstelle die internen Funktionen direkt zu verwenden.

request/nfc_bricklet/<UID>/set_bootloader_mode¶

Anfrage:	mode – Typ: int, Wertebereich: Siehe Symbole
Antwort:	status – Typ: int, Wertebereich: Siehe Symbole

Setzt den Bootloader-Modus und gibt den Status zurück nachdem die Modusänderungsanfrage bearbeitet wurde.

Mit dieser Funktion ist es möglich vom Bootloader- in den Firmware-Modus zu wechseln und umgekehrt. Ein Welchsel vom Bootloader- in der den Firmware-Modus ist nur möglich wenn Entry-Funktion, Device Identifier und CRC vorhanden und korrekt sind.

Diese Funktion wird vom Brick Viewer während des Flashens benutzt. In einem normalem Nutzerprogramm sollte diese Funktion nicht benötigt werden.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für mode:

"bootloader" = 0
"firmware" = 1
"bootloader_wait_for_reboot" = 2
"firmware_wait_for_reboot" = 3
"firmware_wait_for_erase_and_reboot" = 4

Für status:

"ok" = 0
"invalid_mode" = 1
"no_change" = 2
"entry_function_not_present" = 3
"device_identifier_incorrect" = 4
"crc_mismatch" = 5

request/nfc_bricklet/<UID>/get_bootloader_mode¶

Anfrage:	keine Nutzdaten
Antwort:	mode – Typ: int, Wertebereich: Siehe Symbole

Gibt den aktuellen Bootloader-Modus zurück, siehe request/nfc_bricklet/<UID>/set_bootloader_mode.

Die folgenden Symbole sind für diese Funktion verfügbar:

Für mode:

"bootloader" = 0
"firmware" = 1
"bootloader_wait_for_reboot" = 2
"firmware_wait_for_reboot" = 3
"firmware_wait_for_erase_and_reboot" = 4

request/nfc_bricklet/<UID>/set_write_firmware_pointer¶

Anfrage:	pointer – Typ: int, Einheit: 1 B, Wertebereich: [0 bis 2³² - 1]
Antwort:	keine Antwort

Setzt den Firmware-Pointer für request/nfc_bricklet/<UID>/write_firmware. Der Pointer muss um je 64 Byte erhöht werden. Die Daten werden alle 4 Datenblöcke in den Flash geschrieben (4 Datenblöcke entsprechen einer Page mit 256 Byte).

Diese Funktion wird vom Brick Viewer während des Flashens benutzt. In einem normalem Nutzerprogramm sollte diese Funktion nicht benötigt werden.

request/nfc_bricklet/<UID>/write_firmware¶

Anfrage:	data – Typ: [int, ...], Länge: 64, Wertebereich: [0 bis 255]
Antwort:	status – Typ: int, Wertebereich: [0 bis 255]

Schreibt 64 Bytes Firmware an die Position die vorher von request/nfc_bricklet/<UID>/set_write_firmware_pointer gesetzt wurde. Die Firmware wird alle 4 Datenblöcke in den Flash geschrieben.

Eine Firmware kann nur im Bootloader-Mode geschrieben werden.

Diese Funktion wird vom Brick Viewer während des Flashens benutzt. In einem normalem Nutzerprogramm sollte diese Funktion nicht benötigt werden.

request/nfc_bricklet/<UID>/write_uid¶

Anfrage:	uid – Typ: int, Wertebereich: [0 bis 2³² - 1]
Antwort:	keine Antwort

Schreibt eine neue UID in den Flash. Die UID muss zuerst vom Base58 encodierten String in einen Integer decodiert werden.

Wir empfehlen die Nutzung des Brick Viewers zum ändern der UID.

request/nfc_bricklet/<UID>/read_uid¶

Anfrage:	keine Nutzdaten
Antwort:	uid – Typ: int, Wertebereich: [0 bis 2³² - 1]

Gibt die aktuelle UID als Integer zurück. Dieser Integer kann als Base58 encodiert werden um an den üblichen UID-String zu gelangen.