KNX-Dimmer mit OH3 wollen nicht so richtig

[Yankee0815]

Hallo zusammen,

ich weiß, das ist hier schon x-mal besprochen worden, aber ich komme da irgendwie nicht mit zurecht.
Ich habe frisch von OH2.5 auf OH 3 gewechselt.

Und nun bekomme ich die Dimmer nicht so richtig ans laufen:
Ich habe eine KNX Installation mit OH 3 als openhabian auf einem Raspi 4.
Folgende GRuppenadressen sind im Gebrauch:

Dimmer 1:
Ein/Aus (switch): 1/2/5
Dimmen (increase/decrease): 1/2/6
Wert (lesen, schreiben in Prozent): 1/2/13


Dimmer 2:
Ein/Aus (switch): 1/2/7
Dimmen (increase/decrease): 1/2/8
Wert (lesen,schreiben in Prozent): 1/2/14


Hier die Config von dem Channels:

Code: Alles auswählen

- id: Licht_UG_Wohnzimmer1
    channelTypeUID: knx:dimmer
    label: Dimmer 1 Wohnzimmer
    description: ""
    configuration:
      increaseDecrease: 1/2/6
      position: <1/2/13+<1/2/13
      switch: 1/2/5
  - id: Licht_UG_Wohnzimmer2
    channelTypeUID: knx:dimmer
    label: Dimmer 2 Wohnzimmer
    description: ""
    configuration:
      increaseDecrease: 1/2/8
      position: <1/2/14+<1/2/14
      switch: 1/2/7

Ich habe schon ziemlich mit den Dimmern und der Config gespielt und ausprobiert, aber ich komme da nicht weiter.
Das Dimmen über die Taster an der Wand klappt immer, muss ja.
Aber mit der Visu bekomme ich das nicht hin.
Ich nutze die Android-App und das Basic UI.

Wenn ich die Slider betätige, dann verändert sich auch die Helligkeit, das passt, der Wert in der Visu passt sich an.
Aber wenn ich dann die Taster an der Wand betätige, dann bekomme ich folgende Meldungen:
Ich bekomme 0% angezeigt für AUS
Ich bekomme 100% angezeigt für AN, Helligkeit egal
Und wenn ich über die Taster dimme, dann bekomme ich "-", also UNDEF

Was mache ich falsch, wo kann ich was besser machen?

Ich weiß da echt nicht mehr weiter....


Danke schonmal im voraus


Yankee

[udo1toni]

Das kann so, wie Du es beschreibst, noch nie funktioniert haben, denn Du hast schon von Beginn einen Fehler drin.

Es gibt in knx keine ungerichtete Kommunikation (außer bei Controllern, also z.B. Wandtaster). Ein Dimmaktor hat mehrere KO (Kommunikationsobjekte), das sind mindestens: Schalten (ON,OFF, nur empfangend), Schaltzustand (ON,OFF nur sendend), Helligkeit (0%-100%, nur empfangen),Helligkeitszustand (0%-100%, nur sendend) sowie relatives Dimmen (heller/dunkler, nur empfangend). Dies sind also 5 KO. In einer konventionellen Installation verwendet man davon mindestens zwei KO, nämlich Schalten und relatives Dimmen. Sobald man Ein-Tasten-Dimmen von mehreren Tastern aus verwendet, muss zwingend noch ein drittes KO verwendet werden, nämlich Schaltzustand. Grund: Wenn man einen Dimmer von OFF direkt dimmen lässt, so sendet der Taster keinen ON-Befehl. Somit wissen die übrigen Taster nicht, dass der Dimmer eingeschaltet wurde und ein kurzer Tastendruck auf einen anderen Dimmer schaltet den Dimmer EIN und nicht AUS. Es müssen dazu in jedem Taster auf dem Schalt-KO zwei GA eingetragen werden, die auf die beiden Schalt-KO des Dimmers gehen (sendende GA auf den Eingang des Dimmers, für die andere GA ist nur der Dimmer sendend).
In einer Umgebung mit UI will man absolut dimmen, nicht relativ. deshalb braucht man zwei weitere KO, nämich Helligkeit setzen und Helligkeit abfragen. Diese beiden KO müssen zwingend mit unterschiedlichen GA verbunden werden. openHAB benötigt also (für eine korrekte Funktion) zwingend zwei GA pro position-Parameter. Es darf keinesfalls zweimal die selbe GA angegeben werden. Es gibt pro Channel exakt eine GA, die gelesen wird, niemals(!) mehrere.

Der technische Ablauf muss folgender sein: Dimmvorgang wird gestartet (egal wie) -> Dimmer führt den Dimmvorgang aus -> Dimmvorgang wird beendet -> Dimmer meldet (auf einer exklusiven GA, nur für diesen Dimmer) seine aktuelle Helligkeit -> openHAB empfängt den neuen Helligkeitswert und setzt das Item passend.

[Yankee0815]

Hallo Toni,

schonmal Danke für die schnelle Antwort.
Ich habe mir schon sowas gedacht, das da noch die aktuelle Helligkeit fehlt....

Nun habe ich die Wago-SPS mit KNX-Klemme im Gebrauch, habe das auch alles programmiert.
Da habe ich auch den Dimmer verarbeitet, ich bekomme da nur nicht den aktuellen Wert als GA zurück.
Ich denke ich muss das noch was nachprogrammieren...

Aber ich denke das ist was für ein anderes Forum....


Dankeschön erstmal

[udo1toni]

Die Rückmeldungen von Absolutwerten werden gerne in der Grundkonfiguration vergessen, wenn nicht von Anfang an eine Visu integriert ist.
Mit der ETS ist das aber kein Ding, da nachzurüsten.

[Yankee0815]

HAllo Udo,

hat ein bisschen gedauert.
Ich musste die Rückmeldungen erst in der Codesys nachprogrammieren, wusste aber nicht mehr genau, wie das geht.
Nach mehreren Jahren kann man sowas wohl mal vergessen......

Mit ein bisschen Hilfe aus einem anderen Board hat es dann geklappt.
Der Absolutwert ist angelegt und der Channel ist angepasst.

Folgendermaßen habe ich das parametriert:

Code: Alles auswählen

1/2/5
The group address(es) in Group Address Notation to toggle the dimmer on or off


1/2/13+<5/1/48
The group address(es) in Group Address Notation to set the absolute position of the dimmer


1/2/6
The group address(es) in Group Address Notation to increase or decrease the dimmer

5/1/48 ist der Absolut-Wert.

Und ich muss sagen, einwandfrei!!!
Endlich funktionieren die Dimmer, wie ich das möchte...


Vielen Dank nochmal!
So kann das neue Jahr kommen....



Gruß
Yankee

[udo1toni]

Guten Rutsch!

[WolfNRW]

Hallo zusammen,
zunächst mal noch ein frohes neues Jahr!
Ich habe (fast) das gleiche Problem, vermute bei mir aber grundlegend eine andere Ursache (ich hänge die Frage trotzdem mal hier an, weil ich nicht sicher bin, ob dafür ein eigener Thread sinnvoll ist - sonst bitte verschieben):
Ich habe jetzt schon 2 Varianten probiert, die beide nicht funktionieren. Alles KNX-Zeugs hängt bei mir über eine Bridge im Netz.
Grundsätzlich funktioniert das Senden und Empfangen von KNX-Telegrammen über diese Bridge, denn die Schaltaktoren z.B. lassen sich problemlos ansprechen (und Stati zurücklesen).
Heißt, egal ob der Aktor von einem KNX-Taster aus geschaltet wurde oder aus der OpenHAB-GUI heraus, passen die "Status-LED's" in der GUI und auch am Taster ...
Aber beim Versuch etwas über HAB zu Dimmen geht bei mir gar nichts. Ich bin ziemlicher HAB-Neuling, und könnte in dem Fall ein wenig "Anschubhilfe" gebrauchen.

Folgende "Konfiguration" ist aktuell implementiert:
Als "Thing" ist ein KNX-Dimmer eingetragen:

Code: Alles auswählen

UID: knx:device:258b31a8a3:fc618_AKD-0401
label: KNX_Dimmaktor_OG_AKD-0401
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  address: 1.1.14
  readInterval: 0
  fetch: true
bridgeUID: knx:ip:258b31a
location: OG
channels:
  - id: OG_CH_A
    channelTypeUID: knx:dimmer
    label: OG_CH_A
    description: ""
    configuration:
      increaseDecrease: 3.007:3/2/4 //IncDec
      position: 5.001:3/1/4+<3/4/54  //position
      switch: 1.001:3/0/54 //switch
  - id: OG_CH_C
    channelTypeUID: knx:dimmer
    label: OG_CH_C
    description: null
    configuration:
      increaseDecrease: 3.007:3/2/6 //IncDec
      position: 5.001:3/1/6+<3/4/56  //position
      switch: 1.001:3/0/56 //switch

Eigentlich wollte ich "increaseDecrease" gar nicht nutzen und hatte dafür auch gar keine GA's im ETS angelegt, habe das aber nun mal testweise "nachgezogen", allerdings ohne erkennbare Besserung ...
Dann habe ich in meiner "Items-Datei" folgende Einträge für die zwei Dimm-Kanäle:

Code: Alles auswählen

 
[...]
Dimmer Licht_OG_ArbZi	    "Licht ArbZi Dimmer" <light> (gOG, gOGLicht, OG_ArbZi)
Dimmer Licht_OG_SchlafZi	"Licht SchlafZi"     <light> (gOG, gOGLicht, OG_SchlafZi)
[...]

Und dann habe ich (naiver Weise) wie auch bei Schaltern (z.B. "Switch Licht_OG_ArbZi2 "Licht ArbZi2" <light> (gOG, gOGLicht, OG_ArbZi")) die jeweiligen Items mit den Channels der ensprechenden "Things" verknüpft und bekomme die auch vernünftig in die Visu.

Änderungen am "Slider" bewirken nichts, ein mal neu eingerichtetes "Schalt-Item" mit Verknüpfung rein auf den "Dimm-Switch-Channel" ebenfalls nicht.
Was ich mit nichts meine:
Bereits herausfinden konnte ich, dass Änderungen am Slider (u.a. Switch) zu keinem Senden von Befehlen über die Bridge führt, denn die dort befindlichen Send-/Rcv-LEDs blinken in diesem Fall nicht (anders als beim Ansteuern von Schaltaktoren)...
Der Dimmaktor selber wird mir aber in der "Things-Übersicht" als genauso "ONLINE" angezeigt, wie alle anderen angeschlossenen und eingerichteten KNX-Komponenten auch. Wo steckt also der Denkfehler bzw. hängt's in der Syntax, dass das KNX-Binding hier die Änderungen an den Items nicht auf die Hardware schaufelt?

Herzlichen Dank für Eure Unterstützung schon mal im Voraus!!

[WolfNRW]

Nachtrag: Ich habe auch eine GA für "Dimmer On/Off-Status" im ETS angelegt und hatte diese ebenfalls mal mit im "Thing" bzw. "Channel" eingetragen; also z.B.:

Code: Alles auswählen

position: 5.001:3/1/4+<3/4/54  //position
      switch: 1.001:3/0/54+<3/4/44 //switch

Aber auch das hat keinen Unterschied ausgemacht.

Wie schon beschrieben vermute ich aber ein Grundsatzproblem was die Kopplung GUI->THING->BINDING->KNX-DEVICE angeht - nur geht mir langsame die Phantasie aus, wo / wie ich noch weiter suchen / debuggen kann ...

BTW:
Im Eventlog sehe ich z.B. folgendes, wenn ich einen der Dimm-Slider bewege:

Code: Alles auswählen

2022-01-10 21:46:18.165 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Licht_OG_ArbZi' received command 35
2022-01-10 21:46:18.168 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Licht_OG_ArbZi' predicted to become 35
2022-01-10 21:46:18.175 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Licht_OG_ArbZi' changed from 16 to 35

Kann ich irgendwie über die Linux-Konsole noch tiefer / anders debuggen?! Z.B. um herauszufinden, warum da nichts gesendet wird?

[int5749]

Wie schon beschrieben vermute ich aber ein Grundsatzproblem was die Kopplung GUI->THING->BINDING->KNX-DEVICE angeht - nur geht mir langsame die Phantasie aus, wo / wie ich noch weiter suchen / debuggen kann ...

Meine Dimmer Konfig weicht von Deiner ab.

zum einen würde ich mal

address: 1.1.14

entfernen, dies wird in der Regel nicht benötigt. (warum? die können anderen besser beantworten )

Ob es sinnvoll/notwendig ist den Typ beim Switch mit anzugeben, kann ich ebenso nicht beantworten, aber ich verfahre nach dem Prinzip "so viel wie nötig, aber so wenig wie möglich" und bisher funktionieren die Dimmer damit seit Jahren ohne Probleme.
Da ich zwar eigentlich über Text-Files konfiguriere, hier anbei die Sniplets aus der Main UI.

Mein Thing

Code: Alles auswählen

UID: knx:device:bridge:ABB_0_0_37
label: ABB UD S2.300.1
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  readInterval: 0
  fetch: false
bridgeUID: knx:ip:bridge
location: Hausanschlußraum
channels:
  - id: ch1
    channelTypeUID: knx:dimmer
    label: Wohnzimmer Tisch
    description: null
    configuration:
      increaseDecrease: 1/1/16
      position: 1/1/20+<0/4/51
      switch: 1/1/0+<0/4/4

Bei Deinem geposteten Item fehlt mir der Link zum Channel
Bei mir sieht dies dann so aus ....

Code: Alles auswählen

Dimmer Lampe_Wohnzimmer_Tisch	"Wohnzimmer Tisch[%d %%]"	<light>		(EG_Wohnen, Lampen, gGroundLiving)		["Lightbulb"]			{channel="knx:device:bridge:ABB_0_0_37:ch1"}

In der Sitemap habe ich dann nur einen Slider und kann dort entsprechend wählen, kann aber die gewünschte Helligkeit als Wert 0-100 senden oder stumpf "ON" oder "OFF". Dies alles mit nur 1 Item.

Evtl. hilft dies weiter.

[udo1toni]

Ich verwirre mal... address 1.1.14 kannst Du stehen lassen (so das auch die korrekte physikalische Adresse des Dimmaktors ist). fetch solltest Du aber unbedingt auf false setzen. fetch ruft zusätzliche Informationen zum Device ab, die aber für die Funktion von openHAB komplett irrelevant sind. Nicht alle Devices kommen mit der Anfrage klar, insofern sollte diese Funktion grundsätzlich erst mal aus sein.
Ich hoffe mal, die Kommentare, die Du im code stehen hast, stehen nur hier im Forum drin?
Weiterhin möchte ich empfehlen, die DPT nur dann anzugeben, wenn dies unbedingt notwendig ist. Da hier überall die Standard DPT verwendet werden, sollte es ohne gehen.

Bitte pro Channel nur exakt eine Rückmelde-GA angeben (das ist position), das angebundene Item kann nur einen Status halten, nicht deren zwei.

Leider fehlt die Definition der Bridge, das wäre wichtig. Seltsamerweise passen UID und bridgeUID bei Deinem Thing nicht zueinander, das darf eigentlich nicht passieren. Es wäre sinnvoll, die Bridge neu anzulegen und dabei eine sinnvolle UID zu erzeugen. Gleiches gilt sinngemäß für das Thing. Beim Anlegen des Thing kann man die UID frei setzen (natürlich nur den Teil, der das Thing selbst benennt).