photron

In brickd 2.4.1 wird "After=network.target" enthalten sein. Version 2.4.1 ist aber noch nicht veröffentlicht und aktuell kann ich dir auch noch keinen Termin dafür nennen. Sprich, bei 2.4.0 musst du die Zeile händisch hinzufügen. Ab 2.4.1 dann nicht mehr.

Die *_register_callback Funktionen erwarten C Funktions-Pointer. Du versucht da aber einen Pointer auf eine C++ Methode zu übergeben. Der Unterschied zwischen einer C Funktion und einer C++ Methode ist der this Pointer. Der übliche Weg das zu regeln ist über den Umweg einer statischen C++ Methode, die wie eine C Funktion auftreten kann, da sie keinen this Pointer hat. Im angehängten Beispiel wird die statische C++ Methode cb_enumerate_static bei der IP Connection registriert und als user_data wird der this Pointer mitgegeben. Die cb_enumerate_static Methode nimmt dann den per user_data übergebenen this Pointer und ruft damit die C++ Methode cb_enumerate auf. example_enumerate.cpp

Zwischen diesen beiden Zeilen git clone https://github.com/Tinkerforge/daemonlib git reset --hard brickd-2.4.0 fehlt ein cd daemonlib und dann passt auch das cd .. wieder. Ist aber nicht so kritisch. Der Unterschied zwischen HEAD und brickd-2.4.0 im der daemonlib ist aktuell für deinen Fall nicht relevant.

Der Jetson Nano scheint arm64 Architektur zu sein. Dafür bieten wir aktuell kein vorgebautes Package an. Du kannst dort nicht das Package für die armhf Architektur (Raspberry Pi, RED Brick, ...) installieren. Du solltest aber selbst ein passendes Package bauen können. Führt mal diese Folge von Befehlen auf dem Jetson aus: sudo apt-get install git build-essential pkg-config libusb-1.0-0-dev git clone https://github.com/Tinkerforge/brickd cd brickd git reset --hard v2.4.0 cd src git clone https://github.com/Tinkerforge/daemonlib cd daemonlib git reset --hard brickd-2.4.0 cd .. python build_src.py sudo dpkg -i brickd-2.4.0_arm64.deb Das ist ungetestet, ich habe hier kein Jetson oder anderes arm64 Board zu Hand.

Okay, systemd startet brickd also noch bevor die /dev/ Einträge angelegt sind. Ein Service kann Abhängigkeiten auf /dev/ Einträge haben. Das würde die allgemeine brickd ARM Installation aber spezifisch für's Raspberry Pi machen. Ich habe jetzt erstmal für die nächste brickd Version das After=network.target eingefügt. Das hat eh gefehlt und abhängig von dem /dev/ Problem. Und wenn das auch das /dev/ Problem behebt, um so besser.

Teste mal bitte diese brickd.service Datei: [unit] Description=Brick Daemon After=network.target [service] Type=forking ExecStart=/usr/bin/brickd --daemon [install] WantedBy=multi-user.target Es könnte sein, dass systemd brickd startet bevor das Netzwerksubsystem läuft. Dann kann brickd keinen Socket öffnen und beendet sich wieder. Neu in dieser brickd.service Datei ist die After=network.target Zeile. Zeig auch mal bitte die /var/log/brickd.log Datei vor. Ich erwarte, dass brickd sagt, dass kein Socket gebunden werden kann und sich dann wieder beendet.

Hast du beim Sound Pressure Level Bricklet mal die verschiedenen Gewichtungen durchprobiert? Du solltest getSpectrum() Aufrufen, nicht getSpectrumLowLevel(). Das Spektrum ist zu groß um ein einem Packet übertragen zu werden. Die getSpectrumLowLevel() gibt das Spektrum in Stücken (Chunks) aus. Die getSpectrum() nutzt intern die getSpectrumLowLevel() Funktion und setzt das vollständige Spektrum aus Chunks zusammen. Wie die Dokumentation für die getSpectrum() Funktion beschreibt gibt dieses das Frequenzspektrum in form eines FFT aus. Daraus kannst du dir verschiedenste Darstellung ableiten.

The problem was that during flashing the WIFI Extension firmware, Brick Viewer did not configure the flash size for the ESP8266 module correctly (Python 2 vs Python 3 bug). This resulted in the web interface HTML/CSS/JS files being stored after the configured end of flash. This make the webserver on the WIFI Extension 2.0 unable to access those files, resulting in a 404. The bug was introduced in Brick Viewer 2.4.0 and will be fixed in Brick Viewer 2.4.7. Older or newer Brick Viewer versions are not affected. Thanks for reporting this problem.

You've found a bug. The problem seems to be that Brick Viewer since 2.4.0 doesn't flash the WIFI Extension 2.0 correctly anymore. If you use Brick Viewer 2.3.17 or older to flash the WIFI Extension 2.0 firmware then the Web Interface on port 80 works. I'll figure this out and this will be fixed in the next Brick Viewer version 2.4.7.

Ich nehme an, du hast auf dem Raspberry Pi 4 einen HAT Brick mit Bricklets angeschlossen. Das sieht bei mir in htop wie auf dem angehängten Bild aus. Das ist erwartet, da brickd durchgehend mit den angeschlossenen Bricklets kommuniziert. Auf dem Raspberry Pi 4 habe ich 2019-07-10-raspbian-buster-lite.img laufen. Wenn du keinen HAT Brick auf dem Raspberry Pi 4 hast dann sollte da auch keine signifikante CPU Last entstehen. Wie sieht denn dein Aufbau genau aus? Und wie genau sieht die CPU Last in htop aus? Hast du auf dem Raspberry Pi 4 die aktuelle Raspbian Version laufen?

https://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick.html#red-brick-web-interface

Brick Viewer 2.4.6 Fix message box explosion for color gradient with one LED in LED Strip Bricklet 2.0 plugin Only check WIFI Extension 2.0 AP password length if password is changed Downloads: Windows, Linux, macOS

Brick Viewer 2.4.6 Dialogbox-Explosion für Color-Gradient mit einer LED im LED Strip Bricklet 2.0 Plugin entfernt WIFI Extension 2.0 AP Password-Längenprüfung wird nur durchgeführt, wenn das Password geändert wird Downloads: Windows, Linux, macOS

Alle Programme die du über den Brick Viewer auf den RED Brick lädst werden mit dem Nutzer tf ausgeführt. Eine Möglichkeit ist es sudo das Password per Kommandozeile zu übergeben: echo tf | sudo -S -p "" rm /var/log/brickd.log Dazu das Password tf per echo ausgeben und sudo mit der -S Option das Password von stdin lesen lassen. Die -p "" Option unterdrückt das Password Prompt von sudo.

Okay, that means that the RED Brick did not fully boot up. This can be an issue with the SD card itself or the file system on the SD card. If you don't have any important data stored on the SD card then you could try flashing a fresh RED Brick image to the SD card: https://www.tinkerforge.com/en/doc/Hardware/Bricks/RED_Brick.html#copy-image-to-sd-card Alternatively, if you have another SD card similar to the RED Brick one then you could try flashing a fresh RED Brick image to that SD card instead.

Please check if the three LEDs on the RED Brick light up in the documented sequence: https://www.tinkerforge.com/en/doc/Hardware/Bricks/RED_Brick.html#leds If they don't, what's the sequence you're seeing when you power up the RED Brick?

Das Log ist voller Debug Nachrichten. Das ist nicht die Standardeinstellung. Normalerweise werden nur Info, Warn und Error Nachrichten geloggt. Schau mal im Brick Viewer RED Brick Tab unter Settings -> Brick Daemon nach. Da sollte Log Level auf Info stehen. Ich erwarte, dass dort bei dir Debug steht. Wenn du das auf Info zurückstellst, dann hört auch das brickd.log auf so schnell zu wachsen.

Hast du den Brick Daemon auf deinem Windows PC oder dem RED Brick aktualisiert?

Das Logfile sollte nicht so explodieren. Kannst du mal so ein Logfile zeigen, damit ich verstehen kann was da passiert?

Wenn dir die 8 bzw. 4 Brickletanschlüsse des HAT (Zero) Bricks auf Dauer nicht reichen, dann kannst du natürlich zusätzlich immer noch weitere Master Bricks über USB zusätzlich zum HAT (Zero) Brick anschließen.

Okay, dass sieht erstmal gut aus. Der RED Brick hat also ordentlich Netzwerkverbindung. Was du da jetzt nicht getestet hast, ist, ob du vom Laptop den RED Brick pingen kannst. Da es aber in die andere Richtung geht, sollte das auch funktionieren. Da du den RED Brick per USB erreichen kannst muss der Brick Daemon grundsätzlich laufen. Aber über Netzwerk ist Brick Daemon nicht erreichbar. Netzwerk funktioniert aber. Daher bleibt nur das Brick Daemon nicht richtig aufs Netzwerk lauscht. Verbinde dich bitte mal per USB mit dem RED Brick und überprüfe die Brick Daemon Config auf dem RED Brick -> Settings -> Brick Daemon Tab. Dort muss die Listen Address auf 0.0.0.0 und der Port auf 4223 stehen. Wenn das nicht der Fall ist dann stellt das bitte mal so um und bestätige das mit dem Save Knopf unten rechts. Falls das nicht das Problem löst, dann zeig mal bitte das brickd.log vor. Das kannst du über den RED Brick -> Import/Export -> System Logs herunterladen.

Brick Viewer 2.4.5 Improve GUI and error handling of RS485 Bricklet plugin Improve WIFI Extension 2.0 configuration validation Handle spectrum stream-out-of-sync error for Sound Pressure Level Bricklet Handle station/sensor loss for Outdoor Weather Bricklet Don't trigger overview updates while RED Brick plugin is not visible Fix duplicated async-reads in RED Brick plugin script manager Enable Retina mode on macOS Fix upload of empty files to RED Brick Fix timezone setting for RED Brick Make WIFI Extension 2.0 flashing more robust by increasing the number of bootloader connection attempts Downloads: Windows, Linux, macOS

Brick Viewer 2.4.5 GUI und Fehlerbehandlung des RS485 Bricklet Plugin überarbeitet WIFI Extension 2.0 Konfigurationsprüfung verbessert Spektrum Stream-Out-Of-Sync Fehler wird im Sound Pressure Level Bricklet Plugin korrekt behandelt Stations/Sensor-Verlust wird im Outdoor Weather Bricklet Plugin korrekt behandelt Overview-Updates werden nicht durchgeführt, wenn das RED Brick Plugin nicht sichtbar ist Es werden keine doppelten Async-Reads im RED Brick Plugin Script Manager ausgelöst Retina-Modus auf macOS aktiviert Hochladen leerer Dateien auf den RED Brick korrigiert Zeitzoneneinstellung auf dem RED Brick korrigiert WIFI Extension 2.0 Flashing ist robuster, durch erhöhte Anzahl an Bootloader-Verbindungsversuchen Downloads: Windows, Linux, macOS

Du kannst weiterhin ganz normal Bricks per USB am Raspberry Pi anschließen, auch gleichzeitig zum HAT.

Okay, der Brick Viewer Screenshot sieht gut aus. Wechsel in Brick Viewer mal auf den Console Tab des RED Brick und verbinde dich mit der seriellen Schnittstelle des RED Brick. Teste dort mal die WLAN Verbindung des RED Bricks in dem du vom RED Brick aus versuchst mal denen Laptop zu pingen. Und auch mal versuchst irgendwas im Internet wie google.de oder heise.de zu pingen.