Jump to content

rtrbt

Administrators
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    1.544

  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    150

 Inhaltstyp 

Posts erstellt von rtrbt

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Sorry, deinen Post hatte ich übersehen.

    On 2/1/2020 at 4:39 PM, Maxicko said:

    Leider klappt das noch nicht so ganz.

    Was mir dabei aufgefallen ist, der Channel "Command" für die TypeA-Things wird mit Typ "String" und nicht mit "Switch" angegeben. Ist das so korrekt?

    Was klappt dabei noch nicht? Die Command-Channels sind Strings statt Switches, da es keinen Rückkanal von den Steckdosen gibt: openHAB kann nicht abfragen, ob eine Dose gerade an oder aus ist, also kann ich bei einem Switch nicht den Initialzustand setzen. Command-Channels (die in der PaperUI Buttons erzeugen) sind intern String-Channels. Du kannst z.b. aus Rules StringCommands "ON" oder "OFF" schicken um die Dose zu schalten.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Moin,

    19 hours ago, StefanOHAN said:

    Frage: ist das eine Funktion die noch nicht aktiv ist ? Oder welche Aufgabe hat diese ?

    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.

     

    19 hours ago, StefanOHAN said:

    Einzig für EdgeCount der „per Channel mit einem Item“ verlinkt ist, bekomme ich noch immer 0 als Ergebnis, kann aber daran liegen dass ich diesen evlt. falsch nutze.

    Benutzt du zum Auslesen dann den Channel? Falls ja, musst du aktuell immer mal REFRESH-Commands schicken, damit der Wert sich bewegt.

     

    19 hours ago, StefanOHAN said:

    Einen komischen Effekt habe ich beim „Multi Touch Bricklet 2.0“ (mit der alten V1 Version habe ich es nicht getestet), egal welche Elektroden-Taste ich berühre, es kommt immer für alle (die nicht berührt wurden) Elektroden die Meldung „triggered RELEASED. Ist das so gewollt ? (ich verwende Euer Key-Pad 3x4)

    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.

     

    19 hours ago, StefanOHAN said:

    Frage: Meinst Du es würde zu viel Last verursachen wenn ich die für das IO-16 / IO-4 den „Update Interval“ von 1000ms auf 250ms verkürze ? Wenn ich diese als Input für angeschlossene „Taster“ zum Lichtschalten verwende sind 1000ms etwas lange. Ich würde maximal dies für 2 x IO-16 anwenden.

    Das sollte kein Problem sein, da die Callbacks alle nur auslösen sollten, wenn sich Werte ändern.

     

    19 hours ago, omiT said:

    kann man die LEDs am Motion Detector nur leuchten lassen in verschiedenen Stärken (0-255) oder kann man diese auch blinken lassen?

    Das kannst du z.B. mit einer Rule und einem time-based-trigger machen.

     

    4 hours ago, StefanOHAN said:

    Kannst Du das mit dem Connetion Lost bitte nochmal checken ?

    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.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Moin,

    mit dem Dual Relay V2 meinst du das Industrial Dual Relay? Sehe ich mir mal an.

    27 minutes ago, StefanOHAN said:

    1) funktionieren mit Deinem Binding Bricklets, die über das Isolatro-Bricklet angeschlossen sind ?

    Jupp

    28 minutes ago, StefanOHAN said:

    2) lassen sich nur die Bricklets an das IsolatorBricklet anschließen die als Beispiel in Euer Doku genannt werden , oder können generell alle Bricklets (7-polige V2-Versionen) angeschlossen werden ?

    Das geht mit allen 7-Pol-Bricklets.

    28 minutes ago, StefanOHAN said:

    3) gibt es eine Einschränkung der verwendeten Leitungslängen ? Also Zuleitung und Ableitung je 2 Meter ?

    Nein, da kannst du die vollen 4 (also 2+2) Meter benutzen.

    28 minutes ago, StefanOHAN said:

    Könnte ich das Istolator-Bricklet evlt zur „Leitungsverlängerung“ nutzen ? 

    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.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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.

    MQTT Wert statt Objekt

    in Software, Programmierung und externe Tools

    Geschrieben

    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

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Moin,

    @StefanOHAN

    15 hours ago, StefanOHAN said:

    >>„Industrial Digital In 4 Bricklet 2.0“

    Frage: Kann es sein, dass Du keine Action für „getEdgeCount(int channel, boolean resetCounter)“ mehr vorgesehen hast ?

    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.

    16 hours ago, StefanOHAN said:

    Ich bekomme (nur) für das IO-16 V1 folgende Fehlermeldung im Log

     

    Quote

    2020-01-26 16:55:19.065 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Dual-Relais2': An error occurred during the script execution: Cannot convert number literal to typejava.lang.Short

    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.

     

    16 hours ago, StefanOHAN said:

    Ich hätte einen Alarm mit 1000Hz Startfrequenz, der jede Sekunde in 100 Hz Schritten bis 2500 Hz ansteigt und dies 10 Sekunden lang andauert. Es kommt aber nur ein kurzer 1000 Hz Ton dann fällt er wieder auf die Channel-Konfiguration zurück (Startfrequenz = 200Hz, Endfrequenz = 1000Hz, StepSize = 100 , StepDelay = 100 , DefaultVolumen = 1 , Duration = 5000)

    Wo liegt der Fehler in meiner Rule ?

    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.

     

    16 hours ago, StefanOHAN said:

    Einen Frage zu den Channel des MultiTouch V2

    Generell funktionieren bei mir die mit ITEM-Verlinken Channel, diese kann ich auch problemlos in Rules verwenden.

    Kann es sein, dass die Channel nicht direkt in einer Rule als Trigger genutzt werden können ?

    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

    12 hours ago, omiT said:

    In OH Control wird für Top Left, Top Right und Bottom Indicator immer 0 angezeigt. Muss das so sein?

    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

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    2 hours ago, StefanOHAN said:

    1) Bezüglich "Schema für ThingUID" : Ich habe die beiden Brick-Daemons (für WIFI & USB angeschlossene Master-Bricks) nicht "entfernt und neu hinzugefügt", nur die restlichen Tinkerforge-Things. Frage: könnte dies evtl später zu Problemen führen, bis jetzt funktioniert alles.

    Das sollte kein Problem sein, die ThingUID des Brick Daemons habe ich nicht verändert.

    2 hours ago, StefanOHAN said:

    2) wie oft/wann wird denn der "Sensor/Station Identifiers" des OutDoor Weather aktualisiert ? Nachdem ich den zweiten TH-6148-Sensor aktiviert hatte, könnte ich zwar über den Brickviewer dessen ID lesen, und mit dieser dann den Sensor in die Konfiguration einbinden, jedoch zeigte mir "Sensor Identifiers" nur die ID des bereits aktiven an. Nach ca 10 min habe ich das System 1 x rebootet (incl Stromabschaltung), danach wurden beide ID angezeigt. Wie gesagt den zweiten Sensor konnte ich funktionsfähig einbinden obwohl dessen ID noch nicht im Sensor-Identifier angezeigt wurde.

    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.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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.

    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.

×
×
  • Neu erstellen...