photron

Hast du in der GpsMain.java Datei ein package definiert? Da du tinkerforge.GpsMain als Möglichkeit auflistest lässt mich das glauben, dass du in GpsMain.java oben "package tinkerforge;" stehen hast. Wenn das der Fall ist dann ist tinkerforge.GpsMain richtig. Allerdings muss du dann nicht GpsMain.class direkt hochladen, sondern den tinkerforge Ordner selbst in dem GpsMain.class liegt.

Meistens reicht printf über die serielle Schnittstelle aus, die der Debug Brick über seinen USB Anschluss rausreicht. Zum Auslesen der Daten reicht dann minicom oder Putty. Für Timing-Analysen eignet es sich gut freie Pins zu setzen und das Timing mit einem Logic Analyzer zu vermessen. Als Logic Analyzer haben wir hier einen Logic16 von Saleae. JTAG kommt nur dann zum Einsatz, wenn das beides nicht reicht. Dafür wird dann Eclipse mit OpenOCD verwendet.

Espressif hat das Problem im aktuellen SDK 2.1 gefixt. Momentan verwendet die WIFI Extension noch das SDK 1.5, weil damals Mesh nur mit 1.5 funktionierte. Es sieht aber so, dass das SDK 2.1 jetzt direkt mit Mesh Support kommt. Es wird in Kürze eine neue Firmware für die WIFI Extension geben.

Assuming you're running Linux the config file should be here now, according to the openHAB2 documentation: /etc/openhab2/services/tinkerforge.cfg But the legacy support might also pickup the old openhab.cfg here: /etc/openhab2/services/openhab.cfg

Diese "initialized" Meldungen zeigen, dass eine Enumerate der Bricks und Bricklets ausgelöst wurde. Das kann zwei Gründe haben: a) Das Enumerate wurde angefragt über IPConnection.enumerate(). Brick Viewer macht z.B. genau das einmal, wenn du den "Connect" Knopf klickst. Alternative hast du auf dem Raspberry Pi noch ein anderes Programm laufen, dass immer wieder ein Enumerate anfragt. b) Die Bricks und Bricklets senden auch von sich aus ein Enumerate beim Start. Es kann also sein, das die Wetterstation alle paar Sekunden neustartet. Du kannst die beiden Fälle an zwei Dingen unterscheiden: 1) Am enumeration_type. Du kannst weather_station.py ab ändern und z.B. in der "log.info('LCD 20x4 initialized')" den enumeration_type mit ausgeben: log.info('LCD 20x4 initialized: ' + str(enumeration_type)) 0 bedeutet, dass das Enumerate angefragt wurde, 1 bedeutet, dass die Wetterstation neugestartet ist. 2) An den 4 blauen LEDs an der rechten Seite des Master Bricks. Beim Neustart zeigen diese kurz ein Lauflicht an.

Teste mal bitte die angehängte Version der Python Bindings. Die braucht jetzt keine UTF-8 Trickserei mehr. Dort ist die ganze Behandlung für Strings und Listen von Chars überarbeitet und verbessert worden. Strings und Listen von Chars werden jetzt als jegliche listenartige Darstellung von Bytes (0-255) angenommen: - str, wird intern mittels map(ord, string) in eine Liste von Bytes (0-255) umgewandelt - bytes und bytearray - list mit ints im Bereich 0-255 - list mit 1-Zeichen langen str, wobei wiederum ord intern zur Umwandlung verwendet wird - list mit 1-Element langen bytes oder bytearray Für die Umwandlung zwischen der internen Protokolldarstellung als Liste von Bytes und der str Darstellung der Python Bindings wird nur ord/chr verwendet. Die Kombination funktioniert in Python 2 und 3 ohne Problem für alle Werte von 0 bis 255. Es wird keinerlei UTF Kodierung mehr verwendet. Wenn dir die Bindings Strings und Listen von Chars per Getter/Callback zurückgeben, dann wird ein String als str zurückgegeben der per "".join(map(chr, list_of_bytes)) aus eine Liste von Bytes zusammengebaut wurde. Ähnlich wird eine Liste von Chars als [chr(b) for b in list_of_bytes] zurückgegeben. Dadurch funktioniert jetzt auch dein Beispiel aus dem ersten Post direkt: rs485.write(b'\x02\x00\x00\x01\x00\xd1') tinkerforge_python_bindings_2_1_14_0e494eae3a34499.zip

There's a new test version: beta1 See https://www.tinkerforge.com/en/blog/red-brick-image-110-beta-test/

Es gibt eine neue Testversion: Beta1 Siehe: https://www.tinkerforge.com/de/blog/red-brick-image-110-beta-test/

RED Brick Image 1.10 Beta Test Blog Entry

RED Brick Image 1.10 Beta Test Blogeintrag

buntstifte, es funktioniert also mit Putty aber nicht mit deinem eigenen Programm? Dann muss es ja an deinem eigenen Programm liegen. Öffnest du in deinem Programm die richtige serielle Schnittstelle, stellst du die Baudrate, Parität und Stopbits richtig ein?

ngauruhoe, ist das Problem auch für dich behoben, oder tritt es bei dir weiterhin mit dieser "Detected missing constraints for <private>" Meldung auf?

Das Problem war, dass wir seit dieser Version im RED Brick Plugin ein Python Module namens distutils verwenden, um RED Brick Versionsnummern zu vergleichen. Dieses distutils Module aber auf der Exclude Liste in unserem Script stand, das die Brick Viewer App zusammenbaut. Daher ist dann das distutils Module nicht Teil der App und die App bricht beim Starten mit einem Export Fehler ab. Das Problem tritt also nur auf, wenn Brick Viewer als App startet, aber nicht wenn man Brick Viewer aus dem Source Code direkt aus dem Terminal herausstartet. Das Problem ist mir gestern wohl nicht aufgefallen, weil ich vergessen habe Brick Viewer als App zu testen. Ich vermute, dass ngauruhoe eine unzusammenhängende Fehlermeldung aus dem Systemlog kopiert hat, denn den "Detected missing constraints for <private>" Fehler kann ich nicht nachvollziehen. Weil diese Meldung sich wie ein Kompatibilitätsproblem lass, war das unser erster Gedanke den borg dann dazu auch geäußert hat.

Das Problem scheint anders als gedacht! Testet mal bitte diese Version: http://download.tinkerforge.com/_stuff/brickv_macos_2_3_11_distutil_fix.dmg

Brick Viewer 2.3.11 Add support for RED Brick Image 1.10 Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.3.11 Support für RED Brick Image 1.10 hinzugefügt Downloads: Windows, Linux, Mac OS X

Brick Daemon 2.3.1 Add support for RED Brick Image 1.10 and drop support for older RED Brick Image versions Recover from stalled USB transfers Avoid race condition with USB prober on Mac OS X while opening USB devices Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.3.1 Support für RED Brick Image 1.10 hinzugefügt und Support für ältere RED Brick Image Versionen entfernt Gestallte USB Transfers werden jetzt wiederhergestellt Race Condition mit USB Probern auf Mac OS X während des Öffnens von USB Geräte vermieden Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

wehnerc: Der SDS011 ist uns bekannt. Ein generelles Problem bei dieser Art von Staubsensoren ist, das die nach einer Weile innen drin zustauben und das die verbaute Laserdiode altert. Beim SDS011 hat die Laserdiode laut Datenblatt eine Lebenszeit von 8000 Stunden, was bei Dauerbetrieb nicht mal ein Jahr ist.

Du hast einen Bug gefunden und dein Fix ist richtig. Was da passiert ist folgendes: Die IPConnection empfängt eine Antwort auf einen Getter oder einen Callback für einen Brick oder Bricklet für das du keine Instanz angelegt hast. Eigentlich sollte die IPConnection Nachrichten von unbekannten Bricks und Bricklets ignorieren. Der Check dafür fehlt aber hier. Danke für den Hinweis, das Problem wird in der nächsten Version behoben sein.

Unter Lubuntu 16.04.3 geht der WDN-4200 problemlos. Komisch. Kannst du noch mal einen Verbindungsversuch mit dem WDN4200 auf dem RED Brick machen und mir /var/log/syslog vom RED Brick zukommen lassen? Das Syslog kannst du z.B. im Brick Viewer auf dem RED Brick Tab unter "Import/Export -> System Logs" herunterladen.

Nic, das Password-Speicher-Problem haben wir behoben. Die 5 Sekunden Verzögerung können wir nachstellen und arbeiten daran, dass zu verbessern. Das ist kein Typo, dass du da vom TP-Link WDN4200 und TP-Link WDN3200 schreibst? Der 3200 der vorher nicht ging, funktioniert jetzt, aber der 4200 funktioniert weiterhin nicht? Funktioniert der TP-Link WDN4200 denn unter Ubuntu?

Okay, here's Alpha 2 including the following changes: All network management is now done by Network Manager. this reduces the waiting times in Brick Viewer while configuring the network. The only thing that's not working yet is connecting to hidden WIFI networks OpenHAB updated to version 2 Image size not too close to 8GB boundary anymore http://download.tinkerforge.com/red_110alpha2/ Edit: The image is now uploaded.

Okay, hier jetzt Alpha 2, mit folgenden Änderungen: Netzwerk Verwaltung auf Network Manager umgestellt, dadurch spürbar kürzere Wartezeit in Brick Viewer bei der Netzwerkkonfiguration. Einzig die Verbindung zu versteckten WLAN Netzen funktioniert aktuell noch nicht OpenHAB auf Version 2 aktualisiert Image jetzt nicht mehr zu nah an der 8GB Grenze Nic, teste bitte, ob der TL-WDN3200 WLAN Stick jetzt besser funktioniert. http://download.tinkerforge.com/red_110alpha2/ Edit: Das Image ist jetzt hochgeladen.

Antwort über PM war, das es vorher auch noch nicht funktioniert hat.