TF Protocol 2.0 Beta

borg · December 21, 2012 at 19:30

Hallo zusammen,

Pünktlich zu Weihnachten sind wir endlich soweit die erste Beta vom Protocol 2.0 zu veröffentlichen. Die Bindings, Firmwares und Tools zum neuen Protokoll gibt es hier: http://download.tinkerforge.com/protocol_v2_beta/

Dokumentation gibt es hier: http://www.tinkerforge.com/doc_v2/index.html

Wer noch nicht weiß was es mit dem neuen Protokoll auf sich hat, kann hier Informationen finden: http://www.tinkerforge.com/doc/Protocol_20.html

Die komplette API Dokumentation und alle Beispiele sollten kompatibel zum neuen Protokoll sein, alles andere in der Doku ist noch nicht angepasst (Einführungstutorial etc).

Was auch noch dringend fehlt ist ein "Wie porte ich meinen Code vom alten auf das neue Protokoll"-Tutorial. Ich denke, dass ich dies vor Weihnachten noch verfasse.

Also: Wer lust hat das neue Protokoll zu testen um uns beim Fehlerfinden zu helfen ist dazu herzlich eingeladen .

AuronX · December 21, 2012 at 21:51

Oh schade, bin über Weihnachten außer Reichweite meiner Bricks. Hätte aber gerne geholfen ^^

Noch etwas zu C#: Ich habe ja damals empfohlen, dass man den sender als Object in die Calbacks reingibt. Ich habe gerade darüber meditiert warum das sinnvoll ist. Der übliche Use-Case ist ja Wiederverwendbarkeit, ich möchte also, dass verschiedene Klassen das gleich Event anbieten könnten.

Aber im Fall von der TF-API sind ja die Event-Delegates alleine schon an die Klasse gebunden (z.B. BrickServo.PositionReachedEventHandler). Dann kann man eigentlich auch den sender direkt korrekt getypt übergeben, das macht Callbacks noch einfacher (und typsicherer):

static void ReachedCB(BrickServo sender, byte servoNum, short position)
{
    sender.SetPosition(servoNum, -9000);
}

Sorry für den späten Hinweis ^^

Frohes Fest!

edit: Spannende Lektüre

thunderbird · December 21, 2012 at 23:12

Gibt es irgendwo ein Log vom Brickd ?? Ich glaube da ist irgendwas im Busch. Ich habe gerade ein Callback für ein Temp. Bicklet geschrieben. Das läuft zwar auch aber nur mit 100% CPU Auslastung.

borg · December 22, 2012 at 09:42

Unter /var/log/brickd.log sollte es ein log geben.

Edit: Wenn du brickd selber kompilierst kannst du in log.c auch die LOG_LEVEL auf LOG_LEVEL_DEBUG stellen, dann gibt es eine Unmenge an log Ausgaben. Eine Config-Datei zum umstellen der Logging Level gibt es leider noch nicht, kommt aber noch.

thunderbird · December 22, 2012 at 15:51

Super Danke.

Also ich konnte den Fehler wieder beobachten. Das ganze passiert wenn mein Programm läuft und man den Master per Reset neustartet. Dann geht die CPU-Last hoch und das Log wird innerhalb von Sekunden extrem groß(1GB).

Ich benutze die Java Bindings mit Callbacks (Temperatur)

Plattform ist 64 Bit

Könntet ihr bitte noch den Brickd für den Raspberry Pi (arm) als deb Paket bereitstellen? Dann würde ich das dort auch sofort testen ;-)

Hier mal das LOG

2012-12-22 16:33:18.958975 <I> <main_linux.c:275> Brick Daemon 2.0.0 started (daemonized)
2012-12-22 16:33:19.193359 <I> <usb.c:137> Added USB device (bus: 2, device: 6) at index 0: Master Brick [67N4R3]
2012-12-22 16:34:14.630459 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:35:20.991206 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:35:27.535909 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:35:36.839606 <I> <client.c:61> Socket (handle: 18) disconnected by client
2012-12-22 16:35:39.685049 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:35:44.676683 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:35:48.520440 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:36:02.533402 <I> <client.c:61> Socket (handle: 18) disconnected by client
2012-12-22 16:36:03.983742 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:36:09.237350 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:36:14.174956 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:36:18.364469 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:36:59.951934 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:37:02.877460 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:37:10.114530 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:37:15.943577 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:37:49.366481 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:38:25.558476 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:38:27.828234 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:39:14.282072 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:39:20.523027 <W> <transfer.c:60> Read transfer 0x18d9d40 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523162 <W> <transfer.c:60> Read transfer 0x18d9db8 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523524 <W> <transfer.c:60> Read transfer 0x18d9e30 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523737 <W> <transfer.c:60> Read transfer 0x18d9c50 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.524057 <W> <transfer.c:60> Read transfer 0x18d9cc8 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.565888 <I> <usb.c:262> Removing USB device (bus: 2, device: 6) at index 0: Master Brick [67N4R3]
2012-12-22 16:39:20.569079 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569109 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569129 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569139 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569152 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569161 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569172 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569182 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569194 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569203 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569214 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569223 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569234 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569244 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569270 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569279 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569290 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569298 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569308 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)

borg · December 22, 2012 at 20:15

Danke für das log, das sieht sehr hilfreich aus, gucke ich mir heute Nacht an . Reproduzieren kann ich es aber leider auf Anhieb nicht.

Auf dem Raspberry PI kompilieren sollte sehr einfach sein. gcc und libusb installieren und make aufrufen. Außer libusb haben wir keine Abhängigkeiten im neuen brickd!

thunderbird · December 22, 2012 at 23:02

Danke borg. Ich werde das mit dem brickd mal morgen testen.

Mir ist aber noch was aufgefallen.

Wenn ich einen Callback benutze am Temp. Bricklet und den mit temp.setTemperatureCallbackPeriod(1000); einstelle, sollte meiner Meinung nach eine TimeoutException ausgelöst werden wenn kein Brick oder Bricklet an den PC angeschlossen ist.

Spätestens wenn man dann den Listener mit temp.addListener hinzufügt sollte ja was passieren.

Aber da tut sich nichts. Ist das normal ??

borg · December 22, 2012 at 23:47

Setter erwarten Standardmäßig auch in neuen Protokoll keine Antwort, man kann es aber anstellen. Ist allerdings anscheinen noch nicht dokumentiert .

Alle Devices haben die folgenden 3 Funktionen:

public void setResponseExpected(byte functionId, boolean responseExpected);
public boolean getResponseExpected(byte functionId);
public void setResponseExpectedAll(boolean responseExpected)

d.h. du müsstest

temp_bricklet.setResponseExpected(TemperatureBricklet.SET_TEMPERATURE_CALLBACK_PERIOD, true);

aufrufen können und dann auch einen Timeout bekommen!

Edit: Allerdings bringst du mich da auf eine Idee, vielleicht sollten die CallbackPeriod und CallbackThreshold setter als Standardeinstellung alle responseExpected = true haben. Mit dem Hintergedanken: Die beiden Setter werden meist nur einmal beim starten des Programms aufgerufen und sind nicht relevant für die Performance.

Wenn jemand aus irgendwelchen Grüden die Periode oder den Threshold oft ändern muss, kann er es ja wieder zurück setzen. Mhmhmhmh

thunderbird · December 23, 2012 at 10:44

Moin Moin,

ja es wäre eine sehr gute Idee das für set*CallbackPeriod immer aktiv zu haben.

Mir ist da noch was aufgefallen. Es passiert ab und an schonmal das ein Bricklet (aus welchen Gründen auch immer ) nicht mehr antwortet. Da ich nur mit Callbacks arbeite finde ich das erst dann raus wenn irgendwas offensichtlich nicht mehr geht ( Es regnet es wird aber vom IO4 Bricklet kein Callback ausgelöst). Das ist dann immer recht ärgerlich. Deswegen habe ich mir überlegt (wurde auch schonmal hier diskutiert) meinetwegen jede Stunde alle Bricklets an zu "pingen". Soweit kein Problem, die Methode getIdentity() ist da ja gut für geeignet. Hat man aber jetzt eine Liste aus Devices bekommt man das Problem das man erstmal rausfinden muss was das für ein Bricklet/Brick war damit man es Casten kann und die Methode ausführen kann. Wäre es nicht möglich diese Methode (soweit ich das gesehen habe ist sie ja bei jedem Brick/Bricklet verfügbar) in die Device Klasse zu schieben ?

Oder gibt es da eine schönere Lösung zu ??

thunderbird · December 23, 2012 at 13:44

Soo habe jetzt meine beiden Stationen und meine Testumgebung auf 2.0 umgestellt läuft alles soweit gut :-)

Auch auf dem Raspberry läuft alles.

Was nicht geklappt hat ist das Auto Update für das Temp-IR Bricklet da hat er angezeigt neuste Version ist 0.0.0. Von Hand lief das aber problemlos.

borg · December 23, 2012 at 13:49

@getIdentitiy in Device Klasse: Es würde reichen wenn sie dort drin ist und von den Brick/Bricklet Klassen überschrieben wird oder?

Kannst du das 100% CPU Problem nochmal erzeugen während brickd mit "--debug" gestartet ist?

thunderbird · December 23, 2012 at 14:03

@getIdentitiy in Device Klasse: jopp das sollte passen.

Mach ich weiß aber nicht ob ich das heute noch schaffe.

photron · December 23, 2012 at 21:42

Also ich konnte den Fehler wieder beobachten. Das ganze passiert wenn mein Programm läuft und man den Master per Reset neustartet. Dann geht die CPU-Last hoch und das Log wird innerhalb von Sekunden extrem groß(1GB).

Ich benutze die Java Bindings mit Callbacks (Temperatur)

Plattform ist 64 Bit

Hier mal das LOG

2012-12-22 16:33:18.958975 <I> <main_linux.c:275> Brick Daemon 2.0.0 started (daemonized)
2012-12-22 16:33:19.193359 <I> <usb.c:137> Added USB device (bus: 2, device: 6) at index 0: Master Brick [67N4R3]
2012-12-22 16:34:14.630459 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:35:20.991206 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:35:27.535909 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:35:36.839606 <I> <client.c:61> Socket (handle: 18) disconnected by client
2012-12-22 16:35:39.685049 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:35:44.676683 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:35:48.520440 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:36:02.533402 <I> <client.c:61> Socket (handle: 18) disconnected by client
2012-12-22 16:36:03.983742 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:36:09.237350 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:36:14.174956 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:36:18.364469 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:36:59.951934 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:37:02.877460 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:37:10.114530 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:37:15.943577 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:37:49.366481 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:38:25.558476 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:38:27.828234 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:39:14.282072 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:39:20.523027 <W> <transfer.c:60> Read transfer 0x18d9d40 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523162 <W> <transfer.c:60> Read transfer 0x18d9db8 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523524 <W> <transfer.c:60> Read transfer 0x18d9e30 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523737 <W> <transfer.c:60> Read transfer 0x18d9c50 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.524057 <W> <transfer.c:60> Read transfer 0x18d9cc8 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.565888 <I> <usb.c:262> Removing USB device (bus: 2, device: 6) at index 0: Master Brick [67N4R3]
2012-12-22 16:39:20.569079 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569109 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569129 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569139 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569152 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569161 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569172 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569182 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569194 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569203 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569214 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569223 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569234 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569244 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569270 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569279 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569290 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569298 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569308 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)

Das Log reicht mir schon, kein weiteres mit LOG_LEVEL_DEBUG bzw --debug nötig.

Das Problem tritt nur auf, wenn mehreren Clients gleichzeitig eine Verbindung zu brickd haben. Dabei kann es passieren, dass die Clients in einer anderen zeitlichen Reihenfolge die Verbindung trennen verglichen mit der Reihenfolge des Verbindungsaufbaus. Das passiert in deinem Fall. Warum dass gerade mit dem Reset des Master Bricks zusammen fällt ist mir nicht klar.

Dadurch kommt die Datenhaltung in brickd durcheinander. brickd fällt in eine Schleife in der er versucht einen Client aus der Liste der verbundenen Client zu entfernen, scheitert aber durch den Fehler in der Datenhaltung. Diesen Bug habe ich gerade behoben. Auf github findet sich jetzt die korrigierte Version.

Zum Testen hab ich ein Debian AMD64 Package angehängt. Um Windows und Mac OS X Installer neuzubauen habe ich gerade nicht die dafür eingerichteten PCs zur Hand.

brickd-2.0.0_eda6a29a188cd8ce667afa9cdabbdef47f75f27b_amd64.deb

thunderbird · December 23, 2012 at 21:47

Super hab ich gerade geladen und installiert. Werde ich jetzt mal testen.

thunderbird · December 25, 2012 at 10:06

Konnte bis jetzt keine Probleme mehr feststellen. Das Problem mit der CPU Auslastung konnte ich mit dem neuen BrickD nicht mehr produzieren ;-)

Einstein · December 27, 2012 at 13:36

Sooo nune komm ich mit meinen Problemen

Ich habe meine Stacks umgestellt Probehalber.

Aufbau

Master1(mit WIfi) --RS485--> Master2(mit vielen Bricklets) --RS485--> Master3(mit ein paar Bricklets)

Nun mein Problem. Ich mache meine Verbindungen auf den Wifi-Master und bekomme ständig timeouts und abstürze im brickv. Die Bricklets bzw. die anderen Master sind nur zu erreichen wenn ich mich an den Master mit der Wifi direkt stecke.

Ist das vielleicht ein Timeoutproblem über Wifi?

Kleiner edit:

Das kommt im brickd auf einem Rechner.

2012-12-27 15:23:14.905820 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-27 15:23:14.906004 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-27 15:23:14.906142 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-27 15:23:14.906289 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-27 15:23:14.906419 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-27 15:23:14.907012 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)

Tritt dieser Fehler vielleicht auch intern im WiFi auf?

thunderbird · December 27, 2012 at 14:54

@ Einstein Das Problem was du im Brickd siehst, kannst du lösen in dem du dir das Paket auf der ersten Seite von photron suchst oder den Brickd aus git selber baust. In dem fertigen Paket ist noch ein Fehler. Mit der WiFi Extension kann ich leider nicht helfen.

Gruß Sven

Einstein · December 27, 2012 at 15:18

Hallo thunderbird,

soweit hab ich mich dann durchgesucht und festgestellt wenn ich mich an der letzten rs485 per usb anstecke nur diese sehe.

Edit: Ausgabe des Brickv.

Traceback (most recent call last):
  File "/usr/share/brickv/mainwindow.py", line 362, in cb_enumerate
    uid, firmware_version)
  File "/usr/share/brickv/plugin_system/plugin_manager.py", line 56, in get_plugin
    return plugin(ipcon, uid, version)
  File "/usr/share/brickv/plugin_system/plugins/temperature/temperature.py", line 51, in __init__
    self.cb_temperature(self.tem.get_temperature())
  File "/usr/share/brickv/bindings/bricklet_temperature.py", line 78, in get_temperature
    return self.ipcon.send_request(self, BrickletTemperature.FUNCTION_GET_TEMPERATURE, (), '', 'h')
  File "/usr/share/brickv/bindings/ip_connection.py", line 634, in send_request
    raise Error(Error.TIMEOUT, msg)
bindings.ip_connection.Error: -1: Did not receive response for function 1 in time
Traceback (most recent call last):
  File "/usr/share/brickv/mainwindow.py", line 362, in cb_enumerate
    uid, firmware_version)
  File "/usr/share/brickv/plugin_system/plugin_manager.py", line 56, in get_plugin
    return plugin(ipcon, uid, version)
  File "/usr/share/brickv/plugin_system/plugins/temperature/temperature.py", line 51, in __init__
    self.cb_temperature(self.tem.get_temperature())
  File "/usr/share/brickv/bindings/bricklet_temperature.py", line 78, in get_temperature
    return self.ipcon.send_request(self, BrickletTemperature.FUNCTION_GET_TEMPERATURE, (), '', 'h')
  File "/usr/share/brickv/bindings/ip_connection.py", line 634, in send_request
    raise Error(Error.TIMEOUT, msg)
bindings.ip_connection.Error: -1: Did not receive response for function 1 in time
Traceback (most recent call last):
  File "/usr/share/brickv/mainwindow.py", line 240, in connect_pressed
    self.reset_view()
  File "/usr/share/brickv/mainwindow.py", line 193, in reset_view
    infos.infos[key].plugin.stop()
AttributeError: 'NoneType' object has no attribute 'stop'
Traceback (most recent call last):
  File "/usr/share/brickv/mainwindow.py", line 240, in connect_pressed
    self.reset_view()
  File "/usr/share/brickv/mainwindow.py", line 193, in reset_view
    infos.infos[key].plugin.stop()
AttributeError: 'NoneType' object has no attribute 'stop'
Traceback (most recent call last):
  File "/usr/share/brickv/mainwindow.py", line 240, in connect_pressed
    self.reset_view()
  File "/usr/share/brickv/mainwindow.py", line 193, in reset_view
    infos.infos[key].plugin.stop()
AttributeError: 'NoneType' object has no attribute 'stop'
Traceback (most recent call last):
  File "/usr/share/brickv/mainwindow.py", line 240, in connect_pressed
    self.reset_view()
  File "/usr/share/brickv/mainwindow.py", line 193, in reset_view
    infos.infos[key].plugin.stop()
AttributeError: 'NoneType' object has no attribute 'stop'
Traceback (most recent call last):
  File "/usr/share/brickv/mainwindow.py", line 240, in connect_pressed
    self.reset_view()
  File "/usr/share/brickv/mainwindow.py", line 193, in reset_view
    infos.infos[key].plugin.stop()
AttributeError: 'NoneType' object has no attribute 'stop'
Traceback (most recent call last):
  File "/usr/share/brickv/mainwindow.py", line 240, in connect_pressed
    self.reset_view()
  File "/usr/share/brickv/mainwindow.py", line 193, in reset_view
    infos.infos[key].plugin.stop()
AttributeError: 'NoneType' object has no attribute 'stop'
Traceback (most recent call last):
  File "/usr/share/brickv/mainwindow.py", line 240, in connect_pressed
    self.reset_view()
  File "/usr/share/brickv/mainwindow.py", line 193, in reset_view
    infos.infos[key].plugin.stop()
AttributeError: 'NoneType' object has no attribute 'stop'
Traceback (most recent call last):
  File "/usr/share/brickv/mainwindow.py", line 136, in closeEvent
    self.exit_brickv()
  File "/usr/share/brickv/mainwindow.py", line 152, in exit_brickv
    self.reset_view()
  File "/usr/share/brickv/mainwindow.py", line 193, in reset_view
    infos.infos[key].plugin.stop()
AttributeError: 'NoneType' object has no attribute 'stop'

Oder ein Problem mit dem Temperatur bricklet.

Noch nen edit2: Ich hab erstmal alles etwas umgebaut. die letzte rs485 ist nun master damit erstmal wieder die wetterstation geht.

Nun hab ich festgestellt wenn mehr als 1 rs485 client and der wifi extension per rs485 angebunden ist steigt im brickv der timeoutcounter an und es gibt im brickv die probleme (s.o.).

borg · December 27, 2012 at 23:30

So, beta2 vom brickd ist jetzt für alle Betriebssysteme online.

@Einstein: Kannst du mal genau Aufschreiben was du für Stacks verwendest? Also welche Bricks, Welche Bricklets usw.

Ich bin mir sicher dieses Szenario getestet zu haben (WIFI + mehrere RS485 Extensions). Ich würde dann morgen einmal genau deinen Aufbau versuchen zu reproduzieren.

Edit: Der Traceback hat aber schon einen Bug zum Vorschein gebracht . Im neuen brickv sollten eigentlich alle Aufrufe asynchron sein. Die Idee ist, dass brickv immer ansprechbar bleibt, auch wenn ein Stack eine Zeitlang nicht erreichbar ist (z.B. da die WIFI Extension außer Reichweite ist).

Daher ist das hier ein Bug:

 File "/usr/share/brickv/plugin_system/plugins/temperature/temperature.py", line 51, in __init__
   self.cb_temperature(self.tem.get_temperature())

Aber dadurch sollte natürlich trotzdem kein Timeout entstehen.

Nic · December 28, 2012 at 09:34

Hier ist ein weiterer Beta-Tester ...

Was auch noch dringend fehlt ist ein "Wie porte ich meinen Code vom alten auf das neue Protokoll"-Tutorial. Ich denke, dass ich dies vor Weihnachten noch verfasse.

Müssen bei der Migration auf das neue Protokoll im eigenen Code Anpassungen vorgenommen werden ?

Wo liegt unter Win das Log-File des BrickD-Treibers ? Lässt sich der Log-Level einstellen ? Bzw. ist das nötig ?

photron · December 28, 2012 at 09:58

Hier ist ein weiterer Beta-Tester ...

Was auch noch dringend fehlt ist ein "Wie porte ich meinen Code vom alten auf das neue Protokoll"-Tutorial. Ich denke, dass ich dies vor Weihnachten noch verfasse.
Müssen bei der Migration auf das neue Protokoll im eigenen Code Anpassungen vorgenommen werden ?

Ja. Das betrifft hauptsächlich die IPConnection und die Signatur von Callbacks. Vergleiche v1 mit v2 des Temperature Bricklet Callback Beispiels.

Wo liegt unter Win das Log-File des BrickD-Treibers ? Lässt sich der Log-Level einstellen ? Bzw. ist das nötig ?

Standardmässig schreibt brickd unter Windows kein Logfile, sondern wird Errors und Warnings ins Event Log schreiben. "wird" weil die aktuelle Beta das noch nicht tut. Wird brickd allerdings mit --debug Option gestartet dann schreibt er ein Logfile mit vollem Debug Level in eine brickd.log Datei ins gleiche Verzeichnis in der auch brickd.exe liegt.

Um brickd mit --debug Option zu starten muss er über die Computerverwaltung beendet, als Startparameter --debug angegeben und wieder gestartete werden.

Es wird dann auch noch die Möglichkeit geben, das Logging genauer über eine Konfigurationsdatei einzustellen. Im Moment kann das nur über die --debug Option gesteuert werden.

Nic · December 28, 2012 at 10:10

Ok, also "nur"

* AddDevice entfällt, dafür erhält die Create-Methode des Brick/Bricklet ein weiteres Argument für die Referenz auf die IPConnection

* Callbacks haben zusätzlich die Referenz zum Sender

Logfile: Gibt es für den Brick-Viewer auch eine erweiterte Debug/Log-Option ?

Einstein · December 28, 2012 at 13:05

@Einstein: Kannst du mal genau Aufschreiben was du für Stacks verwendest? Also welche Bricks, Welche Bricklets usw.

Hallo borg,

also folgender aufbau (immer von unten nach oben).

Master1: Step-Down -> Master (Port A ein Temperatur Bricklet, Port B ein Temp-IR) -> RS485 -> Wifi
Master2: Step-Down -> Master -> RS485 (Port A Ambilight, Port B Temperatur Bricklet, Port C Humidity, Port D Barometer)
Master3: Step-Down -> Master -> RS485 (aktuell nichts angesteckt).

Verbindung alle untereinander über RS485. Master1->Master2->Master3.

Aktuell (damit es funktioniert ist der Master3 der RS485 master und hängt per USB am Rechner. sollte aber eigentlich alles über die WiFi gehen.

Einstein · December 28, 2012 at 22:27

Kleiner zusatz noch. Wenn es doch einmal funktioniert und die ganzen Timeouts nicht stören (bzw. gegen 0 gehen) kommt dieses verhalten heraus.

Ich meine speziell das konstant bleiben der Temperatur.

thunderbird · December 29, 2012 at 16:58

Hmmm ich habe da auch noch was gefunden.

Bis jetzt hatte ich immer RS485 Extensions die schon eine Config hatten. Jetzt habe ich eine ganz neue. Da bekomme ich beim Speichern der Config einen Fehler.

Es schein was mit der "Rolle" Master zu tuen zu haben. Meine Slave Einstellungen kann ich problemlos speichern.

Anmelden

TF Protocol 2.0 Beta

Recommended Posts

borg

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Posted Images

AuronX

thunderbird

borg

thunderbird

borg

thunderbird

borg

thunderbird

thunderbird

borg

thunderbird

photron

thunderbird

thunderbird

Einstein

thunderbird

Einstein

borg

Nic

photron

Nic

Einstein

Einstein

thunderbird

Join the conversation

Umsehen

Aktivitäten