OH3 - Problem beim Wechsel von KNX1 auf KNX2/3 mit Dimmern

[flagg]

Hallo Forum,

ich habe openHAB 2 mit KNX1 bei mir. Nun baue ich gerade eine neue openHAB 3 Umgebung auf und muss von KNX1 auf das neue KNX umstellen.

Der erste Funktionscheck ist in Ordnung d.h. ich habe eine Verbindung aus openHAB 3 und kann auch Lichter über KNX schalten. Aktuell bekomme ich aber das Dimmen der Lichter nicht hin (unter openHAB 2.x hat das funktioniert) - ich bin jetzt nur nicht der KNX-Experte um genau zu verstehen warum es in openHAB 3.x nicht funktioniert.

Ich habe einen Dimmaktor wie folgt als Thing hinterlegt (das Schalten damit funktioniert auch):

KNX.things:

Thing device dimmaktor_ug [
        address="0.0.1",
        fetch=false,
        pingInterval=300,
        readInterval=0
    ] {
        Type dimmer     : dimmer_EG_Wohnen           "Wohnzimmer"     [switch="<0/0/60+0/0/63", position="0/0/62", increaseDecrease="0/0/61"]
    }

KNX.items:

Switch Licht_EG_Wohnen             "Licht Wohnzimmer"                       (gEG_Wohnen, gLicht_EG, gLicht)     [ "Lighting" ]  { channel="knx:device:bridge:dimmaktor_ug:dimmer_EG_ Wohnen" }
Dimmer Dimmen_EG_Wohnen            "Dimmen Wohnzimmer"                      (gEG_Wohnen, gLicht_EG, gLicht)     [ "Lighting" ]  { channel="knx:device:bridge:dimmaktor_ug:dimmer_EG_ Wohnen" }

Meine Konfiguration im ETS sieht so aus:

- Ausgang 1 - Schalten - 0/0/60
- Ausgang 1 - Dimmen - 0/0/61
- Ausgang 1 - Helligkeitswert - 0/0/62
- Ausgang 1 - Rückmeldung Schalten - 0/0/63
- Ausgang 1 - Rückmeldung Helligkeitswert - NICHTS HINTERLEGT

Ich habe in der Things-Datei schon etwas mit den Adressen probiert, aber das Dimmen bekomme ich nicht hin.
Weiß jemand was bei "position" und "increaseDecrease" die richtigen Werte sein müssen?

Im events.log kommt beim Dimmversuch folgendes:

2021-01-10 13:46:03.028 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Dimmen_EG_Wohnen' received command 52
2021-01-10 13:46:03.052 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Dimmen_EG_Wohnen' predicted to become 52
2021-01-10 13:46:03.068 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Dimmen_EG_Wohnen' changed from 0 to 52

Mit der KNX2-Dokumentation werde ich da nicht richtig schlau und die KNX1-Dokumentation ist für einen Vergleich nicht mehr zur Verfügung.
Der Aufbau zwischen 1 und 2 ist da doch etwas unterschiedlich :-(

Danke,
Reinhard

[DiMa]

Auf "position" musst du die GA für "Dimmen absolut" senden, auf "increasedecrease" die GA für "Dimmen relativ". Wenn du den Dimmwert auf 50% (52) setzen wolltest, sagt dein Log, dass alles richtig verstanden wurde - vmtl. stimmen die GA nicht. An "position" hängt man üblicherweise noch den Status für den Dimmwert an, sonst wird's nix mit der Visu.

[flagg]

Hi DiMa,

vielen Dank für deine Antwort. Leider stehe ich etwas auf dem Schlauch.

So sieht meine Konfiguration aus:

2021-01-10_165927.png
"Dimmen absolut" und "Dimmen relativ" habe ich bei mir nicht drin. Aber auch die GA kann ich nicht einsehen.

Hast du einen Tipp was ich wo hinterlegen muss? Irgendwie ist das komisch, weil es ja mit dem alten Binding in KNX1 auch ging :-(

In KNX1 hatte ich es wie folgt mit drin und da hat es funktioniert:

Switch Licht_EG_Wohnen             "Licht Wohnzimmer"                       (gEG_Wohnen, gLicht_EG, gLicht)     [ "Lighting" ]  {knx="<0/0/60"}
Dimmer Dimmen_EG_Wohnen            "Dimmen Wohnzimmer"                      (gEG_Wohnen, gLicht_EG, gLicht)     [ "Lighting" ]  {knx="<0/0/60,0/0/61,0/0/62"}

Danke,
Reinhard

[udo1toni]

Also...

Leider ist die gewählte Ansicht etwas ungünstig, denn sie verrät nichts über die verwendeten DPT. Macht aber nichts

Schalten -> 1Bit KO (DPT1.001), welches den Befehl entgegen nimmt, ob der Dimmer ein oder ausgeschaltet werden soll (beim Einschalten wird dann die default Helligkeit angefahren, das kann auch die zuletzt gewähle Helligkeit sein, je nach Konfiguration des Aktors)
Dimmen -> 4Bit KO (DPT3.007) (relatives Dimmen...) das MSB entscheidet über die Richtung (heller/dunkler), die drei LSB entscheiden über die Schrittweite. Dies funktioniert im Zusammenhang mit openHAB als Steuerzentrale nur bei bestimmten Dimmermodellen, da openHAB kein Start-Stop-Dimmen beherrscht, es aber diverse Dimmer am Markt gibt, die nur Start-Stop-Dimmen unterstützen (z.B. Hager)
Helligkeitswert -> 8Bit KO (DPT5.001) (absoluter Helligkeitswert) nimmt die gewünschte Helligkeitsstufe entgegen.
Rückmeldung Schalten -> 1Bit KO (DPT1.001), sendet ON bei Helligkeitsstufen > 0 und OFF bei Helligkeitsstufe 0. Wird in openHAB nicht gebraucht!
Rückmeldung Helligkeitswert -> 8Bit KO (DPT5.001) sendet den absoluten Helligkeitswert bei Ende des Dimmvorgangs. Dieses KO wird in openHAB für korrekte Funktion zwingend gebraucht!

Du hast vermutlich in openHAB2 im Zusammenspiel mit Deiner Konfiguration die Classic UI genutzt? Nur dort konntest Du überhaupt sinnvoll INCREASE/DECREASE Kommandos absetzen.

Die korrekte Konfiguration eines Dimmers sieht dann so aus:

    Thing device dimmaktor_ug [
        address="0.0.1",
        fetch=false,
        pingInterval=300,
        readInterval=0
    ] {
        Type dimmer : dimmer_EG_Wohnen "Wohnzimmer" [ switch="0/0/60", position="0/0/62+<0/0/64" ]
    }

Wobei 0/0/64 dann die GA für das KO 9 (Rückmeldung Helligkeitswert) wäre. Wichtig wäre dann auch, dass diese GA als einzige dem KO zugeordnet ist und die Flags K,L,Ü gesetzt sind.
Du möchtest einen Dimmer von openHAB aus nicht relativ steuern, sondern absolut. Du möchtest außerdem nicht wissen, ob das Licht an ist, sondern, wie hell das Licht leuchtet. Das ist der große Unterschied zur Bedienung über "konventionelle" Lichtschalter, dass man genaue quantitative Aussagen treffen kann.

[flagg]

Hi udo1toni,

vielen Dank für die Erklärung. Ich teste das heute Abend gleich einmal.
Die "Rückmeldung Helligkeitswert" müsste ich dann noch bei allen Dimmern im Haus einbauen (0/0/64).

Welche Ansicht wäre denn hilfreich gewesen bzw. wo hätte ich die DPT gefunden?

In openHAB 2.x habe ich die Basic UI für das Dimmen verwendet und das hat ganz gut funktioniert. Das hat dann wie folgt ausgesehen:

2021-01-11_072243.png

Edit (11.01.2021, 07:30 Uhr): Es hat mir jetzt doch keine Ruhe mehr gelassen und ich habe den Dimmer wie folgt in openHAB 3.x eingebaut:

Type dimmer     : dimmer_EG_Wohnen           "Wohnzimmer"     [ switch="0/0/60", position="0/0/62" ]

Das Ergebnis ist in der Basic UI wie folgt (der Status des Dimmer wird nicht angezeigt und mit dem Slider kann ich den Helligkeitswert nicht ändern):

2021-01-11_073422.png

Die "Rückmeldung Helligkeitswert" habe ich jetzt im ersten Schritt noch nicht eingebaut (weil es ja mit openHAB 2.x auch so ging) - das mache ich dann im Nachgang (ich hoffe das war so richtig).

Hat noch jemand eine Idee?

Danke,
Reinhard

Edit (11.01.2021, 07:45 Uhr): Ah ich habe den Kommentar überlesen d.h. ich muss erst die Rückmeldung einbauen im ETS damit es generell in openHAB 3.x wieder geht.

>Rückmeldung Helligkeitswert -> 8Bit KO (DPT5.001) sendet den absoluten Helligkeitswert bei Ende des Dimmvorgangs. Dieses KO >wird in openHAB für korrekte Funktion zwingend gebraucht!

[flagg]

Hallo,

jetzt noch einmal ein Test gegen 08:00 Uhr :-)

Ich habe den Dimmer so eingebaut:

Type dimmer     : dimmer_EG_Wohnen           "Wohnzimmer"     [ switch="0/0/60", position="0/0/62+<0/0/64" ]

Und die 0/0/64 (Rückmeldung Helligkeitswert) so hinzufgefügt:

2021-01-11_075606.png
2021-01-11_075620.png
2021-01-11_075638.png
Leider klappt damit das Dimmen immer noch nicht. Im Log sehe ich folgende Events (wie vor der Änderung):

icht_EG_Wohnen' changed from ON to OFF
2021-01-11 07:57:29.309 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Dimmen_EG_Wohnen' received command 52
2021-01-11 07:57:29.318 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Dimmen_EG_Wohnen' predicted to become 52
2021-01-11 07:57:29.326 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Dimmen_EG_Wohnen' changed from 20 to 52
2021-01-11 07:57:31.717 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Dimmen_EG_Wohnen' received command 16

Irgendetwas scheint hier komisch zu sein :-(

Gibt es noch Ideen?

Danke,
Reinhard

Edit 11.01.2021, 08:19 Uhr:

Jetzt habe ich das mit den Datentypen gefunden (so habe ich die aktuell konfiguriert):

- Schalten - Länge: 1 Bit (Datentyp nicht angegeben) - K L S
- Dimmen - Länge: 4 Bit (Datentyp nicht angegeben) - K L S
- Helligkeitswert - Länge: 1 Byte (5.001 Prozent) - K L S
- Rückmeldung Schalten - Länge: 1 Bit (Datentyp nicht angegeben) - K L Ü
- Rückmeldung Helligkeitswert - Länge: 1 Byte (5.001 Prozent) - K L Ü

Mit dieser Konfiguration "dimmt" es leider auch noch nicht.

[udo1toni]

Und Du hast openHAB zwischendurch mal durchgestartet?

[flagg]

Nein hatte ich nicht. Ich dachte wenn das Schalten geht, dann sollte alles passen ... ich teste später mal.

Edit 11.01.2020 19:39 Uhr:

Ich brech ab, der Neustart war es. Danach funktioniert das Dimmen einwandfrei. Auch wenn ich im laufenden Betrieb nach den Hinweise von udo1ton1 die Konfigurationen vornehme. Ich muss dazu nicht einmal etwas im EIB ändern.

Sorry für den Umstand, das mit dem Neustart hätte ich auch mal testen können. Kanntest du das Problem oder war das nur die letzte Idee? :-)

Ich teste jetzt mal weiter und muss dann noch die Themen aus dem Beitrag entsprechend im ganzen Haus anpassen. Aber jetzt bin ich erst einmal guter Dinge das ich das selbst schaffe :-)

[ToBus]

Hallo zusammen,
super, dass es nun klappt.
Jetzt wo das Problem gelöst zu sein scheint, hätte ich mal ein paar generelle Fragen:
1) Lohnt sich aus deiner Sicht das Update auf OH3?
Ich nutze aktuell auch das KNX1-binding und stehe vor der gleichen Problematik, falls ich mal von OH 2.5 updaten möchte.
2) Hast du noch mehr Änderungen zu bewältigen, bis alles wieder rund läuft?
Viele Grüße
Tobus

[udo1toni]

Also, ich kann nur dringend raten, zumindest alle Bindings auf 2er Versionen umzustellen.

openHAB3 ist wesentlich ausgereifter als openHAB2 (speziell, was die Main UI angeht, welche die Paper UI ersetzt)

Ein Upgrade auf OH3 ist also zwar (sehr) mühsam, lohnt sich aber aus meiner Sicht definitiv (nicht, dass es bei mir schon soweit wäre... aber zumindest habe ich ein Testsystem und ein System, welches nachher alle Aufgaben übernehmen soll - ich nutze virtuelle Maschinen...)

Alles, was man unter OH2.5 auf aktuelle Technik umstellt (Thing-basiert), kann man recht schnell in OH3 in Betrieb nehmen, notfalls sogar mit den original *.things und *.items Dateien aus OH2.5.
In den Rules muss man alles, was mit JodaTime läuft auf JavaTime umstellen, aber es gibt für alles auch eine Entsprechung (auch wenn sie manchmal etwas umständlicher wirkt).

[flagg]

Hi ToBus,

>1) Lohnt sich aus deiner Sicht das Update auf OH3?
>Ich nutze aktuell auch das KNX1-binding und stehe vor der gleichen Problematik, falls ich mal von OH 2.5 updaten >möchte.

Ja, es ist viel mehr auf Einfachheit ausgelegt, aber ich nutze die alten textbasierten Methoden d.h. der Mehrwert ist für mich hauptsächlich wieder auf der aktuellen Version zu sein. Gibt bestimmt eine Menge sonstige Vorteile ...

>2) Hast du noch mehr Änderungen zu bewältigen, bis alles wieder rund läuft?

Ich wechsele in dem Schritt auch komplett die Hardware und baue das System komplett neu auf (weil ich eine Menge alte Funktionen etc. individuell gemacht habe die mittlerweile direkt im Standard gehen). Ich hatte aber noch viele alte 1er-Bindings d.h. die verursachen gerade auch etwas Umstellungsaufwand.

Beim Einsatz von alten 1er-Bindings mit openHAB 2.x kann man überlegen diese gleich noch auf die neue Version umzustellen um dann den Aufwand am Umstellungstag etwas zu minimieren.


Und halt wie hier geschrieben hat das KNX-Binding von 1 auf 2 schon fast die meisten Änderungen. Aber die Umstellung war bei mir eh überfällig und hat jetzt (für den ersten Schritt) mit diesem Forum gut funktioniert :-)

Schöne Grüße,
Reinhard

[DiMa]

Ein Upgrade auf OH3 ist also zwar (sehr) mühsam, lohnt sich aber aus meiner Sicht definitiv (nicht, dass es bei mir schon soweit wäre... aber zumindest habe ich ein Testsystem und ein System, welches nachher alle Aufgaben übernehmen soll - ich nutze virtuelle Maschinen...)

Ich werde auch mal ein Testsystem aufsetzen, aber mir ist da langsam zu viel Wartungsaufwand erforderlich. Erst der Wechsel auf KNX2 - das ist auch erst 2-3 Jahre her, oder? - jetzt die ganzen Änderungen in OH3... Mir wird das ganze zu lästig. Ich mein', das ist kein reines Hobby von mir, ich habe keine Lust, alle paar Jahre im Prinzip meine Haussteuerung neu aufzusetzen. Obwohl ich eigentlich für sowas closed source gar nicht mag (und no-code Umgebungen schon gar nicht) versuche ich aktuell erst mal alles auf einen X1 umzuziehen. Ich bin die ständigen legacy breaking Änderungen leid. Mal schauen, wie sich das entwickelt.

Mein Fazit: OH3 kriegt noch mal eine Chance, aber wenn das nicht toll ist oder in 2-3 Jahren OH4 wieder "alles einmal neu" erfordert, war's das für mich.

In den Rules muss man alles, was mit JodaTime läuft auf JavaTime umstellen, aber es gibt für alles auch eine Entsprechung (auch wenn
sie manchmal etwas umständlicher wirkt).

Das ist einer der Hauptgründe für einen Wechsel für mich 😉

[udo1toni]

Das ist einer der Hauptgründe für einen Wechsel für mich 😉

Dann vermute ich mal, dass Du ohnehin in Java zuhause bist? Letztlich ist es mir egal, welche Bibliotheken verwendet werden (und ich kann die Gründe, das umzustellen nachvollziehen), es ist halt sehr lästig, sich die entsprechenden Informationen mühsam zusammensuchen zu müssen. Es ist ja nicht so, dass die Umstellung von heute auf morgen vollzogen worden wäre. Da wäre ein howto (zumindest mit den wichtigsten Ausdrücken) schon angebracht gewesen.
Inzwischen gibt es ja zumindest eine Entsprechung für die Konvertierung der DateTime Datentypen, so wie es das schon für openHAB2 gibt, auch speziell für openHAB3. Dennoch wäre eine Tabelle alter Befehl <-> neuer Befehl noch wesentlich hilfreicher...