rtrbt

Moin, Das ist der FirmwareProvider, der holt sich von downloads.tinkerforge.com die aktuellen Firmwareversionen ab und zeigt Updates an. Ich habe das bei mir auch gerade im Log, sehe ich mir mal an. Das null sollte eigentlich eine hilfreichere Fehlermeldung sein, aber da fliegt scheinbar eine Exception, die keine Nachricht hat. Benutzt du zum Auslesen dann den Channel? Falls ja, musst du aktuell immer mal REFRESH-Commands schicken, damit der Wert sich bewegt. Das liegt daran, dass ich die Elektroden jetzt als Trigger-Channel behandle, aber das Bricklet selbst nur ein Callback für alle Elektroden hat, dieses aber bei jeder Änderung auslöst. Da muss ich mir mal was einfallen lassen. Das sollte kein Problem sein, da die Callbacks alle nur auslösen sollten, wenn sich Werte ändern. Das kannst du z.B. mit einer Rule und einem time-based-trigger machen. Sehe ich mir nochmal an. Du kannst mal in der Karaf-Konsole log:set TRACE org.eclipse.smarthome.binding.tinkerforge ausführen. Dann sollten im Log alle 90 Sekunden solche Ausgaben erscheinen: [DEBUG] [rforge.internal.handler.DeviceHandler] - Checking reachability of 6esErP [DEBUG] [rforge.internal.handler.DeviceHandler] - Done checking reachability of 6esErP Falls da was schiefgeht kommen eventuell hilfreiche Informationen raus.

Moin, Wir haben hier noch einen Brick, den können wir dir zuschicken. Falls du mehr brauchst: bei Mouser noch drei Stück. Der Nachfolger wird das Servo Bricklet, das ist gerade in Entwicklung. Das sieht dann so aus.

Moin, Beta 17 ist jetzt im Post oben. Die Remote Switch Bricklets sind jetzt deutlich einfacher benutzbar: Es gibt, ähnlich wie beim Outdoor Weather Bricklet jetzt eigene Devices für die Typ-A bis C Dosen und Typ-B Dimmer, die auf die entsprechende Adresse usw. konfiguriert werden können. Der Handler stellt dabei automatisch sicher, dass immer nur ein Schaltvorgang gleichzeitig stattfindet. Das ganze funktioniert ohne Rules schreiben zu müssen, die Actions werden aber alle weiterhin unterstützt. Damit Rules einfacher zu schreiben sind, habe ich mal das Java-Typ-Schema umgebaut: Bisher hatte ich die Java-Bindings unverändert benutzt, weshalb für ältere Bricklets die Actions oft byte und short für Parameter und Rückgabewerte verwendet haben. Das habe ich rausgeschmissen, jetzt werden nur noch int und long verwendet. Das ist jetzt erstmal etwas verwirrend, da die Java-Doku nicht mehr passt, behebt sich dann aber wenn ich dazu komme einen richtigen openHAB-Doku-Generator zu schreiben. Für die Übergangszeit: alles was short oder byte war ist jetzt int, man kann aber in den Rules anscheinend auch einfach "as Number" casten, das sollte immer gehen. Die minimale Firmware-Version wird jetzt anhand der von den Bindings verwendeten Features gesetzt, das dürfte aber nicht auffallen, weil mit der Information im Moment nichts angefangen wird. Die Bindings sollten jetzt robuster sein, wenn die Verbindung zum Brick Daemon oft verloren geht, da fehlte eine Neuinitialisierung der Devices, weshalb dann manchmal Callbacks nicht mehr ankamen. @StefanOHAN Deine Rules sollten jetzt nicht mehr beim Initialisieren oder wenn die Verbindung wiederhergestellt wird triggern. Die IO16-Sache hatte ich hier nochmal getestet, das funktionierte. Ist das mit der neuen Beta bei dir noch kaputt? Gruß, Erik

Moin, mit dem Dual Relay V2 meinst du das Industrial Dual Relay? Sehe ich mir mal an. Jupp Das geht mit allen 7-Pol-Bricklets. Nein, da kannst du die vollen 4 (also 2+2) Meter benutzen. Ja, und das hat gegenüber der Variante zwei Kabel zu schlachten den Vorteil, dass es wie ein Repeater wirkt, also das Signal aufgefrischt. Du kannst aber nicht, falls du noch längere Kabel brauchst, zwei Isolatoren hintereinander benutzen, das würde den Master Brick verwirren.

Moin, Du hast da zwei unabhängige Probleme: 1. ist meine Reconnectlogik da anscheinend zu aggresiv, das muss ich mir nochmal ansehen. 2. versuche ich, wenn ein Device initialisiert wird, alle Channel in einen definierten Zustand zu bringen, indem ich ein REFRESH-Command schicke. Das sollte ich aber nur bei nicht-Trigger-Channels machen, damit es nicht so aussieht als gäbe es Zustandswechsel, die nicht wirklich da sind. Das habe ich hier gerade mal testweise eingebaut und es scheint zu funktionieren. Kommt in die nächste Beta.

Moin, In den Bindings ist kein anderes Ausgabeformat vorgesehen, also kannst du das nicht einfach durch einen Kommandozeilenparameter ö.Ä. lösen. Ohne das ich mich jetzt mit ioBroker konkret auskenne: Warum ist es ein Problem JSON zu verarbeiten? Ich habe bei kurzem Suchen das hier gefunden. Andere Ausgabeformate wären schwierig, weil ja teilweise strukturierte Daten rausgegeben werden. Gruß, Erik

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.

Hi, msg.topic = topicPrefixRequest+brickletUID+"/set_all_input_value_callback_configuration"; msg.payload = {"period": 0, "value_has_to_change": true}; node.send(msg); A period of 0 disables the callback, you have to set it to (at least) 1.

Moin, Im Brick Viewer kannst du das 50 Hz-Signal nicht sehen, weil die Zeitskala dafür zu weit ist. Außerdem ruft er unabhängig von der eingestellten Sample Rate (die sich nur auf die Konfiguration des Bricklets bezieht, nicht auf die Kommunikation zwischen Bricklet und PC) nur alle 100ms die Spannungswerte ab. Ich habe den Data Logger hier mal mit einem 50Hz-Signal aus einem Funktionsgenerator getestet und es funktioniert (siehe ad-hoc geplotteter Anhang). Wichtig ist dabei, dass du nicht nur die Sample Rate hochdrehst, sondern auch die Abfrage-Rate des Loggers (siehe angehangener Screenshot). Falls du mehr als nur die eine Spannung messen willst musst du aber darauf achten, dass insgesamt nur ungefähr 1000 Nachrichten pro Sekunde an Durchsatz pro angeschlossenem Stack möglich sind. Der Plot wird aber auch bei kleineren Abfrageraten (z.b. 4ms, dann sind es nur noch 250 Nachrichten pro Sekunde) noch ganz gut lesbar.

Moin, Der Temperaturkanal beim Barometer 1.0 fehlt, da das eigentlich nur ein interner Wert des Sensors ist, der nicht wirklich genau ist. Deshalb heißt die entsprechende API-Funktion auch getChipTemperature. Es gibt auch kein Callback dazu, d.h. der Wert würde sich nicht automatisch aktualisieren. Um die anderen Rückmeldungen kümmere ich mich diese Woche, mal wieder danke fürs Testen

Moin, Bezüglich der Brick Viewer-Probleme: Das die am RED-Brick angeschlossene Hardware nicht auftaucht klingt nach einem Enumerierungsproblem. Du hast echt verfluchte Hardware. Wenn du den Reboot per Brick Viewer machst, merkt der Brick Viewer dass die Verbindung weg ist? (Dann steht im Button oben nicht mehr disconnect sondern abort pending automatic reconnect) Falls ja, sollte die Verbindung eigentlich nachdem der RED-Brick wieder gebootet und verbunden ist (nach ungefähr einer Minute bei mir) wieder aufgebaut werden. Tauschen klingt nach einer guten Idee, dann kann ich das eventuell hier weiter untersuchen. Schreib mal eine E-Mail mit Adressdaten usw. an nicolai@tinkerforge.com (er ist heute schon weg, sonst hätte ich das gerade angeschubst). Wenn du reinschreibst, dass er mich (Erik) mal fragen soll musst du nicht die ganze Vorgeschichte anhängen.