rtrbt

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.

Moin, Wenn du garnicht programmieren willst, kannst du entweder den Data-Logger des Brick Viewers benutzen, der schreibt die Messdaten dann in eine CSV-Datei, die du z.B. mit Excel ö.Ä. auswerten kannst, oder alternativ nimmst du das Tabletop Weather Station Demo-Programm. Das schreibt die Messdaten in eine sqlite-Datenbank und kann sie auf einem LCD 128x64 Bricklet anzeigen.

Moin, Ich bin diese Woche noch im Urlaub, sehe mir das alles mal nächste Woche an.

Uff, ein Weihnachtswunder :D Ich bin diese Woche noch im Urlaub, nächste Woche melde ich mich dann nochmal.

Das dürfte an der Namensänderung liegen, die ich machen musste. Da jetzt intern alles anders heißt (z.b. ein Stepper Brick nicht mehr nur Stepper), betrachtet openHAB das als andere Devices. Die alten musst du vermutlich löschen und neu anlegen, sorry dafür! Edit: @sihui Diese Warnung sehe ich bei mir auch immer, habe noch auf der TODO-Liste rauszufinden, was da das Problem ist. Funktionieren tuts ja anscheinend auch so.

Versuch mal remoteActions.brickletRemoteSwitchSwitchSocketA(28 as short, 1 as short, 1 as short) Das Remote Switch 1.0 ist aus der Zeit, in der die Java-Bindings noch versuchten clever zu sein und kleinere Datentypen zu benutzen. Leider konvertieren Literale nicht automatisch nach short.

Hast du beim Neustart des Pythonscripts (damit meinst du die MQTT-Bindings?) das init-file wieder benutzt? Sonst funktioniert es nicht, weil die Bindings die Callback-Registrierung verlieren wenn du sie neu startest.