rtrbt

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.

Moin, Das ist leider etwas ungünstig dokumentiert, aber die Rust-Bindings mappen die ersten 256 UTF-8 Codepoints auf auf die möglichen Werte eines Bytes um. In den Bindings sieht das so aus: fn try_to_le_byte_vec(s: String, max_len: usize) -> Result<Vec<u8>, BrickletError> { if s.chars().any(|c| c as u32 > 255) { return Err(BrickletError::InvalidParameter); } let bytes: Vec<u8> = s.chars().map(|c| c as u8).collect(); if bytes.len() > max_len { Err(BrickletError::InvalidParameter) } else { let mut result = vec![0u8; max_len]; result[0..bytes.len()].copy_from_slice(&bytes); Ok(result) } } Das heißt du solltest das Characterset mit \u{01} bis \u{FF} benutzen können. Edit: Brainfart, \u{00} terminiert den String (aus Bricklet-API-Sicht), \u{01} ist das erste sinnvolle Zeichen.