rtrbt

Hm, bei den Callbacks war das noch anderweitig kaputt, sorry dafür! Die angehangene Variante sollte funktionieren. tinkerforge_perl_bindings_2_1_25.zip

Eventuell. Versuche mal das wie hier beschrieben zu installieren. Alternativ kannst du den Tinkerforge-Ordner aus source/lib rauskopieren, neben das Beispiel legen und dann ganz oben im Beispiel use lib './'; einfügen. Dann sollte auf jeden Fall die lokale Variante benutzt werden.

Moin, Teste mal bitte die angehangene Version der Bindings. tinkerforge_perl_bindings_2_1_25.zip

Moin, Die IO-16-Geschichte sehe ich mir gleich nochmal an, das sollte eigentlich funktionieren (die letzten Worte des Informatikers ) Beim Piezo kannst du die getAlarm-Action benutzen, die gibt nicht nur die Gesamt-Duration des aktuellen Alarms zurück, sondern auch durationRemaining, also wie lange der aktuelle Alarm noch läuft (falls einer läuft).

Moin, @StefanOHAN Hm, die fehlt. Mir ist dabei ein strukturelles Problem aufgefallen: Eigentlich sind nur die Teile der Java-API als Actions rausgeführt, die den Zustand des Bricks/Bricklets nicht ändern (mit Ausnahme einiger Bricklets wie z.b. der Remote-Switches, die nicht gut auf das Channel-Modell mappen), damit nicht die openHAB-Sicht des Bricklets und der tatsächliche Zustand auseinanderlaufen. Ich hatte jetzt den Gedanken, dass ich Actions, die den Zustand ändern erlauben kann, wenn ich im Generator hinterlege, welche Channels dann aktualisiert werden müssen. Da muss ich die API nochmal durchgehen, aber in dem Zuge wird dann die getEdgeCount-Action kommen. Das liegt daran, dass ich im Moment die Java-Bindings unverändert benutze. Die wiederum haben aus Legacy-Gründen bei älteren Bricklets andere Parameter- und Rückgabetypen. Die IO-16 gibt dir da einen Short (also eine 16-Bit-Zahl) zurück. Wenn du das so machst: val currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(0, false).get("count") as short sollte es eigentlich funktionieren. Ist PiezoAlarm das Item mit dem du den Alarm-Channel benutzt? Dann passiert in deiner Rule folgendes: Du schickst das Command an den Alarm-Channel, das ist etwas langsam, weil die Nachricht einmal quer durch openHAB muss. Direkt danach startest du einen weiteren Alarm von Hand (die Action heißt zwar SetAlarm, aber konfiguriert nicht nur, sondern löst den Alarm auch direkt aus). Das geht schneller, weil die Action direkt an die Java-Bindings gekoppelt ist. Der zweite Alarm geht jetzt los, danach kommt das Command am Channel an, der intern auch SetAlarm benutzt und damit den Alarm aus deiner Rule überschreibt. Stimmt, da ist die Modellierung nicht gut: Das ist im Moment ein normaler Channel mit State pro Elektrode, mit dem Switch-Typ. Sinnvoller ist ein Trigger-Channel. Das konfiguriere ich mal um. @omiT Das sind die LEDs die auf dem Bricklet verbaut sind. Du kannst da Zahlen bis 255 reingeben, dann leuchten die LEDs entsprechend hell. Ich baue eventuell noch ein, dass auch PercentType-Kommandos akzeptiert werden, dann kann ich das in der PaperUI schöner anzeigen. Mal wieder danke für's Testen! Erik

Sorry, das hatte ich übersehen. Du kannst die Repeats mit der brickletRemoteSwitchSetRepeats Action einstellen.

The configuration seems to be correct. You could try the following: Run the bindings with --debug Read back the callback configuration with mosquitto_pub -t tinkerforge/request/air_quality_bricklet/Jvj/get_all_values_callback_configuration -m '' after you've set it. Also the period is in milliseconds, so 10 should work, but will flood you with data that will be very often identical.

Das sollte kein Problem sein, die ThingUID des Brick Daemons habe ich nicht verändert. Da gibt es leider kein Callback für, also wird die Liste im Moment nur aktualisiert, wenn openHAB danach ist, oder du händisch ein Refresh-Command schickst. Auf der TODO-Liste steht noch das allgemein über den Scheduler von openHAB zu lösen, das Problem haben ja einige Bricklets.

So, Beta 16 ist im Post oben. Ich habe das Schema für ThingUIDs geändert, die führen jetzt nicht mehr die ID des Brick Daemon mit. Damit funktioniert der Wechsel eines Things von einem Brick Daemon zu einem anderen zuverlässig und ohne duplizierte Inboxeinträge. Allerdings müssen deshalb alle Things nochmal neu erstellt werden, diesmal hoffentlich zum letzten mal.

Moin, Das war ein etwas dämlicher Fehler meinerseits: Das Bricklet vergisst ja bei einem Reboot alle Sensoren/Stationen, damit kam aber der Code nicht klar, das ist mir durch die Tests gerutscht. Der Fix kommt heute noch. Das zweite Problem habe ich damit auch gleich erschlagen.

Moin, Beta 15 ist jetzt im Post oben. Das Outdoor Weather Bricklet funktioniert jetzt wie hier beschrieben: Außerdem habe ich das Problem mit der Bridge Selection gefunden, sodass jetzt keine Fehler mehr auftauchen, wenn man die in den Thing-Einstellungen editiert. Das heißt, dass man jetzt konfigurierte Bricks und Bricklets zwischen Brick Daemons (und damit auch Stapeln) verschieben kann. Im Moment führt das noch dazu, dass dann in der Inbox noch ein Thing zu viel auftaucht, das fixe ich in der nächsten Beta. Die Firmware-Update-Logik funktioniert jetzt über die Interfaces die openHAB dafür bietet, d.h. dass jetzt die Firmware-Version und ob es ein Update gibt in den Eigenschaften der Things steht. Das Backlight des LCD20x4 sollte jetzt auch korrekt funktionieren. Hm und ich sollte keine Typen raten sondern auch in der Doku nachsehen.

Du bekommst aus der Action eine Map<String, Object>, aus der du mit .get("keyname") Daten rausholen kannst. Um die Keys rauszufinden kannst du folgendes machen: logInfo("test", "TouchPosition" + lcdActions128x64.brickletLCD128x64GetTouchPosition().toString()) dann wird sowas hier ausgegeben: TouchPosition{x=65, y=43, pressure=1, age=0} Das heißt, dass die Keys "x", "y", "pressure" und "age" sind. Du könntest dann z.B. sowas hier bauen: rule "test" when Channel "tinkerforge:brickletlcd128x64:6c8d2c7d:HQ6:BrickletLCD128x64TouchPosition" triggered then val lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:6c8d2c7d:HQ6") val touchPos = lcdActions128x64.brickletLCD128x64GetTouchPosition() val x = touchPos.get("x") as Integer val y = touchPos.get("y") as Integer val pressure = touchPos.get("pressure") as Integer val age = touchPos.get("age") as Integer if (x < 64 && y < 32) { logInfo("test", "oben links") } else if (x < 64 && y >= 32) { logInfo("test", "unten links") } else if (x >= 64 && y < 32) { logInfo("test", "oben rechts") } else { logInfo("test", "unten rechts") } end Die Regel gibt aus, ob in welchem Viertel des Displays eine Berührung war.

Moin, Falls du gleich auf openHAB wechseln möchtest: Hier gibt es die aktuelle Beta-Version der neuen Bindings, die auch das Remote Switch Bricklet unterstützen.

Moin, Das IO-16 geht beim Start auf allen Pins in den Input with Pull-Up-Modus, deshalb siehst du High auf den Pins. Das Industrial Quad Relay Bricklet lässt die Relays offen, wenn es hochfährt, die Relays öffnen auch, wenn es die Stromversorgung verliert. Deine Szenarien habe ich sicherheitshalber nochmal getestet, in allen Fällen ist das Relay offen. Gruß, Erik

Moin, Das LCD20x4-Backlight-Problem habe ich gefunden, das war unpraktisch konfiguriert, sollte mit der nächsten Beta wieder funktionieren. 1) Wäre mir nicht bewusst. 2) Das passiert ab Firmware-Version 2.0.2 des Bricklets, zumindest innerhalb des Bricklet-Speichers, es ist aber durchaus möglich, dass meine openHAB-Implementierung da noch einen Bug hat. Das ist aber wegen folgendem nicht schlimm: 3) Ich habe da nochmal drüber nachgedacht und bin zu folgendem Schluss gekommen: Den Handler für das Outdoor Weather Bricklet habe ich von Hand geschrieben, d.h. da habe ich mehr Möglichkeiten, deshalb kann ich das nochmal komplett anders bauen. Das Bricklet bleibt eine Bridge, bekommt aber zusätzlich einen Channel, der eine Liste von bekannten Sensor- und Station-IDs zurückgibt. (Das ist die Liste die das Bricklet selbst hält, d.h. die wird automatisch nach 12 Stunden bereinigt wenn eine ID verschwindet). Die Sensoren und Stationen werden dann nicht mehr automatisch in die Inbox gelegt, sondern ähnlich zum Brick Daemon vom Nutzer hinzugefügt, die "echte" ID ist dann nur eine Konfiguration, als UID (im openHAB-Sinne) wird eine ausgewürfelt oder ausgewählt (wie bei Brick Daemons). Wenn sich dann eine ID durch Batteriewechsel ändert muss nur die konfigurierte ID des Devices geändert werden, das Device bleibt das selbe -> alle Channel-Verlinkungen, Rules usw. funktionieren weiter. Da gibt es theoretische Überlegungen, aber noch nichts konkretes. Hm steht in den openHAB-Logs dazu etwas interessantes? Eventuell hilft auch ein Brick Daemon Log.