Equinox

Hallo Ojax, kannst du bitte mal posten, was du auf den Chip als NDEF-Message schreiben willst? Ich kann dann versuchen, diese Nachricht zu erzeugen. Dann müsste der Fehler leichter zu finden sein.

Hallo Ojax, wenn eine korrekte NDEF-Nachricht vom Typ "URI" und ID-Code zwischen 1 und 4 auf dem Chip abgelegt ist und diese Nachricht vom Smartphone ausgelesen wird, dann habe ich bisher verschiedene Verhalten gesehen: [*]Das Smartphone öffnet die URL aus der NDEF-Nachricht ungefragt. [*]Das Smartphone "fragt nach", ob es die URL öffnen soll. [*]Das Smartphone zeigt die URL an und öffnet sie, wenn man darauf "klickt" Wenn "No NDEF detected" erscheint, dann ist auf dem Chip keine korrekte NDEF-Nachricht gespeichert. Das Startbyte einer NDEF-Nachricht ist immer 0x03 und das Ende-Byte ist immer 0xfe. Ich habe des Python-Beispiel noch nicht ausprobiert, aber ich gehe davon aus, dass das Programm korrekte NDEF-Nachrichten erzeugt. Kannst du auslesen, was auf der Karte gespeichert ist (in Hex)? In den Pages ab 4 müsste folgendes stehen (Auslieferungszustand von TF): 4: 032e9101 5: 10550174 6: 696e6b65 7: 72666f72 8: 67652e63 9: 6f6d5101 10: 16540265 11: 6e486176 12: 65206675 13: 6e207469 14: 6e6b6572 15: 696e6721 16: fe000000 Das sind 2 NDEF-Nachrichten: Einmal ein URI (tinkerforge.com) und ein Text "Have fun tinkering!".

Ich habe (noch) keinen RED und kann deshalb nicht sagen, was darauf alles installiert ist. Ein HTTP-Server ist mit Node.js natürlich ohne weitere Packages installieren zu müssen, möglich. Für WebServices reicht das aber nicht aus, wenn man "echte" WebServices nutzen möchte, d.h. nicht nur HTTP-GET- und PUT-Requests (REST), sondern auch z.B. WSDL-basierende RPCs.

Hallo, wenn es für dich OK ist, dass der Server (RED) nicht aktiv Werte an deine App sendet, sondern deine App in regelmäßigen Abständen die Werte per Request vom Server abholt, könntest du auch WebServices benutzen. Du bräuchtest dann kein eigenes Protokoll und kannst die WebServices auch "außerhalb" der App einfach nutzen. Ein WebServices-Server muss nicht extra installiert werden, wenn du ihn mit Java erstellst. Mit Node.js musst du vmtl. ein paar Module nachinstallieren, sollte aber auch kein Problem sein.

Hmm, das ist komisch. Mit dem Brick-Viewer kann ich alle Pages von 0-44 auslesen, mit meinem Handy hört es aber bei Page 41 auf. Vielleicht zeigt mein Handy diese Daten einfach nicht an. Ich komme aber bei Pages 0-44 auch "nur" auf 45 Seiten, d.h. 180 Bytes, also trotzdem 4 Bytes zu wenig. Im Brick-Viewer kann man nur bis Page 99 als Startpage einstellen (ist das so gewollt?), von daher kann ich nicht sagen, wie es bei der Scheckkarte ist. Mein Handy liest hier bis Page 230 aus.

Hallo, danke für die Antwort! Das ist auch so ein Punkt: Bei mir steht an dem Längenbyte (Page 3, drittes Byte) 0x17 (=23), d.h., es müssten 23*8=184 Bytes sein. Das Tag hat aber nur 42 Pages zu je 4 Bytes, also 168 Bytes. Ebenso ist es bei mir bei der NFC Scheckkarte. Hier steht bei mir 0x7d (=125), was genau 1000 Bytes wären. Allerdings hat die Karte nur 231 Pages, also 924 Bytes. Warum ist das so bzw. funktioniert es trotzdem? Hmm, was hab ich denn da gemacht? So habe ich es erwartet (und so ist es auch). Ich denke, ich habe dezimal 91 (51) in Binär umgerechnet Sorry, mein Fehler (man sollte solche Sachen vmtl. nicht machen, wenn man von einem Virus dahingerafft wurde ...) Ich meinte das Byte 0x02. Dies ist ein Statusbyte. Die Informationen dazu habe ich mittlerweile gefunden. Zur Info: Es enthält neben der Länge des Language-Codes auch das Encoding, d.h., ob es UTF-8 oder UTF-16 ist (höchstwertiges Bit=0 --> UTF-8, höchstwertiges Bit=1 --> UTF-16, die 6 niederwertigsten Bits geben die Länge an und das verbleibende Bit ist reserviert (for future use) und muss 0 sein. Das hat mir geholfen, danke! Weiss jemand, wie man NDEF-Nachrichten mit mehr als 255 Bytes erzeugen kann?

Jemand eine Idee oder einen Tipp?

Hallo remotecontrol, ich habe das NDEF-Format auch noch nicht verstanden (siehe mein Post: http://www.tinkerunity.org/forum/index.php/topic,2792.0.html), aber ich denke auch, dass da in der Doku was falsch ist. Die "vorinstallierte" Nachricht beginnt bei Page 4 mit der NDEF-Kennung (nicht bei Page 3) und wie du auch sagst, muss man ab Page 4 überschreiben. Ich habe zwar keine NFC-Aufkleber, aber einen Schlüsselanhänger, der dieselbe Kapazität hat. Bei dem ist es so: Pages 0 und 1: UID Page 2: reserviert/lock bits Page 3: OTP (one time programmable?) Pages 4 - 39: Für eigene Daten nutzbar Page 40: reserviert/lock bits Page 41: Counter Area (wofür?) D.h: Gesamtkapazität: 42 Pages mit je 4 Bytes = 168 Bytes. Nutzbar: 168 Bytes - 6 * 4 Bytes = 144 Bytes

Super, vielen Dank!

Hallo, Sorry, ja, mein Fehler :'( Habe vergessen, einen hart codierten Wert in eine Variable zu packen. Danke!

Hallo, danke für die Antwort. Noch eine Frage zur Vorgehensweise für das Schreiben von mehr als 16 Bytes: Das ist im Prinzip klar, die Frage für mich war, wo dies zu machen ist. Im Moment rufe ich das erste WritePage im Callback von "STATE_REQUEST_TAG_ID_READY" auf und alle weiteren WritePage-Aufrufe im Callback von "STATE_WRITE_PAGE_READY". Ist das so gedacht? Oder sollte man das außerhalb der Callbacks machen?

Hallo zusammen, das Auslesen der richtigen Page funktioniert mittlerweile (bin mir nicht sicher an was es lag). Auch das Schreiben von mehr als 16 Bytes funktioniert, aber ich bin mir nicht sicher, ob das so der ideale Weg ist. Wie sieht denn hier die beste Vorgehensweise aus? Wäre es möglich, in der API eine Methode anzubieten, die ein Byte-Array beliebiger Länge entgegen nimmt und dies dann vollständig auf das Tag schreibt (und dabei nur einmal in den Zustand "WritePageReady" wechselt)? Ebenso zum Lesen: Startseite und Anzahl Bytes übergeben? Und was ist mit "Rufe getTagID() auf und überprüfe ob Tag ID korrekt ist." gemeint? Zielt das darauf ab, dass wenn zwischen Erkennen des Tags und dem Schreibvorgang ein größerer Zeitraum ist, das Tag inzwischen weg sein kann bzw. ein anderes aufliegen könnte? Danke!

Hallo zusammen, wenn ich "writePage" mit einer Pagenummer größer als 30 aufrufe, dann bekomme ich eine Nullpointerexception: java.lang.NullPointerException at com.tinkerforge.BrickletNFCRFID.writePage(BrickletNFCRFID.java:290) at WriteTag$1.stateChanged(WriteTag.java:62) at com.tinkerforge.BrickletNFCRFID$1.callback(BrickletNFCRFID.java:114) at com.tinkerforge.IPConnection.callDeviceListener(IPConnection.java:159) at com.tinkerforge.CallbackThread.dispatchPacket(IPConnectionBase.java:253) at com.tinkerforge.CallbackThread.run(IPConnectionBase.java:286) Wenn das Schreiben über die Page 30 hinausgeht, wird auch nur bis maximal Page 30 geschrieben. Ist das ein Bug oder mache ich was falsch? Falls letzteres, wie kann ich Daten in Pages jenseits 30 schreiben? Danke!

Hallo zusammen, ich habe das Beispielprogramm zum Schreiben/Lesen von RFID-Tags leicht abgeändert, sodass es nur noch liest. Mein Problem dabei ist, dass es immer Page 5 liest, egal was ich bei requestPage() als Parameter angebe. Selbst ohne den Aufruf requestPage() wird der Abschnitt unter "BrickletNFCRFID.STATE_REQUEST_PAGE_READY" ausgeführt. Was mache ich falsch? Wie lese ich die requestierte Seite aus? Wie funktioniert das Lesen und Schreiben von mehreren Seiten, d.h. mehr als 16 Bytes? Ist dies mit Callbacks sinnvoll machbar, da diese ja asynchron ausgeführt werden? Oder macht man das anders? Wie sieht hier die "Best Practice" aus? Könntet ihr dazu bitte ein Beispielprogramm posten (Lesen und Schreiben von mehr als 16 Bytes)? Und eins noch: In der Doku steht beim Lesen und Schreiben jeweils der Satz: "Rufe getTagID() auf und überprüfe ob Tag ID korrekt ist." Was ist damit gemeint? Ob die TagID dem requestierten Typ entspricht? Wenn ich das richtig sehe, fehlt dieser Schritt auch in den Beispielprogrammen. Vielen Dank. Hier mein Programm: import com.tinkerforge.BrickletNFCRFID; import com.tinkerforge.IPConnection; public class ReadTag { private static final String host = "localhost"; private static final int port = 4223; private static final String UID = "oBF"; // NFC Bricklet // Note: To make the example code cleaner we do not handle exceptions. Exceptions you // might normally want to catch are described in the commnents below public static void main(String args[]) throws Exception { IPConnection ipcon = new IPConnection(); // Create IP connection final BrickletNFCRFID nfc = new BrickletNFCRFID(UID, ipcon); // Create device object ipcon.connect(host, port); // Connect to brickd // Don't use device before ipcon is connected // Add and implement state changed listener (called if state changes) nfc.addStateChangedListener(new BrickletNFCRFID.StateChangedListener() { public void stateChanged(short state, boolean idle) { try { if(state == BrickletNFCRFID.STATE_REQUEST_TAG_ID_READY) { System.out.println("Tag found"); //System.out.println(nfc.getTagID()); System.out.println("Requesting data (pages 4-7) ..."); // Request pages 4-7 nfc.requestPage(4); } else if(state == BrickletNFCRFID.STATE_WRITE_PAGE_READY) { System.out.println("Write Page ready ... sollte nichts erscheinen"); } else if(state == BrickletNFCRFID.STATE_REQUEST_PAGE_READY) { // Get and print pages System.out.println("Data: "); short[] data = nfc.getPage(); String s = "Read data (Dezimal): [" + data[0]; String sHex = "Read data (hex): [" + Integer.toHexString(data[0] & 0xffff); for(int i = 1; i < data.length; i++) { s += " " + data[i]; sHex += " " + Integer.toHexString(data[i] & 0xffff); } s += "]"; sHex += "]"; System.out.println(s); System.out.println(sHex); } else if((state & (1 << 6)) == (1 << 6)) { // All errors have bit 6 set System.out.println("Error: " + state); } } catch(Exception e) { System.out.println(e); } } }); // Select NFC Forum Type 2 tag nfc.requestTagID(BrickletNFCRFID.TAG_TYPE_TYPE2); System.out.println("Press key to exit"); System.in.read(); ipcon.disconnect(); } } Wie gesagt: Selbst ohne die Zeile "nfc.requestPage(4);" erhalte ich eine Ausgabe.

Hallo zusammen und frohes, neues Jahr! Zu Weihnachten habe ich mir ein NFC/RFID-Bricklet geschenkt. Ich möchte darauf gerne NDEF-konforme Nachrichten speichern. Ich habe es auch geschafft, einige korrekte Nachrichten zu erzeugen, allerdings sind bei mir da noch einige Fragen offen, was das Format angeht. Kennt jemand eine gute(!) Dokumentation dafür (und ich meine nicht die Spezifikation https://github.com/Tinkerforge/nfc-rfid-bricklet/raw/master/datasheets/specification_ndef.pdf)? Meine Fragen im Einzelnen: [*]Ich habe die "NFC Forum Typ 2"-Tags aus dem TF-Shop. Ich dachte, man sollte/darf erst ab Page 5 eigene Daten schreiben. Warum beginnt die "vorinstallierte" Nachricht dann schon bei Page 4? [*]Wo in der Spezifikation steht, dass eine NDEF Nachricht mit 0x03 beginnen muss? Ich habe das nur auf einer anderen Internetseite gefunden, dass dies so sein muss zur Identifikation als NDEF-Nachricht. Gibt es noch andere definierte "Startbytes"? [*]Nach dem 0x03 steht die Gesamtlänge der Nachricht in einem Byte. Wie kann ich dann Nachrichten mit mehr als 255 Bytes erzeugen? Seltsamerweise gibt es bei den einzelnen Records die Möglichkeit, dass diese 232-1 Bytes lang werden können (mit eigenem Längenfeld). Das macht doch aber keinen Sinn, wenn die Nachricht sowieso nur 255 Bytes lang werden kann, oder? [*]In der vorinstallierten Nachricht folgt als nächstes 0x91 als erstes Header-Byte. Dies bedeutet, dass das Message-End Bit, das Short Record Bit ID-Length Bit gesetzt sind und als TNF "Absolute URI". Müsste da nicht zumindest auch das Message Begin-Bit gesetzt sein? Warum ist das Message End-Bit gesetzt? Es folgt doch noch eine weiterer Record. ID-Length ist gesetzt, aber ich konnte in der Nachricht keine ID finden. Ist das bei Absolute URI automatisch der Payload? Falls ja, wo kann man das Nachlesen? Warum wird "Absolute URI" verwendet bzw. was ist der Unterschied zu "Well-Known" (0x01)? Es kommt ja noch ein Byte, das den Typ angibt. Da muss bei URI 0x55 stehen. Wie würde die vorinstallierte Nachricht mit TNF 0x01 aussehen (hat bei mir nicht funkktioniert)? Auf einer anderen Seite habe ich gelesen, dass man TNF 0x03 nicht verwenden sollte, sondern 0x01 (leider ohne Begründung) [*]In der vorinstallierten Textnachricht steht als Header-Byte 0x51. Auch hier ist das Message Begin Bit nicht gesetzt, keine ID und TNF ist 0x01. Kann es sein, dass in einer Nachricht, keine 2 Records gleichen Typs stehen dürfen, d.h. deshalb wurde für URI TNF 0x03 genommen, damit man noch eine Textnachricht mit TNF 0x01 anhängen kann? Falls dem nicht so ist, hat jemand ein Beispiel, wie z.B. zweimal die Nachricht "Hallo" aussehen würde (d.h. in zwei eigenen Records)? [*] Nach dem Typ (0x54 für Text und 0x55 für URI) folgt ein Statusbyte. Nach einiger Suche konnte ich eine Spezifikation dafür im Falle einer Textnachricht finden, allerdings nicht vollständig erklärt. Wie ist die Spezifikation dafür für URIs? Ich könnte mich natürlich durch das TF-Beispielprogramm wühlen, aber einerseits steht da dann "nur" dass es so ist und nicht warum und andererseits würde mich schon auch interessieren, woher die Informationen sind (ich konnte zumindest einiges nicht in der Spezifikation finden, wie z.B. das Startbyte 0x03). Vielen Dank!

Hallo, Die Idee finde ich sehr gut. Es dürfte nur kein Bricklet sein das per eingetauchter Leiterplatte misst. Besser wäre da vll. eine Lösung per Differenzdrucksensor und getauchtem Schlauch. Stimmt. Ein flexibler "Messstab" ist besser. Eine starre Stange kann nicht überall eingesetzt werden.

Hallo, eine Idee für ein (einfaches?) Bricklet: Wie wäre es mit einem Bricklet zum Messen von Füllständen von Flüssigkeiten (Wasser, Öl, etc.)? Ich stelle mir hier ein Bricklet vor, an das ein Messstab angeschlossen wird, der in eine Flüssigkeit getaucht werden kann. Das Bricklet gibt dann den Wert z.B. in Millimeter zurück, wie tief der Stab in der Flüssigkeit eingetaucht ist. Dies könnte man z.B. dazu verwenden, die Regenmenge (für die Wetterstation) oder seinen Heizölverbrauch zu messen. Auch für Zisternen sehr sinnvoll. Auf Parties könnte man den Stab in ein Bierfass stecken. Damit könnte man den Bierkonsum messen und bei niedrigem Füllstand rechtzeitig für Nachschub sorgen. Die Gäste wären dann auch ständig informiert, wieviel an flüssiger Nahrung noch da ist

Hallo, für mich am wichtigsten ist im Moment eine Möglichkeit, die TF-Infrastruktur flexibler zu machen, was den Standort angeht. Sprich: Eine einfache, kostengünstige Möglichkeit, die Bricklets per Funk anzubinden. (Siehe http://www.tinkerunity.org/forum/index.php/topic,2511.0.html) Das geht zwar in Richtung Chibi-Extension, aber (wenn ich es richtig verstanden habe), ist mir das zu "oversized". Ich stelle mir ein "Transceiver-Brick" vor (mit Batterie?), an das ich beliebige Bricklets anschließen kann. D.h., ich habe einen Stapel mit Master-Brick und Transceiver-Brick (und evtl. weitere Bricklets) und viele weitere Stapel, die nur aus Transceiver-Brick und Bricklets bestehen (also ohne Master) und per Funk mit dem Master-Stapel kommunizieren.

Hallo, ich stimme dir voll zu! Ich hoffe, TF geht das bald an. Hier noch eine Möglichkeit: http://www.semtech.com/wireless-rf/lora.html

Hallo, grundsätzlich kann ich deinen Ärger verstehen, auf der anderen Seite aber auch nicht, denn schließlich gibt es ja eine Alternative, nämlich das Voltage/Current Bricklet, das auch noch genauer sein soll. Warum sollte TF zwei Bricklets, die den selben Zweck erfüllen, anbieten? Da ist es sinnvoll, eines aus dem Programm zu nehmen. OK, das Voltage/Current Bricklet hat keinen extra 5V Ausgang, aber auch dafür gibt es Alternativen.

Hallo, hast du auch das "final" entfernt? Ich mache das auch und es geht problemlos. Beispiel: IPConnection direkt nach der Klassendefinition private IPConnection ipcon = null; und dann in einer Methode (die bei mir init() heißt): ipcon.addConnectedListener(new IPConnection.ConnectedListener() { @Override public void connected(short disconnectReason) { try { System.out.println("Connected CB called."); ipcon.enumerate(); } catch (NotConnectedException exc) { // Should never happen System.out.println("Connected called but not connected."); System.out.println(exc.getMessage()); } } }); Ich rufe in meinen Listenern auch Methoden der umgebenden Klasse auf.

ahhh, und "final" sollte sie auch nicht sein.

Hallo, versuch mal die Variable als Klassenvariable anzulegen, d.h. zwischen public class ExampleSimple { private static final String HOST = "localhost"; private static final int PORT = 4223; private static final String UIDDualRelay = "kuE"; // Change to your UID private static final String UIDHumidity = "nED"; // Change to your UID private static final String UIDDisplay = "ocE"; // Change to your UID und public static void main(String args[]) throws Exception { also da, wo du auch die Konstanten definierst.

Hi Rob, you may use switches using e.g. "Z-Wave" technology. Works fine with a Raspberry Pi and the "Razberry"-extension.

Hi Rob, there's no such function as it is not possible to determine the state of the remote switch These "standard" remote switches are just able to receive signals, but they cannot send any signal. You can send the desired initial state the plug and then just hope that the plug received it.