photron

Funktioniert das "ExampleSimple" selbst denn?

Das kann auf dem RED Brick ein Treiberproblem sein. Da du jetzt einen funktionierenden Aufbau hast kannst du mit "lsusb" auf dem Raspberry Pi herausfinden welcher Treiber da genutzt wird. Kannst du auf dem Raspberry Pi in einem Terminal folgende Befehle ausführen und deren Ausgabe hier zeigen? Dabei muss das Display angesteckt sein: lsusb und lsusb -t Dann kann ich herausfinden, ob ich diesen Treiber auch auf dem RED Brick aktivieren kann.

FlyingDoc, mit welchen Einstellungen nutzt du das Bricklet und hast du am PC noch eine richtige RS232 Schnittstelle, oder nutzt du eine weiteres RS232 Bricklet oder einen USB RS232 Adapter? Doncarlos' Einstellungen kenne ich schon. Ihr habt beide einen ähnlichen Aufbau, wenn ich das richtig verstehe. Also RED Brick mit Master Brick und RS232 Bricklet. Das RS232 Bricklet wird dann zur Kommunikation mit einem anderen RS232 Gerät (Heizung bzw. PC) genutzt. Welche RS232 und Bricklet Kabellängen benutzt ihr? Hintergrund ist, ich will hier mal einen Langzeittest aufbauen, um zu sehen, ob ich das Problem reproduzieren kann.

FlyingDoc, wir haben gerade kurz in den Bricklet Code geschaut. Da ist auf den ersten Blick aber keine Möglichkeit drin, dass sich die Einstellungen im laufenden Betrieb von selbst ändern. Kannst du Testen, ob es wirklich, dass Neusetzen der Konfiguration ist, dass das Problem behebt? Oder ob es doch irgendetwas anderes ist, dass du beim Start deines Programms machst?

FlyingDoc, wie stellst du fest, dass das Bricklet nicht mit den richtigen Einstellungen arbeitet?

Uploading it as a program like that is the correct way to go. The error message is a bit misleading. The script tries to connect to an MQTT broker as localhost:1883 by default. If there is no such broker then you get that error message. You need to install an MQTT broker on the RED Brick or tell the script to connect to another broker. You can install a broker with this command on the RED Brick: sudo apt-get install mosquitto

Ich setze das mal auf die TODO Liste.

Die Fehlermeldung besagt eigentlich, dass das pywintypes Modul nicht mit dem ü in Büro im Installationspfad zurecht kommt: E:\Daten.2016\Büro.2016\Allgemein.2016\DB.2016\TinkerForge\Brickv\brickv.exe Hast du beim Installieren in einen anderen Ordner einen ohne Umlaute im Pfad gewählt?

Diese Problem bestand in Brick Viewer Version 2.3.3 und wurde in Brick Viewer Version 2.3.4 behoben. Die Funktion heißt "Auto-Update All Bricklets". Der Update Dialog zeigt dir zwar auch neue Versionen der Brick Firmwares und Brick Viewer selbst an, Auto-Update aktualisiert aber nur die Bricklets. Brick Viewer Version 2.3.4 muss du von Hand herunterladen und installieren. Danach musst du im Update Dialog auf dem Bricklet Tab den Brick und Port für das falsche Temperature Bricklet auswählen, dann als Plugin Thermocouple Bricklet auswählen und Save klicken.

So ein richtig klares Bild ergibt sich da noch nicht. Macht es einen Unterschied, wenn du beim "neuen Laptop" Aufbau den Laptop mit seinem Netzteil anstatt Akku betreibst? Sprich du grob elektrisch gesehen den gleichen Aufbau wie beim "alten Laptop" hast? Ich frage mich, ob das hier ein Problem mit der Masseverbindung zwischen Heizung und Bricklet ist. Annahme ist: Diese Masseverbindung ist gestört bzw. nicht vorhanden, wird beim "alten Laptop" Aufbau aber übers Stromnetz hergestellt. Wenn du ein Multimeter zur Hand hast, dann könntest du messen, ob von Masse am Bricklet über deine selbstgebautes Kabel Kontakt zur Masse am RJ45 Stecker für die Heizung besteht. Am Bricklet findest du Masse auf der Stiftleiste und der Schraubklemme. Was meinst du beim "RED Standalone" Aufbau mit "Daten auslesen funktioniert nicht"? Kommt da dann gar nichts an, oder ist das auch so kaputt wie beim "neuen Laptop" Aufbau? Funktioniert folgender Nullmodem Test, wenn du den alten Laptop die Heizung simulieren lässt (unter der Annahme, dass der alte Laptop noch einen richtigen RS232 Anschluss hat)? 230V --- alter Laptop --- Nullmodem --- RS232 Bricklet --- neuer Laptop --- Akku

Der Treiber für den GT811 ist im RED Brick Kernel enthalten. Es sollte also kein Treiberproblem sein. Du kannst auf dem RED Brick Console Tab im Brick Viewer nutzen und dir die Ausgabe des lsusb Befehles ansehen. Einmal mit und einmal ohne das der Touch Screen an USB angeschlossen ist. Die Ausgabe des lsusb Befehls sollte mehr ausgeben, als die ohne. Falls in beiden Fällen die Ausgabe exakt gleich ist, dann wird der Touch Screen nicht erkannt. Wir verkaufen einen passenden WLAN USB Stick: https://www.tinkerforge.com/de/shop/accessories/red-brick/wifi-usb-adapter.html Im Wiki haben anderen Nutzer ihre Erfahrungen zusammengetragen: http://www.tinkerunity.org/wiki/index.php/DE/RED_USB

Wie genau ist denn dein Aufbau? Hast den den Stapel am Laptop per USB angeschlossen und die Stromversorgung geht auch über USB? Wie hast du den Stapel mit dem Laptop verbunden, wenn du das 5V Netzteil verwendest? Das macht den Eindruck eines Masseschleifenproblems. Allerdings würde ich dann erwarten, dass es besser funktioniert wenn der Labtop und der Stapel Batteriebetrieben sind. Die einzige Masseverbindung also übers RS232 Kabel läuft.

Tritt das Problem auch noch auf, wenn du den Aufbau vereinfachst? Also z.B. nur den RED Brick alleine an USB angeschlossen hast und dann über Brick Viewer einen Neustart machst?

Brick Viewer 2.3.4 Add support for Real-Time Clock Bricklet Don't auto-update Thermocouple Bricket with Temperature Bricklet firmware Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.3.4 Support für Real-Time Clock Bricklet hinzugefügt Thermocouple Bricket wird nicht mehr mit Temperature Bricklet Firmware auto-aktualisiert Downloads: Windows, Linux, Mac OS X

Das Flat Flex Kabel müsste speziell angefertigt werden, die gibt es nicht von der Stange. Momentan gibt es da keine Pläne für. Es gibt schlicht sehr sehr wenig bis keine Nachfrage dafür, daher ist das softwareseitig auch noch unfertig.

Funktioniert der Touch Screen nur am RED Brick nicht, oder funktioniert er an einem anderen PC auch nicht? Es kann sein, dass im RED Brick Kernel der Treiber für den Touch Screen Controller fehlt oder nicht aktiviert ist. Ich konnte auf Anhieb nicht herausfinden, welcher Touch Screen Controller bei dem Display verbaut ist. Vielleicht kannst du das heraus bekommen, wenn du den Touch Screen an einem anderen PC anschließt. Alternative kannst du auch die Nummern von den zwei großen Chips auf der Rückseite ablesen und hier posten.

Du kannst pro Master Brick mit einem LED Strip Bricklet und drei freien Bricklet Ports 320 LEDS ansteuern. Für die nächsten 320 LEDs brauch du dann einen weiteren Master Brick mit einem weiteren LED Strip Bricklet und 3 freien Ports. Du kannst nicht 400 LEDs am Stück ansteuern. Du könntest deine 400 LEDs auf 2 Master Bricks + LED Strip Bricklets aufteilen: Master Brick 1 ---> LED Strip Bricklet 1 ---> 200 LEDs | PC ---> Master Brick 2 ---> LED Strip Bricklet 2 ---> 200 LEDs Die beiden Master Bricks können dabei in einem Stack sein. Die LEDs können flasche Farben anzeigen, wenn du sie nicht ansteuerst, denn dann können sie rauschen auf den Leitungen als Daten missversteht. Das beste Vorgehen ist also immer alle angeschlossenen LEDs anzusteuern und die die du nicht brauchst auf 0,0,0 (schwarz) zu setzen.

Ich habe gerade folgendes getestet: - GPU aus, Desktop aus, Spalsh aus, openHAB an, "Save and Reboot" - Dateisystem "Reboot and Expand" - openHAB Config geändert, gespeichert und "Reboot RED Brick" Funktioniert alles ohne Probleme. Bei dir funktioniert es also nicht über Brick Viewer einen Neustart zu machen? Mit welchem LED Zustand bleibt der Bootvorgang denn stehen? Normalerweise solltest du kurz die rote LED aufleuchten sehen. Dann sollte die rote ausgehen und die grüne leuchten. Nach einem Moment sollte die grüne dann blinken. Es funktioniert aber, wenn du durch Strom ab-/anstecken einen harten Neustart erzwingst?

Auf der GPIO Schnittstelle des RED Brick liegen auch UART Pins, ja. Die GPIO Schnittstelle ist aber momentan nur in Hardware vorhanden. Sie wird vom Kernel momentan weder passend konfiguriert, noch gibt es momentan ein passendes Flat Flex Kabel dazu. Das ist also nichts was du kurzfristig nutzen könntest.

Funktioniert hier. Sowohl "Reboot RED Brick" als auch "Restart Brick Daemon". Von was für einem Build sprichst du nach dessen Installation ein Neustart zwingend notwendig sein soll?

Wir verwenden hier z.B. diese SD Kartenleser: http://www.amazon.de/Transcend-TS-RDF5K-Kartenleseger%C3%A4t-MicroSDHC-microSDXC/dp/B009D79VH4/

So eine frei Speicherfunktion gibt es im System so nicht. Die UIDs der Bricks werden aus der UIDs des Mikrocontrollers abgeleitet und sind nicht änderbar. Die UIDs der Bricklets sind ein uint32 der Base58 kodiert dargestellt wird. Du könntest also eine Bricklet UID als 4 Byte freien Speicher missbrauchen. Der uint32 Wert darf nur nicht 0 sein.

Hier die Funktion der Read Klasse ohne Klasse. Dazu ersetzt du in deinem Beispiel die cb_read Funktion durch diese Version: buffer = '' # Global buffer to collect all incoming data # Callback function for read callback def cb_read(message, length): s = char_list_to_string(message, length) # Append new data to global buffer global buffer buffer += s # Check if global buffer contains a complete response i = buffer.find('\r\n') if i >= 0: # Get response (without \r\n) from buffer response = buffer[:i] # Remove response (with \r\n) from buffer buffer = buffer[i + 2:] # Print response print('Response: ' + response) Im Read Callback kommen die Daten immer noch stückweise an, daran ändert sich nichts. Der Code nutzt jetzt aber einen globalen Buffer in dem alle eingehenden Stück gesammelt werden. Dann wird in den Buffer geschaut, ob eine komplette Antwort (endet mit \r\n) im Buffer zusammen gesammelt wurde. Wenn ja wird sie aus dem Buffer entfernt und ausgegeben.

Ah, da muss ein deaktiviert stehen!