[TCP/IP] Temperaturantwortpaket beinhaltet auch IO4 Datenpakete/Fragmente.

Hallo zusammen,

der eigentliche Betragstitel sollte heissen: "Bitte keine Werbung schicken oder was ist das fuer Paketpost?" Ich habe mich doch dann mehr sachorientiert ausgedrueckt. 

Ich stelle gerade einen weiteren Brickstack auf Protokoll v2 um. Dabei tritt folgendes Problem auf, dass ich jetzt in Antwortpaketen einer Temperaturabfrage Daten von IO4 Paketen habe!

Dies ist das Temperaturabfragepaket.

# hexdump -C OUT.NOW.bin
00000000  [color=green]62 57[/color] 00 00 08 01 18 00                           |bW......|
00000008

Wird fast immer mit 18, 26, 34 Byte langen Paketen beantwortet! Erwartet werden aber nur 10 Bytes.

-rw-r--r-- 1 root root       26 19. Apr 14:04 IN.20130419_140409.bin
-rw-r--r-- 1 root root       18 19. Apr 14:05 IN.20130419_140509.bin
-rw-r--r-- 1 root root       18 19. Apr 14:06 IN.20130419_140609.bin
-rw-r--r-- 1 root root       34 19. Apr 14:07 IN.20130419_140710.bin
-rw-r--r-- 1 root root       26 19. Apr 14:08 IN.20130419_140810.bin
-rw-r--r-- 1 root root       26 19. Apr 14:09 IN.20130419_140909.bin
-rw-r--r-- 1 root root       34 19. Apr 14:10 IN.20130419_141011.bin
-rw-r--r-- 1 root root       18 19. Apr 14:11 IN.20130419_141109.bin
-rw-r--r-- 1 root root       26 19. Apr 14:12 IN.20130419_141209.bin

Hier ein Beispiel:

hexdump -C IN.20130419_135509.bin
00000000  [color=green]62 57 00 00 0a 01 18 00  15 09[/color] [color=orange]a2 59 00 00 08 03[/color]  |bW.........Y....|
00000010  [color=orange]18 00[/color] [color=pink]a2 59 00 00 08 03  18 00[/color] [color=red]a2 59 00 00 08 03[/color]  |...Y.......Y....|
*

Die ersten 10 Byte sind meistens* die erwartete Antwort. Der Rest kommt von einem IO4 Bricklet.

Warum kommt es mehrmals (Orange,Pink.Red)?

Warum ist das letzte Paket kaputt?

Hat das was mit der Folgenummer zu tun? Die Pakete kommen aber von unterschiedlichen IPs/PCs oder zumindest von einer anderen TCP Session.

So sieht die Infrastruktur folgendermassen aus. Dies sind die Bricklet UIDs:

7DG [color=green]62 57[/color] Temperatur
7ud 3c 55 Ambient
7Tf 74 5a Humidity
7PC [color=red]a2 59[/color] IO4

Der Aufbau sieht folgendermassen aus:

[Temper.+Ambi+Hmidity+IO4--Master--USB--PC0]--LAN--WAN--+--WAN--PC1(fragt Temper. ab)
                                         |              +--WAN--PC1(unset io4 Bit0)
                 PC0(set io4 Bit0,1,2)   +              +--WAN--PC2(unset io4 Bit1)
                                                        +--WAN--PC3(unset io4 Bit1)

Alle 3 PC (1,2,3) arbeiten per Cron jede Minute einen Job ab und greifen auf die Bricklets an PC0 zu.

So, warum bekommt ich bei der Temperaturabfrage Fragmente von IO4 Paketen? Wer laesst da was uebrig?

Danke fuer eure Unterstuetzung

Der Loetkolben

PS: *Anscheinend gibt es sogar noch Paketkombinationen wo noch mehr Muell drinsteckt, aber die habe ich noch nicht fangen koennen.

PPS: Hatte ich schon erwaehnt dass ich das Protokoll v2 nicht so prickelnd finde. 

Benutzt du auf den anderen PCs (die die mit dem IO4 interagieren) die Funktion set_configuration?

Falls ja: Setzt du dabei das ResponseExpected-Flag?

Falls auch hier ja: Wartest du auch ab bis dir die Antwort geschickt wird?

Ich vermute du hast das Flag gesetzt obwohl du es lieber gar nciht gesetzt haben willst.

Btw. ich finde das neue Protokoll cool. Aber es ist sicherlich nicht darauf optimiert mittels Shell-Scripten implementiert zu werden... dennoch spannend, dass es offenbar möglich ist

Ansonsten glaube ich, dass einige deiner Probleme nicht spezifisch für das Protokoll 2.0 sind, sondern eher auf zum Teil neues Verhalten im brickd (unabhängig vom Protokoll) zurückzuführen sind.

Benutzt du auf den anderen PCs (die die mit dem IO4 interagieren) die Funktion set_configuration?

Ja, die LED am IO4 mache ich so aus:

SENDPACKET=$UID"\x0B\x03\x18\x00\x01\x6F\x00

SENDPACKET=
\$UID            = UID in Hex
\x0B             = Paketlange 11 Byte
\x03             = Funktion " IO4.set_configuration"
\x18             = "Sequence number 1 and response expected 1 as uint8 (0x18) and"
\x00             = Flags = 0
\x01             = "Selection Mask", welche LED/Port gesteuert werden soll
\x6F             = 6f="o", also Output
\x00             = 00=off x01=on

Falls ja: Setzt du dabei das ResponseExpected-Flag?

Falls auch hier ja: Wartest du auch ab bis dir die Antwort geschickt wird?

Ja, setze ich.

Ich warte nicht unbedingt, zumindest Werte ich die Antwort nicht aus. Das schaue ich mir nochmals an.

Ich vermute du hast das Flag gesetzt obwohl du es lieber gar nciht gesetzt haben willst.

Ok, das schaue ich mir nochmals an. Danke fuer die Hinweis, ABER hat das wirklich was mit meinem Problem zu tun. :gruebel:  Vielleicht kann ich damit mein Problem vermeiden, aber warum werden eventuell nicht abgeholte Paket dann bei irgendeiner anderen, hier Temperatur, Abfrage mit weggeschickt?

Frei nach dem Motto: Pakete die keiner abgeholt hat, bekommt dann einfach der naechste der eine Anfrage stellt??? Das kann es doch nicht sein. 

Btw. ich finde das neue Protokoll cool. Aber es ist sicherlich nicht darauf optimiert mittels Shell-Scripten implementiert zu werden... dennoch spannend, dass es offenbar möglich ist

Wie denn sonst?    Mir hat man versprochen: Raider heisst jetzt Twix, sonst aendert sich nix. 

Der Loetkolben

Wie AuronX sagt, sind die Antworten vom IO-4, die du da sieht, die fürs Response Expected Flag. Unter der Annahme, dass du die Temperaturabfrage und das IO-4 Setzen nicht über die gleiche TCP/IP Verbindung machst solltest du diese IO-4 Antworten da nicht sehen.

Spielt dir da vielleicht netcat einen Streich, oder machst du doch beides über eine TCP/IP Verbindung?

Hast du mal ins brickd Log geschaut und dort nachverfolgt wann TCP/IP Verbindung auf und abgebaut werden und wo welche Antworten hingesandt werden? Wireshark kann auch sehr hilfreich sein.

Dass da einer der IO-4 Nachrichten die letzten 2 Byte fehlen könnte an netcat liegen, dass dann eben nur die ersten n-2 von n Byte empfangen hat.

Hallo photron,

danke fuer die Unterstuetzung.

Ich habe bei allen 4 PC die "IO4.set_configuration" benutzen das "response expected" flag geloescht (auf "0" gesetzt) und dann war Ruhe. Die Temperaturabfrage hat nur 10 Byte empfangen. Soweit ok.

Unter der Annahme, dass du die Temperaturabfrage und das IO-4 Setzen nicht über die gleiche TCP/IP Verbindung machst solltest du diese IO-4 Antworten da nicht sehen.

Die Info von photron hat mir keine Ruhe gelassen und ich habe NUR an PC2 das "response expected" wieder auf 1 gesetzt. Das Problem ist wieder da. Damit sollte ausgeschlossen sein, dass es sich um die gleiche IP Verbindung handelt.

Also: 3 PCs (0,1,3) greifen mit "response expected flag = 0" auf das IO4 zu.

PC 1 holt AUCH Temperaturdaten ab.

PC 2 greift als einziger mit "response expected flag = 1" auf IO4 zu.

Ergebnis: 18 Byte lange Antworten an PC1 der die Temperatur abfragt:

# hexdump -C IN.20130419_163609.bin
00000000  [color=green]62 57 00 00 0a 01 18 00  02 09[/color] [color=red]a2 59 00 00 08 03[/color]  |bW.........Y....|
00000010  [color=red]18 00[/color]                                             |..|
00000012

[Temper.+Ambi+Hmidity+IO4--Master--USB--PC0]--LAN--WAN--+--WAN--PC1(fragt Temper. ab) R=1, logisch da Temper. Abfrage
                                         |              +--WAN--PC1(unset io4 Bit0) R=0
             PC0(set io4 Bit0,1,2) R=0   +              +--WAN--PC2(unset io4 Bit1) R=1
                                                        +--WAN--PC3(unset io4 Bit1) R=0

Alle PCs haben unterschiedliche IP und unterschiedliche Netze.

Hast du mal ins brickd Log geschaut und dort nachverfolgt wann TCP/IP Verbindung auf und abgebaut werden und wo welche Antworten hingesandt werden?

Bezueglich Logfile:

17:01:01.200814 <I> <network.c:94> Added new client (socket: 10, peer: [color=green]PC1[/color])
17:01:01.655124 <I> <network.c:94> Added new client (socket: 16, peer: [color=brown]PC0-lokalhost[/color])
17:01:01.655828 <I> <client.c:65> Client (socket: 16, peer: [color=brown]PC0-lokalhost[/color]) disconnected by peer
17:01:03.180328 <I> <network.c:94> Added new client (socket: 16, peer: [color=green]PC1[/color])
17:01:03.183070 <I> <client.c:65> Client (socket: 16, peer: [color=green]PC1[/color]) disconnected by peer
17:01:03.676506 <I> <network.c:94> Added new client (socket: 16, peer: [color=red]PC2[/color])
17:01:03.677726 <I> <client.c:65> Client (socket: 16, peer: [color=red]PC2[/color]) disconnected by peer
17:01:03.678439 <W> <network.c:280> Broadcasting response because no client has a matching pending request
17:01:04.289453 <I> <network.c:94> Added new client (socket: 16, peer: [color=purple]PC3[/color])
17:01:04.293536 <I> <client.c:65> Client (socket: 16, peer: [color=purple]PC3[/color]) disconnected by peer
17:01:09.707918 <I> <client.c:65> Client (socket: 10, peer: [color=green]PC1[/color]) disconnected by peer

Nochmals zur Erleuterung:
[color=brown]PC0[/color] setzt IO4 mit R=0
[color=green]PC1[/color] holt Temperatur UND setzt IO4 mit R=0
[color=red]PC2[/color] setzt IO4 mit R=1
[color=purple]PC2[/color] setzt IO4 mit R=0

Was ich sehen kann ist, dass zumindest die Anzahl der Anfragen passt. Der Warningeintrag scheint ein Hinweis darauf zu sein, aber ich kann es nicht genau interpretieren.

So, der Ball ist wieder ueberm Netz. 

Danke.

Der Loetkolben

Okay, jetzt weiss ich was da passiert.

PC2 verlangt einen Response für den set_configuration, wartet aber nicht auf die Antwort sondern macht die Verbindung wieder zu, bevor die Antwort bei brickd angekommen ist.

Kurzer brickd Interna Ausflug: Für eingehende Anfragen mit R Flag merkt sich brickd den Header des Pakets in einer Liste pro TCP/IP Verbindung. Dadurch kann er eingehende Antworten an die Verbindung weiterreicht, die auf diese Antwort wartet. Wenn eine Antwort ankommt, auf die keiner wartet dann wir sie an alle geschickt.

Dann kommt die verlangte Antwort von set_configuration an. Da aber die anfragende Verbindung schon wieder zu ist wartet keiner mehr auf diese Antwort und brickd schickt sie an alle offenen TCP/IP Verbindungen. Und daher bekommt deine temperaturabfragende Verbindung die IO-4 Antworten.

Da ist also by-Design wenn du so willst.

Nachdem ich noch ein wenig gesucht habe hier eine kleine Zusammenfassung:

Antwortpakete die nicht zugestellt werden koennen erzeugen einen Broadcast und werden irgendeinem anderen Anfrager mit aufs Auge gedrueckt.

nc -q1 nc wartet nicht auf Antwort und "response expected flag = 0" : Alles OK.

nc -q1 nc wartet nicht auf Antwort und "response expected flag = 1" : Erzeugt einen Error und ein Broadcastpaket an alle, da der Stack nicht weiss wohin er die Antwort schicken soll. 

nc -w1 nc wartet auf Antwort und "response expected flag = 0" : Alles OK, da sowieso keine Antwort kommt.

nc -w1 nc wartet auf Antwort und "response expected flag = 1" : Alles OK, da die Antwort abgeholt wird.

Hallo photron,

habe gerade vor dem abschicken deinen Beitrag gelesen und freue mich _wirklich_ sehr das das Phaenomen geklaert ist. Danke. Du stellst das auch gut da, aber ist folgende Aussage wirklich clever?

Wenn eine Antwort ankommt, auf die keiner wartet dann wird sie an alle geschickt.

Soll man da lachen oder weinen?    Ich wuerde sagen: Wenn eine Antwort kommt auf die keiner wartet, dann schmeiss sie weg! Damit kann ein fehlerhaftes Programm alle anderen Programme die auch auf den gleichen Stack zugreifen ausser Tritt bringen.

Was sollen denn ueberhaupt andere Programme mit Antworten anfangen die sie nie angefragt haben? - Das verstehe ich nicht.

Der Loetkolben

Mir hat man versprochen: Raider heisst jetzt Twix, sonst aendert sich nix.

Das gilt ja quasi auch für alle Anwender oberhalb von TCP/IP ^^ Aber eben nicht auf TCP/IP-Ebene, weil da hat sich ja alles geändert ^^

Was ich mich gerade noch frage: Diese Pakete die da übrig waren:

Warst du wirklich verbunden während die Antwort kam oder hast du dich verbunden nachdem die Antwort kam?

Für den Fall, dass die Pakete nur dann kommen wenn man "zufällig" zur gleichen Zeit verbunden ist, würde ich das by-Design Argument so unterschreiben kurze Planänderung: Ich schließe ich Loeti an und frage doch nochmal nach dem "Warum?". Also warum ist es sinnvoll dann zu broadcasten?

Falls  aber die Nachrichten einfach später an den nächstbesten der sich verbindet zugestellt wird, würde ich es allgemein nicht verstehen.

Soll man da lachen oder weinen?    Ich wuerde sagen: Wenn eine Antwort kommt auf die keiner wartet, dann schmeiss sie weg! Damit kann ein fehlerhaftes Programm alle anderen Programme die auch auf den gleichen Stack zugreifen ausser Tritt bringen.

Warum das? Alle unsere Bindings erkennen das die Nachricht nicht für sie ist und schmeißen sie weg.

Falls nun aber ein Fehler in der Routingtabelle entsteht, kommt die Nachricht trotzdem noch an (würde sie nicht wenn Brickd sie wegwerfen würden).

Noch mehr Sinn macht das Verhalten wenn die WIFI oder Ethernet Extension benutzt wird: Die Brickd Implementierung auf dem Master Brick hat nur eine vergleichsweise kleine Maximalgröße für die Routing-Tabelle. Dort kann es also passieren das sie "überläuft", dann gibt es das gleiche Verhalten.

Warum sollte ich die Nachricht denn da wegwerfen und evtl. unnötige Timeouts erzeugen?

Hallo AuronX,

irgendwie es ist noch mysterioeser. Um Deine Frage zu beantworten ob die Verbindung noch aktuell war habe ich alle nicht relevanten PC Anfragen rausgenommen.

Hier redet nur noch der PC1 der die Temperatur abfragt und PC2 der das IO4 setzt mit R=1, aber ohne auf Antwort zu warten.

Dies ist wie erwartet. Siehe obige Beitrage. BEISPIEL 1

18:13:01.459377 <I> <network.c:94> Added new client (socket: 10, peer: [color=blue]PC1[/color]) # Get-Temepratur open
18:13:03.475265 <I> <network.c:94> Added new client (socket: 16, peer: [color=red]PC2[/color]) # Set-IO4 open, [color=red]don´t wait for answer, R=1[/color]
18:13:03.476944 <I> <client.c:65> Client (socket: 16, peer: [color=red]PC2[/color]) disconnected by peer # Set-IO4 close
18:13:03.477411 <W> <network.c:280> Broadcasting response because no client has a matching pending request
18:13:09.566455 <I> <client.c:65> Client (socket: 10, peer: [color=blue]PC1[/color]) disconnected by peer # [color=red]Get-Temperatur close, with IO4 Data[/color]

-rw-r--r-- 1 root root [color=purple]18[/color] 19. Apr 18:13 IN.20130419_181309.bin

Hier wird es "lustig". Ich lasse zuerst das IO4 setzen, warte dann 15 Sekunden und hole dann die Temperatur ab. Komischerweise wird kein Broadcast erzeugt? Auch hier ist die Anfrage fehlerhaft. BEISPIEL 2

2013-04-19 18:16:03.683922 <I> <network.c:94> Added new client (socket: 10, peer: [color=red]PC2[/color]) # Set-IO4 open, [color=red]don´t wait for answer, R=1[/color]
2013-04-19 18:16:03.685432 <I> <client.c:65> Client (socket: 10, peer: [color=red]PC2[/color]) disconnected by peer # Set-IO4 close - [color=orange]WARUM WIRD KEIN BROADCAST ERZEUGT??[/color]
#15 Sekunden Pause
2013-04-19 18:16:16.919782 <I> <network.c:94> Added new client (socket: 10, peer: [color=blue]PC1[/color]) # Get-Temepratur open
2013-04-19 18:16:22.952056 <I> <client.c:65> Client (socket: 10, peer: [color=blue]PC1[/color]) disconnected by peer # Get-Temperatur close, [color=green]ONLY Temperatur Data[/color]

-rw-r--r-- 1 root root [color=purple]10[/color] 19. Apr 18:16 IN.20130419_181622.bin

Tritt das Phaenomen nur auf wenn zufaellig andere Anfragen "offen" sind?

Der Loetkolben

Hallo borg.

Alle unsere Bindings erkennen das die Nachricht nicht für sie ist und schmeißen sie weg.

Warum erst durch die Gegend schicken wenn sie dann doch weggeschmissen werden. :gruebel:

Falls nun aber ein Fehler in der Routingtabelle entsteht, kommt die Nachricht trotzdem noch an (würde sie nicht wenn Brickd sie wegwerfen würden).

Das mit der Routingtablle ansich verstehe ich nicht ganz. Sollte man da nicht die Routingtabelle in Ordnung bringen wenn sie fehlerhaft ist und nur dorthin was schicken wo es hingehoert?

Noch mehr Sinn macht das Verhalten wenn die WIFI oder Ethernet Extension benutzt wird: Die Brickd Implementierung auf dem Master Brick hat nur eine vergleichsweise kleine Maximalgröße für die Routing-Tabelle. Dort kann es also passieren das sie "überläuft", dann gibt es das gleiche Verhalten.

Geht mir weg mit dem WLAN. Da habe ich bisher noch gar keine Loesung. Der WLAN Stack muellt mich mit Broadcast zu ohne dass ich vorher testen kann ob es ein WLAN Stack ist. Das eigentliche erwartete Datenpaket steekt dann irgendwo mitten drin.

Diese ganzen unverlangten Pakete die irgendwann und irgendwo auftauchen machen mich vollkommen fertig. Siehe auch den Beitrag direkt darueber von mir. Mal wird ein Broadcast erzeugt wenn kein Empfaenger (mehr) da ist, mal nicht. Das ist doch keine Lotterie hier sondern Computerei. Manchmal moechte ich die Brocken hinwerfen. 

BTW: Ich mag Tinkerforge, aber habe ich schon gesagt, dass ich das Protokoll V2 nicht gut finde? 

Der Loetkolben

Tritt das Phaenomen nur auf wenn zufaellig andere Anfragen "offen" sind?

So hat es photron beschrieben, wenn es so läuft, dann ist alles "normal".

Noch mehr Sinn macht das Verhalten wenn die WIFI oder Ethernet Extension benutzt wird: Die Brickd Implementierung auf dem Master Brick hat nur eine vergleichsweise kleine Maximalgröße für die Routing-Tabelle. Dort kann es also passieren das sie "überläuft", dann gibt es das gleiche Verhalten.

Ah, das (begrenzter Speicher) ist eine sinnvolle Erklärung für das Kaputtgehen der Routingtabelle. Dementsprechend sollten Bindings grundsätzlich damit umgehen können.

Btw. ist eigentlich in der Doku vermerkt, dass man auch Pakete kriegen kann die man nicht gefordert hat? Das wäre noch was ^^ Sollte wie immer nur da stehen, dann weiß man es.

Dennoch: Kann im (Software-)Brickd die Routing-Tabelle auch kaputtgehen? (abgesehen von Programmierfehlern)

P.S.: Oh mein Gott TF, beeilt euch mit den Shell-Bindings

Hier wird es "lustig". Ich lasse zuerst das IO4 setzen, warte dann 15 Sekunden und hole dann die Temperatur ab. Komischerweise wird kein Broadcast erzeugt? Auch hier ist die Anfrage fehlerhaft.

Ich sehe da jetzt das Problem nicht. Im zweiten Fall wird nichts gebroadcasted weil gar kein Socket mehr auf ist. Wo soll Brickd es denn hinschicken ?

Du könntest Brickd mit --debug starten, dann bekommst du viel mehr Ausgaben und es wird evtl klarer was passiert.

Das mit der Routingtablle ansich verstehe ich nicht ganz. Sollte man da nicht die Routingtabelle in Ordnung bringen wenn sie fehlerhaft ist und nur dorthin was schicken wo es hingehoert?

Wie sollen wir denn die Routing Tabelle in so einem Fall in Ordnung bringen? Die korrekten Informationen sind ja nicht mehr da. Die Funktionsweise ist die gleiche wie die von einem Ethernet Switch.

Dennoch: Kann im (Software-)Brickd die Routing-Tabelle auch kaputtgehen? (abgesehen von Programmierfehlern)

Mir würde da auf Anhieb keine Möglichkeit einfallen. Ich könnte auch damit leben wenn (Software-)Brickd dort die Nachricht wegwirft. Aber das Protokoll garantiert einfach nicht, das auf eine Anfrage eine Antwort direkt im nächsten TCP/IP Paket kommt, da kommen wir nicht drumrum. Hat das alte Protokoll übrigens auch nicht... Hat nur so wie Loeti es benutzt hat zufällig funktioniert .

P.S.: Oh mein Gott TF, beeilt euch mit den Shell-Bindings

Kommt nach LabView .

Hallo AuronX, hallo borg.

Darf ich zusammenfassen:

Wenn jemand eine Antwort anfragt (R=1) , diese aber nicht abholt/abnimmt wird sie an alle geschickt, die gerade eine Verbindung offen haben, auch wenn sie sie nicht haben wollen (BEISPIEL 1). Sollte keine Verbindung offen sein wird sie verworfen (BEISPIEL 2).

Richtig? 

Der Loetkolben

Zusammenfassend: Sie wird an alle geschickt die zum Zeitpunkt des eintreffens verbunden sind. In Beispiel 2 ist das nur zufällig niemand.

In einer RFC-Style-Doku würdest du dazu etwas in der Art lesen:

Clients MUST NOT rely on receiving only responses they have requested.

(so oder so ähnlich)

@Loeti: Da ich nicht glaube, dass du Zeit (oder gar Lust) dazu hast vollständige Bindings im Alleingang zu implementieren wäre vermutlich mein bester Rat an dich abzuwarten bis TF die Shell-Bindings veröffentlicht hat. Die sind ja dann quasi genau für dich gemacht. Da solltest du auch frühzeitig anfangen TF zu bitten Feedback geben zu dürfen

Das Protokoll ist roh eben nicht so lecker wie die gekochten Bindings

Zusammenfassend: Sie (die Antwort) wird an alle geschickt die zum Zeitpunkt des eintreffens verbunden sind, aber nur dann wenn der urspruengliche Anfrager nicht mehr erreichbar ist.

Meine Ergaenzung in Rot, denn das ist der springende Punkt.

In einer RFC-Style-Doku würdest du dazu etwas in der Art lesen:

Clients MUST NOT rely on receiving only responses they have requested.

(so oder so ähnlich)

Grummel.

@Loeti: Da ich nicht glaube, dass du Zeit (oder gar Lust) dazu hast vollständige Bindings im Alleingang zu implementieren wäre vermutlich mein bester Rat an dich abzuwarten bis TF die Shell-Bindings veröffentlicht hat.

Da schauen wir mal. 

Die sind ja dann quasi genau für dich gemacht.

Auch ich habe auch das Gefuehl, dass sie die Bindungs nur fuer mich stricken (werden). Das muss wirklich nicht sein, da ich nur wenige Funktionen benutze! So viel Hardware kann ich garnicht kaufen, dass sich die Programmierstunden dafuer bezahlt machen. Das ist mir schon klar und aergert mich selbst.

Es wuerde mir es reichen wenn das Protokoll sinnvoll funktionieren wuerde. 

Das Protokoll ist roh eben nicht so lecker wie die gekochten Bindings

Wer will das schon, ich esse gegrilltes auch lieber ohne diese Marinadentunke. Wer weiss was sich darin alles verbirgt. Vielleicht kommt da auch das ein oder andere Paket unverlangt wieder hoch vorbei. 

Auf zur Revolution. Hiermit starte ich die Petition: Tinkerforge Protkoll V2.1

Der Loetkolben

Hallo zusammen,

hier die _vorerst_ lauffaehige Antwort. Ich gehe davon aus, dass das Paket was ich haben will in der Antwort vorhanden ist. Also matche ich ob und wo es vorkommt und schneide dann den Temperaturwert aus.

Wer mag kann ja mal testen.

#!/bin/bash

HOST=192.168.1.40
PORT=4223

tUID=abc

ALPHABET="123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ"
BASECOUNT=`expr length $ALPHABET`
DECODED=0
MULTI=1
for ((i=`expr length $tUID - 1` ; i > -1 ; i--))
  do
    VALUE=${tUID:$i:1}
    DECODEDVALUE=`expr index $ALPHABET $VALUE`
    DECODEDVALUE=`expr $DECODEDVALUE - 1`
    DECODED=`expr $DECODED + $MULTI \* $DECODEDVALUE`
    MULTI=`expr $MULTI \* $BASECOUNT`
  done
HEXDECODEDSTR=""
HEXDECODED=`printf "%08x" $DECODED`
for i in {6,4,2,0}
  do
    DIGIT=${HEXDECODED:$i:2}
    HEXDECODEDSTR=$HEXDECODEDSTR"\x"$DIGIT
  done

SENDPACKET=$HEXDECODEDSTR"\x08\x01\x18\x00"
RECEIVEPATTERN=`echo -n -e $HEXDECODEDSTR"\x0a\x01\x18\x00" | od -A n -t x1 | tr -d " "`
RECEIVEPACKET=`echo -n -e "$SENDPACKET" | nc -w1 $HOST $PORT | xxd -p`
FOUNDSTART=`echo -e -n $RECEIVEPACKET | xxd -r -p | od -w16384 -A n -t x1 | tr -d " " | grep -o -F $RECEIVEPATTERN -b | cut -f1 -d ":"`
FOUNDSTART=`expr $FOUNDSTART + 17`
FOUNDEND=`expr $FOUNDSTART + 3`

TEMP1=`echo -e -n $RECEIVEPACKET | xxd -r -p | od -w16384 -A n -t x2 | tr -d " " | cut -b $FOUNDSTART-$FOUNDEND | tr "[:lower:]" "[:upper:]"`
TEMP2=`echo "scale=2 ; ibase=16; $TEMP1 / 64" | bc`

if [ "$1" = "x" ] ; then echo "`date +%Y%m%d_%H:%M:%S';'%s`;$TEMP2"
   else
     echo -e "\nDie Temperatur betraegt: $TEMP2 Grad.\nParameter x gibt Logfileoutputformat.\n"
fi

Der Loetkolben

@Loetkolben: Schon gesehen: http://www.tinkerunity.org/forum/index.php/topic,1578.0.html ?

Hallo borg,

ja habe ich schon gestern gesehen, aber keine Moeglichkeiten gehabt das zu testen. Heute habe ich erstmal mein WLAN Shell_Abfrage_Provisorium durch eine "runde" Version ersetzt und dann die Bindings getestet. Sie funktionieren bei meinen ersten Tests, wobei ich noch nicht verstehe wie das mit dem Formatieren gehen soll. Auf jeden Fall einen "Herzlichen Glueckwunsch" dazu. 

Wenn man bei mir die immer gleiche Base58 Umwandlung weglaesst und die Werte direkt einsetzt komme ich vielleich auf 5 Zeilen, die man prima in andere Scripte mit einbauen kann und Python ist auch nicht notwendig. 

Schaun wir mal. :-)

Der Loetkolben.