Jump to content

TF Protocol 2.0 Beta


borg
 Share

Recommended Posts

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 ;D.

Link to comment
Share on other sites

  • Replies 71
  • Created
  • Last Reply

Top Posters In This Topic

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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 ??

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 ??

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.).

Link to comment
Share on other sites

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  ;D. 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.

Link to comment
Share on other sites

Hier ist ein weiterer Beta-Tester :D...

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 ?

Link to comment
Share on other sites

Hier ist ein weiterer Beta-Tester :D...

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.

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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.

1891226339_Bildschirmfoto_vom_2012-12-29_175504.thumb.png.beaf57e0d506d215cef82addf4f967eb.png

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


×
×
  • Create New...