rtrbt

Moin, Sorry, beim LEDValueIndex hast du vollkommen recht, da habe ich den Bug für das LED Strip V2 gefixt und es damit für das alte Bricklet wieder kaputt gemacht. Das LED Strip V2 addressiert auf Farb-Ebene. Was klappte mit der Action nicht? Findet sich hier Es gab da mal die Überlegung, einen Simple-Mode direkt in die Firmware einzubauen, dann aber vermutlich nur für das neuere NFC-Bricklet oder einen eventuellen Nachfolger. (Der Flash ist schon recht voll, vorallem beim alten NFC-RFID). Deshalb würde ich da erstmal ungern eine openHAB-spezifische Lösung bauen. Du kannst übrigens anstelle der Xtend-Skripte auch die experimentelle Rule-Engine verwenden, mit der du in diversen "richtigen" Programmiersprachen skripten kannst.

Firmware: Industrial Dual Analog In 2.0 Bricklet 2.0.5 Fix callback generation limit of 500 voltage callbacks per second per channel Download: Industrial Dual Analog In 2.0

Firmware: Industrial Dual Analog In 2.0 Bricklet 2.0.5 Entferne Callback-Limit von 500 Voltage-Callbacks pro Sekunde pro Channel Download: Industrial Dual Analog In 2.0

Moin, Vorweg: get_adc_values gibt dir die Rohwerte des ADCs, die solltest du eigentlich nur benötigen, wenn du das Bricklet kalibrieren möchtest. Wenn du get_voltages benutzt erreichst du nur 500 Nachrichten pro Sekunde, weil 500 Nachrichten zum Bricklet geschickt werden (die Anfragen) und dann 500 Nachrichten wieder vom Bricklet zurück (die Antworten) Die ~1000 Nachrichten pro Sekunde sind die Limitierung, wie viel Durchsatz ein Master Brick an USB erreichen kann: Der Master Brick ist per USB 2.0 angebunden, was mit 1000Hz auf neue Nachrichten pollt. Daraus leitet sich dann auch die Tick-Rate der Firmware des Master Bricks ab, die auch bei 1000Hz liegt. Das hat mit den 976 Messwerten pro Sekunde des Bricklets keinen direkten Zusammenhang: Die bis zu 976 Messungen pro Sekunde macht der Chip, der auf dem Bricklet verbaut ist, das Bricklet selbst kann dann mit bis zu 1000 Nachrichten pro Sekunde die Messwerte kommunizieren. Das heißt dann auch, dass du, wenn du die Sample-Rate auf 1 Sample pro Sekunde setzt, das Callback aber auf einer Millisekunde (und value_has_to_change=false) lässt, du theoretisch 1000 Nachrichten pro Sekunde bekommen solltest, die dann aber nur eine Messwertänderung pro Sekunde beinhalten, du bekommst also sehr viele gleiche Nachrichten. Ich habe hier das ganze mal getestet und festgestellt, dass die Firmware einen Bug hat: Wenn man nur einen Channel verwendet, ist die Callback-Geschwindigkeit (nicht die Messrate!) auf 500 Nachrichten pro Sekunde limitiert. Teste bitte nochmal mit und ohne Isolator Bricklet mit der Firmware 2.0.5, die gerade veröffentlicht wurde. Da zwischen dem Bricklet und dem Programm auf dem Rechner einige Buffer liegen, die asynchron gepollt werden, kann es da zu unintuitiven Effekten kommen: Bei meinen Tests schaffe ich ohne Isolator Bricklet nur ~ 900 Nachrichten, mit Isolator aber 1000. Es kann auch helfen, wenn du den Master Brick an einen USB-3 Hub hängst, es gibt manche, die auch USB-2-Geräte mit mehr als 1000 Hz pollen. Falls du einen Raspberry Pi mit HAT zur Hand hast, könnte das auch helfen. Ich habe dir mal mein Testprogramm angehangen, das noch ein paar Tricks verwendet, damit die Kommunikation möglichst effizient läuft: Wenn du damit testen willst, musst du noch die UIDs austauschen, gegebenenfalls den Port am Master Brick und, wenn du mit Isolator testest, die Zeilen 22 bis 24 mit reinnehmen. Gruß, Erik main.rs

Hi, I agree, the documentation is a bit confusing there. I've changed this to For a Bricklet this is the UID of the Brick or Bricklet it is connected to. For a Brick it is the UID of the bottommost Brick in the stack. For the bottommost Brick in a stack it is "0". The change will soon be in the online documentation. The Rust (and Go) documentation in the code and on docs.rs will be updated with the next bindings release.

Moin, Beta 21 ist jetzt im Post oben. Bitte darauf achten, dass sie von den Java-Bindings (als Maven-Package, ist auch in der Zip enthalten) abhängen, die auch in das Addons-Verzeichnis gelegt werden müssen. Die nächsten Wochen werde ich an einem anderen Projekt arbeiten müssen, das etwas dringender geworden ist. Die Bindings nähern sich aber sowieso langsam einem "fertigen" Zustand. Ich würde deshalb die Entwicklung für die nächsten Wochen erstmal ruhen lassen, und nur nach und nach die deutsche Dokumentation schreiben. Dabei sehe ich mir nochmal die Modellierung aller Devices an, und verpasse ihr einen Feinschliff, insbesondere für die möglichst einfache Verwendung mit Channels, da kompliziertere Anwendungsfälle mit Actions abgebildet werden können. Zum Beispiel werde ich den LEDStrip Values Channel so umstellen, dass man mit einem ColorPicker-Item alle angeschlossenen LEDs konfigurieren kann. Nebenbei kümmere ich mich dann auch darum, wie die Bindings nach dem Ende der Betaphase zur Verfügung gestellt werden (Lies: ob sie in die openHAB-Distribution integriert werden). Was mir sehr helfen würde ist, wenn Ihr alle Bugs, die im Betrieb auftreten nochmal hier erwähnt, damit möglichst nichts übersehen wird. @matthiask Sorry für die späte Antwort, du hast da vollkommen recht. Teste bitte nochmal mit Beta 21, da ist der Fix drin. Da du einer der mir bisher bekannten Nutzer des LED-Strip Bricklets bist: würde es dir für deinen Anwendungsfall reichen, wenn du alle LEDs auf einmal mit einem Color-Item kontrollieren könntest, oder machst du kompliziertere Dinge? Hast du dir schon die Actions des Bricklets angesehen? Gruß und Frohe Ostern, Erik

Moin, Das unterstützt die Firmware bereits: Wenn du dein Relay nicht mit set_state sondern set_monoflop schaltest, hast du im Endeffekt einen Watchdog. Hier wird das genauer erklärt.

Moin André, Sind die Werte 0 und 1 Rohwerte, die das Bricklet zurück liefert oder hast du da schon durch 100 geteilt um Lux zu bekommen? Falls ja: Ist das Problem einfach, dass du keine float-Division machst, weshalb Rohwerte kleiner 100 eine 0 erzeugen? Ich habe mal in der Firmware nachgesehen, der zurückgegebene Wert wird auf 1 gesetzt, wenn bei der Berechnung etwas kleineres rauskommen sollte (siehe hier). Das heißt die 0 (als Rohwert) bedeutet wirklich, dass der Sensor saturiert ist (siehe hier). Das sind die einzigen beiden Stellen, an denen der Illuminance-Wert zugewiesen wird. Gruß, Erik

Moin, Die GUI wird in einem separaten Buffer gezeichnet. Die API des Bricklets hat zur Zeit keine Möglichkeit, den Buffer auszulesen. Ich setze mir mal auf die Liste, dafür eine Funktion einzubauen.

Moin, Beispiele sind eine interessante Frage, das ist nicht unbedingt bei jedem Device nötig, z.B. ein Temperatursensor funktioniert ja einfach so. Ich tendiere im Moment dazu, als Beispiel für jedes Bricklet nur das Grundgerüst, damit man die Actions benutzen kann zu generieren und zusätzlich die etwas komplizierteren Beispiele die teilweise ja hier im Thread schon gewachsen sind zu übernehmen. Das Remote Switch ist ein schwieriger Fall. Ich muss dem Doku-Generator noch beibringen, mit den speziellen Devices (Den Sockets, aber auch der Wetterstation usw.) umzugehen. Prinzipiell ist die Doku aber korrekt, du kannst mit den Actions direkt schalten ohne eigene Devices anzulegen. Das ist nur schwieriger weil du händisch dafür sorgen musst, dass immer nur ein Schaltvorgang gleichzeitig läuft. Bezüglich der REFRESHs: Das sollte eigentlich nicht mehr nötig sein, weil die Channel sich periodisch selbst aktualisieren. Hast du da noch Probleme bei irgendeinem Bricklet? Ich schreibe das trotzdem mal in die Doku, es gibt eventuell Anwendungsfälle, wo man das kontrollieren will, wann der Channel sich aktualisiert.

Moin, Es gibt jetzt einen ersten Prototypen der openHAB-Dokumentation. Erstmal nur auf Englisch und noch ohne die allgemeinen Dinge wie Installationsanleitung, Beispiele usw. Falls noch device-spezifische Dinge fehlen, oder euch etwas anderes auffällt, bitte melden. Gruß, Erik

Ich meinte damit nur die CPU-Last von Brick Daemon. Wenn ich mir deinen nmon-Screenshot ansehe, ist dein Problem anscheinend, dass der Arbeitsspeicher voll ist, der Java-Prozess lässt dann die ganze Zeit den Garbage Collector laufen, was die CPU-Last in die Höhe treibt. Du kannst etwas Arbeitsspeicher freiräumen, wenn mit dem Brick Viewer alle Services deaktivierst, die du nicht brauchst, z.B. die graphische Oberfläche, usw. Du kannst mit der available-Spalte von free -m nachsehen, wie viel Arbeitsspeicher wirklich frei ist. Linux benutzt freien Arbeitsspeicher gerne um Daten zu cachen, wirft die Caches aber weg, wenn der RAM knapp wird, damit Anwendungen ihn benutzen können. Deshalb ist die free-Spalte nicht so aussagekräftig.

Moin, Das ist normal, wenn du einen Stapel auf dem RED-Brick hast. Der RED-Brick hat nur einen CPU-Kern, der ungefähr so schnell ist wie ein Raspberry Pi 1.

Moin, Hast du das Problem mit einem Industrial Dual Analog In 1.0 oder 2.0? Ich habe es hier mit dem 2.0 getestet und es funktioniert so wie es soll. Hast du eventuell beide Channels auf das selbe Item registriert?

Moin, Die Limits, die hier angegeben sind, kannst du mit einem Master Brick über USB erreichen, andere Verbindungen wie Ethernet, Wifi oder auch die HATs schaffen laut meiner ad-hoc-Tests weniger.

Moin, Das Problem tritt anscheinend manchmal bei Perl auf. Teste mal das hier beschriebene Vorgehen mit den bei dir passenden Versionsnummern (also denen, die in /var/cache/apt/archives/ liegen). Gruß, Erik

Das müsste gehen, der IMU Brick gibt Heading (das ist der "Kompass-Wert"), Pitch (das wäre dein Schrägwinkel) und Roll (den nahe bei der Ausgangslage lassen, sonst wird das Fahren schwierig ) als Euler-Winkel aus, bei deinem Anwendungsfall solltest du theoretisch auch nicht in ein Gimbal Lock laufen. Durch die anderen Sensoren kann der Brick das korrigieren, wenn er gekippt wird. Gruß, Erik

Moin, Wo bekommst du die Werte angezeigt? Im Brick Viewer oder in einem Programm, das du geschrieben hast? Prinzipiell hast du, wenn du das Bricklet neigst das Problem, dass die Messung des Headings am genausten ist, wenn das Bricklet im richtigen Winkel steht. Das Problem wird hier erklärt.

Moin, Die Regenmessung setzt sich von alleine nicht zurück. Das liegt daran, dass das Outdoor Weather Bricklet nur die Daten der Wetterstation empfangen kann, aber nicht senden. Wenn du einen relativen Messwert willst, musst du da etwas mehr Arbeit investieren. Die mächtigste Variante wäre, die die Messwerte in eine Datenbank zu schreiben, dann kannst du auch Graphen erzeugen und sowas. Hier gibt es ein Tutorial dazu. Wenn du einen deutlich einfacheren Weg willst, der dann aber nicht ganz so schön ist, kannst du folgendes machen: In der PaperUI kannst du Items anlegen, die nicht direkt mit einem Thing zusammenhängen (in Configuration->Items). Da kannst du dir zwei Items anlegen, eins das den Regen-Messwert von Mitternacht speichert und eins für den relativen Messwert. Dann kannst du mit einer Rule wie dieser rule "Reset Rain Fall" when System started or Time is midnight or Channel "tinkerforge:brickletrgbledbutton:Enx:BrickletRGBLEDButtonButton" triggered PRESSED then Last_Rain_Fall.postUpdate(TinkerforgeOutdoorWeatherStationWS6147_RainFall.state) end rule "Calculate relative rain fall" when Item TinkerforgeOutdoorWeatherStationWS6147_LastChange changed then val cur = (TinkerforgeOutdoorWeatherStationWS6147_RainFall.state as QuantityType<Number>).doubleValue val last = (Last_Rain_Fall.state as QuantityType<Number>).doubleValue Relative_Rain_Fall.postUpdate(cur - last) end (Die musst du in eine Datei im conf/rules-Ordner deiner openHAB-Installation legen.) Das sind zwei Regeln: die erste aktualisiert das Last_Rain_Fall-Item mit dem Wert, den die Wetterstation um Mitternacht ausgibt. (Oder wenn ich den Knopf drücke der vor mir liegt, sowas ist immer hilfreich zum Testen von Regeln. Wenn du keinen Button oder sowas zur Hand hast lass " or Channel "tinkerforge:brickletrgbledbutton:Enx:BrickletRGBLEDButtonButton" triggered PRESSED" weg) Die zweite Regel aktualisiert den relativen Messwert (in Relative_Rain_Fall) immer wenn die Wetterstation neue Daten geschickt hat. Dafür musst du dir das zugehörige LastChange-Item der Station anlegen. Wenn du dir das übernehmen willst, musst du noch die Namen der ganzen Items anpassen. Diese Variante hat den Nachteil, dass du dann nur den Regen seit Mitternacht bekommst, nicht den Regen in den letzten 24 Stunden, aber das kann man noch beliebig aufbohren. Erik Edit: Ich habe den Trigger der ersten Regel noch um System started erweitert, ohne den zusätzlichen Trigger erzeugt die zweite Regel Fehler, wenn openHAB neu gestartet wird, weil Last_Rain_Fall noch keinen Wert hat.

Moin Andreas, Item.sendCommand("ON") sollte funktionieren.

Moin, Die Doku sagt, dass du set_value ein value vom Typ [bool, ...] der Länge: 4 mitgeben musst. Das heißt, dass value eine Liste ist. So sollte es funktionieren: io.set_value([False, False, True, True])

Moin, Grundlegend gilt: Du kannst nicht zwei Stapel direkt mit Ethernet-Extensions verbinden, ohne ein Netzwerk dazwischen. Das geht nur mit RS485-Extensions. Du kannst nur zwei Stapel mit jeweils einer Extension an ein Netzwerk anschließen, die bekommen dann aber separate IPs und du musst sie getrennt voneinander kontrollieren. Die einzige Variante, wie das funktionieren würde ist, wenn du in einem Stapel einen RED-Brick hast und dann mit einem Crossover-Kabel den zweiten Stack anbindest.

Du musst die Bitmap byte-weise befüllen: Ein Pixel im Thermal-Bild ist nicht ein Bit sondern ein Byte. Ob du den Wert dann als cold/nichts/hot betrachtest hängt von deiner Farbpalette ab. Im Brick Viewer sind es 0-32 -> cold, 33 -> 222 -> schwarz, 223-255 -> hot.

Wenn du das Bild, was dir GetTemperatureImage zurückgibt nicht in einer Variable zwischenspeicherst, wird bei jeder Pixelabfrage mit .GetTemperatureImage(x) das ganze Bild neu abgerufen. Das Bricklet muss dann für jeden Pixel das ganze Bild schicken, es schafft aber nur ungefähr 4 Bilder pro Sekunde, deshalb dauert das dann 1200 Sekunden pro Bild. Du kannst mal folgendes versuchen: Dim img as Byte() = ti.GetHighContrastImage() und dann immer mit img(x) die Pixel lesen. Der Callback-Ansatz ist schneller, weil das Bricklet dann von sich aus Daten schicken darf. Damit sollten bis zu 9 Bilder pro Sekunde möglich sein. Es gibt hier ein Beispiel. Durch den SetImageTransferConfig wird dem Bricklet mitgeteilt, dass es Callbacks schicken darf. Die Zeile AddHandler ti.HighContrastImageCallback, AddressOf HighContrastImageCB registriert den Sub HighContrastImageCB als die Funktion die (automatisch) ausgeführt werden soll, wenn ein neues Bild ankommt. Du kannst dann in dem Sub (nach dem "image is an array of ..." Kommentar) das Bild aus dem image-Parameter auslesen und in die PictureBox schreiben.

Fast alle. Falls du noch alte Bricklets mit dem flachen 10-Pol-Stecker hast: die gehen nicht. Wir verkaufen noch Restposten an 10-Pol-Bricklets (z.B. das Tilt-Bricklet), im Shop steht dann aber jeweils, was der 7-polige Ersatz ist (in diesem Fall das Accelerometer 2.0).