rtrbt

Hm, du hast da noch einen alten Kernel laufen, das sehe ich an dieser Meldung: fc-r02-sensor kernel: ring_buf_dump: f->f_op->write_iter (das ist der Debug-Code für das andere Problem, der ist nicht mehr drin) Du kannst dir mit uname -v die Zeit ausgeben lassen, zu der der Kernel kompiliert wurde. Das ist beim richtigen #10 Tue Dec 10 12:27:26 CET 2019 Hast du vielleicht die Pakete vertauscht?

Moin, Das sieht nach einem neuen Problem oder zumindest einer neuen Ausprägung aus. Ich habe dir mal wieder einen Kernel mit Debug-Ausgaben angehangen, wenn du das mit dem reproduzieren kannst, schick nochmal das ganze Kernel-Log. (Der interessante Teil beginnt dann mit dem Packet Size Error und endet mit "Dump done.") Hier her senden würde vermutlich nicht viel helfen, den Fehler habe ich so auch noch nicht gesehen, da vermute ich mal, dass die Umgebung mit reinspielt. linux-image-4_13.0-red-brick-1_4_13.0-red-brick-1_armhf.deb

Behebt sich das Problem, wenn du den Stack, an dem das Outdoor Weather Bricklet angeschlossen ist, neu startest? (Also Strom weg und Strom wieder dran) Das Bricklet merkt sich einmal gesehene Stations-IDs, seit Firmware Version 2.0.2 (prüfe übrigens mal, ob du die aktuelle Firmware hast) werden Stations-IDs, wenn von ihnen 12 Stunden lang keine Daten empfangen wurden, wieder gelöscht.

Moin, Kannst du wirklich keine Things löschen, oder erscheinen sie nur nach dem Löschen wieder (nach ein paar Minuten)? Das läge dann daran, dass die Bindings alle 10 Minuten nach angeschlossenen Bricks und Bricklets suchen. Dabei landen auch gelöschte Things wieder in der Inbox. Ausblenden ist da der richtige Weg. Dass du aber die Wetterstation in der Inbox hast, obwohl sie schon als Thing hinzugefügt ist, ist aber definitiv kaputt. Weißt du, was du gemacht hast, um die Inboxeinträge zu erzeugen? (openHAB-Updates oder oft in der Inbox löschen und suchen oder sowas?)

Die werden alle unterstützt. Nein, das musst du von Hand bauen: Das Java-Beispiel hier sollte relativ gut in eine Rule konvertierbar sein. Wenn das automatisch funktionieren soll, könntest du eine Rule bauen, die periodisch searchBus ausführt und mit der REST API von openHAB Items anlegt. Das wird aber relativ viel Aufwand, deshalb würde ich eher statisch Items für die Temperatursensoren anlegen und mit einer Rule mit Werten befüllen.

Moin, Im aktuellen Image ist openHAB 2.4 vorinstalliert, aber das hat bei meinem spontanen Test nicht funktioniert, bis ich auf der Konsole einmal sudo apt remove openhab2 sudo apt install openhab2 ausgeführt habe. Da ist scheinbar irgendwas kaputt. Wenn von 2.5 die finale Version raus ist, sollte man die auch direkt installieren können, der RED-Brick benutzt das normale openHAB-Debian-Repository.

Du schreibst, dass die SSID gleich ist. Meinst du damit den nur Anzeigenamen oder auch die BSSID? Die Extension findet das Netz vermutlich anhand der BSSID, deshalb kann es helfen, wenn du die Extension einfach nochmal neu konfigurierst. Alternativ kann es sein, dass die Extension Probleme mit der Implementierung des n-Standards der FritzBox hat. Neuere FritzBoxen deaktivieren die älteren g- und b-Standards, die mit der Extension verlässlicher laufen. Hier steht, wie man die älteren Standards aktivieren kann.

Was sagt das Kernel-Log? Und steht im Log von deinem Switch was hilfreiches? Edit: Was mir noch einfiel: Hast du die Probleme jetzt nur noch mit einem der RED-Bricks oder mit beiden?

Moin, Mit alle LEDs leuchten meinst du die blaue an allen Bricks (auch dem RED-Brick) und am RED-Brick zusätzlich noch die rote (aber nicht die grüne) und das ganze steht dann so? Dann hängt der RED-Brick laut Doku daran, den Bootloader zu laden. Bei einem Kontaktproblem mit der SD-Karte ergibt das Sinn: Die rote LED wird vom Bootloader (der auf der SD-Karte ist) abgeschaltet.

Moin, Teste mal mit dem (neuen) RED Brick Image 1.15. Ich quäle den Aufbau hier seit einiger Zeit mit iperf und bisher funktioniert es.

Moin, Hm im Log sind keine hilfreichen Aussagen drin, die ring_buf_dumpI ist übrigens nur die, die zum Systemstart angelegt wird, damit teste ich nur ob das Dateien schreiben aus dem Kernelmodul klappt. Ich würde das erstmal hier lassen, ist ja eventuell für die Nachwelt relevant. Mit den Updates meinst du über apt oder den Kernel den ich dir gegeben habe? Die beiden RED-Bricks hier haben das Wochenende mit dem modifizierten Kernel übrigens gut überstanden, d.h. eventuell hast du noch ein zusätzliches Problem.

Hm, das ist seltsam, im Log sehe ich nur, wie 13:15 der neue Kernel startet, danach kommt nichts mehr. War das eventuell ein anderes Problem? Was macht der zweite RED-Brick?

Du meinst, 2-3 Stunden bis die Netzwerkverbindung wieder weg war? Was sagt das Kernel-Log dazu? (dmesg oder /var/log/messages)

Moin, Ich bin dem ganzen in den letzten Tagen mal nachgegangen. Du kannst mal den angehangenen Kernel testen, der im Modul für die Ethernet-Extension zwei Änderungen hat: Falls das Problem nochmal auftritt (und direkt zum Start einmal), werden im Wurzelverzeichnis ring_buf_dump-Dateien angelegt, die jeweils die letzten 4 Pakete, die gesendet wurden enthalten. (Das hilft mir beim Debuggen). Zweitens habe ich einen möglichen Fix für das Problem (siehe unten) gefunden, deshalb kannst du das mal testen. Ich lasse hier auch zwei RED-Bricks über das Wochenende laufen, bisher haben sie 18 Stunden ausgehalten. Um den Kernel zu installieren musst du das angehangene Paket auf den RED-Brick schieben (z.b. mit scp), dann den alten Kernel mit sudo apt purge linux-image-4.13.0-red-brick-1 deinstallieren und den neuen Kernel mit sudo dpkg -i linux-image-4.13.0-red-brick-1_4.13.0-red-brick-1_armhf.deb installieren und den RED-Brick neustarten. Ob es geklappt hat siehst du daran, dass dann nach dem Neustart im Wurzelverzeichnis eine Datei namens ring_buf_dumpI existieren sollte. Die hässlichen Details: Der Ethernet-Chip hat einen Sende-/Empfangsbuffer von jeweils 16384 Byte, die man auf bis zu 8 Sockets verteilen kann. Standardeinstellung sind 2048 Byte pro Socket. Der Treiber konfiguriert das auf 16384 Byte für den ersten Socket und 0 für alle anderen um, da nicht die Sockets des Chips verwendet werden, sondern der Kernel n Sockets in Software auf den ersten Socket in Hardware multiplext. Der Chip scheint aber nach einer Weile die Konfiguration zu vergessen, und setzt sie wieder auf 8 * 2048 Byte. Der Treiber wartet dann endlos, bis die 16384 Byte des ersten Sockets wieder freiwerden, bevor er ein Paket als verschickt interpretiert, was dann aber nie passieren kann (das erzeugt dann die Ausgabeflut im Kernel-Log). Ich hatte erst getestet, in dem Fall die Konfiguration wieder umzustellen, aber dann hing der Chip komplett. Stattdessen lasse ich es jetzt gleich zu Anfang auf 8 * 2048 Byte, die maximale MTU ist sowieso auf ~1500 Byte hardgecodet, nur beim Empfangen hätte sich eventuell mehr gelohnt, das muss ich nochmal in Ruhe testen. linux-image-4_13.0-red-brick-1_4_13.0-red-brick-1_armhf.deb

As a last resort with the IMU Brick, you could try the fusion mode without magnetometer: Call set sensor fusion mode with the constant 2 (as documented for example here). This requires at least firmware 2.0.6. Other possibilities depend on your exact use-case. If you want to get a useful heading in a moving vehicle, you could for example try to use a GPS 2.0 Bricklet.