rtrbt

Moin,

Das klingt seltsam, ich sehe mir das am Montag mal beides an. (Dann aber gleich mit der fertigen 2.5-Version, die soll angeblich am Sonntag erscheinen). Vor Weihnachten gibt es dann auch noch eine neue Beta-Version der Bindings.

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?)

On 12/7/2019 at 12:43 PM, rasby said:

wie sieht es mit der Unterstützung für Temperature, Temperature 2.0, PTC, AirQuality und IO16-Bricklet aus?

Die werden alle unterstützt.

On 12/7/2019 at 12:43 PM, rasby said:

Unterstützt das One Wire Bricklet Plugin auch z.B. das automatische finden von DS18B20 Temperatur-Sensoren und bietet diese als Temperature-Channel an?

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,

On 11/29/2019 at 4:36 PM, linuxmail said:

hi,

sehr seltsam. In der tat. Ich habe jetzt mal ein Tar erzeugt. Da ist die komplette kern.log messages und nochmal die /ring_buf_dumpI drin. Es war auch der richtige Host, da der hinter mir steht. Ich musste allerdings ein wenig umbauen, da mein Rechner ein Laptop ist und der mitgenommen wird ... da wäre das mit dem Strom schwierig 🙂 Daher kann ich da nicht mehr direkt auf die serielle Konsole.

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.

On 11/29/2019 at 4:36 PM, linuxmail said:

Da sich das hier zu einem Chat entwickelt ...  sollen wir hier verbleiben, oder zu einem Github / Redmine /  Gitlab / ... oder was auch immer ihr verwendet  übergehen ? Mail geht natürlich auch (alternativ Matrix.org, wenn ihr das rein zufällig verwendet).

Ich würde das erstmal hier lassen, ist ja eventuell für die Nachwelt relevant.

1 hour ago, linuxmail said:

was ich nicht so verstehe ist, dass der RED ohne jegliches Update erheblich seltener ohne Netzwerk darsteht, als der mit allen Updates.

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.

Moin,

Ich habe das ganze hier reproduzieren können. Ich melde mich, wenn ich mehr weiß.

5 hours ago, linuxmail said:

manchmal passiert es, dass beim (USB) Strom ziehen und wieder reinstecken der RedBrick nicht "an" geht. Die  blaue  status LED bleibt aus. Erst beim wiederholten aus/einstecken geht der RedBrick wieder an. Die übrigen Bricks dagegen leuchten (blau).

Kannst du, wenn das Anstecken nichts tut, den RED-Brick mit dem Power-Knopf starten (Braucht so 2-3 Sekunden, der Knopf ist links neben der USB-Buchse) oder musst du dann das Kabel neu aus-/einstecken?

Also, if you only need an accurate heading and don't care for the other measurements of the IMU, you can use a Compass Bricklet. This Bricklet can measure the heading with a precision of ± 1 degree, but is more sensitive to magnetic field disturbances.

Danke, eine Frage noch: was machst du mit dem RED-Brick, wenn du das reproduzierst? Lässt du irgendwelche Software laufen oder einfach Idle + SSH oder sowas?

Mach mal, das schadet bestimmt nicht.

Moin,

Die Ausgaben sehen so aus, wie erwartet. Die Logs aus deinem Switch dürften zeitlich mit den PHY-Resets zusammenfallen.

Das Problem scheint zu sein, dass die Ethernet-Extension 14kb an Netzwerkdaten verschicken will, aber die aus irgendeinem Grund nicht hinbekommt. Nachdem das eine Weile nicht funktioniert hat, löst der Treiber den Reset aus um irgendwie wieder auf einen sinnvollen Zustand kommt. Ich versuche das hier mal nachzustellen und melde mich dann nochmal.

Gruß,
Erik

Moin,

Dein Problem scheint zu sein, dass der Ethernet-Chip seine Daten nicht senden kann. Das sollte nichts mit Spannungsproblemem, DHCP oder der Anzahl der Verbindungen zu tun haben.

Zum Debuggen bräuchte ich Informationen aus dem Kernel-Log, konkret die Ausgabe folgender Befehle auf dem Terminal:

dmesg | grep -C 5 "PHY RESET"

dmesg | grep ": socket("

dmesg | grep "socket_send(100000)"

Gruß,
Erik

Hi,

The data sheet of the IMU shows on page 15, that the heading error can be ±2.5 degree or more: "The heading accuracy depends on hardware and software. A fully calibrated sensor and ideal tilt compensation are assumed." (for ±2.5 degree). So your observed error of ±3 degree can be explained mostly by that. Also the sensor fuses the measurements of the magnetometer, gyroscope and accelerometer, which could increase the error a bit.

The sudden jump from 359 to 132 degree you've observed, could be explained with the calibration, that the sensor does continously: The sensor always recalibrates its measurements. If you call save calibration (or use the Brick Viewer for this), the current calibration is stored in flash, so that the brick has not start completely fresh again on start-up. Maybe the sensor was adapting to your environment, while your first test was running, generating the observed jump.

Ich habe mir die clearDisplay-Problematik nochmal angesehen. openHAB kommt anscheinend nicht damit zurecht, wenn zwei Actions von unterschiedlichen Devices den selben Namen haben, selbst wenn sie (was ich testweise mal gemacht habe) in unterschiedlichen Scopes liegen. Ich habe hier mal einen Bug-Report eingereicht. Interessanterweise tritt der Fehler nicht bei der neuen (experimentellen) Rule-Engine auf.

Moin,

Ich habe mir aus anderen Gründen das Problem mal angesehen, die Implementierung der getLedValues-Funktion auf dem Bricklet war kaputt. Mit Firmware-Version 2.0.3 (frisch veröffentlicht) sollte sich das Bricklet so verhalten, wie du es erwartest.