Jump to content

rtrbt

Administrators
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    1.548

  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    150

 Inhaltstyp 

Posts erstellt von rtrbt

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Moin,

    Beta 15 ist jetzt im Post oben. Das Outdoor Weather Bricklet funktioniert jetzt wie hier beschrieben:

    On 1/15/2020 at 4:24 PM, rtrbt said:

    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.

    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.

    On 1/20/2020 at 9:36 PM, StefanOHAN said:

    Es kam nur ein kleiner Fehler für "age"

    Hab dann nochmal bei Euch in die Java-Beispiele geschaut >>age – Typ: long, Einheit: 1 ms, Wertebereich: [0 bis 232 - 1]<< und long hat es geklappt.
        

    Ich sehe schon, ich muss mich etwas mehr mit Java beschäftigen 🙂 

    Hm und ich sollte keine Typen raten sondern auch in der Doku nachsehen.

    • Like 1

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    21 hours ago, StefanOHAN said:

    Hallo Erik, 

    dieses Woche habe ich nicht soviel getestet, eine Frage hätte ich aber zu einer Action für das LCD128x64

    Wie kann ich die Daten aus der Action .brickletLCD128x64GetTouchPosition()
    nutzen ?

    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.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Moin,

    Das LCD20x4-Backlight-Problem habe ich gefunden, das war unpraktisch konfiguriert, sollte mit der nächsten Beta wieder funktionieren.

    On 1/5/2020 at 7:44 PM, StefanOHAN said:

    1) gibt es kompatiblen Sensor zum TH-6148 dessen ID man Konfigurieren kann ? (ich vermute der TH-6148 wurde nicht von Euch entwickelt, sondern zugekauft)

    2) Im Post „https://www.tinkerunity.org/topic/4543-id-des-th-6148-temperatursensors/?tab=comments#comment-26305“ wird auf das Problem der „Sensor Leichen“ hingewiesen. „Borg“ meinte er würde es auf seine ToDo Liste setzten (das Löschen der Sensor Leichen). Ist Dir Bekannt ob nach 24h diese Leichen automatisch weg sind ? (hat bei mir nicht geklappt)

    3) siehst Du eine Möglichkeit das Binding so umzubauen, dass zumindest keine neue Verlinkung / Rule Anpassung statt finden muss, wenn die Batterie des Sensor getauscht wurde ?

    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.

    On 1/5/2020 at 7:44 PM, StefanOHAN said:

    Frage: Gibt es eine Planung den FW-Update des Masterbrick zukünftig anderes zu gestalten, ähnlich dem es HAT ? (also ohne betätigen des beiden Tasten)

    Da gibt es theoretische Überlegungen, aber noch nichts konkretes.

    On 1/2/2020 at 5:40 PM, KlausGünther said:

    es ist jetzt mehrfach passiert, dass "augenscheinlich" das TF Binding ausgestiegen ist und eines oder mehrer Bricklets keine Daten mehr gesendet haben bzw. die nicht ankamen.

    Es half dann auf dem kurzen Wege nur der Neustart. Das ganze ging auch jeweils über mehrer Stunden, also nicht nur ein paar Minuten.

    Erik kannst Du da noch mal gucken ?

    Hm steht in den openHAB-Logs dazu etwas interessantes? Eventuell hilft auch ein Brick Daemon Log.

    Samplingrate - Industrial Dual Analog In Bricklet 2.0 - Firmware 2.0.4

    in Hardware

    Geschrieben

    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.

    data_logger.png

    data_logger_einstellungen.png

    RED Brick 1.14: Netzwerk sehr instabil (Reboot notwendig).

    in Allgemeine Diskussionen

    Geschrieben

    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.

    Rust und Bricklet OLED 128x64 - nicht alle Zeichen darstellbar?

    in Software, Programmierung und externe Tools

    Geschrieben

    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.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Moin,

    Beta 14 ist jetzt im Post oben.

    @KlausGünther Das Wetterstations-Problem sollte jetzt weg sein, da fehlte einfach das Wegräumen der alten Discovery-Ergebnisse. Außerdem verkraften die Bindings es jetzt besser, wenn man das Outdoor Weather Bricklet resettet (oder z.b. neu flasht)

    @StefanOHAN Der Bug mit den Actions ist in der finalen 2.5 Version noch drin. Ich habe jetzt kurzerhand die Actions alle mit dem Gerätetyp- und Namen geprefixt. Das ist leider mehr Schreibarbeit, aber funktioniert wenigstens:  lcdActions.clearDisplay() ist jetzt lcdActions.brickletLCD128x64ClearDisplay().

    @sihui Support für die Remote Switch Bricklets ist jetzt drin, das musst du aber über Rules bauen, z.B. so hier: 

    rule "remoteswitch"
    when
        Item Enx_Button changed to ON
    then
        val remoteActions = getActions("tinkerforge", "tinkerforge:brickletremoteswitch:01234567:XYZ")
        remoteActions.brickletRemoteSwitchSwitchSocketA(12, 21, 1)        
    end

    Ansonsten nennenswerte Neuerungen sind (habe ich mal aus dem Changelog kopiert):

    - Add missing labels to channels
    - Use correct character set for displays
    - Allow configuration of status LED and SPI baudrates
    - Add more color palettes to Thermal Imaging Bricklet
    - Use unused and remove unnecessary configuration parameters
    - Set defaults for run-time generated channels
    - Prefix action and channel type names with device category and name
    - Fix Outdoor Weather Bricklet reset behaviour
    - Mark configuration as advanced if API is flagged so
    - Show a warning if a device's firmware is too old

    Schöne Weihnachten und so!

    Erik

    Brickv 2.4.11 startet nicht

    in Software, Programmierung und externe Tools

    Geschrieben

    tzlocal für Python 3 findest du hier. Je nach Distribution gibt es bei dir eventuell ein Package dafür, bei Debian-esken Distributionen z.b. python3-tzlocal. Das selbe Problem hast du dann eventuell noch bei pytz, da heißt das Debian-Package python3-tz.

    Im README haben wir inzwischen als Mindestanforderung python 3.5, d.h. am einfachsten wäre es, wenn du dein Python aktualisierst. Abgesehen davon habe ich gerade den Source nochmal durchsucht und konnte von dem Konstrukt keine weiteren Stellen finden (außer die im Render-Widget). D.h. du kannst mal probieren, ob es dich weiterbringt, wenn du jeweils 

    *color

    durch 

    color[0], color[1], color[2]

    ersetzt. Das sollte in den Zeilen 376, 378, 381, 383, 386 und 388 sein.

    Edit: Ich habe leider gerade kein python3.4 zur Hand, sonst würde ich das selber testen.

    MQTT mehrere Bricklets

    in Anfängerfragen und FAQ

    Geschrieben

    Moin,

    Welche Version der MQTT-Bindings hast du? Tauchen die Daten der Stationen/Sensoren im Brick Viewer auf? Bekommst du über den MQTT-Broker irgendwelche Fehlermeldungen? (Subscribe mal # als Topic, dann bekommst du alles)

    Ich habe das hier gerade mal getestet, und es funktioniert (nachdem ich die UIDs ausgetauscht hatte), also an deinem init-file liegt es nicht.

    Gruß,
    Erik

×
×
  • Neu erstellen...