Dimmer rule für Tastenbefehl On/OFF

[hartmut]

Hallo zusammen,

ich benutze openHAB in Verbindung mit der CometVisu.
Wenn ich mit der visu einen Dimmwert schicke dann wird der Wert richtig übertragen und der Dimmer wird auf den richtigen Wert gestellt.
Das funktioniert bis auf meine Schalter die davon nichts mitbekommen und somit nicht die Led einschalten.
Ich habe ein rule erstellt das dies lösen soll und nach Empfang eines Dimmwertes einen ON oder OFF Schaltbefehl schicken soll.
Das funktionier auch, doch die beiden Abfragen >0 und != 0 funktionieren nicht, es wird immer ein Schaltbefehl zum Dimmwert zusätzlich gesendet, wenn der Dimmwert verstellt wird.

rule "ll"
when Item Licht_WG_Wohnzimmer_LL received command
then
if(receivedCommand instanceof PercentType) {
if (receivedCommand==0) {
if (Licht_WG_Wohnzimmer_LL!=OFF) {
sendCommand(Licht_WG_Wohnzimmer_LL, "OFF")
}
}
if (receivedCommand>0) {
if (Licht_WG_Wohnzimmer_LL!=ON) {
sendCommand(Licht_WG_Wohnzimmer_LL, "ON")
}
}

}
end

ich habe auch schon if (Licht_WG_Wohnzimmer_LL.status!=ON) { ... probiert mit dem gleichen Ergebniss

[udo1toni]

Hast Du KNX? Dann solltest Du auf KNX-Seite den Dimmerzustand (ON/OFF) an die Taster rückmelden (als 2., nicht-sendende GA eintragen).

Du kannst auch in der event.log nachschauen, was auf Licht_WG_Wohnzimmer_LL tatsächlich empfangen wird. Die Frage ist auch, ob receivedCommand überhaupt der richtige Trigger ist. Du hast wahrscheinlich die Dimmer so konfiguriert, dass sie mit dem letzten gewählten Helligkeitswert einschalten, sonst würdest Du vermutlich noch darüber stolpern, dass der Dimmer immer auf den Standard-Einschaltwert springt, sobald Du dimmst - egal ob über die UI oder über einen Raum-Taster.

[hartmut]

Das dumme ist dass der Dimmerzustand auf der KNX Seite nur als 8 Bit Wert ´vorhanden ist. Auf der KNX Seite erscheint nur DImmwert setzen (1 Byte) der Dimmer geht an, sonst bekomme ich keine Meldung.
Im Event.log erscheint "Licht_WG_Wohnzimmer_LL received command 39", dies sind die 39% die ich am Schieberegler einstelle (CometVisu) auf der KNX Seite erscheint dann Dimmwert setzen mit 99 Impulse. Über den Raumtaster springt der Dimmer auf den letzten Wert, über die UI auf den Wert den ich einstelle. Ich habe auf der UI Seite keinen Switch sondern nur den Schieberegler. Über ein rule werde ich noch den Status auslesen wenn der On / Off Befehl empfangen wird, dann ist auch in der UI der Schieberegler richtig.

[udo1toni]

Also, Du kannst mit folgender Rule versuchen:

rule "test"
when
    Item Licht_WG_Wohnzimmer_LL changed
then
    if (Licht_WG_Wohnzimmer_LL.state as DecimalType!=0) {
        if (Licht_WG_Wohnzimmer_LL.previousState==OFF) {
            var int LL_state=(Licht_WG_Wohnzimmer_LL.state as DecimalType).intValue
            Licht_WG_Wohnzimmer_LL.sendCommand(ON)
            Licht_WG_Wohnzimmer_LL.sendCommand(LL_state)
            }
        }
    else
        Licht_WG_Wohnzimmer_LL.sendCommand(OFF)
end

Es kann sein, dass Du dafür das Item persistieren musst (hab das nicht ausprobiert, könnte sein, dass es auch so geht, also vorausgesetzt, es gab bereits eine Änderung)
Die Idee ist, dass Du erstmal auf Änderung triggern lässt, nicht nur auf empfangene Befehle. Wenn der vorherige Zustand OFF war, soll die Rule sich den aktuellen Wert merken, den ON-Befehl schicken und anschließend den alten Wert wiederherstellen (nur zur Sicherheit, siehe erster Post). Wenn der Wert 0 ist, ist diese Unterscheidung natürlich unnötig, denn da es eine Wert-Änderung gab, muss der Wert vorher ungleich 0 gewesen sein.

[hartmut]

Ich habe das mal probiert aber der vorherige Status ist immer null.

 rule "test"
  when
      Item Licht_WG_Wohnzimmer_LL changed
  then
      if (Licht_WG_Wohnzimmer_LL.state as DecimalType!=0) {
          logInfo("ll.rules","vorheriger status:"+ Licht_WG_Wohnzimmer_LL.previousState)
          if (Licht_WG_Wohnzimmer_LL.previousState==OFF) {
              var int LL_state=(Licht_WG_Wohnzimmer_LL.state as DecimalType).intValue
              Licht_WG_Wohnzimmer_LL.sendCommand(ON)
              Licht_WG_Wohnzimmer_LL.sendCommand(LL_state)
              }
          }
      else
          Licht_WG_Wohnzimmer_LL.sendCommand(OFF)
  end

[udo1toni]

Ich habe das mal probiert aber der vorherige Status ist immer null.

Ja, dann musst Du das Item persistieren, also z.B. mit rrd4j mit der Strategie everyChange (rrd4j weil da die Dateigröße fix ist)
Achte auch drauf, dass rrd4j der Standard-Persistence-Service ist, sonst musst Du vermutlich dem .previousState noch die Information mitgeben, dass er rrd4j verwenden soll, um den letzten Wert zu erhalten.

Aber wie ich im ersten Posting schon erwähnte: der bessere Ansatz wäre natürlich, das in KNX korrekt umzusetzen, oder hast Du keine ETS?

[hartmut]

Doch eine ETS habe ich, aber der Dimmer gibt als Status nur 1 Byte zurück und nur auf Anfrage. Siehe Post #3

[udo1toni]

Was ist das denn für ein Dimmer?

[hartmut]

Es ist ein Siemens Schalt- /Dimmaktor 5WG1 525-1AB01 für die Ansteuerung meiner Leuchtstoffröhren 1..10V.
Mir wäre es auch lieber wenn es auf der KNX Seite funktionieren würde.

[hartmut]

So jetzt habe ich nochmals geschaut, in der ETS war bei dem Dimmer nicht das Ü Flag gesetzt. Jetzt geht es, bin am Testen.

Wenn ich mit der Visu den Schieberegler betätige gehen die LED der Schalter an und aus, wie gewünscht. Wenn ich an den Schaltern ein / aus schalte geht die Lampe auf den zuletzt eingestellten Wert, aber in der Visu geht dann der Schieberegler auf 100%.
Da sollte mit einer Rule der Status ausgelesen werden.
Gibt es einen Befehl zum auslesen ich finde nur sendCommand?

[udo1toni]

Ein aktives gezieltes Abrufen von GA ist im laufenden Betrieb nicht vorgesehen, allerdings gibt es offiziell den Wunsch danach, wenn Du die Nightly-Version einsetzt, kannst Du zumindest autorefresh nutzen. Infos aus dem github-Issuetracker: https://github.com/openhab/openhab/pull/1681

Soweit ich die Produktbeschreibung von Siemens verstanden habe, schickt der von Dir verwendete Dimmer den aktuellen Wert nur auf Anfrage (was auch immer sich die Entwickler dabei gedacht haben).

Die Nightly-Version ist übrigens im Allgemeinen genauso stabil, wie die offiziellen stable-Releases (es gibt ab und zu mal einen Ausreißer, ist aber eher selten), dafür hat man aber immer die aktuellen Möglichkeiten zur Verfügung.

[hartmut]

Ja das mit dem autorefresh wäre aber keine gute Lösung da müsste ich die Abfrage Intervalle sehr kurz machen. Wenn ich den Dimmer mit den Tastern dimme werden ja nur In- /Decrase Telegramme empfangen und die Visu Stellung stimmt auch wieder nicht.
Das beste ist ich hoffe, dass einmal ein Abrufen eines Wertes implementiert wird und es dann mit einer rule möglich ist einen Status zu lesen, oder ich kaufe mir einen anderen Dimm Aktor der das kann.

[udo1toni]

Die Frage ist ja eher, was "sehr kurz" in dem Zusammenhang bedeutet, und ob Du tatsäclich sekundengenau den aktuellen Dimmwert in der UI brauchst. Keine Frage, ideal ist es nicht, aber besser als "geht nicht" allemal, und wenn der Dimmwert z.B. alle 30 Sekunden abgerufen wird, sollte das (solange es anders nicht geht) akzeptabel sein. Dass die Anzeige dann zeitweise nicht korrekt ist, ist klar. Aber wenn jeder Anwender das weiß, ist es zu verschmerzen (meiner Meinung). Was die falschen Werte durch Tastersteuerung betrifft, könntest Du den Dimmwert schätzen, indem Du die Zeit vom Dimmstart-Telegramm bis zum Dimmstop-Telegramm misst und per Rule den "korrekten" Dimmwert zurück schreibst. (per postUpdate, dann wird der echte Wert nicht falsch korrigiert). Wobei ich erstmal keine Ahnung habe, wie man sowas per Rule umsetzt. Leider wird dieser Trick für die UI nicht funktionieren, denn openHAB sendet kein Stop-Telegramm am Ende des Dimmvorgangs (weshalb ich nicht relativ dimmen kann, meine Hager-Dimmer benötigen zwingend das Stop-Telegramm)

[hartmut]

Ja da hast du recht, ich werde das mal testen. Da es den Lesebefehl ja schon gibt (<) sollte es doch einfach sein diesen auch in die rule zu implementieren. Mal hoffen ob ein Entwickler sich dem annimmt.

[udo1toni]

Naja, das < zeigt ja nur an, dass openHAB beim Start versuchen soll, den Status zu erfragen. Aber ja, der Wunsch nach einem individuellen Statusupdate auf Nachfrage besteht auch bei anderen. Wie allerdings die Priorisierung aussieht...