photron

The events of stopping brickd and unplugging a stack from USB is delivered with different callbacks. If you stop brickd, it'll close all open client connections. Your program and brickv will receive a disconnected callback for this event. If you unplug a stack from USB then brickd will send you an enumerate callback with type disconnected for this event. In brickv this event is used to remove the affected Bricks and Bricklets from the devices list. If this is not working in brickv then there might be a problem with USB hot(un)plug detection on your Linux system. You can take a look at the brickd log at /var/log/brickd.log, as brickd logs USB device arrival/removal.

Brick Daemon maintains a context per client connection for routing responses. But it doesn't try to be clever about callbacks, because if brickd is wrong about its guesses about callback handling then your application can miss a callback because brickd made the wrong decision. For example, how should brickd decide which enumeration callbacks to send to a particular client connection? Should it keep track about when the last enumerate request was received from a client and pass all incoming enumerate-available callbacks to that client for until x milliseconds after the last enumerate request? But then what's the correct value for x? If it's too short you might miss enumerate-available callbacks you should have received. If it's too large you could get callbacks you want to have filtered out. Also, if the time windows for two client connections for the enumerate-available callback passing overlaps then you still get callbacks twice. It's much easier to deal with this in the client application itself. If you see an enumerate callback that tells you that a Brick(let) is connected/available/disconnected and your client application already knows that the Brick(let) is in that state then you can just ignore this event. Yes, this means your client application needs some state tracking for this. But it is much better suited in your client application than in brickd. Because in your app you can do it in a way that fits your needs. In brickd there would have to be one model that has to fit all needs. Also brickd is designed to keep as minimal state information as possible. The less state brickd has to track the less state can be wrong or out-of-sync. This is something we learned from protocol version 1, were brickd had to track more state information. This approach allows you to restart brickd at any time because with the current protocol version 2, there is no essential state information anymore. The minimal state that brickd tracks is optional and just used to optimize the response routing.

You want to provide 5V to the stack via the black connector on the Servo Brick? That's not possible. This black connector on the Servo Brick can only be used to power servo motors connected to the Servo Brick. You can use a Step-Down Power Supply or the USB connector on the master of the stack to provide the 5V stack power.

Ein NULL-terminierter String kann kein '\0' enthalten. Daher ist der erste Custom Character nicht aus ASCII Code 0, sondern 8: lcd_20x4_write_line(&lcd, 0, 0, "\x08");

theo, lass mich da mal einen Blick drauf werfen.

Du kannst beide Bricks jeweils einzeln per USB an den PC anschließen, kein Problem. Dass heißt, du braucht pro Brick einen USB Anschluss. Ein Master Brick ist hier optional und würde dir erlauben die Bricks zu stapeln und alle über eine gemeinsame USB Verbindung zu erreichen.

brickd führt intern eine Liste darüber welche IPConnection noch auf Antworten (Response) von Brick(let)s warten. Dafür merkt er er sich die Anfragen (Request). Die Meldung besagt jetzt, dass eine IPConnection geschlossen wurde, obwohl sie aus der Sicht von brickd noch auf eine Antwort wartet. Das kann passieren wenn z.B. ein Getter-Aufruf einen Timeout erzeugt, also keine Antwort kommt. So direkt sehe ich da keinen Zusammenhang mit deinem Problem. Das sollte normaler weise nicht passieren. Das besagt, das es einen USB Event gegeben hat (z.B. Antwort ist eingegangen) dieser aber in diesem Durchgang nicht behandelt wurde (werden konnte) von brickd. Das sollte nicht kritisch sein. Und auch hier sehe ich gerade keinen direkten Zusammenhang mit deinem eigentlichen Problem.

Nein, das ist hardwaretechnisch nicht möglich.

brick-flash-cmd hat es jetzt auch in die Dokumentation geschafft: http://www.tinkerforge.com/de/doc/Software/Brickv.html#mit-brick-flash-cmd-auf-linux

Die MassageBox erzeugt eine Pause im Programmablauf und führt auch ihren eigenen Message-Loop aus. Hast du mal einen deutlich längeren Sleep als 500ms probiert? Hast du mal vor und nach dem Sleep versucht jeweils einmal Application.DoEvents() aufzurufen?

Google listet für "TL-WN725N raspberry pi" verschiedene Anleitung auf. Zum Beispiel: http://constey.de/2013/12/howto-raspberry-pi-wlan-stick-installieren-tp-link-tl-wn725n/ oder http://laurenthinoul.com/how-to-install-tp-link-tl-wn725n-on-raspberry-pi/ Im Endeffekt muss du die passenden Treiberversion für den Linux Kernel auf deinem Raspberry Pi wählen und laden.

jan, das TOC ist an der Stelle jetzt zuerst nach Sprache und dann nach Brick/Bricklet sortiert, sodass man sich da durch eine Sprache komplett durchklicken kann. Robin, welches Sprache aufgeklappt ist wird jetzt als Fragment im URL gespeichert und geht somit in die History des Browsers ein. Wenn du jetzt also eine Sprache aufklappst darin ein Brick/Bricklet anklickst und dann per Zurück-Button wieder auf die Index-Seite gehst ist die Sprache noch immer aufgeklappt.

Nic, NFC wird da benutzt um die WLAN Verbindung zwischen zwei Teilnehmer zu konfigurieren, damit du nicht manuell IP Adresse oder Hostname und sonstige Verbindungsinformationen eingeben musst, mehr nicht.

Ich habe deine letzten Version von Today.py und main.py getestet und es funktioniert bei mir. Was ist den das Problem das bei dir auftritt? Damit ich nicht 15min bzw. einen Tag jeweils warten muss habe ich einen Schnelltest eingebaut. Wenn du in main.py Zeile 18 FAST_TEST auf True setzt ist er aktiviert und climate_data.csv wird alle 10sec und climate_summary.csv jedem Minute aktualisiert. main.py Today.py

Hm, die Pfadangabe in der readme.txt ist veraltet. build_all_ui.py lag mal dort, wurde dann aber wegen Änderungen an der Module-Struktur nach src/ verschoben, ohne dabei die Dokumentation anzupassen. Die Dokumentation passt jetzt wieder, danke für den Hinweis.

Die ui_*.py Dateien werden durch das build_all_ui.py Script in /usr/share/brickv-git generiert. Sorry, hatte sich vergessen zu erwähnen. Für weitere Details die ich potentiell vergessen habe sei auf die readme.txt verweisen In der Config Datei siehst du die Entwicklung der Konfiguration. Erst gab es nur host und port, dann kam hosthistory<X> hinzu und die letzte Erweiterung ist hostinfo<X>. Die aktuelle Version schreibt alle diese Felder, um abwärtskompatibel zu sein und liest auch die alten Felder, wenn die neueren nicht da sind, um bei einem Versions-Update die Config Information nicht zu verlieren.

Wie sieht den der Backtrace zu dem Timeout aus? Was ist die exakte Fehlermeldung? Es ist aber nicht sowas einfaches wie falsche IP Adresse, Hostname oder Port in HWD_Main?

Sieht so aus als ob du Today.py jetzt passend abgewandelt hast. Allerdings ist da ein Fehler drin, denke ich: maxhumidity=(self._humidity) in Zeile 21 sollte maxhumidity=max(self._humidity) sein; da fehlt das max(), das das Maximum der _humidity Liste ermittelt.

Du machst da auch wieder Dinge die so nicht gedacht waren Du stolperst da über das Module/Package System von Python. In /usr/share/brickv/main.py bildet der brickv Teil den Namen des Packages in dem main.py und der restliche Code lebt. Genau dieser Packagename ist hier auch drin: from brickv import config Du hast aber den Code in brickv-git abgelegt, daher kann Python jetzt kein brickv finden, bzw. findet den Code in /usr/share/brickv. Ich habe gerade dafür noch einen Workaround eingebaut, mit dem dein brickv-git Verzeichnis jetzt auch funktionieren sollte. main.py schaut sich jetzt an in welchem Verzeichnis es liegt und versucht dann den Code entsprechend von dort zu importieren.

Ja, so war das gemeint.

Unter Windows nutzen wir py2exe, damit kann man den Python Interpreter, die Python Scripte und die Bibliotheken in eine .exe Datei (plus .pyd Dateien) verpacken. Dann kann man das ganz normal an die Nutzer verteilen ohne das diese Python installiert haben müssten. py2exe ist also ein Art Python "Compiler" wenn du so willst. Wenn du jetzt die .py Dateien aus git unter Windows nutzen willst muss du dir erst Python installieren und die benötigten Bibliotheken (primär PyQt). Übrigens ist das unter Mac OS X ähnlich wie unter Windows, dort nutzen wir py2app, das im Prinzip das gleiche tut wie py2exe unter Windows.

Klar geht das, du brauchst dann in deinem Python Programm einfach zwei IPConnections. Eine für die WIFI Verbindung und eine für die Ethernet Verbindung. Dann erstellt du die Bricklet Objekte mit der jeweils dazugehörigen IPConnection und ab da kannst du ganz normal weiter machen: Die Getter/Callback der Sensor Bricklets nutzen um die Daten zu erhalten und die write_line() Funktion des LCD Bricklets um die Daten dort anzuzeigen.

Wenn der Humidity Wert in climate_data.csv drin steht dann hast du Zeile 96 in main.py passend abgeändert: this_row=(time_info['date'],time_info['time'],time_info['zone'],temperature,air_pressure,light_level) Wenn der neue Werte in climate_summary.csv fehlt dann hast du Today.py noch nicht passend geändert. Hast du in Today.py entsprechend der _temp, _lux und _pressure Listen eine _humidity Liste hinzugefügt und die nötigen Berechnungen, damit in Zeile 21 in summary=(date,maxtemp,mintemp,avgtemp,maxpressure,minpressure,avgpressure,maxlux) auch der Humidity-Wert auftaucht? Am besten du hängst deine abgeänderte Today.py und main.py an, anstatt eines Screenshots. Dann kann man besser beurteilen wo das Problem steckt.

Die brickd Debian Packages sind identisch, sie unterscheiden sich nur in der CPU Architektur. Ich würde das auch eigentlich so beibehalten wollen. Außer es gäbe triftige Gründe dagegen, z.B. wenn pm-utils negative Auswirkungen auf dem Raspberry Pi hätte, was mir aber nicht bekannt ist. Unexpected, das 2.1.0 Debian Package kann nicht ohne pm-utils installiert werden. Ich hoffe das ist kein Hinderungsgrund für dich.

Loetkolben, brickv ist reines Python. Wenn du ein Python und die Abhängigkeite für brickv installiert hast kannst du einfach den brickv direkt aus dem Source Code ausführen. Der Source Code liegt auf GitHub: https://github.com/Tinkerforge/brickv Von dort kannst du ihn mit dem git Tool abholen oder direkt als ZIP herunterladen. Das sollte so interpretiert werden: Es ist eingebaut, wer es jetzt testen will, muss sich den aktuellen Source Code aus dem git besorgen, da ich mir die Arbeit sparen will für diese Testversion einmal alle Installer zu bauen