rtrbt

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ß. 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.

Moin, Gut, dass sich das WLAN-Problem behoben hat. Ist auch für mich hilfreich zu wissen, was die Ursache war, der nächste User mit dem Problem kommt bestimmt. Bezüglich der clearDisplay-Action bin ich immer noch nicht schlauer. Ich habe mal eine neue Installation mit Milestone 5 getestet, kurz geflucht, weil die Bindings nicht mehr kompilieren wollten und den Fehler gefixt (das landet in der nächsten Beta, damit die Bindings mit Milestone 5 funktionieren). Nachdem ich dann die ganzen IDs angepasst habe, funktioniert deine Rule, auch mit clearDisplay(). Danach habe ich openHAB neu gestartet und habe jetzt den selben Fehler wie du. Das ist anscheinend nicht deterministisch kaputt.

Moin, getestete Actions LCD128x64: lcdActions.clearDisplay() KO erzeugt einen Fehler im Log Das ist echt verwirrend. Die Fehlermeldung sollte nur ausgegeben werden, wenn die Actions-Klasse mit einer falschen Instanz aufgerufen wird. Das kannst du (meines Wissens) in den Regeln aber nicht erzeugen, ich hatte diese Meldung bei mir nur wegen dem Caching-Problem immer mal gesehen. Das seltsamste daran ist, dass eine LCD20x4Actions-Instanz erwartet wurde, anstelle von einer LCD128x64Actions. Ich habe das bei mir getestet und es funktioniert problemlos. Welche openHAB-Version hast du genau laufen? Dann würde ich das nochmal mit genau deinem Setup zu testen. Du kannst natürlich übergangsweise den clearDisplay-Channel benutzen. (Der nimmt einen StringType, der Wert ist egal, du kannst ihn also mit [item].sendCommand("Blah")) Da musst du aber aufpassen, wenn du Channel- mit Action-Verwendung mischt: Das sendCommand ist asynchron, wenn du direkt danach auf das LCD zeichnest, ist das schneller als das clear-Command, dann wird das danach gezeichnete auch gelöscht. wie wird diese Action benutzt ? Ich hatte keine Reaktion am Display, erwartet hätte ich einen Text Schriftgröße 2x32 , Schriftfarbe schwarz. Muss ich ähnlich wie beim e-Paper noch eine weitere Actions ausführen ? Nein, das sollte so funktionieren. Ich habe das auch gerade mal hier ausprobiert, da ist mir aufgefallen, dass du da statt normalen Anführungszeichen (denen hier), spezielle Unicode-Zeichen für die linken Anführungszeichen hast (diese hier). Macht dein Texteditor da Mist? Hm, das funktioniert bei mir. Teste mal dieses Minimalbeispiel: rule "startrule" when System started then var lcdActions = getActions("tinkerforge", "tinkerforge:lcd128x64:8e8df7e6:HQ6") lcdActions.clearDisplay() lcdActions.removeAllGUI() lcdActions.setGUITabConfiguration(3, false) lcdActions.setGUITabText(0, "Tab A") lcdActions.setGUITabText(1, "Tab B") lcdActions.setGUITabText(2, "Tab C") end und sieh mal nach ob du mit log:tail dann Zeilen wie diese hier siehst, wenn du das Item angelegt hast: 09:58:58.783 [INFO ] [smarthome.event.ItemStateChangedEvent] - HQ6_SelectedTab changed from 1 to 2 Nein, der Wert ist immer in Pixeln. Das musst du dir dann hinterher zurecht skalieren, z.B mit (ungetestet!) Math.round(([item].state as DecimalType) / 52.0 * 10) Dazu hätte ich folgende Fragen: Wie sieht dein Aufbau genau aus? Also wo läuft openHAB? (auf einem Raspberry oder so?), was hast du an der WIFI-Extension? usw. Was steht genau im openHAB-Log? Häng am besten mal die ganze Datei an Steht etwas brauchbares im Log der Fritzbox? Das der Rest funktioniert freut mich schonmal. Nochmal danke dafür, dass du so rigoros testest Gruß, Erik

Bei der E-Paper-Regel fehlt noch ein draw()-Aufruf, so funktioniert es: val ePaper = getActions("tinkerforge", "tinkerforge:epaper296x128:8e8df7e6:Jn6") ePaper.fillDisplay(0) ePaper.drawText(0,0,9,1,0,"test") ePaper.draw() Das ist im Moment ungünstig dokumentiert, aber auch draw(Text/Box/Line) und fillDisplay schreiben nur in den Buffer, damit tatsächlich auf das Display gezeichnet wird muss immer draw() aufgerufen werden. Die Doku passe ich nachher mal an. Die LCD/IO16-Regel war etwas verwirrender, nachdem ich da mal rumgesucht habe, bin ich über diesen Post gestolpert. Da sieht man, dass [item].state dir eine Instanz von State gibt. Wenn die nicht in einen Zahltyp gecastet wird, klappen keine Vergleiche mit Zahlen. So funktioniert es bei mir: LCD128x64_text.sendCommand("1,0,fl-P0-in-G7y-" + H5r_EdgeCountPin0A0.state + "-") val ioActions = getActions("tinkerforge", "tinkerforge:io16v2:8e8df7e6:H5r") H5r_EdgeCountPin0A0.sendCommand(REFRESH) if ((H5r_EdgeCountPin0A0.state as Number).intValue > 10) { if(null == ioActions) { logInfo("actions", "Actions not found, for io4v2") } else { logInfo("actions", "Actions found, for io4v2") ioActions.getEdgeCount(0, true) } } LCD128x64_text.sendCommand("2,0,fl-P0-in-G7y-" + H5r_EdgeCountPin0A0.state + "-") So wie die Regel da steht, hat sie aber noch ein anderes Problem: Der REFRESH ist asynchron, das heißt, du siehst bei den beiden Ausgaben immer den selben Wert, weil der aktualisierte noch nicht da ist, wenn das zweite LCD128x64_text.sendCommand passiert. Alternativ kannst du folgendes machen, dann verhält es sich eher so, wie man es erwartet: LCD128x64_text.sendCommand("1,0,fl-P0-in-G7y-" + H5r_EdgeCountPin0A0.state + "-") val ioActions = getActions("tinkerforge", "tinkerforge:io16v2:8e8df7e6:H5r") if(ioActions === null) { logInfo("actions", "Actions not found, for io4v2") return } val currentEdgeCount = ioActions.getEdgeCount(0, false).get("count") as int if (currentEdgeCount > 10) { val currentEdgeCount = ioActions.getEdgeCount(0, true).get("count") as int } LCD128x64_text.sendCommand("2,0,fl-P0-in-G7y-" + currentEdgeCount + "-") H5r_EdgeCountPin0A0.sendCommand(REFRESH) Da sieht man auch gut, warum ich noch auf meiner TODO-Liste stehen habe, für Actions die nur einen Wert zurückgeben, den direkt rauszuführen und nicht über den Map<String, Object>-Ansatz zu gehen. Dann fällt das ganze ".get("count") as int" weg.

Hm das war ungünstig formuliert. Mit aktualisieren meinte ich, die JAR im Addons-Verzeichnis mit der neuen zu überschreiben. Also was ich mache ist (während openHAB läuft): Die JAR durch die neue ersetzen Warten bis im Log (log:tail) die Reinitialisierung durch ist. Das dauert typischerweise so 20 Sekunden. (Ich habe eine Regel, die eine LED auf Grün setzt wenn System started triggert, das ist alternativ auch ein guter Indikator) openHAB neustarten, wieder auf die grüne LED warten Das hilft typischerweise, ist aber etwas Cargo-Kultesk. Da die anderen Actions bei dir aber funktionieren, vermute ich, dass du nicht das Cachingproblem hast. Das ist auch so. Was ich meinte ist, dass du in deiner ursprünglichen Regel die Action mit false aufgerufen hast, was dir den aktuellen Wert gibt, mit dem hast du dann aber nichts gemacht, deshalb hast du keine Änderung gesehen. Es gibt da 4 sinnvolle Varianten was du in einer Rule machen kannst: ioActions.getEdgeCount(0, true): Das setzt den Zähler zurück, den aktuellen Wert verlierst du dabei. val x = ioActions.getEdgeCount(0, true): Das setzt den Zähler zurück, den alten Wert hast du dann in x und kannst irgendwas damit anfangen. val x = ioActions.getEdgeCount(0, true): Das setzt den Zähler nicht zurück, den alten Wert hast du dann in x und kannst irgendwas damit anfangen. Pin0IO4V2Count.sendCommand(REFRESH): Das aktualisiert den Zähler in openHAB, du hast aber nicht den Wert sofort zur Hand. Damit kannst du aber natürlich eine separate Regel triggern, die auf den Channel-Wert reagiert. Mit ioActions.getEdgeCount(0, true) fragst du nur den Wert ab und verlierst ihn dann, der Zähler wird aber nicht zurückgesetzt, deshalb passiert dann nichts. Perspektivisch kannst du dir das ganze Refreshen aber sparen, dass muss ich sowieso für Werte, die sich nicht automatisch aktualisieren, allgemein lösen, damit wird der Edge Counter dann auch erschlagen. Die Bearbeiten-Funktion des Forums war tatsächlich seltsam, die Standardkonfiguration ist wohl, dass man nur 5 Minuten lang den letzten Post bearbeiten darf. Das habe ich mal geändert. Die LCD/E-Paper-Regeln teste ich mal und melde mich nochmal, eigentlich sehen die funktional aus. Edit: Bei den val x = ioActions.getEdgeCount()-Geschichten muss noch .get("count") as int hinten dran, siehe den nächsten Post

Moin, Das klingt, als ob die Kamera etwas aus ihrem Sockel gerutscht ist. Hilft es, wenn du die Kamera (vorsichtig) wieder in den Sockel drückst?

Moin, Benutzt du die Beta-Version der offiziellen Bindings aus diesem Thread? Dann musst du in der PaperUI von Hand in entweder der Inbox oder Configuration->Things einen Brick Daemon hinzufügen. Die Adresse ist localhost, wenn du openHAB auf dem Raspberry Pi laufen lässt, ansonsten dessen IP-Adresse oder Hostname. Wenn du die von Theo geschriebenen Bindings benutzt, sollte das ähnlich funktionieren. Da müsstest du notfalls mal hier nachlesen oder nachfragen. Gruß, Erik

Moin, Die älteren Bricklets werden unterstützt, nur die Remote Switches fehlen noch (sind aber schon implementiert, kommen mit der nächsten Beta). Das kann ich noch nicht versprechen. Auf der TODO-Liste steht noch, rauszufinden wie ich den Code dafür umbauen müsste Eher nicht. Den AccessPoint-Modus kann man nur ausschalten, indem die ganze Wifi-Konfiguration geschrieben wird, das kostet aber wieder EEPROM-Schreibzyklen, deshalb habe ich das in openHAB nicht eingebaut. Extra API dafür einbauen ist auch nicht sinnvoll, weil man sich dann einen Haufen Probleme für andere Anwendungsfälle einhandelt. Die erste Fehlermeldung bekomme ich auch, das scheint aber nichts relevantes zu sein, die Rules funktionieren trotzdem. Die zweite ist wichtiger, openHAB scheint, wenn man die Bindings-JAR aktualisiert, Teile davon in irgendeinen Cache zu laden, der für die RuleEngine nicht korrekt bereinigt wird, nicht mal wenn openHAB neugestartet wird. Was bei mir zuverlässig hilft ist, die Bindings zu aktualisieren, während openHAB läuft und mit log:tail die Ausgabe zu verfolgen. Nach ~ 20 Sekunden tut sich im Log einiges, weil er die Bindings neugeladen hat, wenn du danach openHAB neustartest, läd er nur die neuen Bindings, danach sollte es funktionieren. Die sieht soweit korrekt aus. Ich gehe mal davon aus, dass das auf das selbe Problem wie oben zurückzuführen ist. So wie du die Action verwendest, fragst du den Edge Counter ab, aber das Ergebnis wird dann verworfen. Wenn du den Wert von openHAB aktualisieren willst, kannst du in der Rule [itemname].sendCommand(REFRESH) aufrufen, wobei [itemname] das EdgeCount-Item ist. Intern ruft das dann auch getEdgeCount(0, false) auf, schreibt das Ergebnis aber in das Item. Stimmt das ist hier egal. Da war ich nur verwirrt, weil ich davor irgendeine andere Sprache benutzt habe. Kein Problem, ist ja freiwillig Habe ich mal weitergegeben.

Ah ja, das funktioniert so nicht. Du kannst den Channel umkonfigurieren, sodass du bei jedem Refresh resettest, dann bekommst du immer relative Werte. Alternativ kannst du es so lassen und wenn du resetten willst in einer Rule val ioActions = getActions("tinkerforge", "tinkerforge:io16v2:f80007d9:H4y") ioActions.getEdgeCount(0, true) aufrufen.

Am IO16 2.0 habe ich seit 16.09. nichts geändert, nur die Actions hinzugefügt. Was für eine Warnung bekommst du denn?

Beta 13 ist jetzt im Post oben. Der Generator kann jetzt Actions, das heißt, dass alle Geräte in Rules verwendet werden können. Genaueres steht im Readme und der Doku.

Moin, Einen Stack kannst Du nur entweder über USB oder Ethernet oder Wifi anschließen. Du kannst aber mit openHAB mehrere Stacks kontrollieren, indem Du mehrere Brick Daemons hinzufügst. Unterstützung für das E-Paper habe ich gestern eingebaut, kommt mit der nächsten Beta.

Moin, Es gibt im Brick Viewer noch keine explizite Rust-Unterstützung (das steht auf einer der zahlreichen TODO-Listen ), du kannst dein Binary aber als C/C++-Programm hochladen. Wenn du dann in Schritt 3 nicht den "Compile from Source"-Haken setzt, versucht der Brick Viewer nicht zu kompilieren, sondern nimmt das Binary so wie es ist.