AuronX

Ah okay, dachte der Master droppt das Paket sofort... Eine Anmerkung hätte ich noch Genaugenommen betrifft die Disconnect-Probe alle Verbindungsarten, also nicht nur WiFi, weil sie auch bei der Verbindung zu einem Remote-Brickd sinnvoll ist. (Nicht jeder connected zu localhost) Viele Grüße Jan

Sieht schick aus. Loetis Hinweis aus dem einen Satz drei zu machen finde ich sinnvoll. Außerdem frage ich mich, ob ein Anfänger erkennt, dass er entweder einen PC oder einen Raspberry Pi braucht, damit er auf dem Display auch etwas sieht. Möglicherweise wird das nicht deutlich (Oder gibt es etwa eine spezielle Firmware die das ermöglicht?). Insbesondere der zuerst auftauchende Satz "Vollwertige Open Source Wetterstation" könnte mich zu der Annahme verleiten, dass ich nichts weiter brauche, um die Messwerte zu sehen. Ansonsten: cool cool cool!

Mir ist entgangen, dass du nach Version 1.x.x suchst ^^ Da funktioniert der Trick natürlich nicht

Tipp hierzu: In anderen Projekten kenne ich auch eine Kennzeichnung eines Latest-Build: Etwa: brickd-latest_all.deb 26-Oct-2012 14:54 76410 brickd-1.0.0_all.deb 08-Dec-2011 10:19 58098 brickd-1.0.10_all.deb 16-Oct-2012 07:53 75450 brickd-1.0.11_all.deb 26-Oct-2012 14:54 76410 Der Vorteil ist, dass man sich nur eine URL merken muss und nciht erst URLs "basteln" muss um an die neueste Version zu kommen

Zwei Ansätze: 1. Der brickd bittet beim Anstecken des Kabels selbst um ein enumerate 2. Der brickd "merkt" sich die Devices und schickt bei jeder TCP-Verbindung ein Fake-enum raus. Mir geht es im Moment auch weniger darum euch davon zu überzeugen, dass ihr (TF) die eine oder die andere Lösung wählen sollt. Wichtig ist mir nur, dass klar nachvollziehbar ist wie das zu erwartende Verhalten an der Schnittstelle zu eurer Hardware ist. Nach allen bisher gängigen APIs die ihr habt ist diese Schnittstelle nunmal das TCP-Protokoll. Das heißt hier muss es dokumentiert werden. Wenn ihr am Ende feststellt, dass es sich unterschiedlich verhalten muss, dann sollte das wenigstens deutlich dokumentiert sein. Ist halt alles nicht so einfach wenn Menschen aufeinander treffen. Für euch ist die logische Schnittstelle der Stecker des Bricks. Für die meisten hier liegt die Schnittstelle aber erst am TCP-Socket. Viele Grüße Jan

Du weißt ja, dass ich jeweils nur aus Sicht der Bindings blicke. Das ist für mich der relevante Teil des Protokolls. Die Bindings bauen eine TCP-Verbindung zu einer unbekannten Gegenstelle auf. Bei Einführung der WLAN-Extension hieß es sogar man müsse existierenden Source nicht anpassen, alles bleibt gleich, nur die IP wird anders. Nun stellt es sich aus Sicht der Bindings (= TCP-Client) so dar: Falls die Gegenstelle ein Software-Brickd ist, dann passiert nichts Falls die Gegenstelle eine WLAN-Extension ist, dann kommt ein enumerate Natürlich kann ich einfach immer nach enum fragen, aber das Verhalten stellt sich mir anders dar. Ich denke der Punkt auf den du hinauswillst ist der: In der Brick-Firmware ist beides das gleiche Ereignis, weil die Firmware das nicht unterscheiden kann. Aus Protokollsicht (und mit Protokoll meine ich den TCP-Transport) hat ein Verbindungsaufbau nichts mit dem Einstecken von Kabeln zu tun. Am Ende sitzt ihr (TF) auf der Entscheidungsseite. Aber bitte versteht, dass das nicht unbedingt intuitives Verhalten ist, wenn man niemals Kontakt zur Firmware-Seite hat. Ich für meinen Teil halte es noch immer für richtiger das Verhalten auf dem Transport-Protokoll konsistent zu halten.

Borg da kann ich dir nicht recht geben. Das Einstecken per USB führt zum Starten des Stacks. Der war vorher stromlos und jetzt ist er da. Bei WLAN kann der Stack seit Jahren laufen und trotzdem kriege ich immer einen Callback als wäre er jetzt gestartet und einsatzbereit. Das ist nicht das gleiche, auch wenn man gleichheit immer anders definieren kann. Wenn du sagst es ist absolut notwendig, dass die WLAN-Extension immer den enumerate-callback auslöst, dann sollte dieser Luxus auch jedem vergönnt sein der sich zu einem brickd verbindet. Ansonsten macht das euer Plug & Play Konzept kaputt! Die Behauptung stand ja im Raum, dass ich nicht wissen muss ob ich mich zu einem brickd verbinde oder zu einer WLAN-Extension, das sollte transparent sein. De facto ist es aber nicht transparent, weil ich beim einen das enumerate auslösen muss und beim anderen nicht. und das obwohl beide Stacks schon seit Stunden am Strom hängen. Ich denke aber die Lösung für Loeti sind weiterhin einfach Shell-Bindings. Wenn ich das richtig sehe, bist du ja darauf aus ein simples "high-level" Konzept zur Verfügung zu haben.

Im Fall der Sortierung muss ich TF in Schutz nehmen. Wir reden hier vom Low-Level-Protokoll. Wenn dort spezifiziert ist, dass die Daten ungeordnet ankommen können, dann ist das okay und durchaus üblich (auch in der IT-Welt; siehe UDP und warum es überhaupt TCP gibt). Der "Sonderfall" bei dir ist ja, dass du immer die Verbindung aufbaust um genau eine Frage zu stellen und dann die Verbindung wieder abbaust. Üblicherweise bestehen Verbindungen länger, zumindest ist das Protokoll darauf ausgelegt und optimiert. Ob es nun wirklich nötig ist den connected-callback bei Verbindung per WLAN loszuschicken weiß ich nicht. Konsequenterweise sollte zumindest der brickd dann das gleiche tun (von mir aus durch caching) wenn ich mich zu ihm verbinde oder niemand sollte es tun. Auf jeden Fall denke ich sollte sich das Verhalten zwischen USB und WiFi nicht unterscheiden. @Loeti: Eine Notlösung falls es nicht auf enorme geschwindigkeit ankommt: Verbindung aufbauen, abwarten bis nix mehr kommt*, Anfrage schicken, Antwort lesen. * "bis nichts mehr kommt" ist abhängig von der Stackgröße und Konfiguration, aber ich denke 2 Sekunden sollten halbwegs sicher sein @TF: Unter Umständen wäre beim Low-Level-Protokoll eine RFC-artige schreibweise besser geeignet. Also insbesondere sollte überall die Unterscheidung zwischen MUST, SHOULD, MUST NOT usw. getroffen werden. Das setzt natürlich eine vollständige Spezifikation vorraus, an diese müssten sich dann auch eure Bricks penibel halten.

Hallo, ich möchte gerade nochmal versuchen die Dinge zusammenzutragen die derzeit nicht dokumentiert sind. Auf der Seite der TCP/IP-Doku wären das: Die Disconnect-Probes der Bindings Die "forced-ACK" Pakete der WLAN-Extension Was meiner Meinung nach bisher auch komisch läuft sind "spezielle" UIDs. In der Beschreibung zu enumerate (FID 254) schreibt ihr, dass die UID 0 für broadcast steht: Allerdings wird auch die disconnect-Probe an Adresse 0 verschickt. Das würde für mich bedeuten, dass das Paket jeden Teilnehmer im Stack erreichen und dieser es selbst ignorieren muss. Ich meine mich zu erinnern, dass das nicht so ist. Das führt aber dazu, dass UID 0 eben keine broadcast-adresse ist, sondern einfach nur die Function-ID 254 was besonderes wäre. Ich fände es übrigens cool, wenn es eine echte Broadcast-Adresse gäbe und halt eine "wegwerf"-Adresse für Dinge wie Pings.

Huhu, mir ist seit gestern abend aufgefallen, dass ich beim Absenden von Nachrichten immer für einen Wimpernschlag so ein kleines rotes Fenster sehe. Da ich nie lesen konnte was da stand habe ich heute mal einen Screenshot gemacht, um es in Ruhe lesen zu können (siehe Anhang). Das Fensterchen sagt, dass der Text in der Titelzeile zu lang sei. Damit habe ich zwei Probleme: 1. Habe ich mir diesen Text nicht ausgedacht, das war das Forum selbst 2. Kommt der Hinweis (für mich) beim Klick auf "Schreiben" und damit eh viel zu spät Viele Grüße Jan

Welche Archtektur haben die Maschinen? Vermutlich stinknormal x86 oder? (ich glaube unter Linux sagt dir das "arch") Ansonsten wurde der neue Brickd in C(++?) geschrieben, um effizienter zu sein und besser auf kleinen Maschinen zu laufen. Das bedeutet aber auch, dass die Plattformunabhängigkeit plötzlich eingeschränkt ist. Hast du einen dieser apt-get-Befehle genutzt, um den brickd zu installieren: http://www.tinkerforge.com/de/doc/Software/Brickd_Install_Linux.html#brickd-install-linux (etwas runterscrollen) Falls ja: Hast du den richtigen genutzt?

Verstehe ich es richtig, dass das Problem gar nicht verschwindet, wenn du die Stromversorgung nur für wenige Sekunden unterbrichst? Was bewirkt das Drücken der Reset-Taste am Brick?

Jop... du müsstest jetzt alle Pakete einzeln parsen, bis du das Paket mit der richtigen Function-ID findest. Oder Onkel TF ganz lieb um hübsche Shell-Bindings bitten

Oh, dummer Fehler von mir ^^ Hatte nen off-by-one-Fehler in meinem kleinen Programm. Das (korrekte) Ergebnis vom zweiten deiner Dumps: Packet("62fV73" fn: 253 seq: 0 resp: True err: 0)[34] Packet("aJY" fn: 253 seq: 0 resp: True err: 0)[34] Packet("auS" fn: 253 seq: 0 resp: True err: 0)[34] Packet("aJY" fn: 1 seq: 1 resp: True err: 0)[10] Packet("b1E" fn: 253 seq: 0 resp: True err: 0)[34] Deine Vermutung mit der Enumeration scheint also korrekt zu sein Ich wusste nur nicht, dass der Callback auch ohne Aufforderung versendet wird. (edit:) Aber tatsächlich ist genau dieses Verhalten dokumentiert...

Habe grad den ersten Dump geparsed: Packet("62fV73" fn: 253 seq: 0 resp: True err: 0)[34] Packet("SpzBW" fn: 8 seq: 0 resp: False err: 1)[253] der zweite sieht genauso aus... Was du hier siehst ist aber nur der Inhalt der Paket-Header, die Payloads werte ich nicht aus. Kannst du die beiden UIDs deinen Bricks/Bricklets zuordnen? Das zweite Paket scheint jeweils ein sehr langes Fehlerpaket zu sein... Der Error-Code 1 beim zweiten Paket sagt laut Doku "Invalid Parameter"

Könntest du die jeweiligen Dumps nochmal als binärdatei (dateiendung ist mir egal ^^) anhängen? Würde die gerne mal durch ein Tool von mir jagen, um den Paketinhalt selbst lesen zu können ^^

In deiner Antwort scheinen schonmal mehrere Pakete zu stecken. Das fünfte Byte deines dump hat als Wert 2216 = 3410. Das bedeutet das erste Paket ist 34 Byte lang. Die Function-ID der ersten Antwort ist 253, da konnte ich auf die Schnelle nicht finden was das ist. Aber offenbar nicht die Antwort auf das von dir verschickte Paket. Denke das ist wieder ein Fall für den Doku-Doktor. edit: Tatsächlich stellte sich heraus, dass das Verhalten wie dokumentiert war (siehe unten). Vermutlich sollte es für deinen Anwendungsfall aber auch so etwas wie Shell-Bindings geben. Binding ist da natürlich nicht das richtige Wort, aber am Ende ein Tool das ich irgendwie so (oder so ähnlich) nutzen kann: > tinker bricklet-temperature myU1D temperature 21.34 edit: Dieser Post bezieht sich auf deinen ersten Dump

Naja, das Protokoll 2.0 wurde tatsächlich ohne gebaut. Das ist in dem Fall eher ein Hack, weil man dem WiFi-Modul nicht ordentlich sagen kann wie es delayed ACK umsetzen soll. Ich wäre aber auch stark dafür, dass mal definiert wird was für "Leernachrichten" in welche Richtung erlaubt sind und welches Verhalten dafür jeweils zu erwarten ist.

Das sind die erzwungenen ACKs, da gab es hier einen Thread zu (Einer der jüngeren WLAN-Problem-Threads). SOllte aber definitiv noch von TF dokumentiert werden. Genauso wie die von den Bindings ausgehenden Pings (falls nicht schon geschehen). edit: hier ist der Thread http://www.tinkerunity.org/forum/index.php/topic,1339.45.html die letzten 1.5 Seiten sind glaube ich der interessante teil...

Habe in dem Thread gar nix mehr geschrieben ^^ Also mein Pull Request ist jetzt im offiziellen Brickv-Repo enthalten, das heißt es liegt jetzt an TF das eventuell auch in Binärform zu veröffentlichen. Bis dahin kannst du dir auf Github den Source-Code als ZIP-Datei herunterladen, das entpacken und im Verzeichnis src/brickv das Python script flash-brick-cli.py ausführen: > python flash-brick-cli.py --help usage: flash-brick-cli.py [-h] -p PORT -f FILE Used to flash firmware onto a brick optional arguments: -h, --help show this help message and exit -p PORT, --port PORT the name of the serial-port the brick is connected to -f FILE, --file FILE The path to the firmware-file Hoffe das hilft dir schonmal weiter. Derzeit unterstützt das Tool halt nur das flashen einer Datei aufs Brick, das Herunterladen des Images müsstest du noch selbst erledigen...

Tatsächlich wäre es cool gewesen beim Protokoll 2.0 eine Begrüßungsnachricht vorzusehen. Das hätte zum einen zukünftige Migrationen erleichtert (weil in so einer Begrüßung auch Protokollversionen enthalten sein können) und eben auch ermöglicht am Anfang zu prüfen, ob der Dienst am anderen Ende tatsächlich ein brickd ist. Wäre aber vermutlich sogar nachrüstbar...

Offenbar ist das ja jetzt auch in die offizielle Firmware eingegangen. Hat die "Deadlock"-Erkennung auch etwas mit diesem Thread zu tun oder kommt wie von woanders?

Ganz ruhig, niemand will trollen... aber wenn man nicht zu allen Argumenten gleichzeitig etwas sagen will oder kann, dann sagt man etwas zu denen zu denen man etwas sagen kann. Das tue ich jetzt auch: Da du das gesagt hast, ohne dass es zuvor im Thread als Idee aufkam wollte ich sichergehen, ob du alles richtig verstanden hast. Du bist quasi initiativ auf das Thema eingegangen... Tatsächlich sind die Sicherheitslücken in "Java" ziemlich irrelevant: [*]Sie betreffen nicht das Konzept der Sprache sondern die konkrete Implementierung der JRE [*]Die JRE wäre für das Brick unabhängig der Software-JRE implementiert, möglicherweise sogar von anderen Herstellern (das heißt nicht, dass es frei von Lücken wäre... es sind nur vollkommen unabhängige Lücken) [*]Alle Lücken betrafen nur den Browser, da es dort ein erstrebenswertes Ziel ist an höhere Privilegien zu gelangen, diese hat man außerhalb des Browsers oder gar auf einem Brick sowieso Last but not least wurde Java aufgrund anderer Kritieren schon nahezu ausgeschlossen, denke aber Sicherheitsbedenken sollten im vorliegenden Fall am wenigsten ausschlaggebend sein. Ist reines Implementierungsdetail. Python könnte auch kompiliert ausgeführt werden (wird es zum Teil auch) und man könnte C auch interpretiert ausführen. Zu ersterem siehe auch den Teil den ich schon zum Thema geschrieben habe. Wenn ich deine Idee richtig verstanden habe würdest du gerne eine neue Sprache haben, um in dieser einige wenige Grundfunktionen umsetzen zu können. Den Code würdest du normal auf dem PC kompilieren (lies als: "Brickfertig machen"). Da frage ich: Warum kann für diesen Zweck nicht eine Untermenge einer bereits existierenden Sprache herhalten?

@Batti: In einem anderen Thread habe ich gelesen, dass es zwei Treiber gibt die abwechselnd für einzelne Zeilen zuständig sind. Da nur jede zweite Zeile (laut Bild) betroffen ist vermute ich, dass einer der Treiber (oder eine andere Komponente die pro Treiber extra zum EInsatz kommt) defekt sein könnte. Gibt es denn elektrische Unterschiede am LCD, je nachdem ob der Strom nur aus dem Master oder aus der Step-Down kommt?

Idealerweise sollte das jetzt gar kein ruckeln mehr sein oder? Weil ein paar Millisekunden sollte sich das OS des PC ja nicht davon stören lassen, dass es kein ACK gibt.