rtrbt

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

Moin, Das geht derzeit nicht out-of-the-box, es ist aber geplant in die Richtung künftig etwas zu entwickeln.

Moin, Du wirst vermutlich nicht darum herum kommen, das Bild pixelweise zu bauen, du kannst aber, damit es schneller läuft (Falls die Performance ein Problem sein sollte) mit Bitmap.LockBits arbeiten. Die Hot-Cold-Palette im Brick Viewer ist recht simpel aufgebaut: Alle Werte kleiner als 33 sind Cold (also RGB 0, 0, 255), alle über 223 heiß (also RGB 255, 0, 0).

Hi, Yes, to get the rain per time frame, you have to calculate it yourself. Unfortunately there is no return channel from the Bricklet to the weather station so you can't reset it's rain counter.

Moin, Versuche mal set_led_state, wie hier beschrieben: db.set_led_state(BrickletDualButtonV2.LED_STATE_OFF, BrickletDualButtonV2.LED_STATE_ON) Bei den Konstantennamen musst du darauf achten, die vom BrickletDualButtonV2 zu benutzen, nicht die vom BrickletDualButton.

So, Beta 20 ist im Post oben. Der Bug mit der IO-16, die seltsame Konfigurationsdarstellung usw. sollten gefixt sein.

Moin, Ja, da ist beim einen neuen Tab aufmachen das von Arbeit trainierte Muskelgedächtnis mit mir durchgegangen Das habe ich mir gerade mal angesehen, da gab es noch einen Konfigurationsfehler, ist behoben, kommt in die nächste Beta. Der seltsamen Anzeige der Konfiguration muss ich mal noch nachgehen, das konnte ich hier gerade reproduzieren. Die Meldungen nicht, nur wann ich einen Daemon als offline betrachte. Das sollte aber nicht die Nachrichten verschlucken, dass er wieder online geht. Sehe ich mir mal an. Frage dazu: Hast du, wenn du die "changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE"-Meldungen siehst davor die Ausgabe "Bridge of [UID] went online"? (Wenn du das DEBUG-Log an hast) in Deinem Beispiel bedeuten. Das ist openHAB-Magie: Wenn man als Trigger auf den geänderten Zustand eines Items wartet, dann ist newState eine implizit definierte Variable, die man einfach benutzen kann. Das ist hier dokumentiert. Du kannst stattdessen auch [Itemname].state verwenden, dann sollte es funktionieren. sind für mich schon fast „grosses JAVA Kino“ 😉 Da benutze ich die Java-8-Streams. tagID ist eine Liste von Integer (eigentlich von Bytes, aber Java kann keine vorzeichenlosen Bytes), String.join klebt eine Liste von Strings mit dem ersten Parameter als Trenner (hier einfach ein Leerzeichen) zusammen. Der zweite Parameter ist die Umwandlung von der Integer-Liste in eine Liste von Strings, die jeweils 0x und dann zwei Hexadezimalziffern sind. Das hätte man auch als Schleife schreiben können, aber da die Rules so schlecht im Herleiten von Typen für Variablen (für Schleifenzähler usw) sind, deshalb die ganzen Casts, wie auch das "as List<Integer>", sonst versteht openHAB nicht, welchen Typ tagID hat, habe ich da lieber einen Stream genommen. Die sollten alle funktionieren. a) Wird unterstützt werden, da sind wir aber noch in der Prototypenphase. b) Die sollte es bald wieder geben, sind schon produziert. Das habe ich selbst noch nicht probiert, sollte aber eigentlich funktionieren. Wenn ich die Dokumentation überarbeite, schreibe ich eventuell eine Anleitung. Hm, stimmt, das behebe ich mal. Danke für das Feedback! Erik

Moin, Du läufst da gerade in diesen Bug. Wenn du openHAB neustartest, nachdem du das Binding aktualisiert und eine Weile gewartet hast, damit openHAB die neue Version einmal geladen hat, sollte das Problem nicht mehr auftreten.

Moin, Beta 19 ist jetzt im Post oben. Größtes neues Feature ist, dass die bisher fehlenden Bricklets jetzt auch unterstützt werden. Die seriellen Schnittstellen und CAN-Bricklets haben jeweils einen Trigger-Channel, der benachrichtigt, dass neue Daten vorhanden sind, die dann mit einer Action abgeholt werden können. Das RS485-Bricklet kann außerdem als Modbus Master verwendet werden, dabei müssen im Gegensatz zur Java-API keine Callbacks benutzt werden, die Read/Write-Funktionen blockieren, bis ein Ergebnis vorhanden ist. Hier eine Beispiel-Rule dazu, die diesen Modbus-Stromzähler ausliest und die Werte auf einem LCD128x64 anzeigt. import java.util.ArrayList val readValue = [ Integer addr | val rs = getActions("tinkerforge", "tinkerforge:brickletrs485:RSS") val result = rs.brickletRS485ModbusMasterReadInputRegisters(1, addr, 2) val exceptionCode = result.get("exceptionCode") as int if (exceptionCode != 0) { return -1 } val inputRegisters = result.get("inputRegisters") as int[] var upper = inputRegisters.get(0) as int val lower = inputRegisters.get(1) as int upper = upper << 16 upper = upper + lower return Float.intBitsToFloat(upper) ] rule "Show Power" when Time cron "0/5 * * * * ?" then val lcd = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HP7") val names = newArrayList('Total ', 'Import', 'Export', 'Total ', 'Import', 'Export') val units = newArrayList('W', 'W', 'W', 'kWh', 'kWh', 'kWh') val addrs = newArrayList(53, 1281, 1283, 343, 73, 75) val ArrayList<String> lines = newArrayList() lines.add(new String("")) for(var i = 0; i < 6; i++) { val value = readValue.apply(addrs.get(i)) val line = "%s %7.2f %s".format(names.get(i), value, units.get(i)) if(i == 3) lines.add("") lines.add(line) } lcd.brickletLCD128x64ClearDisplay() for(var i = 0; i < lines.length(); i++) { lcd.brickletLCD128x64WriteLine(i, 0, lines.get(i)) } lcd.brickletLCD128x64DrawBufferedFrame(false) end Die NFC- und NFC-RFID-Bricklets werden jetzt auch unterstützt, allerdings nur mit der selben API wie auch die anderen Bindings. Das heißt, dass der Zustandsautomat zum Auslesen von Tags in Rules umgesetzt werden muss. Ich habe als Beispiel mal das jeweilige ScanForTags-Beispiel der Bricklets portiert. Als Trigger wird hier noch ein Druck auf einen RGB-LED-Button verwendet (einmal, danach scannt die Regel permanent). Da könnte man alternativ sinnvollerweise darauf reagieren, dass das NFC(-RFID)-Bricklet online kommt. NFC-RFID: import java.util.List; import java.util.stream.Collectors; rule "NFC" when Item UnX_State changed or Channel "tinkerforge:brickletrgbledbutton:Enx:BrickletRGBLEDButtonButton" triggered "PRESSED" then val stateVal = UnX_State.state as Number val int state = stateVal.intValue val nfc = getActions("tinkerforge", "tinkerforge:brickletnfcrfid:unX") val rgb = getActions("tinkerforge", "tinkerforge:brickletrgbledbutton:Enx") if (state == 128) { //Idle rgb.brickletRGBLEDButtonSetColor(255, 127, 0) nfc.brickletNFCRFIDRequestTagID(2) } else if (state == 194) { //Error (typically no tag found) rgb.brickletRGBLEDButtonSetColor(255, 0, 0) nfc.brickletNFCRFIDRequestTagID(2 as short) } else if (state == 130) { //Tag ID Ready logInfo("NFC", "tag id ready") val ret = nfc.brickletNFCRFIDGetTagID() val tagType = ret.get("tagType") val tagID = ret.get("tid") as List<Short> val tagLength = ret.get("tidLength") val tag = String.join(" ", tagID.stream().limit(tagLength).map([i | String.format("0x%02X", i)]).collect(Collectors.toList())); logInfo("NFC", "tag id:" + tag) rgb.brickletRGBLEDButtonSetColor(0, 255, 0) createTimer(now.plusSeconds(1), [|nfc.brickletNFCRFIDRequestTagID(2 as short)]) } end und NFC: import java.util.List; import java.util.stream.Collectors; rule "NFC" when Item HoG_State changed or Channel "tinkerforge:brickletrgbledbutton:Enx:BrickletRGBLEDButtonButton" triggered "PRESSED" then val stateVal = newState as Number val int state = stateVal.intValue val nfc = getActions("tinkerforge", "tinkerforge:brickletnfc:HoG") val rgb = getActions("tinkerforge", "tinkerforge:brickletrgbledbutton:Enx") if (state == 128) { rgb.brickletRGBLEDButtonSetColor(255, 127, 0) nfc.brickletNFCReaderRequestTagID() } else if (state == 194) { rgb.brickletRGBLEDButtonSetColor(255, 0, 0) nfc.brickletNFCReaderRequestTagID() } else if (state == 130) { logInfo("NFC", "tag id ready") val ret = nfc.brickletNFCReaderGetTagID() val tagType = ret.get("tagType") val tagID = ret.get("tagID") as List<Integer> val tag = String.join(" ", tagID.stream().map([i | String.format("0x%02X", i)]).collect(Collectors.toList())); logInfo("NFC", "tag id:" + tag) rgb.brickletRGBLEDButtonSetColor(0, 255, 0) createTimer(now.plusSeconds(1), [|nfc.brickletNFCReaderRequestTagID()]) } end Die Bindings benutzen jetzt außerdem wieder das ältere Java-Typ-Schema für alte Bricklets. Die Umsetzung des neuen Schemas (das alle Integers kleiner 32 Bit auf int mappt) war nur unvollständig und hat die Generierung verkompliziert. Außerdem ist so die Java-Dokumentation hilfreicher. Nachteil ist, dass in den Rules immer mal unoffensichtlich nach short gecastet werden muss, wie z.b. bei der NFC-RFID-Rule. Gruß, Erik

Firmwares: CAN Bricklet 2.0.1 Frame Readable Callback hinzugefügt Firmwares: CAN 2.0 Bricklet 2.0.3 Frame Readable Callback hinzugefügt Error Occurred Callback hinzugefügt Firmwares: RS232 Bricklet 2.0.4 Wenn Read Callback aktiviert ist, wird jetzt von read() eine leere Nachricht zurückgegeben Frame Readable Callback und Read Frame Funktion hinzugefügt Firmwares: RS232 2.0 Bricklet 2.0.3 Setze den Read-Stream durch die Read-Funktion nicht zurück, wenn das entsprechende Callback aktiviert ist und anders herum Frame Readable Callback und Read Frame Funktion hinzugefügt Firmwares: RS232 2.0 Bricklet 2.0.5 Setze den Read-Stream durch die Read-Funktion nicht zurück, wenn das entsprechende Callback aktiviert ist und anders herum Frame Readable Callback und Read Frame Funktion hinzugefügt Repariere andere Wortlängen als 8 Bit Download: CAN Bricklet CAN 2.0 Bricklet RS232 Bricklet RS232 2.0 Bricklet RS485 Bricklet

Firmwares: CAN Bricklet 2.0.1 Add frame readable callback Firmwares: CAN 2.0 Bricklet 2.0.3 Add frame readable callback Add error occured callback Firmwares: RS232 Bricklet 2.0.4 Return empty message from read() if read callback is enabled Add frame readable callback and read frame function Firmwares: RS232 2.0 Bricklet 2.0.3 Don't reset read stream in getter if callback is enabled and vice versa Add frame readable callback and read frame function Firmwares: RS232 2.0 Bricklet 2.0.5 Don't reset read stream in getter if callback is enabled and vice versa Add frame readable callback and read frame function Fix word lengths other than 8 Download: CAN Bricklet CAN 2.0 Bricklet RS232 Bricklet RS232 2.0 Bricklet RS485 Bricklet

Moin, @StefanOHAN Da würde ich mich eher auf die TH-6148 verlassen, zumindest wenn sie weniger messen als das Humidity. Temperatur-Messung ist überraschend schwierig und das Humidity hat prinzipiell ein Problem mit der Selbsterwärmung des Prozessors. @riro Verlass dich da mal nicht 100%ig auf die Java-Doku. Ich habe das für openHAB so gebaut, dass möglichst immer in der Basis-SI-Einheit ausgegeben wird, das vereinfacht die Generation der Bindings. Bei der Regenmenge ist das leider etwas unhandliche Meter. Du kannst in der Sitemap aber auch mit einem Transformation-Service umrechnen, vermutlich mit der JavaScript-Transformation, es sei denn dir reicht es, ein paar Intervalle auf jeweils einen Wert umzubiegen, dann tuts auch die Scale-Transformation. Das liegt daran, dass das Binding die Callbacks des Bricklets benutzt. LastChange ist dann der Zeitpunkt, wann auch immer das letzte Callback ankam. Ich überlege mir mal, ob ich ins Binding noch eine Möglichkeit einbaue, das als relative Zeit zu bekommen, aber ich fürchte, du musst dir mit einer Rule mit Time-Based-Trigger behelfen. Das ist nichts kritisches, du hast da noch einen alten Handler rumfliegen, der versucht die Station/Sensor-IDs zu aktualisieren, obwohl das entsprechende Thing gelöscht ist. Das ist ein Bug, der mit der nächsten Beta behoben sein sollte. Gruß, Erik

Hm das robust zu bauen ist schwierig. Ich würde bei deinem Humidity+LCD-Beispiel folgendes versuchen: Ein Switch-Item, das du mit einer Rule schaltest, wenn der Humidity-Threshold zu hoch ist oder wieder darunter fällt. Dann dazu eine Rule, die sowohl darauf reagiert, wenn das LCD initialisiert ist, als auch wenn das Humidity-Item schaltet und in der Regel mit der Thing-Status-Action als erstes prüft, ob das LCD online ist, und wenn nicht den Wert anzeigt: rule "LCD-Humidity" when Thing <LCD-UID> changed from INITIALIZING to ONLINE or Item <humidity-threshold-item> changed then var thingStatusInfo = getThingStatusInfo("lcd-uid") if ((thingStatusInfo == null) || (thingStatusInfo.getStatus().toString() != "ONLINE")) { return } //lcd-actions holen, wert anzeigen end Vorteil ist, dass du dann sofort einen aktuellen Wert auf dem LCD bekommst, wenn es online ist (oder wieder neu online kommt weil die Verbindung kurz weg war, oder Stromausfall oder was auch immer), aber die Rule auch nur dann läuft. Das ist natürlich je nach Menge der Bricklets relativ viel Rule-Code den du schreiben/kopieren musst.

Moin, 0.1 ist defintiv nicht hoch. Alles über dem Default von 1 hätte ich verstanden, so ists seltsam. Hast du eventuell ein drittes Thermometer, mit dem du messen kannst? Vielleicht liegt es ja garnicht am Humidity Bricklet, sondern an dem TH-6841. Zu der RemoteSwitchActions-Sache: Da habe ich wohl nach dem Testen noch einen Bug eingebaut. Die Bricklets haben eigene Actions, der RemoteSwitchHandler meldet aber openHAB, dass sie nur die DefaultActions (also nichts) unterstützen. Der Fix kommt in die nächste Beta, sorry dafür. Nur aus Interesse und damit ich weiß wie ich das eventuell modelliere: Was würdest du in Rules laufen lassen, die beim ersten Initialisieren vom Binding ausgeführt werden, aber nicht, wenn sich ein Device neu initialisiert?

Anschlussfrage zu dem Initialisierungs-Channel: Würde es nicht reichen, wenn du in den Rules Thing-basierte Trigger benutzt? Zum Beispiel: Thing "tinkerforge:brickletrgbledbutton:Enx" changed from INITIALIZING to ONLINE Das sollte sowohl mit dem Brick Daemon, als auch mit den eigentlichen Devices funktionieren und hat den Vorteil, dass es auch passiert, wenn die Verbindung verloren ging und neu aufgebaut wurde. Also wenn du z.B. einen RGB LED Button hast, der immer eine Farbe haben soll, wenn gerade nichts anderes los ist, kannst du den Trigger benutzen um die Farbe zu setzen. Dann repariert sich das auch, wenn du das Bricklet (oder den ganzen Stack) vom Strom trennst und wieder anschließt.

Moin Das geht nur über eine Rule, du kannst aber (z.b.) ein Switch-Item anlegen, dass du über die Rule steuerst, und das dann normal an Channels koppeln oder in anderen Rules verwenden. 1,2°C heißt, dass das Humidity Bricklet wärmer misst als der TH-6148? Dann liegt es eventuell an der eingestellten Sample Rate des Humidity Bricklets. Wenn die zu hoch ist, heizt es sich selbst auf. Das geht, ich setze es mal auf die TODO-Liste. Was ich übrigens vergessen hatte zu erwähnen: Die Elektroden der Multi Touch Bricklets sind jetzt wieder state-basierte Channel, d.h. du musst wieder Items anlegen, wenn du in Regeln auf sie reagieren willst. Aufgrund der Art und Weise wie die Java-API intern funktioniert, bekomme ich das nicht sauber auf Trigger-Channel gemappt.

Moin, Beta 18 ist jetzt im Post oben. Es sollte damit nicht mehr nötig sein, Channels Refresh-Commands zu schicken. Falls das doch irgendwo noch hängt, bitte einmal Bescheid sagen. @StefanOHAN In der neuen Beta habe ich mehr Debug-Meldungen eingebaut, mit denen wir hoffentlich deinen Verbindungsproblemen auf den Grund gehen können. Außerdem habe ich noch ein paar Bugs in die Richtung behoben, vielleicht funktioniert es ja jetzt einfach. Lass das ganze bitte nochmal mit log:set TRACE org.eclipse.smarthome.binding.tinkerforge laufen. Gruß, Erik