Raffstore mit MDT Aktor und openHAB 3

[sushiprinz]

Hallo,

leider bekomm ich die Steuerung der Raffstores mit openHAB 3 nicht richtig hin.

GAs
Unbenannt.GIF
Things

Type rollershutter: channel_beschattung_EG_Kueche_Nord_Ost_Jalousie "EG Küche Nord-Ost Jalousie" [ upDown="1/0/20", stopMove="1/0/21", position="5.001:1/0/22+<1/0/24" ]
Type number: channel_beschattung_EG_Kueche_Nord_Ost_Lamellenposition "EG Küche Nord-Ost Lamellenposition" [ ga="5.001:1/0/23+<5.001:1/0/25" ]

Items

Rollershutter item_beschattung_EG_Kueche_Nord_Ost_Jalousie "EG Küche Nord-Ost Jalousie [%d %%]" <rollershutter> (group_beschattung_eg) {channel="knx:device:bridge:thing_jalousieaktor_eg:channel_beschattung_EG_Kueche_Nord_Ost_Jalousie", autoupdate="false"}
Number item_beschattung_EG_Kueche_Nord_Ost_Lamellenpositi on "EG Küche Nord-Ost Lamellenposition [%d %%]" {channel="knx:device:bridge:thing_jalousieaktor_eg:channel_beschattung_EG_Kueche_Nord_Ost_Lamellenposition", autoupdate="false"}

GUI
Unbenannt2.GIF

Wenn ich dann einen Wert setze in der GUI, kommt auch ein Eintrag im events.log:

2021-07-18 15:28:18.246 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'item_beschattung_EG_Kueche_Nord_Ost_Lamellenposition' received command 25

Allerdings kommt nichts im Bus an. Eine Vermutung ist der Typ Number: Viele Beispiele hier im Forum sind mit 2 Rollershuttern. Aber eigentlich braucht man ja AUF/AB und STOP nicht bei der Lamelle!? Hat jemand eine Idee, warum es nur mit einer %-Number nicht geht?

Vielen Dank vorab für die Hilfe!

[TomW80]

Aber eigentlich braucht man ja AUF/AB und STOP nicht bei der Lamelle!?

Warum denn nicht? Du willst die Lamelle doch auch mal Auf/Zu fahren oder willst Du immer den Wert angeben?

Ich hab es so: (OH2. 5)

Type rollershutter : ChannelB_1 "Jalousie Wohnzimmer Süd 3M1" [ upDown="2/2/31+<2/0/0+<2/0/1+<2/0/3+<2/0/6+<2/2/30", stopMove="2/3/31+<2/1/0+<2/1/1+<2/1/3+<2/1/6+<2/3/30", position="2/4/3+<2/7/3" ]
Type rollershutter : ChannelB_2 "Lamelle Wohnzimmer Süd 3M1" [ upDown="2/3/31+<2/0/0+<2/0/1+<2/0/3+<2/0/6+<2/2/30", stopMove="", position="2/5/3+<2/7/4" ]

[udo1toni]

Number kann nicht gut mit Prozentwerten umgehen. Nimm ein Dimmer Item, das sollte funktionieren.

[McMaster05]

Ich hab es so: (OH2. 5)

Type rollershutter : ChannelB_1 "Jalousie Wohnzimmer Süd 3M1" [ upDown="2/2/31+<2/0/0+<2/0/1+<2/0/3+<2/0/6+<2/2/30", stopMove="2/3/31+<2/1/0+<2/1/1+<2/1/3+<2/1/6+<2/3/30", position="2/4/3+<2/7/3" ]
Type rollershutter : ChannelB_2 "Lamelle Wohnzimmer Süd 3M1" [ upDown="2/3/31+<2/0/0+<2/0/1+<2/0/3+<2/0/6+<2/2/30", stopMove="", position="2/5/3+<2/7/4" ]

TomW80, könntest Du bitte mal einen Screenshot von Deinen Gruppenadressen in der ETS machen? Ich hoffe, dann würde ich Deinen Notationen verstehen und könnte das bei mir in OH3 mal versuchen.
Für die Steuerung der Glastaster habe ich nur 3 GAs im Einsatz:

1. Jalousie AUF / AB
2. Lamellenverstellung / Stopp
3. Status aktuelle Position

Damit kann ich am Glastaster hoch/runterfahren, stoppen, und per kurz hoch/runter die Lamellen verstellen. Das ist eigentlich alles was ich brauche. Leider bekomme ich das aber in OH3 nicht hin und erhoffe mir, dass Deine Gruppenadressen da etwas Licht ins Dunkel bringen. Danke

[udo1toni]

Also, grundsätzlich...

< kennzeichnet GA, von denen ein Status aktiv gelesen werden kann.
upDown hat allenfalls insofern einen Status, als dass die letzte Fahrtrichtung angegeben werden kann. Da es sich um eine binäre Information handelt, fehlt ein Wert, denn ein Rollladen kann fahren oder stehen, die Fahrt kann in zwei Richtungen stattfinden. Insofern ist es nicht sinnvoll, hier überhaupt eine GA lesbar anzugeben.
Gleiches gilt entsprechend für stopMove, auch hier gibt es allgemein keine Rückmeldung, die sinnvoll verwertbar wäre.

Auch eine 2. GA in einem der beiden Felder zu hinterlegen ist nicht sinnvoll, gesendet wird sie nicht und openHAB sollte auf diese GA ohnehin nicht reagieren.

Abgesehen davon kann es immer nur einen Chef geben. Ein einzelner Channel sollte exakt eine GA lesbar hinterlegt haben, dabei kommt es vor allem darauf an, um was für einen Typ es sich handelt. Bei einem Rollershutter Channel ist ausschließlich die Behanghöhe als lesbare GA sinnvoll, denn das Item speichert genau diese Information. Bei einem Dimmer könnte man alternativ auch den Switch Zustand als lesbar eintragen, aber man möchte ja eigentlich die exakte Helligkeit haben, die wird aber nicht vom switch geliefert.

Wie oben erwähnt möchte ich dazu raten, statt number einfach dimmer zu nehmen. Alternativ kannst Du natürlich auch einen weiteren rollershutter Channel verwenden und eben upDown mit der stopMove-Adresse belegen (oder diesen Teil der Konfiguration komplett weg lassen, weil Du vielleicht nur mit absoluten Lamellenpositionen arbeiten willst)

[TomW80]

TomW80, könntest Du bitte mal einen Screenshot von Deinen Gruppenadressen in der ETS machen?

Bitte sehr:

ETS WZ Jalousie.JPG

[udo1toni]

TomW80 Hast Du mal einen Blick in openhab.log geworfen, nachdem Du das System neu gestartet hast? Dort wird es zu jeder GA, der Liste, bei der kein L-Flag gesetzt ist, die aber mit einem < gekennzeichnet ist eine Fehlermeldung geben, weil der Bus nicht auf die Leseanfrage antwortet. Es sei denn natürlich, das L-Flag ist in einem anderen Device gesetzt, was bei einer Command-GA eine schlechte Idee ist.

[TomW80]

TomW80 Hast Du mal einen Blick in openhab.log geworfen, nachdem Du das System neu gestartet hast? Dort wird es zu jeder GA, der Liste, bei der kein L-Flag gesetzt ist, die aber mit einem < gekennzeichnet ist eine Fehlermeldung geben, weil der Bus nicht auf die Leseanfrage antwortet. Es sei denn natürlich, das L-Flag ist in einem anderen Device gesetzt, was bei einer Command-GA eine schlechte Idee ist.

Meinst Du diese Fehlermeldung?

2021-05-21 00:00:27.019 [WARN ] [nx.internal.client.AbstractKNXClient] - Giving up reading datapoint 2/0/0, the number of maximum retries (3) is reached.

Heißt das ich kann die GAs bei denen kein L-Flag gesetzt ist weglassen?

[udo1toni]

Du kannst alle GA weg lassen, die nicht zwingend notwendig sind.
Das heißt, bei einem Channel Parameter, der nur zum Steuern von knx Komponenten verwendet wird, reicht eine GA.
Bei Channel Parametern, die zusätzlich eine Rückmeldung liefern sollen, reichen zwei GA, die erste zum Steuern des Geräts, die zweite zum Setzen des Status in openHAB.
Die Rückmeldung darf nur vom Aktor kommen, der auch der "Besitzer" des Kanals ist, also z.B. der Rückmeldekanal eines Relais Aktors. Über diesen wird immer zu jeder Zeit der echte Schaltzustand gemeldet, unabhängig davon, wodurch der Schaltzustand herbeigeführt wird (direkter Schaltbefehl, Szene, Zwangssteuerung, Aktor-interne Steuerung, z.B. durch Zeitsteuerung...).
Das Gleiche gilt sinngemäß für alle Arten von Aktoren. Ein Dimmer hat die Helligkeit als Status, nichts anderes. Ein Rollladenaktor hat ausschließlich die Behanghöhe als Status (auch wenn es noch andere Status vom Aktor gibt, ist dies der einzige Status, der in openHAB gespeichert wird).
Und wenn es um Sensoren geht, gilt natürlich der jeweils gelieferte Messwert als Statusquelle, Sensoren haben nur eine GA, weil sie readonly sind.

Die Abbildung anderer GA, die z.B. als (zusätzliche) Zentralfunktion im Aktor hinterlegt sind, ist hingegen nicht sinnvoll.

Die Abfrage einer GA, in der bei keinem verknüpften KO das L-Flag gesetzt ist, wird immer zu einem Timeout führen, weil eben kein KO antwortet. Leider gibt es auch jede Menge Geräte, die vom Hersteller mit gesetztem L-Flag auf KO ausgeliefert werden, die dazu nicht geeignet sind. Nur weil ein KO ein gesetztes L-Flag hat, bedeutet das also nicht, dass es sinnvoll ist, die verknüpfte GA abzufragen. Es kann durchaus sinnvoll sein, solche unnötigen L-Flags zu entfernen, um den knx Bus zuverlässiger zu machen - immer vorausgesetzt, dass das KO auch mit einer oder mehreren GA verknüpft ist.

[TomW80]

Danke udo1toni!
Ich werde die GAs mal entfernen und schauen ob noch alles läuft.