R_Gerald
-
Gesamte Inhalte
6 -
Benutzer seit
-
Letzter Besuch
Posts erstellt von R_Gerald
-
-
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?
-
Hab nur den HAT auch versucht, macht aber keinen Unterschied. Bekomme morgen ein paar SD Karten und einen 2. Raspberry.....
-
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?
-
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
-
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?
Raspberry Pi 4 hängt wenn Brick Deamon läuft und HAT Brick ist gesteckt
in Anfängerfragen und FAQ
Geschrieben
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?