photron

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

Okay, Ich hab jetzt eingebaut, dass "Port", "Use Authentication", "Secret" und "Remember Secret" per Host verwaltet und gespeichert werden. Ist im git. Zum Testen also einmal brickv aus den git Sourcen besorgen.

Die Host-Liste ist jetzt 10 lang, das ist einfach zu ändern. Alles andere mitblättern zu lassen heißt auch dies jeweils 10 mal zu speichern. Dafür ist noch keine Logik da, dass muss erst gebaut werden, mal sehen wie aufwändig das ist.

Wenn du das .dmg öffnest dann wird das unter /Volumes/Brickv-2.1.0 eingebunden. Wenn du brickv von dort startest (was normalerweise funktioniert) und er dann crasht, dann kommt dieser Pfad zustande. Was mich aber verwundert, ist, dass brickv 2.1.0 nicht funktioniert, aber brickv 2.0.9. Beide sind hier auf dem gleichen MacBook mit dem gleichen Mac OS X 10.8 gebaut. Ich denke da müssen wir mal unser MacBook hier auf 10.9 updaten un sehen was passiert.

brick-flash-cmd ist flash-brick-cli.py und samba.py in einem. Das Package Build Script baut brick-flash-cmd passend zusammen. Dann kann brick-flash-cmd einfach unter /usr/bin liegen ohne dass samba.py irgendwo passen liegen müsste damit Python es finden kann.

Wenn das mitblättert was ist dann mit den 3 Checkboxen für Authentication? Blättern die auch mit, oder sind die dann wieder global? Und ganz so einfach ist das dann auch nicht, das erfordert, das GUI zu ändern, die interne Speicherlogik zu ändern, was ist mit Abwärtskompatibilität und Update von einer Version die das alte Speicherformat nutzt auf eine die das neue nutzt? Das muss alles bedacht werden. Außerdem denke ich das es von der Benutzung her komisch ist, wenn das Scret mitblättert. Dann müsste man doch eher ein ordentliche Host Add/Edit/Remove haben, das dann aber doch etwas übertrieben ist für den Zweck des Brick Viewers.

Im git ist die Host-Liste jetzt 10 Einträge lang. Host und Port in einen Eintrag kann man damit argumentieren, dass der Port eine Host-spezifische Einstellung ist. Aber was macht man dann mit dem Secret und dessen Einstellungen?

Loetkolben, weil bald Ostern ist, hier ein Debian Package für dich zum Testen brick-flash-cmd -p /dev/ttyACM0 -f brick_master_firmware_2_2_1.bin brick-flash-cmd-1.0.0_all.deb

Brick Daemon 2.1.0 Support für Authentifizierung hinzugefügt (standardmäßig deaktiviert) Support für WebSockets hinzugefügt (Port 4280, standardmäßig deaktiviert) USB Device Lookup ist jetzt robuster gegen einige USB Treiber Bugs auf Windows Mitgelieferte libusb Version für Mac OS X auf 1.0.18 aktualisiert, behebet einen SIGFPE Bug Mitgelieferte libusb Version für Windows auf 1.0.18 aktualisiert, fügt Support für einige Intel und AMD USB 3.0 Root Hubs hinzu Behandlung von Request mit ungültiger Länge im Header korrigiert Seltener Fall von EWOULDBLOCK Fehler bei socket_receive wird jetzt richtig behandelt Verbindung zu USB Devices nach einem Host-Suspend auf Linux und Mac OS X wird jetzt wieder hergestellt (benötigt pm-utils auf Linux) Limits Für Pending-Requests und USB-Write Queues verdoppelt socket_send-Queue für Clients hinzugefügt; senden von Pakete wird wiederholt falls socket_send blockieren würde anstatt die Verbindung zum Client zu trennen Response-Pakete werden nur noch an den ersten Client mit einem passenden Request gesendet; verhindert das Duplizieren von Response-Paketen Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.1.0 Add authentication support (disabled by default) Add WebSocket support (port 4280, disabled by default) Make USB device lookup more robust in case of some USB driver bugs on Windows Update bundled libusb to 1.0.18 on Mac OS X, fixes a SIGFPE bug Update bundled libusb to 1.0.18 on Windows, adds support for Intel and AMD USB 3.0 root hubs Improve handling of request packets with invalid length in the header Handle rare case of socket_receive failing with EWOULDBLOCK Don't lose connection to USB devices on host-resume-from-suspend on Linux and Mac OS X (requires pm-utils on Linux) Increase upper limits for pending requests and USB write queues Add socket_send queue for clients, enqueue packet instead of disconnecting client if socket_send would block Only dispatch response to the first client with a matching pending request, fixes response duplication Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X