KNX Dimmer Status auslesen

[Buggyfahrer]

Hallo Zusammen,

Ich stehe irgendwie auf dem Schlauch, und wäre dankbar, wenn mich jemand in Richtung Lösung stupst:

Ich komme in der dunkeln Jahreszeit einfach besser aus dem Bett, wenn mit dem Wecker auch mein Schlafzimmerlicht angeht.

Also habe ich mir eine kleine Rule gebastelt, die genau dieses tut, Wochentags um 6:30 das Licht an machen.

rule "Wecker_ein"
when
    Time cron "0 30 6 ? * MON-FRI"
then
    logInfo("meine.rules", "Wecker")
    sendCommand(SZ_Decke, 90)
end

Dimmer SZ_Decke "Schlafzimmer Decke [%s]" (Lights) { knx="1/0/0+1/0/3, 1/0/1, 1/0/2+1/0/4" }

Das funktioniert auch so. So weit so gut.

Nun wird aber irgendwann das Frühjahr kommen und zu meiner Aufstehzeit hat Petrus dann bereits draußen das Licht angemacht, meine Rule braucht also nichts mehr zu tun. Also wäre es schön, wenn ich in die Rule eine Abfrage einbauen könnte (Im Frühjahr den Schaltbefehl auszukommentieren um ihn im nächsten Herbst wieder zu aktivieren, wäre irgendwie "unsmart"):

Wenn es draußen noch Dunkel ist, dann mache das Licht an.

Die Information "draußen noch Dunkel" steckt im KNX-Statusobjekt eines Nachtlichtes, das nachts leuchtet.

Dimmer SO_Nachtlicht "Nachtlicht [%s]" (Lights) { knx="14/0/0+14/0/3, 14/0/1, 14/0/2+14/0/4" }

Nur wie kriege ich die Information da raus? Sprich, wie kann ich die Statusobjekte (Ein/Aus und interessehalber auch den Helligkeitswert) von KNX-Dimmern auslesen.

Hinweise zu Beispielen und/oder auf die entsprechenden Stellen in der Doku wären als Hilfe zur Selbsthilfe hoch willkommen. "Notfalls" aber auch gerne passende Codeschnipsel.

Danke schon mal

Lars

[udo1toni]

Ich verstehe jetzt nicht so ganz... suchst Du tatsächlich einfach nur nach dem Status des Items?

rule "Wecker_ein"
when
    Time cron "0 30 6 ? * MON-FRI"
then
    if(!(SO_Nachtlicht.state instanceof Number))     // das Item wurde noch nicht initialisiert
        SO_Nachtlicht.sendCommand(0)                 // also nehmen wir an, dass das Licht aus ist
    if((SO_Nachtlicht.state as Number) != 0) {       // falls das Licht nicht aus ist
        logInfo("meine.rules", "Wecker")
        SZ_Decke.sendCommand(90)
    }
end

Die erste if-Anweisung fängt den Fehler ab, der entsteht, wenn SO_Nachtlicht seit dem Start von openHAB noch keinen gültigen Status erhalten hat.

[Julian0o]

Für die Initialisierung der Werte habe ich eine Regel die beim Event "System started" ausgelöst wird. Dann braucht man das nicht per Cron machen und regelmäßig erneuern wenn es gar nicht nötig ist. Fängst du zwar auch über die if Bedingung ab, aber die Regel muss ja erst gar nicht ausgelöst werden.

[Buggyfahrer]

udo1toni:

Ja, genau das war es, was ich suchte und irgendwie nicht finden konnte. Vielen Dank für den Code, ich habe ihn direkt übernommen.

Ich gehe davon aus, das in "SO_Nachtlicht.state" der Inhalt der GA 14/0/3 steckt, also der An/Aus Status des Dimmers.
Wie heißt den nun das Objekt für den aktuellen Dimmwert des Dimmers.

Gibt es irgendwo eine Doku in der ich das für die verschiedenen items nachlesen könnte?

Julian0o:

Soviel, das ich mein System damit übermäßig belaste, hat dieses noch nicht zu tun. Und die Routine wird auch ja nur einmal am Tag aufgerufen. Aber ich merke mir den Tipp gerne dafür, wenn sich das mal ändert. Vielen Dank dafür..

[Julian0o]

Ja aber das summiert sich irgendwann auf deswegen kann man direkt von Anfang an drauf achten. Und es gibt dir Komfortgewinn. Bei deiner Regel hast du im schlimmsten Fall 23:59 den Status nicht richtig im System.

[udo1toni]

Julian0o
Ich denke, hier liegt ein Missverständnis vor. Die Klausel

 if(!(SO_Nachtlicht.state instanceof Number))     // das Item wurde noch nicht initialisiert
        SO_Nachtlicht.sendCommand(0)                 // also nehmen wir an, dass das Licht aus is

ist lediglich für den Fall vorgesehen, dass das Item nicht initialisiert ist, aus welchen Gründen auch immer. Ich könnte eine Deinitialisierung erzwingen, indem ich vorher ein

SO_Nachtlicht.postUpdate(NULL)

absetze, das wird man natürlich nur tun, wenn man genau weiß, was und warum, der Punkt ist aber, dass man nicht einfach so davon ausgehen sollte, dass ein Item schon einen bestimmten Status haben wird, man sollte es sicherstellen.

Ich gehe davon aus, das in "SO_Nachtlicht.state" der Inhalt der GA 14/0/3 steckt, also der An/Aus Status des Dimmers.

Nein, das ist falsch. Es wird der Inhalt von 14/0/4 bzw. 14/0/2 gehalten. Es handelt sich um ein Dimmer Item, das kennt exakt 102 verschiedene Status, nämlich die Integerwerte 0-100 und NULL. Letzterer ist das Zeichen dafür, dass der Status nicht initialisiert (oder gezielt deinitialisiert) wurde, die anderen 101 Status stehen für die Helligkeit in %, wobei ein Befehl OFF zu einer Helligkeit 0 führt, und ein Befehl ON zunächst *) zu einer Helligkeit 100. Möchte man gezielt den ON/OFF-Zustand des Items sehen, muss man das mittels

SO_Nachtlicht.getStateAs(OnOffType)

erfragen. Allerdings ist es einfacher, auf 0 oder Ungleich 0 zu testen

*) openHAB aktualisiert default den Status des Items mit dem Befehl, bei einem Dimmer führt ON also zu 100. Man kann das mit dem "Bindingparameter" autoupdate="false" abschalten, dann ändert sich der Status nur durch den rückgemeldeten Status. Wenn man seine knx Dimmer auf eine Einschalthelligkeit <100 konfiguriert hat, wird diese Helligkeit angezeigt, sobald das entsprechende Telegramm von openHAB empfangen wurde.

[Julian0o]

Vielen Dank für deine Ausführungen! Es ist also etwas schwierig alle KOs zu benutzen so wie ich das sehe. Das führt bei mir zu einigen Problemen. Im KNX selbst ist alles super. Aber meine Anbindung an Alexa und Siri kommt dabei aus dem tritt. Wenn ich Siri z.B. sage "Schalte Licht im Schlafzimmer auf 10%" wenn es aus ist, dann geht das Licht erst auf auf volle Hütte an. Beim gleichen befehl dann noch mal direkt danach geht die Helligkeit auf 10%. Wenn ich sage "Schalte licht im Schlafzimmer an" dann geht es auf 100% obwohl ein ON befehl an den Aktor HCL starten sollte. Hab das jetzt nicht per ETS genau nachkontrolliert was wirklich gesendet wird, aber so sind meine Beobachtungen.

Das legt nahe das OH rein die Absolutwerte benutzt und der Switch Parameter ziemlich egal ist. Ein EIN befehlt sollte aber auch den Switch benutzen und nicht davon ausgehen das man 100% haben möchte. Meiner Meinung nach ist dann das Binding noch verbesserungswürdig. Komischerweise wird in der Doku ja genau diese Syntax angegeben. Bei mir sieht das durchweg so aus:

Type dimmer : Licht_Schlafen1_Spot "Spots Schlafen groß" [ switch="1/1/90+<1/1/93", position="1/1/92+<1/1/94", increaseDecrease="1/1/91" ]

Siehst du da Verbesserungspotential?

[udo1toni]

Andersherum wird ein Schuh daraus. Ein Switch Befehl kennt nur zwei Zustände (bzw. Befehle), nämlich OFF und ON. Diese beiden Befehle müssen bei einem Dimmer immer mit den Extremwerten gleichgesetzt werden, da dies das normale Verhalten eines Dimmers ist. Einschalten eines Dimmers führt normalerweise zu maximaler Helligkeit. Es gibt Dimmer, die kann man so konfigurieren, dass sie auf die zuletzt gewählte Helligkeit gehen (und bei knx Dimmern kann man im Allgemeinen gar eine feste Einschalthelligkeit vorgeben), aber das sind Spezialfälle.
Wenn ich über die UI einen Dimmer setze (also mit dem Slider) dann dimmt der Dimmer exakt diesen Wert an. In der UI wird aber kurz 100% angezeigt, weil openHAB gegen das Item ein postUpdate(ON) absetzt, welches dann natürlich als 100 interpretiert wird. Wenn der Dimmer seine Helligkeit erreicht hat, springt die Anzeige aber auf die gewählte Helligkeit, da der Dimmer selbst eine Rückmeldung sendet.
openHAB sendet genau den Befehl, der abgesetzt wird. Ein Slider Widget sendet ausschließlich Zahlen von 0 bis 100. Wenn Du zusätzlich ein Switch Widget mit dem Item verknüpfst, sendet dieser Switch ausschließlich ON oder OFF, und das wird dann auch an den Dimmer weiter gereicht (nicht 100 oder 0, da es ja explizit eine Switch GA gibt)

Selbstverständlich kannst Du alle KO verwenden, Du musst sie aber korrekt verwenden

Ein Dimmer hat typischerweise folgende KO (GA habe ich aus Deiner Konfiguration abgeleitet):

Name	DPT	GA	L-Flag
Ein/Aus	1.001	1/1/90
Absolutwert	5.001	1/1/92
Dimmen	3.007	1/1/91
Rückmeldung Ein/Aus	1.001	1/1/93	ja
Rückmeldung Absolutwert	5.001	1/1/94	ja

Die Rückmeldung Ein/Aus solltest Du schon mal weg lassen, diese Information ist grundsätzlich nicht notwendig, da sie aus der Rückmeldung Absolutwert abgeleitet werden kann und muss (sonst sendet knx ON als Rückmeldung an openHAB, welches daraus 100 macht).

Der Dimm-Befehl (increaseDecrease) funktioniert nur mit Dimmern, die kein Start/Stop Dimmen benutzen. Ob man den Befehl überhaupt braucht, hängt von der Verwendung der UI ab, denn in der Classic UI gibt es keinen Slider, stattdessen rendert das Slider Widget zwei Schaltflächen, über die dann mit kurzem Klick ein- und ausgeschaltet und mit langem Klick gedimmt wird.
Verwendet der Dimmer Start/Stop Dimming, funktioniert das nicht, da openHAB kein Stop-Telegramm senden kann, der Dimmer dimmt immer bis zum Anschlag, also entweder 0% oder 100%.
In knx verzichtet man also allgemein besser auf den Parameter increaseDecrease, es sei denn, man möchte auf den Steuerbefehl aus knx reagieren, z.B. einen Wandschalter als Dimmer konfigurieren und dann zur Steuerung der Lautstärke eines Audioplayers nutzen, dann muss openHAB natürlich den Befehl empfangen können (aber das ist ja dann kein echter Dimmer... und man muss dann als Channel Type dimmer-control verwenden).

Dein Channel sollte also vermutlich eher so aussehen:

Type dimmer : Licht_Schlafen1_Spot "Spots Schlafen groß" [ switch="1/1/90", position="1/1/92+<1/1/94"" ]

Das passende Item dazu wäre dann (Bridge und Thing geschätzt):

Dimmer Licht_Schlafen1_Spot "Spots Schlafen groß" ["Lighting"] {channel="knx:device:bridge:thing:Licht_Schlafen1_Spot",autoupdate="false"}

Das ,autoupdate="false" verhindert, dass openHAB aus einem ON-Befehl ein postUpdate(ON) generiert, damit springt die Anzeige also nicht hin und her.

Es ist natürlich Geschmacksache, wie man die Namen der Channel wählt. Ich habe eine strikt hardwarebezogene Konfiguration, d.h., ich verwende Hersteller, Typ und PA als Thing Namen und die Channel heißen dann einfach ch1 - chx, z.B.

Thing device hagerDim1_1_4 "Einzeldimmer" @ "KNX" [
    address="1.1.4",
    fetch=false,
    pingInterval=600,
    readInterval=0
 ] {
      Type dimmer : ch1 "Eltern Strahler" [ switch="8/5/0",position="5.001:8/5/2+<8/5/7" ]
  }

Das ergibt dann in den Items dies hier:

 Dimmer Einzeldimmer_Ch1 "Eltern Strahler" (GLights,GDimmer) {channel="knx:device:bridge:hagerDim1_1_4:ch1",autoupdate="false"}

Damit ist der Channel-Teil des Items kürzer, andererseits sehe ich direkt, welcher Aktor dahinter steckt.Den Zusammenhang zur Funktion habe ich dennoch in beiden Dateien, da es ja ein Label gibt...

Ich nutze keine Sprachsteuerung, so dass ich zu den speziellen Problemen, Alexa & Co. betreffend nichts beitragen kann, aber die grundsätzliche Funktion von Dimmern arbeitet in openHAB korrekt, das kann ich Dir versichern.