photron

Du kannst über Brick Viewer Programme auf den RED Brick laden und ausführen lassen: https://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick_Program_Tab.html Auf dem RED Brick läuft ein Debian Linux, daher unterschiedet sich der RED Brick vom Betriebssystem her nicht stark von einem Raspberry Pi. Über USB steht dir eine serielle Konsole bereit, die du auch auch über den Brick Viewer zugreifen kannst. Wenn du dem RED Brick über eine USB WLAN Strick oder USB Ethernet Stick oder eine Ethernet Master Extension eine Netzwerkschnittstelle gibst, die du über Brick Viewer konfigurieren kannst, dann kannst du den RED Brick auch über SSH erreichen.

Das Verhalten passt zum klassischen Problem eines ungeflashten 10 Pol Bricklets. Wenn auf einem 10 Pol Bricklet keine oder eine defekte Firmware ist, dann versucht der Brick diese trotzdem auszuführen und stürzt dabei ab. Das passt zum den Symptomen, dass die 4 LEDs nicht leuchten. Das passt allerdings nicht damit zusammen, dass das bei 4 verschiedenen Bricklets auftritt. Du kannst versuchen eines der 10 Pol Bricklets per Hotplug zu flashen, aber ich erwarte nicht wirklich dass das hilft. Dazu schließt du zuerst den Brick ohne Bricklets an USB an und erst danach (eigentlich verbotenerweise) schließt du an den laufenden Master Brick ein Bricklet an. Wenn du jetzt keine elektrischen Probleme auf dem Master Brick hast, dann sollte der Master Brick dir das nicht Übel nehmen. Aber das Bricklet wird so jetzt nicht erkannt und der Master versucht jetzt nicht das zu nutzen. In Brick Viewer flasht du jetzt das Bricklet neu. Dazu wählst du sozusagen blind Parent, Port und Plugin aus, entsprechend dem was du angeschlossen hast. Wenn der Flashvorgang erfolgreich war kannst du jetzt den Master Brick neustarten und alles funktioniert wieder. Ich erwarte aber fast, dass der Master Brick ein Problem mit seinem I2C Bus hat und das Hotplug Flashen mit einem Fehler scheitert. Ein Unterschied zwischen 7 Pol und 10 Pol Bricklets ist, dass die 7 Pol Bricklet den I2C Bus der Bricks nicht mehr verwenden, das entspricht den 3 fehlenden Pins. Auf der Unterseite des Master Brick sitzt ein 20 Pin Chip der Teil des I2C Bus ist. Schau mal nach ob dort vielleicht durch Verschmutzung ein Kurzschluss zwischen den Pins vorliegt. Schau auch mal nach, oder in den Bricklet Anschlüssen Pins krumm sind und Kurzschlüsse machen.

Das Debug Log Level ist nicht für den normalen Betrieb gedacht, da es abhängig vom System so viele Meldungen ausgeben kann, dass darunter die Performance von Brick Daemon leiden kann. Ich werde das Level dieser Meldung in der nächsten Brick Daemon Version auf Info ändern, da diese Meldung offensichtlicher Weise für den Nutzer interessant ist 😁. Bis dahin kannst du dir über den Debug Filter behelfen. Aktuell kann dieser nicht einzelnen Zeilen erfassen, sondern nur auf Dateibasis arbeiten. Mittels -all,+bricklet.c kannst du die Debug Logausgabe auf die Datei bricklet.c beschränken. Wenn du das Level auf Debug stellst, aber keinen Filter angibst, werden alle Debug Meldungen ausgegeben, daher müssen zuerst über "-all" alle Debug Meldungen wieder herausgefiltert werden, um dann mit "+bricklet.c" nur die aus der Datei bricklet.c wieder zuzulassen. Auf der langen Nice-to-have-Liste steht auch noch "-all,+bricklet.c:256" zu unterstützen, um auch auf Zeilennummern filtern zu können, aber ob und wann das was wird steht in den Sternen.

Nach kurzem googlen kann ich dazu nur finden wie man auf Basis einen PyPI Packages selbst eine Conda Package bauen kann: https://docs.conda.io/projects/conda-build/en/latest/user-guide/tutorials/build-pkgs-skeleton.html#building-a-simple-package-with-conda-skeleton-pypi Alternative dazu diese Stack Overflow Frage, wobei das mit Vorsicht zu sehen ist, da Frage und Antworten schon älter sind. Möglicherweise entspricht die Option die du da gefunden hast der pip_interop_enabled Option in der in der letzten Antwort die Rede ist. Wenn ich das richtig verstehe, kann Conda dadurch PyPi Packages zwar nicht installieren, kann aber über pip installierte PyPI Packages nutzen: https://stackoverflow.com/questions/29286624/how-to-install-pypi-packages-using-anaconda-conda-command

Das liegt daran, dass die Tinkeforge API Bindings nicht in Conda (bzw der kommerziellen Variante Anaconda) verfügbar sind, weil sie noch niemand dafür paketiert hat.

Bindings: JavaScript 2.1.30 Restore ECMAScript 5 compatibility Add 64-bit integer support using BigInt Download: JavaScript

Bindings: JavaScript 2.1.30 ECMAScript 5 Kompatibilität wieder hergestellt 64-Bit Integer Support mittels BigInt hinzugefügt Download: JavaScript

Error 31 is "Timeout". The most common cause for this is that you used the wrong UID in the example. Are you sure it's error 31? Error 13 is "Connection Failed" that could be caused by wrong IP address or port configuration. The RED Brick does not used the WebSocket port configured on the Ethernet Extension itself. For the RED Brick you need to configure the WebSocket port on the RED Brick itself: Brick Viewer > RED Brick > Settings > Brick Viewer > Web Socket Port.

Diese Frage kam schon häufiger auf und ich dachte eigentlich wir hätten das mittlerweile dokumentiert, scheint nicht der Fall zu sein. Der Sensor misst einfach die absolute Niederschlagsmenge seitdem die Batterien eingelegt wurden. Jeglichen anderen Zeitbezug musst du selbst berechnen. Das der Messwert fällt sollte unmöglich sein, wenn du nicht die Batterien für einen Reset herausgenommen hast. Hast du vielleicht mehr als eine Station in Empfangsreichweite und die haben zufälligerweise die gleiche ID?

Also, so wie du Promise verwendest kann das nicht funktionieren. Du legst ein leeres device_promises Array an, und im Prinzip rufst direkt danach Promise.all auf ein leeres Array auf. Dieses Promise ist natürlich sofort erfüllt, denn die Enumerate Callbacks kommen erst danach an. Damit der Ansatz funktioniert musst du vor dem ipcon.enumerate() Aufruf wissen wie viele Devices vorhanden sind und die Promises vorher anlegen und nicht erst im Enumerate Callback, denn dort ist es zu spät. Wenn du nicht weißt wie viele Devices vorhanden sind kannst du das über einen Timeout lösen. Die Annahme dabei ist, dass zwischen dem ipcon.enumerate() Aufruf und dem ersten Enumerate Callback und dann den darauf noch folgenden Enumerate Callbacks jeweils weniger als eine Sekunde vergeht. Ich habe dir mal das Enumerate Example abgeändert. ExampleEnumerate_theobald.html

Ja, das ist leider so. Ich habe dem Update Dialog jetzt einen Hinweis hinzugefügt, dass der Prozess durchaus bis zu 2 Stunden dauern kann.

Brick Viewer 2.4.14 Fix monoflop handling to cover full uint32 duration range Better indicate disconnected state Highlight timeout error counter > 0 in bold red Fix slider/spinbox mismatch on auto-reconnect in DC Brick plugin Avoid UI jumps on value changes in Energy Monitor Bricklet plugin Add extra checkbox to avoid accidental port number changes Handle all errors while downloading firmware updates Downloads: Windows, Linux, macOS

Brick Viewer 2.4.14 Monoflop-Behandlung korrigiert damit der gesamte uint32 Zeitbereich genutzt werden kann Disconnected-Zustand wird besser dargestellt Timeout-Fehlerzähler wird bei Werten > 0 fett-rot hervorgehoben Abweichung zwischen Slider- und Spinbox-Wert im DC Brick Plugin nach Auto-Reconnect korrigiert UI springt nicht mehr bei Werteänderungen im Energy Monitor Bricklet Plugin Extra Checkbox soll unabsichtliche Änderungen der Portnummer verhindern Alle Fehler beim Herunterladen von Firmware Updates werden behandelt Downloads: Windows, Linux, macOS

Periodisch abgefragt werden: https://download.tinkerforge.com/latest_versions.txt https://download.tinkerforge.com/all_versions.txt Es kann sein, dass du das Popup da nicht siehst, weil es zu schnell wieder weg ist.

Brick Viewer fragt auf tinkerforge.com die Liste der aktuellen Firmware Versionen ab, um Updates anzeigen zu können. Bei dieser Abfrage ist ein Übertragungsfehler aufgetreten, der im Code nicht behandelt wurde. Unbehandelt Fehler landen dann in diesem Fehlermeldungsdialog. Das hat nichts damit zu tun was du zu dem Zeitpunkt getan hast. So richtig erklären kann in den speziellen Fehler nicht. Da hatte entweder unser Server oder deine Internetverbindung gerade Schluckauf. Trat der Fehler nur einmal auf, oder tritt der immer wieder auf? In der nächste Brick Viewer wird dieser Fehler richtig behandelt werden.

@duaw Der Fehler "NameError: name 'display_names' is not defined" wurde in den MQTT Bindings 2.0.10 behoben, wobei 2.0.11 die aktuelle Version ist. Du verwendest also nicht die aktuellste Version der MQTT Bindings. Teste mal bitte mit Version 2.0.11, ob da dein Problem auch noch auftritt. Stehen diese unvollständigen Zeilen "2020-08-06 17:05:49,497 <DEBUG> MQTT bindings:" da so wirklich so, oder hast du da etwas gekürzt?

Die Inkompatibilität mit dem 5.4 Kernel ist durch das Firmware Update 2.0.2 des HAT Bricks behoben. Das Problem dabei ist das Firmware Update 2.0.2 auf den HAT zu bekommen, während der Kernel 5.4 verwendet wird. Das einfachst ist dafür auf einen älteren Kernel zu wechseln. Sobald du dann Firmware Update 2.0.2 auf dem HAT hast kannst du auch wieder Kernel 5.4 verwenden.

systemd-timesyncd als NTP Client ist normalerweise installiert und ist eigentlich auch bei Raspbian dabei. Aber systemd-timesyncd ist eine simple minimale SNTP Implementierung. Das reicht für viele Zwecke. Aber ich habe auch schon festgestellt, dass systemd-timesyncd absolute nicht damit klar kommt, wenn die Internetverbindung schlecht ist, dann kommt keine sinnvolle Zeitsynchronisierung zustande. Für ntpd und chronyd ist das aber kein Problem. Interessant, wäre trotzdem zu sehen was passiert, wenn du alle NTP Dienste deaktivierst, damit zu erkennen ist, was die RTC da wirklich tut, denn wenn du NTP laufen hast, dann überstimmt das die RTC in jedem Fall.

Die Doku ist da etwas ungenau, das ist ein Super-Cap, keine Batterie. Leider hält der auf der aktuellen HAT Version 1.4 nicht besonders lange vor, bedingt durch den zu großen Leckstrom einer Diode. Das Problem ist auf der nächsten Hat Version 1.5 behoben. Es sollte eigentlich folgendes passieren: Das Raspberry Pi erkennt den HAT Brick und lädt den Kernel Treiber für den RTC Chip PCF8523. Der Kernel führt aber kein hwclock --hctosys aus, um die Systemzeit von der RTC Zeit zu setzen, dazu müsste der Kernel mit CONFIG_RTC_HCTOSYS=y gebaut sein, was bei Raspbian aber nicht der Fall ist. Jetzt lädt der Kernel das Userland und systemd startet brickd. Brick Daemon erkennt, dass der HAT Brick angeschlossen ist und führt jetzt hwclock --hctosys aus, dass die Hardware Clock (hc) liest (den RTC Chip) und damit die System Clock (sys) setzt. Das sollte die Systemzeit auf die RTC Zeit springen lassen, aber nur wenn der Super-Cap durchgehalten hat. In das ganze kann jetzt auch noch fake-hwclock mit hineinspielen. Teste mal, ob sich das Verhalten ändert, wenn du fake-hwlock deinstallierst. Normalerweise läuft Zeitsynchronisation auf Linux so, dass am Anfang einmal die Systemzeit auf die richtige Zeit springt (z.B. per NTP oder RTC) und danach, z.B. durch NTP die Systemzeit ständig nachkorrigiert wird. Diese Nachkorrigieren wird dann durch Strecken und Stauchen von Sekunden gemacht, damit die Systemzeit monoton ist und nicht springt. Was mich wundert ist das schnelle hochzählen, das ist nicht normal. Welche Kernel Version hast du laufen? Du kannst auch mal testen einen richtigen NTP Dienst zu installieren (z.B. chrony) anstelle dieser Krücke systemd-timesyncd die standardmäßig läuft.

Okay, dass bestätigt, dass irgendwo her ein Packet kommt, das an den HAT Brick geschickt wird und der dies als Abschaltbefehl für die Bricklets versteht. Das brickd.log verwirrt uns hier. Das Log quillt über an Warnungen dieser Art: Broadcasting response (...) because no client/zombie has a matching pending request Brick Daemon hat eine Antwort von der Hardware empfangen, für die es keine offene Anfrage gibt. Teilweise sind dies Antworten, die offensichtlich korrupt sind (unbekannte UID, ungültige Länge oder unbekannte Funktions-ID). Viele andere Antworten sind aber so ohne Kontext erstmal gültige Antworten. Das passt zum Brick Viewer Screenshot von vorher auf dessen Industrial Dual Relay Tab 174 Timeouts (fehlende Antworten) zu sehen waren. Die Antworten konnten in Brick Daemon nicht mehr zugeordnet werden, weil diese korrumpiert wurden. Die "Broadcasting Response" Meldungen im Log sollten unter normalen Umständen überhaupt nicht auftreten. Eine Vermutung wäre, dass die Bricklet Kommunikation durch die Umgebung gestört wird. Und zwar so stark, dass die Protokoll-Checksummen das nicht mehr abfangen können. Ein möglicher Test wäre es den Hardware Aufbau zu vereinfachen, z.B. den Display vollständig abzubauen, Bricklet Leitungslängen verkürzen und damit die Antennenwirkung der Kabel verringern. Oder auch mal den Aufbau wo anders betreiben (Draußen, Zuhause, etc.) rtrbt postet gleich auch noch ein Testprogramm auf Basis der neuen "C/C++ Bindings für Mikrocontroller", die ohne brickd auskommen. Einfach um zu sehen wie sich das verhält, und ob dort auch diese Fehler auftreten.

Der HAT Brick flasht sich etwas ungewöhnlich. Du schließt den nicht per USB an, der micro USB Anschluss ist nur für Strom. Sondern du lässt den HAT Brick auf dem Raspberry Pi stecken, verbindest dich dann mit Brick Viewer zum Raspberry Pi und wählst auf den Update/Flashing Dialog den Bricklet Tab aus. Dort wählst du als Parent None und kannst dann als Port den HAT Brick auswählen. Dort wählst du als Plugin Custom aus und kannst dann die Firmware Datei über den Browse Knopf auswählen und der Flash Knopf die Firmwae flashen. Mit dem HAT Brick hat sich die Trennung zwischen Bricks und Bricklets etwas verwischt. Der HAT Brick ist nach außen in Brick nutzt intern aber Bricklet Strukturen, wodurch er wie ein Bricklet geflasht wird. Auf Dauer werden wir den Flash Dialog in Brick Viewer überarbeiten und vereinfachen.

Teste auch mal bitte die angehängte Firmware 2.0.3 für den HAT Brick. Diese Version legt die set_bricklet_power Funktion tot, um zu verifizieren, dass es wirklich ein fälschlicher Aufruf dieser Funktion ist, der das Problem erzeugt. hat-brick-firmware-203.zbin

Willst du damit sagen, dass du das Problem nicht nur an einem, sondern an zwei Aufbauten hast? Update auch mal bitte alle Tinkerforge Software. Also Brick Viewer auf 2.4.13, Brick Daemon auf dem Raspberry Pi auf 2.4.1 und C/C++ auf 2.1.19. Mir ist kein Bug bekannt in den alten Versionen der zum Problem passt, aber ich möchte vermeiden, dass wir hier alte bereits behobene Bugs suchen. Kannst du bitte das /var/log/brickd.log vom Raspberry Pi hier anhängen, vielleicht steht dort etwas interessantes drin. Welche Kernel Version hast du auf dem Raspberry Pi laufen (was gibt "uname -a" aus)? Was steht in /boot/cmdline.txt und /boot/config.txt auf dem Raspberry Pi?

Hast du da einfach eine UID Kollision? Schau mal bitte das alle Bricks und Bricklets unterschiedliche UIDs haben.

Zusätzlich könntest du das Programm in Valgrind laufen lassen. Valgrind dient u.a. dazu Speicherkorruption zu finden.