R_Gerald Posted September 20, 2021 at 12:14 PM Share Posted September 20, 2021 at 12:14 PM Habe seit kurzen eine HAT Brick + ein paar Bricks. Habe brickd und brickv laut Anleitung auf meinem Raspberry Pi 4 Modell installiert, und den HAT Brick 1.6 angesteckt. Es hat den Anschein nachdem der brickd ausgeführt wird der Pi komplett ausgelastet und ist nicht mehr ansprechbar (ping zum PI funktioniert nicht mehr). Nach einem Neustart mit gestecktem HAT Brick ist der Pi kurz nach dem Hochlauf bedienbar, dann aber nicht mehr. Wird der HAT Brick abgesteckt und neu gestartet funktioniert der Pi wieder und ich konnte das Log auslesen. 2021-09-20 13:30:12.653002 <I> <main_linux.c:367> Brick Daemon 2.4.3 started (pid: 543, daemonized: 1) 2021-09-20 13:30:18.918088 <I> <network.c:304> Added new client (N: 127.0.0.1:53614, T: plain-socket, H: 18/18, B: 0, P: 0, A: disabled) 2021-09-20 13:39:15.234342 <I> <network.c:304> Added new client (N: 127.0.0.1:53678, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) 2021-09-20 13:40:36.183747 <I> <client.c:252> Client (N: 127.0.0.1:53678, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) disconnected by peer 2021-09-20 13:40:37.240314 <I> <network.c:304> Added new client (N: 127.0.0.1:53700, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) 2021-09-20 13:40:42.227717 <I> <client.c:252> Client (N: 127.0.0.1:53700, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) disconnected by peer 2021-09-20 13:40:43.062705 <I> <network.c:304> Added new client (N: 127.0.0.1:53702, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) 2021-09-20 13:40:43.853351 <I> <client.c:252> Client (N: 127.0.0.1:53702, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) disconnected by peer 2021-09-20 13:40:44.597336 <I> <network.c:304> Added new client (N: 127.0.0.1:53704, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) 2021-09-20 13:40:45.367081 <I> <client.c:252> Client (N: 127.0.0.1:53704, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) disconnected by peer 2021-09-20 13:40:46.003491 <I> <network.c:304> Added new client (N: 127.0.0.1:53706, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) 2021-09-20 13:40:46.661200 <I> <client.c:252> Client (N: 127.0.0.1:53706, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) disconnected by peer 2021-09-20 13:40:47.536743 <I> <network.c:304> Added new client (N: 127.0.0.1:53710, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) 2021-09-20 13:40:48.196749 <I> <client.c:252> Client (N: 127.0.0.1:53710, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) disconnected by peer 2021-09-20 13:40:54.998926 <I> <signal.c:55> Received SIGTERM 2021-09-20 13:40:55.007573 <I> <main_linux.c:571> Brick Daemon 2.4.3 stopped 2021-09-20 13:40:58.554272 <I> <main_linux.c:367> Brick Daemon 2.4.3 started (pid: 534, daemonized: 1) 2021-09-20 13:40:58.660610 <I> <bricklet.c:270> Found supported HAT product_id 0x084e in device tree, using default HAT Brick config 2021-09-20 13:40:58.660728 <I> <bricklet.c:311> Found Bricklet port A (spidev: /dev/spidev0.0, driver: gpio, name: gpio23, num: 23) 2021-09-20 13:40:58.661002 <I> <bricklet_stack_linux.c:129> Using BCM2835 backend for Bricklets (Raspberry Pi detected) 2021-09-20 13:40:58.665155 <W> <bricklet_stack_linux_bcm2835.c:129> Raspberry Pi core frequency (core_freq: 500, core_freq_min: 200) is unstable, SPI throughput will be unstable too 2021-09-20 13:40:58.665256 <I> <bricklet_stack_linux_bcm2835.c:133> Using 500 MHz Raspberry Pi core frequency (core_freq: 500, core_freq_min: 200) for BCM2835 backend 2021-09-20 13:40:58.666350 <I> <bricklet.c:311> Found Bricklet port B (spidev: /dev/spidev0.0, driver: gpio, name: gpio22, num: 22) 2021-09-20 13:40:58.666683 <I> <bricklet.c:311> Found Bricklet port C (spidev: /dev/spidev0.0, driver: gpio, name: gpio25, num: 25) 2021-09-20 13:40:58.666957 <I> <bricklet.c:311> Found Bricklet port D (spidev: /dev/spidev0.0, driver: gpio, name: gpio26, num: 26) 2021-09-20 13:40:58.667342 <I> <bricklet.c:311> Found Bricklet port E (spidev: /dev/spidev0.0, driver: gpio, name: gpio27, num: 27) 2021-09-20 13:40:58.667650 <I> <bricklet.c:311> Found Bricklet port F (spidev: /dev/spidev0.0, driver: gpio, name: gpio24, num: 24) 2021-09-20 13:40:58.667950 <I> <bricklet.c:311> Found Bricklet port G (spidev: /dev/spidev0.0, driver: gpio, name: gpio7, num: 7) 2021-09-20 13:40:58.668207 <I> <bricklet.c:311> Found Bricklet port H (spidev: /dev/spidev0.0, driver: gpio, name: gpio6, num: 6) 2021-09-20 13:40:58.668484 <I> <bricklet.c:311> Found Bricklet port I (spidev: /dev/spidev0.0, driver: gpio, name: gpio5, num: 5) hwclock: Timed out waiting for time change. 2021-09-20 13:41:00.287786 <I> <bricklet.c:358> Updated system time from RTC time using '/sbin/hwclock --hctosys' 2021-09-20 13:41:04.858382 <I> <network.c:304> Added new client (N: 127.0.0.1:53792, T: plain-socket, H: 27/27, B: 0, P: 0, A: disabled) 2021-09-20 13:42:15.613951 <E> <bricklet_stack.c:478> Message checksum error (port: A, count: 1) 2021-09-20 13:42:22.832849 <E> <bricklet_stack.c:478> Message checksum error (port: A, count: 2) 2021-09-20 13:42:11.298809 <I> <main_linux.c:367> Brick Daemon 2.4.3 started (pid: 532, daemonized: 1) 2021-09-20 13:42:18.245951 <I> <network.c:304> Added new client (N: 127.0.0.1:45096, T: plain-socket, H: 18/18, B: 0, P: 0, A: disabled) Scheinbar wird der HAT Brick und das erste Bricklet gefunden. Gibt es ein Problem mit der core Frequenz? Quote Link to comment Share on other sites More sharing options...
photron Posted September 20, 2021 at 01:35 PM Share Posted September 20, 2021 at 01:35 PM Hast du am HAT Brick noch Bricklets angeschlossen, oder ist das HAT Brick alleine? Falls Bricklets angeschlossen sind, macht es dann einen Unterschied, wenn du diese absteckst? Welche Kernel Version läuft auf dem Raspberry Pi? Das kannst du mit folgenden Kommando abfragen: uname -a Brick Daemon kann auf zwei verschiedene Arten mit dem HAT Brick kommunizieren. Standardmäßig wird auf dem Raspberry Pi der BCM2835 Backend verwendet. Das kannst du an dieser Zeile sehen: 2021-09-20 13:40:58.661002 <I> <bricklet_stack_linux.c:129> Using BCM2835 backend for Bricklets (Raspberry Pi detected) Du kannst brickd aber zwingen den spidev Backend zu verwenden. Dazu musst du die Datei /etc/brickd.conf bearbeiten und folgende Zeile anhängen: bricklet.spi.driver = spidev Um die Änderung zu übernehmen musst du dann brickd neustarten, oder das ganze Raspberry Pi neustarten. Das Kommando für den brickd Neustart ist: sudo systemctl restart brickd Wenn die Änderung geklappt hat sollte folgende Zeile im Log stehen: Using spidev backend for Bricklets (forced by config) Macht es dann einen Unterschied, wenn du auf das spidev Backend wechselst? Quote Link to comment Share on other sites More sharing options...
R_Gerald Posted September 20, 2021 at 02:18 PM Author Share Posted September 20, 2021 at 02:18 PM Danke, jetzt kann läuft der Raspberry wenigsten auch mit der HAT Brick Kernel Linux raspberrypi 5.10.60-v7l+ #1449 SMP Wed Aug 25 15:00:44 BST 2021 armv7l GNU/Linux Nach einiger Zeit erscheint sogar der Brick und die Bricklets im brick viewer, jedoch scheint es ein Problem mit der Kommunikation zu geben. Sie logs im Anhang brickv_error_report_2021-09-20_16-13-53.txt brickd.log Quote Link to comment Share on other sites More sharing options...
photron Posted September 20, 2021 at 03:59 PM Share Posted September 20, 2021 at 03:59 PM Laut Log treten da massive Kommunikationsprobleme zwischen Raspberry Pi und HAT Brick auf. Wie kommst du auf Kernel 5.10.60? Wenn ich ein frisches Raspberry Pi OS Image mit dem Image Tool auf eine SD Karte dann bekomme ich Kernel 5.10.17. Hast du den Kernel mit rpi-update aktualisiert? Bei mir tritt das Problem nicht auf. Weder mit Kernel 5.10.17 noch mit 5.10.60. Hast du eine weitere SD Karte zur Hand auf der du ein frisches Raspberry Pi OS aufsetzen kannst? Oder hast du ein anderes Raspberry Pi zur Hand mit dem du testen kannst? Quote Link to comment Share on other sites More sharing options...
R_Gerald Posted September 21, 2021 at 06:19 AM Author Share Posted September 21, 2021 at 06:19 AM JA habe den Raspberry schon eine weile in Betrieb und hab dann ein Update gemacht. Muss mir noch eine SD Karte besorgen, 2. Raspberry hab ich nicht zur Hand. Schaut es eher nach einem SW oder HW Problem aus? Quote Link to comment Share on other sites More sharing options...
Backdraft007 Posted September 21, 2021 at 06:21 AM Share Posted September 21, 2021 at 06:21 AM Hast Du Bricklets am HAT angeschlossen? Wie sieht es aus, wenn keine Bricklets angeschlossen sind? Quote Link to comment Share on other sites More sharing options...
R_Gerald Posted September 21, 2021 at 06:52 AM Author Share Posted September 21, 2021 at 06:52 AM Hab nur den HAT auch versucht, macht aber keinen Unterschied. Bekomme morgen ein paar SD Karten und einen 2. Raspberry..... Quote Link to comment Share on other sites More sharing options...
photron Posted September 21, 2021 at 08:50 AM Share Posted September 21, 2021 at 08:50 AM 2 hours ago, R_Gerald said: Schaut es eher nach einem SW oder HW Problem aus? Kann beides sein. Daher die Fragen ob du mit frischer SD Karte oder anderem Raspberry Pi testen kannst. Es kann auch sein, dass der HAT Brick selbst einen Schaden hat. Hast du die /etc/brickd.conf Änderung auf spidev gemacht? Laut Log wird immer noch der BCM2835 Treiber verwendet. Quote Link to comment Share on other sites More sharing options...
R_Gerald Posted September 21, 2021 at 01:25 PM Author Share Posted September 21, 2021 at 01:25 PM Hab die config auf spidev geändert. Schaffe jetzt auch eine Kommunikation zum Brick und den Bricklets. Möglicherweise ist der Kühlkörper vom Raspberry ein wenig im Weg, hab ihn mal ein wenig isoliert vom HAT. Laut Health Monitor gibt es aber schon noch viele Checksum und Frame Erros. Morgen versuch ich das ganze nochmals auf einem anderen Raspberry PI. Wenn ich spidev wieder auskommentiere ist der Raspbarry wieder nicht mehr ansprechbar. Woran liegt das? Mein Ziel ist es eigentlich die Daten in die Cumulocity IoT Plattform zu übertragen. Haben den Cumulocity Agent bereits eingerichtet und auch bereits in der Plattform registriert. https://cumulocity.com/guides/device-tutorials/raspberry-pi-4/ Die Sensordaten der Child devices werden aber nicht übertragen es kommen diese Fehlermeldung am Raspberry PI Sep 21 15:10:31 raspberrypi root: 15:10:31.161 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 111 Sep 21 15:10:31 raspberrypi root: 15:10:31.195 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 111 Sep 21 15:10:31 raspberrypi root: 15:10:31.230 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 290 Sep 21 15:10:31 raspberrypi root: 15:10:31.274 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 297 Sep 21 15:10:31 raspberrypi root: 15:10:31.309 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 292 Sep 21 15:10:31 raspberrypi root: 15:10:31.345 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 292 Sep 21 15:10:31 raspberrypi root: 15:10:31.377 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 290 Sep 21 15:10:31 raspberrypi root: 15:10:31.409 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 292 Sep 21 15:10:31 raspberrypi root: 15:10:31.443 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 297 Sep 21 15:10:31 raspberrypi root: 15:10:31.477 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 290 Sep 21 15:10:31 raspberrypi root: 15:10:31.518 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 292 Sep 21 15:10:31 raspberrypi root: 15:10:31.559 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 297 Sep 21 15:10:31 raspberrypi root: 15:10:31.595 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 111 Sep 21 15:10:31 raspberrypi root: 15:10:31.630 [Callback-Processor] WARN c8y.tinkerforge.Discoverer - Unsuported device identifier: 111 Und in der Cumulocity Plattform sehe ich folgende Events Meine Ausprägung Liegt dies daran, dass spidev anstelle vom BCM2835 Treiber verwendt wird? Quote Link to comment Share on other sites More sharing options...
photron Posted September 21, 2021 at 03:32 PM Share Posted September 21, 2021 at 03:32 PM 1 hour ago, R_Gerald said: Wenn ich spidev wieder auskommentiere ist der Raspbarry wieder nicht mehr ansprechbar. Woran liegt das? Das ist die Frage hier! Wenn du in der Config nicht die spidev Zeile drin hast, dann verwendet Brick Daemon den BCM2835 Treiber um mit dem HAT Brick und den Bricklets zu kommunizieren. Wenn du die spidev Zeile drin hast, dann verwendet Brick Daemon stattdessen den spidev Treiber. Warum das jetzt einen Unterschied macht ist mir gerade unklar. Eigentlich ist der BCM2835 Treiber besser, da mit diesem der Durchsatz höher ist. Das ist alles mit Kernel 5.10.60, oder? Interessant wäre zu sehen ob das mit 5.10.17 besser wird. Es kann sein, dass eine Kernel Änderungen das Problem auslöst, muss aber nicht. 1 hour ago, R_Gerald said: Laut Health Monitor gibt es aber schon noch viele Checksum und Frame Erros. Bleiben die Fehlerzähler gleich, oder steigen die kontinuierlich? Im Health Monitor kannst du die Werte auch in einer Datei speichern. Mach das bitte mal und häng die Datei hier an. 1 hour ago, R_Gerald said: Die Sensordaten der Child devices werden aber nicht übertragen es kommen diese Fehlermeldung am Raspberry PI Wir pflegen den Tinkerforge Support in Cumulocity nicht, sondern das macht Cumulocity selbst. Cumulocity scheint einfach alle deine Bricks und Bricklets nicht zu unterstützen: Device Identifier 111 ist der HAT Brick Device Identifier 290 ist das Sound Pressure Level Bricklet Device Identifier 292 ist das Motion Detector Bricklet 2.0 Device Identifier 297 ist das Air Quality Bricklet Das hat also nichts mit dem HAT Brick Problem zu tun, sondern einfach damit, dass der Cumulocity Support für Tinkerforge unvollständig ist. Das ist hier auch nachzulesen: https://cumulocity.com/tinkerforge/ (in der Fussnote) https://cumulocity.com/guides/device-tutorials/tinkerforge/ Quote Link to comment Share on other sites More sharing options...
R_Gerald Posted September 23, 2021 at 10:06 AM Author Share Posted September 23, 2021 at 10:06 AM So nun hab ich das ganze nochmals mit einem neuen Raspberry Pi 4B versucht. Obwohl nach dem Update der Kernel wieder bei 5.10.60 war hat der Brick Daemon mit Brick Viewer und Standard settings ohne Probleme funktioniert. Danach hab ich wieder den Cumulocity agent installiert anfänglich haben sich beide Komponenten gut vertragen aber nach öfteren Start Stop vom Brick Daemon und Cumulocity agent, war der Raspberry mit HAT Brick nicht mehr ansprechbar, erst nach deinstallation des Brick Deamon konnte ich den Raspberry mit gestecktem HAT Brick wieder starten. Ist es auch möglich über Modbus TCP die Bricklets auszulesen? Quote Link to comment Share on other sites More sharing options...
photron Posted September 23, 2021 at 11:21 AM Share Posted September 23, 2021 at 11:21 AM Also ist das eine Wechselwirkung zwischen Cumulocity Agent und Brick Daemon? Wenn du also den Cumulocity Agent deinstallierst anstelle von Brick Daemon dann läuft es auch it HAT Brick? 1 hour ago, R_Gerald said: Ist es auch möglich über Modbus TCP die Bricklets auszulesen? Nein, dazu kannst du aber irgendeine Modbus TCP Bibliothek verwenden z.B. PyModbus. Für Modbus TCP brauchst du keine extra Hardware, da das einfach über die normale Netzwerkschnittstelle geht. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.