Jump to content

ulugutz

Members
  • Gesamte Inhalte

    7
  • Benutzer seit

  • Letzter Besuch

ulugutz's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. Ich bin gerade dabei die Socken für Weihnachten befüllen und frage mich ob es dieses Jahr wieder eine Rabattaktion bei Tinkerforge geben soll? Gruß Ulugutz
  2. Hallo, ich habe mal eine Frage zur Betriebstemperatur der Bricks und Bricklets. Ich habe hier im Forum mal danach gesucht und bisher kam nur die Aussage +40 °C sind OK. Was mich nun mal interessiert, wie sieht das generell aus? Vor allem bei den Masterbricks und seinen Extensions zusammen mit dem Temperatur, Feuchtigkeits und Barometer Bricklets. Normalerweise heißt es bei Endverbrauchern ja immer 0-70 °C. Funktionieren die Tinkerforge Bauteile aber auch im erweiterten Temperaturbereich von -45 - +85 °C? Habt ihr hierzu schon Testdaten?
  3. Vielen Dank. Es geht nun. Und eine kleine ping() Routine wäre echt nicht schlecht. Möglicherweise sogar im Hintergrund oder so
  4. Solange ich nur nur Callbacks am Laufen habe, bekomme ich das leider nicht mit und kann sie auch so nicht neu registrieren. Rufe ich allerdings einen Getter auf, dann springt er mir mit einem connection error (Error.TIMEOUT) in den Tod. Auch wenn der Brick schon längst wieder da ist. Ich muss erst (mit hellseherischen Fähigkeiten) die IPcon neu aufbauen. Gibt es da einen Weg drum herum? Der Brickv scheint das irgendwie mitzubekommen. Zumindest meldet der einen Fehler und verbindet dann neu. Ich habe bisher den Source nur grob gesichtet und dabei keinen so großen Unterschied zum Rugged Example gefunden.
  5. Ich habe vorhin versucht meine Python scripte auf das neue TF2.0 Protokoll umzustellen und dabei statt getter callbacks zu verwenden. Ich habe mich hierbei am Beispiel "Robuster Ansatz" orientiert: http://www.tinkerforge.com/doc/Tutorials/Tutorial_Rugged/Tutorial.html Nun ist mein Problem folgendes: Ich bekomme nicht mitgeteilt, wenn der Brick (über WIFI angeschlossen) getrennt wird. Ich verwende hierbei zum Testen den "reset" Button. Ebenso gibt sie Methode get_connection_state immer noch CONNECTION_STATE_CONNECTED zurück, selbst wenn der Brick seit einer Minute vom Strom getrennt ist. Hat jemand einen Vorschlag was ich hier falsch mache? Oder geht das gar nicht mit dem WLAN? Edit: Noch eine Frage zu den Callbacks: Ist es möglich mehr als einen Callback für einen Sensorwert zu haben? Sobald ich z.B. den Brickv auf habe und einen Callback auf einen (anderen) Rechner setze, wird die "callback period" auf diesen Wert gesetzt. Ebenso wird der Callback gelöscht, wenn ich das Programm beende. Dies bedeutet, dass ich effektiv nur einen Callback gleichzeitig laufen lassen kann
  6. Ich kann bestätigen, dass der Bug mit Version 1.4.4 gefixed wurde. Bitte Topic schließen.
  7. Hi, ich habe gerade 3 Master Bricks mit der neusten Firmware (1.4.1) geflashed. Nach dem Flashen hängen sich alle 3 Master beim Booten auf. Ich habe alle Bricklets entfernt, bis auf die Chibi Extension. Keine Änderung. Erst wenn ich die Chibi Extension entferne startet der Brick neu. Die blauen LEDs leuchten sowohl am Master, wie auch der Extension. Die Bricks, bei denen Chibi als Slave eingerichtet war, booten zwar, werden aber nicht von funktionsfähigen Mastern erkannt (FW 1.2.4). Sobald man Einstellungen, wie z.B. die Chibi ID ändert, bleibt der Brick auch beim Booten hängen. Ich habe nun alle Firmwares getestet und das Problem taucht ab FW 1.3.0 auf.
×
×
  • Neu erstellen...