KNX auf Openhab

[udo1toni]

Wie erwähnt... Bitte ändere den knx Type number mal auf number-control ab. Denke auch daran, dass die Änderungen höchstwahrscheinlich erst nach einem openHAB Neustart berücksichtigt werden.


Gesendet von iPad mit Tapatalk

[Philipp00]

Sry das mit dem Control wars wohl, was hat es mit dem Control aufsich, wo macht dies überwall Sinn?

[udo1toni]

NEIN! Die -control Channel von knx drehen das Verhalten von openHAB um.

Das normale Verhalten: openHAB verhält sich z.B. wie ein Lichtschalter, es sendet Befehle (sendCommand) an an knx und wertet ankommende Telegramme ausschließlich als Status (Trigger: received update, changed)
Das umgekehrte Verhalten (*-control): openHAB verhält sich wie ein Aktor, es sendet Status Updates an den Bus (postUpdate) und interpretiert ankommende Telegramme ausschließlich als Befehle (Trigger: received command). Und genau so werden ankommende Telegramme auch weitergeleitet.

Da das mqtt Addon die Temperatur als Status an openHAB sendet, leitet openHAB dieses Status Update mit dem *-control Channel direkt an knx weiter.

[Philipp00]

Habe wieder mal eine KNX Problem.
Es geht um folgendes, ich schalte über KNX ein Shelly Aktor, nun liegt das Problem beim Status, wenn ich das Licht über einen KNX Taster schalte wird der Status auf OH nicht erkannst und ungekehrt, wenn ich direkt mit dem Taster am Shelly oder über den Shelly Sensor geschaltet wird muss ich danach den Taster am KNX zwei mal drücken.
Meiner Ansicht nach hat das mit dem Status zutung (KNX Gruppenadresse 1/7/1) nun bin ich mir aber nicht sicher wie ich dies umsetzen soll.

Code: Alles auswählen

    Thing device BedienpanelZimmer "Bedienpanel Zimmer" @ "KNX" [ 
     ] {    
        Type switch                 : ch1   "Kanal 1"                         [ ga="1/1/1+<1/7/1" ]

Code: Alles auswählen

rule "Alarm Feuchtigkeit"
when  
  Item HBadklein changed // hier wird auf das Ereignis getriggert.    
then 
      if (HBadklein.state >= 50) { 		// hier wird geprüft ob das Ereignis zutrifft 
      // und zwischen den geschweiften Klammern wir der Code ausgeführt
      //sendCommand (BuroBBeleuchtungBuero, ON)
      BuroBBeleuchtungBuero.sendCommand(ON)
      
      logInfo("Beleuchtung Büro","Eingeschaltet.")
	}
      else 
      {
      BuroBBeleuchtungBuero.sendCommand(OFF)

      logInfo("Beleuchtung Büro","Ausgeschaltet.")  
      }        
end

[ibot1989]

Kannst du nicht den "Umweg" über OpenHAB machen.
Also nicht direkt aus KNX den Shelly schalten, sondern über eine Rule durch den KNX Schalter den Shelly schalten lassen.

Oder habe ich dein Post falsch verstanden?

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

[Philipp00]

Den mache ich ja, aber weiss nicht genau wo das Problem liegt..

[ibot1989]

Okay, dann habe ich dich falsch verstanden.

Wird den der Status vom Shelly in OpenHAB korrekt übermittelt, wenn du über den angeschlossenen Schalter direkt in OpenHAB schaltest?

Schaltest du evtl. den falschen Channel? (Den Input statt das Relay?)

Kannst du uns hier nochmal deine Item Konfiguration anhängen und evtl. ein Beispiel Ablauf aus deinen Logfiles, wo es nicht korrekt funktioniert?

Aktuell kann ich mir das aktuell nicht erklären, da gerade der Weg über die Rule eindeutig sein müsste und daher der Status passen muss und ich ehr andersrum (schalten am Shelly direkt) Probleme erwarten würde.

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

[udo1toni]

Nein, die Lösung ist hier eine andere.

Es ist wirklich wichtig, zu verstehen, wie die Rollen hier verteilt sind.

Gewöhnlich tritt openHAB gegenüber angeschlossenen Geräte wie ein Schalter auf. Das Gerät wird von openHAB geschaltet, das Gerät meldet seine neue Schaltstellung an openHAB, welches die neue Schaltstellung anzeigt.

Hier ist es aber (in Richtung knx) umgekehrt, das heißt, openHAB tritt gegenüber knx als Aktor auf. Das knx Device ist der Schalter, der openHAB schaltet, openHAB liefert den Status an knx.

Daraus ergeben sich zwei Dinge:

1. Das Status kommt nicht von knx und darf auch nicht von dort gelesen werden (es darf kein < Zeichen gesetzt werden)
2. Die Status-GA muss an 1. Stelle stehen, die Steuer-GA (welche den Befehl sendet), muss an 2. Stelle stehen, denn openHAB sendet (wie alle knx Geräte) ausschließlich auf der jeweils 1. GA.

Bei verschiedenen Bindings gibt es da durchaus Schwierigkeiten, ausgerechnet im Zusammenhang mit knx ist es aber sehr einfach, dieses Problem zu lösen, und zwar, indem der Channel korrekt konfiguriert wird, als switch-control Channel:

Code: Alles auswählen

Thing device BedienpanelZimmer "Bedienpanel Zimmer" @ "KNX" [ 
     ] {    
        Type switch-control         : ch1   "Kanal 1"                         [ ga="1/7/1+1/1/1" ]

Es reicht nun streng genommen eine Verlinkung zwischen dem knx Channel und dem Item, welches bereits mit dem Shelly Aktor gekoppelt ist. Der knx Taster braucht kein eigenes Item!

Das Bedienpanel sendet GA 1/1/1 an openHAB. Dort kommt der Wert als Command an(!). Das Command wird an das zweite verknüpfte Addon weitergereicht, welches den Schaltbefehl ausführt. Daraufhin wechselt der Status des Items. Der Status wird umgehend an knx gesendet.

Möchtest Du es per Rule lösen, so brauchst Du auf jeden Fall zwei Rules, eine, die den Befehl von knx an den Aktor weiterleitet, eine weitere, die den Status des Aktors an knx sendet.

Die von Dir gepostete Rule hat allerdings nichts mit dem Panel zu tun