Wie Reset von Masterbrick per Software? brickd Logfile.

[Loetkolben]

Hallo zusammen,

 

ab und zu haengt sich der Masterbrick anscheinend auf und man kann keine Werte abfragen. Ein stop und start des brickd auf dem Debian hilft auch nichts.

 

Es reicht aber aus einmal den Resetknopf zu druecken.  Mein Arm ist aber nicht kilometerlang! Kann man das auch mit einem Tool machen?

 

Wie sieht es eigentlich mit dem Logfile des brickd aus? Im letzten Fehlerfall wurde nichts reingeschrieben (Zeitstempel des Logfiles selbst) und auch ansonsten sieht es recht duerftig aus.  Ohne richtige Zeitstempel wird das nix.

 

/var/log/brickd

--- <exception caught here> ---

  File "/usr/lib/python2.6/dist-packages/twisted/internet/gtk2reactor.py", line 288, in _doReadOrWrite

    why = source.doRead()

  File "/usr/lib/python2.6/dist-packages/twisted/internet/tcp.py", line 460, in doRead

    return self.protocol.dataReceived(data)

  File "/usr/share/brickd/brick_protocol.py", line 111, in dataReceived

    length = get_length_from_data(data)

  File "/usr/share/brickd/brick_protocol.py", line 46, in get_length_from_data

    return struct.unpack('<H', data[2:4])[0]

struct.error: unpack requires a string argument of length 2

 

Waere wenigstens super wenn der brickd schreiben wuerde, dass er das Masterbrick nicht erreichen kann. Das der brickd selbst erreichbar ist kann man daher sehen, dass ein MasterbrickHardwareReset reicht ohne den brickd neu zu starten.

 

Der Loetkolben

 

 

 

 

[Wumpus]

Zuspruch von meiner Seite für ein Software-Reset per API.

 

Bei mir hängt sich häufig das Humidity Bricklet über Chibi auf, so dass es vielfach gepollt werden muss, bis es einen Wert zurückliefert. Die ständige Lauferei zum Master ist schon lästig. Ausserdem muss man ja auch immer resetten, wenn man am Stack gefummelt hat und die Chibis neu angemeldet werden müssen. Vor allen Dingen könnte man automatisiert reagieren, wenn mal irgendetwas hängt.

[AuronX]

Die Frage ist halt wie gut ein Reset per Software funktioniert, wenn doch die Software (bzw. Firmware) hängt...

[photron]

Wie AuronX sagt scheitert Reset per Software daran das eben diese Software ja hängt.

 

Loetkolben, der

 

struct.error: unpack requires a string argument of length 2

 

kommt durch dadurch wenn im brickd ein Packet in mehreren Teilen ankommt. Dass das passieren kann wurde bisher in brickd ignoriert. In brickd Version 1.0.7 ist das jetzt behoben.

[Loetkolben]

Die Frage ist halt wie gut ein Reset per Software funktioniert, wenn doch die Software (bzw. Firmware) hängt...

 

Das ist die Frage. Was haengt und was geht noch? Hat sich der Masterbrick oder der brickd aufgehangen?

Wenn der brickd noch ansprechbar ist, kann er dann via USB noch einen Reset am Masterbrick ausloesen?

Kann man das mit einem USB Kommando (Debian) erreichen?

 

Die Errormessage stammt NICHT vom letzten Aufhaengen. Das konnte ich am Timestamp des Logfiles (war ca. 2 Tage alt) sehen. Einen Grund fuer die letzten Haenger kenne ich nicht.

 

Welche brickd Version habe denn am laufen?? Nehme mal den neuen brickd. Danke fuer den Hinweis!

Bisher:
root@PC:~# dpkg -l | grep brickd
ii  brickd                             1.0                          Brick Daemon

Neu:
root@PC:~# dpkg -l | grep brickd
ii  brickd                             1.0.7                        Brick Daemon

 

Wie sagt Franz? Schauen wir mal. ...

 

Der Loetkolben

 

[Loetkolben]

Ich antworte mal mir selbst.

 

0:1 Verloren!

 

Der 1.0.7 brickd melde nichts zurueck! Wenn ich mich mit dem brickv auf den brickd verbinde kommt die Verbindung ohne Fehlermeldung zustande, aber es wir kein Brick oder Bricklet angezeigt. Die einzige Aktion die ich machen kann ist ein "Disconnect".

Eine Enumerateanfrage per TCP Paket bekommt keine Anwort.

 

Aus meiner Sicht kann man doch mit dem brickd kommunizieren. Kann man den nicht fragen wo denn das Problem ist??

 

Edit: Ich war auf den kilometerlangen Arm der den Masterbrick resetten kann. Masterbrick hat aktuelle FW 1.1.7

 

Der Loetkolben

 

 

 

[ThomasKl]

Könnte man nicht in der Firmware einen Timeout einbauen der die Teile die nicht funktionieren zeitnah resettet.

[Loetkolben]

Hallo ThomasKl,

 

danke fuer die Idee!

Die Frage bleibt: Was hat sich aufgehaengt? Brick oder brickd?

 

Muss da etwa ein Hardwarewatchdog her? Hat die CPU einen an Board?

 

Der Loetkolben

[borg]

@Loetkolben: Hast du irgendeine Vorgehensweise mit der wir das Aufhängen von Master Brick/Brickd reproduzieren können?

[Loetkolben]

Hallo borg,

 

leider nicht wirklich. Es dauert ein paar Stunden oder etwas mehr und dann kann man keine Werte mehr abfragen.

 

Geb mir bitte mal einen Tipp:

Situaltion: Masterbrick nicht abfragbar. Dann habe ich folgens gemacht:

brickd neu installiert mit Version 1.0.7 - Weiterhin keine Datenabfrage moeglich

lsusb

Bus 001 Device 011: ID 16d0:063d GrauTec

Bus 001 Device 010: ID 046d:09a4 Logitech, Inc. QuickCam E 3500

Bus 001 Device 006: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader (Cardreader)

Bus 001 Device 005: ID 058f:6254 Alcor Micro Corp. USB Hub

Bus 001 Device 003: ID 14cd:125a Super Top (Cardreader)

Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

 

Warum bekomme ich bei lsusb eine Rueckmeldung?

Was heisst das? Hat sich der Masterbrick aufgehangen oder nicht?

 

Kann ich den brickd irgendwie zu Debuginformation ueberreden?

Kann man irgendwie eingrenzen wer nicht mehr redet und warum?

Kann es mit dem hohen Speicherverbrauch vom brickd zu tun?

 

Einen Reset am Masterbrick selbst kann ich erst spaeter durchfuehren lassen. Ein funktionsfaehiges "usbreset" Tool gibt es wohl nicht.

 

Der Loetkolben.

 

Nachtrag 23:09h: Resetknopf gedrueckt am Masterbrick. Sonst nichts. Sofort konnten wieder Werte abgefragt werden. Lasse nun den Masterbrick mal mit dem neu installierten brickd 1.0.7 laufen.

Die obigen Fragen bleiben aber noch offen. 

[Wumpus]

Irgendwie kommt mir deine Schilderung bekannt vor. Kannst du den Master selbst noch abfragen (z.B. master_get_chibi_signal_strength)? Bei mir hängen häufig die Humidity Bricklets und ich bekomme beim Auslesen ein Timeout. Erstaunlicherweise kann der brickv dann, wenn man ihn länger laufen lässt, irgend wann (nach ca. 40 Sekunden) wieder Werte lesen. Bei mir hat als Workaround geholfen, dass ich alle Werte im Fehlerfall wiederholt auslese. Dabei benötige ich dann so 3 bis 4 Versuche ehe mal ein Wert kommt. Das ist nicht schön, aber liefert mit dem Workaround zumindest noch Werte.

[Loetkolben]

Hallo Wumpus,

 

anscheinend kann ich im Fehlerfall auch den Masterbrick nicht abfragen. Ich habe kein "master_get_chibi_signal_strength", sondern habe eine Enumerationsanfrage geschickt. Da kam dann nichts zurueck.

 

Ich muesste mal versuchen eine Abfrage zu machen die nur den Masterbrick betrifft, wie z.B. Firmwareversion abzufragen.

 

Den brickv habe ich im Fehlerfall nie so lange arbeiten lassen, werde es aber mal machen. Im Moment laeuft alles stabil.

 

@Tinkerforge: Bei dieser Kaffesatzleserei waere es total super, wenn der brickd ein Logfile schreiben wuerde (Z.B Jeder Zugriff von aussen protokolliert) und man so festellen kann, ob der brickd oder die Kummunikation zum Masterbrick haengt.

Weiterhin waere eine Abfrage, z.B. der Versionsnummer vom brickd super. Damit koennte man im Fehlerfall auch festellen wo das Problem ist und es haette noch einen gewissen nutzen! :-)

 

Der Loetkolben

[photron]

Loetkolben, brickd schreibt ein Log unter /var/log/brickd.log. Allerdings landen da standardmässig nur Errors.

 

Das Log Level kannst du in src/brickd/config.py einstellen.

 

LOGGING_LEVEL = logging.DEBUG

 

aktiviert alle Log Ausgaben. Wenn du brickd per Debian Package installiert hast findet sich die Datei unter

 

/usr/share/brickd/config.py

[Nic]

@photron

Vermute ich richtig, die Angaben gelten auch für die Windows-Version ?

 

Ich schlage vor, diese u.U. wichtigen Internas in die Doku von BrickD mit aufzunehmen. In ein paar Wo. ist dieses Topic von der Forumsbildfläche verschwunden, und das Wissen übers Logging und wie man dieses justiert unbekannt.

 

Das gleiche gilt u.a für die Versionierung zum BrickV aus der Registry.

[ArcaneDraconum]

@Nic:

Der aktuelle BrickViewer zeigt ja seine Version an. Da gibt es keine Raterei mehr und keine Sucherei in der Registry.

Das ist das schöne hier: Einfache Vorschläge werden rasch umgesetzt. daher denke ich werden wir auch bald die Doku zum BrickDaemon bekommen.

[Nic]

Ahh, danke Arcane, dass hatte ich noch gar nicht bemerkt. Sehr praktisch.

[photron]

@photron

Vermute ich richtig, die Angaben gelten auch für die Windows-Version ?

 

Ich schlage vor, diese u.U. wichtigen Internas in die Doku von BrickD mit aufzunehmen.

 

Im Prinzip gibts config.py auch auf Windows, allerdings ist es nicht als editierbare Datei verfügbar, wenn du Brick[dv] per Installer installierst. Bessere Konfigurierbarkeit des Loggings und einfaches Ablesen der Versionsnummer sowie Dokumentation des ganzen steht auf der Todoliste

[photron]

Loetkolben, mir ist bei deiner Munin Speicher Grafik nicht ganz klar was die grüne Linie darstellt und welche Achsenskalierung dazugehört. Denn das Anschließen eines Bricks wird keine 15MB Speicher extra brauchen.

 

Ja, brickd 1.0.7 belegt im Moment bei jedem Anschließen eines Bricks so ca. 100kB mehr Speicher. Da ist also ein Memoryleak. Ich bin dem ganzen aber auf der Spur.

 

Was deinen Eindruck mit mehr "unused" Speicher nach der Installation von brickd 1.0.7 angeht, so sieht das für mich einfach nach Flushen des Filesystem Caches in deiner Grafik aus.

[Loetkolben]

Hallo photon,

 

danke fuer die Unterstuetzung. Die gruene Linie muesste der "commited" memory sein (Vergleiche Farben), wobei ich nicht verstanden habe was dieser Wert bedeutet. Die Scalierung muesste ebenfalls links sein, also MB.

 

ICH denke/dachte: Es ist der Speicher der angefordert wird?? Was das bedeutet und warum die Swapspeicherauslastung nicht ansteigt weiss ich nicht.

 

Die Maschine hat 96MB Ram (80 System + 16 Shared Graphics) + 32 MB Swap auf SD Card.

 

Wie kommst du auf die Aussage, dass das anschliessen eines Bricks 15MB kostet?

Meinst du den Uebergang von Punkt 6 auf Punkt 7?

 

Seit einer Woche ist ruhe. Kein Reboot, kein Absturz. Siehe Grafik.

Da es keine Fehler gibt, obwohl die Grafik "unschoen" aussieht, habe ich das Thema erstmal nicht weiter verfolgt.

 

Was soll ich denn machen? Brickd mal stoppen oder hast du andere Vorschlaege?

 

Viele Gruesse

 

Der Loetkolben

[photron]

Die gruene Linie muesste der "commited" memory sein (Vergleiche Farben), wobei ich nicht verstanden habe was dieser Wert bedeutet. Die Scalierung muesste ebenfalls links sein, also MB.

 

ICH denke/dachte: Es ist der Speicher der angefordert wird?? Was das bedeutet und warum die Swapspeicherauslastung nicht ansteigt weiss ich nicht.

 

Committed ist (soweit ich das sehe) der Speicher den die Prozesse wirklich angefordert haben. Aber das ist nicht der Speicher den sie wirklich auch belegen. Daher kann das auch mehr sein als RAM und Swap zusammen gerade belegt sind.

 

Committed ist also nicht der richtige Wert zur Beurteilung des Speicherverbrauchs von brickd. Dazu solltest du dir das Resident Set (RSS) von brickd ansehen. Das Resident Set ist der Teil des Virtuellen Speichers eines Prozesses der wirklich im physikalischen RAM liegt. Zusätzlich solltest du auch noch den Swap Wert des brickd Prozesses ansehen. Beides ist unter /proc/<brickd PID>/status als VmRSS und VmSwap zu finden.

 

Bei mir liegt VmRSS + VmSwap bei ca. 15MB und steigt bei jedem Brick Reset oder neu verbundenen Brick um ein paar kB.

 

Wie kommst du auf die Aussage, dass das anschliessen eines Bricks 15MB kostet?

Meinst du den Uebergang von Punkt 6 auf Punkt 7?

 

Ja den Übergang meine ich. Und ich habe gesagt, dass mir die grüne Linie komisch vorkommt, "denn das Anschließen eines Bricks wird keine 15MB Speicher extra brauchen."

 

15MB kamen mir zuviel vor, aber ich habe die Achse falsch gelesen und der Sprung zwischen 6 und 7 ist nur 7MB hoch. Aber dennoch ist mir das komisch, denn ich kann das hier nicht reproduzieren.

 

Seit einer Woche ist ruhe. Kein Reboot, kein Absturz. Siehe Grafik.

Da es keine Fehler gibt, obwohl die Grafik "unschoen" aussieht, habe ich das Thema erstmal nicht weiter verfolgt.

 

Was soll ich denn machen? Brickd mal stoppen oder hast du andere Vorschlaege?

 

Solange es läuft ist doch gut, lass es laufen

 

Es gibt noch ein potentielles Problem in den Bindings, dass wenn Packets nicht in einem Stück ankommen sie nicht richtig behandelt werden, was aber im allgemeinen nicht passiert. Diese habe ich in brickd Version 1.0.7 behoben und werde es in den nächsten Tagen auch in allen Bindings beheben.

[photron]

Es gibt noch ein potentielles Problem in den Bindings, dass wenn Packets nicht in einem Stück ankommen sie nicht richtig behandelt werden, was aber im allgemeinen nicht passiert. Diese habe ich in brickd Version 1.0.7 behoben und werde es in den nächsten Tagen auch in allen Bindings beheben.

 

Die Behandlung fragmentierter Packets ist in den aktuellen Versionen aller Bindings (C/C++ 1.0.11, C# 1.1.4, Java 1.0.10, PHP 1.0.5, Python 1.0.13, Ruby 1.0.2) korrigiert.

[Loetkolben]

Mache ich einen neuen Thread auf oder geht es hier weiter? 

 

Nachdem nun 2 Wochen ruhe war ist es wieder soweit. 

Man kann vom brickd keine Daten mehr bekommen.

 

Vor 3 Tagen brickd neu gestartet. OK

Vor 2 Tagen musste brickd neu gestartet werden und Reset am Masterbrick. OK.

Heute 15:00h brickd neu starten. Reicht aus. OK.

Heute 18:00h brickd neu starten reicht nicht. (Resetdruecker im Moment nicht verfuegbar.

 

Daraufhin habe ich den Loglevel mal auf "Debug" gestellt.

18:01:01 <INFO> <brickd_linux.py:76> brickd started

18:01:01 <INFO> <usb_device.py:113> Adding read transfer

18:01:02 <INFO> <usb_device.py:113> Adding read transfer

18:01:02 <INFO> <usb_device.py:113> Adding read transfer

18:01:02 <INFO> <usb_device.py:113> Adding read transfer

18:01:02 <INFO> <usb_device.py:113> Adding read transfer

18:01:02 <INFO> <usb_device.py:121> Adding write transfer

18:01:02 <INFO> <usb_device.py:121> Adding write transfer

18:01:02 <INFO> <usb_device.py:121> Adding write transfer

18:01:02 <INFO> <usb_device.py:121> Adding write transfer

18:01:02 <INFO> <usb_device.py:121> Adding write transfer

18:01:02 <INFO> <usb_device.py:331> Calling get_devices on: <usb_device.USBDevice instance at 0x867bb8c>

18:01:02 <INFO> <usb_device.py:311> Write to device: 254

18:01:02 <INFO> <usb_device.py:184> Write callback length: 4

18:01:16 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x8681aec>

18:01:18 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x8681aec>

18:01:25 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x8681d4c>

18:01:27 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x8681d4c>

18:01:56 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x8681acc>

18:01:58 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x8681acc>

18:29:00 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x8681aec>

18:29:02 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x8681aec>

 

Die Temperaturabfragen bleiben unbeantwortet.

 

Frage:

Was soll mir das Logfile sagen?

Was muesste drinstehen?

Kommuniziert der Brickd noch mit dem Masterbrick?

Kann ich den Masterbrick remote resetten? ...

Die Speicherauslastung sieht immer noch aehnlich aus.

Wo ist das Problem?

 

Vielleicht kommen wir ein wenig weiter.

 

Viele Gruesse

 

Der Loetkolben

[photron]

18:01:02 <INFO> <usb_device.py:311> Write to device: 254
18:01:02 <INFO> <usb_device.py:184> Write callback length: 4

 

Bis zu dieser Zeile ist das Log exakt wie erwartet unter der Annahme, dass du brickd gestartet hast und der Brick schon angesteckt war. Hier nach sollte die Antwort auf das Enumerate kommen. Denn "Write to device: 254" will dir sagen, dass ein Enumerate Packet (Function ID 254) über USB rausgeschickt wurde. Darauf sollte folgendes für die eintreffenden Antworten im Log stehen (für einen Master mit Temperature Bricklet):

 

19:53:01 <INFO> <usb_device.py:378> New device Master Brick 1.0 with Stack ID 1 
19:53:01 <INFO> <usb_device.py:298> Read callback: 0 253
19:53:01 <INFO> <usb_device.py:378> New device Temperature Bricklet 1.0 with Stack ID 2 
19:53:01 <INFO> <usb_device.py:298> Read callback: 0 253

 

Das ist intern von brickd und passiert für jeden Brick den du ansteckst.

 

Allgemein steht für jedes Packet das über USB rausgeht ein "Write to device" im Log und für jedes über USB eingehende Packet ein "Read callback".

 

Dein Log sagt also, dass in diesem Fall der Master nicht geantwortet hat. Das heißt auch, dass du den Master nicht remote Resetten kannst denn er reagiert ja schon auf ein Enumerate nicht mehr.

 

Was hier genau das Problem ist ist mir leider nicht klar. Wie liest du die Temperatur denn aus, machst du für jede Anfrage eine neue IPConnection auf etc? Ich denke wir werden nicht drum herum kommen, das hier mal versuchen nachzustellen um das Problem zu reproduzieren.

[Loetkolben]

Hallo photron,

 

danke fuer die Unterstuetzung.

 

Was hier genau das Problem ist ist mir leider nicht klar. Wie liest du die Temperatur denn aus, machst du für jede Anfrage eine neue IPConnection auf etc? Ich denke wir werden nicht drum herum kommen, das hier mal versuchen nachzustellen um das Problem zu reproduzieren.

 

Ich lese die mit netcat aus.  Ungefaehr so:

echo -n -e "\x$STACKID\x01\x04\00" | nc -w1 $HOST 4223

Deshalb kommt wahrscheinlich immer eine neue IP Connection zu stande.

Diese Abfrage erfolgt im Normalfall 1 mal pro Stunde. (Im obingen Logfile waren es Testaufrufe)

 

Nach dem Umstecken sieht der USB Port seit 2 Wochen so aus:

USB1.1_Port -- USB2.0_Hub +-- Masterbrick_mit_0,3m_Kabel 
                          +--Webcam_mit_1m_Kabel

 

Die Webcam laeuft problemlos weiter. Der Rambedarf hat sich vor den Abstuerzen nicht veraendert, so dann man annehmen kann, dass es kritische Stelle ueberschritten wurden.

Aber mal weitergedacht: Da sich die Abstuerze/Disconnects immer schneller ereignen scheint evtl eine andere Resource zur Neige zu gehen. Welche koennte das sein?

 

Ich will beim besten Willen weder dem brickd noch dem Masterbrick die Schuld an den Problemen geben, aber egal wo das Problem ist, wenn es Auftritt kann man sie nicht mehr absprechen.

 

Ich bin mir auch bewusst, dass der Rechner schmal bemessen ist, aber nach meiner Einschaetzung ist er ausreichend dimensioniert um diese beiden Aufgaben zu erledigen. Die durchschnittliche CPU nutzung der 200Mhz CPU liegt bei 15%.

 

Wie kann ich helfen um das Problem zu finden?

 

Edit: Nachtrag.

Der Masterbrick muss aber noch ansprechbar sein! Masterbrick wird noch gelistet. Zur Zeit ist der brickd "stoped".

lsusb
Bus 001 Device 017: ID 16d0:063d GrauTec (2. USB Port)
Bus 001 Device 016: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader (2. USB Port)
Bus 001 Device 014: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 (2. USB Port)
Bus 001 Device 005: ID 058f:6254 Alcor Micro Corp. USB Hub (2. USB Port)
Bus 001 Device 003: ID 14cd:125a Super Top (1. USB Port)
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub (System)

 

Ich gehe davon aus, dass wenn ich den Masterbrick vom USB abziehe, dass lsusb ihn auch nicht mehr anzeigt. Dementsprechend muss noch eine Kommunikation moeglich sein.

 

Der Loetkolben.

[Loetkolben]

Noch ein Nachtrag: Da hat jemand den Resetknopf am Masterbrick gedrueckt waehrend der brickd gestartet war und das kommt dabei raus:

 

20:53:17 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect
20:53:17 <INFO> <brickd_linux.py:95> Removed USB device
20:53:17 <INFO> <brickd_linux.py:95> Removed USB device
20:53:22 <INFO> <brickd_linux.py:92> New USB device
20:53:22 <INFO> <usb_device.py:113> Adding read transfer
20:53:22 <INFO> <usb_device.py:113> Adding read transfer
20:53:22 <INFO> <usb_device.py:113> Adding read transfer
20:53:22 <INFO> <usb_device.py:113> Adding read transfer
20:53:22 <INFO> <usb_device.py:113> Adding read transfer
20:53:22 <INFO> <usb_device.py:121> Adding write transfer
20:53:22 <INFO> <usb_device.py:121> Adding write transfer
20:53:22 <INFO> <usb_device.py:121> Adding write transfer
20:53:22 <INFO> <usb_device.py:121> Adding write transfer
20:53:22 <INFO> <usb_device.py:121> Adding write transfer
20:53:22 <INFO> <usb_device.py:331> Calling get_devices on: <usb_device.USBDevice instance at 0x998ddac>
20:53:22 <INFO> <usb_device.py:311> Write to device: 254
20:53:22 <INFO> <brickd_linux.py:92> New USB device
20:53:22 <INFO> <usb_device.py:184> Write callback length: 4
20:53:22 <INFO> <usb_device.py:349> New device Master Brick 1.0 with Stack ID 1 
20:53:22 <INFO> <usb_device.py:275> Read callback: 253
20:53:22 <INFO> <usb_device.py:349> New device Temperature Bricklet 1.0 with Stack ID 2 
20:53:22 <INFO> <usb_device.py:275> Read callback: 253
20:53:22 <INFO> <usb_device.py:349> New device IO-4 Bricklet 1.0 with Stack ID 3 
20:53:22 <INFO> <usb_device.py:275> Read callback: 253
20:53:52 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x999482c>
...

 

Der Loetkolben