Und nochmal Dimmer...

[udo1toni]

Guten Abend allerseits,

bin gerade (total begeistert) dabei, mit openhab (1.0.0) "in echt" zu spielen. So gut wie alle knx-Adressen sind inzwischen einigermaßen sinnvoll vergeben und die Schalter funktionieren gut. Was allerdings die Dimmer betrifft, sieht es nicht ganz so gut aus:
Egal, ob ich kurz oder lang auf die Pfeile klicke, die Leuchten werden komplett hoch- oder runtergedimmt, Zwischenwerte kann ich nicht ansteuern.
Inzwischen habe ich allerdings auch Habdroid auf meinem Tablet eingerichtet, und was soll ich sagen? Die Dimmer lassen sich über die dort eingeblendeten Slider prima einstellen. An den knx-Adressen sollte es nicht liegen, denn über die knx-Taster (gira ts2+) funktioniert's ohne Probleme.

Auszug aus meiner .items:

Dimmer Light_OG_E2 "Sterne" (gEltern) {knx="<8/5/10+8/5/16,8/5/11,8/5/12+8/5/17"}

wobei ..10-> An/Aus; 16->Zustand (An/Aus); 11->Increase/Decrease; 12->Dimmwert absolut; 17->Zustand (%)
Auszug aus meiner .sitemap:

Slider item= Light_OG_E2 sendFrequency=400 switchSupport

Woran könnte das denn liegen, oder was mache ich falsch?

[teichsta]

Woran könnte das denn liegen, oder was mache ich falsch?

vielleicht gar nichts!

Könntest Du openHAB mal im Debug-Modus starten (über start_debug.xx) und dann das openhab.log beobachten, während Du über das Classic-UI dimmst? Interessant zu wissen wäre, ob dort nach längerem Klick (und lochlassen) noch weitere INCREASE-Nachrichten im Log findest oder nicht.

Gruß,

Thomas E.-E.

[udo1toni]

So sieht die Debug-Ausgabe aus.

13:25:53.124 INFO  runtime.busevents[:42] - Light_Kueche received command INCREASE
13:25:53.125 DEBUG o.o.b.k.i.bus.KNXBinding[:173] - Wrote value 'INCREASE' to datapoint 'command DP 4/5/1 Light_Kueche, DPT main 0 id 3.007, low priority'
13:25:53.216 INFO  runtime.busevents[:46] - Light_Kueche2 state updated to ON
13:25:53.434 INFO  runtime.busevents[:42] - Light_Kueche received command INCREASE
13:25:53.434 DEBUG o.o.b.k.i.bus.KNXBinding[:173] - Wrote value 'INCREASE' to datapoint 'command DP 4/5/1 Light_Kueche, DPT main 0 id 3.007, low priority'
13:25:53.743 INFO  runtime.busevents[:42] - Light_Kueche received command INCREASE
13:25:53.743 DEBUG o.o.b.k.i.bus.KNXBinding[:173] - Wrote value 'INCREASE' to datapoint 'command DP 4/5/1 Light_Kueche, DPT main 0 id 3.007, low priority'
13:25:54.051 INFO  runtime.busevents[:42] - Light_Kueche received command INCREASE
13:25:54.052 DEBUG o.o.b.k.i.bus.KNXBinding[:173] - Wrote value 'INCREASE' to datapoint 'command DP 4/5/1 Light_Kueche, DPT main 0 id 3.007, low priority'
13:25:57.523 INFO  runtime.busevents[:46] - Light_Kueche state updated to 100
13:26:11.907 INFO  runtime.busevents[:42] - Light_Kueche received command DECREASE
13:26:11.912 DEBUG o.o.b.k.i.bus.KNXBinding[:173] - Wrote value 'DECREASE' to datapoint 'command DP 4/5/1 Light_Kueche, DPT main 0 id 3.007, low priority'
13:26:12.220 INFO  runtime.busevents[:42] - Light_Kueche received command DECREASE
13:26:12.220 DEBUG o.o.b.k.i.bus.KNXBinding[:173] - Wrote value 'DECREASE' to datapoint 'command DP 4/5/1 Light_Kueche, DPT main 0 id 3.007, low priority'
13:26:12.529 INFO  runtime.busevents[:42] - Light_Kueche received command DECREASE
13:26:12.529 DEBUG o.o.b.k.i.bus.KNXBinding[:173] - Wrote value 'DECREASE' to datapoint 'command DP 4/5/1 Light_Kueche, DPT main 0 id 3.007, low priority'
13:26:12.837 INFO  runtime.busevents[:42] - Light_Kueche received command DECREASE
13:26:12.837 DEBUG o.o.b.k.i.bus.KNXBinding[:173] - Wrote value 'DECREASE' to datapoint 'command DP 4/5/1 Light_Kueche, DPT main 0 id 3.007, low priority'
13:26:16.258 INFO  runtime.busevents[:46] - Light_Kueche state updated to 1
13:26:23.104 INFO  runtime.busevents[:42] - Light_Kueche received command OFF
13:26:23.105 DEBUG o.o.b.k.i.bus.KNXBinding[:173] - Wrote value 'OFF' to datapoint 'command DP 4/5/0 Light_Kueche, DPT main 0 id 1.001, low priority'
13:26:23.196 INFO  runtime.busevents[:46] - Light_Kueche2 state updated to OFF
13:26:23.281 INFO  runtime.busevents[:46] - Light_Kueche state updated to 0

Und so sieht's aus, wenn ich mal kurz am Schalter dimme...

13:29:55.010 INFO  runtime.busevents[:42] - Light_Kueche2 received command INCREASE
13:29:55.121 INFO  runtime.busevents[:46] - Light_Kueche2 state updated to ON
13:29:57.447 INFO  runtime.busevents[:42] - Light_Kueche2 received command DECREASE
13:29:57.505 INFO  runtime.busevents[:46] - Light_Kueche state updated to 56
13:30:00.823 INFO  runtime.busevents[:42] - Light_Kueche2 received command OFF
13:30:03.924 INFO  runtime.busevents[:46] - Light_Kueche2 state updated to OFF
13:30:03.981 INFO  runtime.busevents[:46] - Light_Kueche state updated to 0

Scheint so, als ob der Dimmer irgendwie anders angesteuert werden muss. Der Taster schickt zu Beginn des Dimmvorgangs einen Increase-Befehl, zum Ende einen anderen (den openhab als Decrease anzeigt, muss aber eine andere bitfolge sein, da beim runter dimmen auch ein Decrease angezeigt wird, und zum Stoppen des Dimmvorgangs ebenfalls ein Decrease)

der ETS-Gruppenmonitor spuckt hier ein "100% aufwärts" "stopp" "100% abwärts" aus (wobei das "stopp" vom opemhab auch als decrease gewertet wird.

Der Dimmer ist ein Hager TXA213, aber auch der noch vorhandene TL210A wird so angesteuert.

[teichsta]

kurze Zwischenfrage: oben war das Item Light_OG_E2 ein Thema. Im letzten Post die Items Light_Kueche und Light_Kueche2 ... sind die ganz sicher gleich konfiguriert, damit wir die Dinge auch vergleichen können?

[udo1toni]

Ja, die sind bisher alle gleich angelegt. Nur war ich das eine mal am PC im Schlafzimmer, das andere mal am Laptop in der Küche, da war der Lichtschalter von der Küche halt näher
Aber die Dimmer sind überall die gleichen und vor allem ist das Verhalten überall dasselbe. Anhand des Gruppenmonitors von ETS kann ich ja auch sehr schön sehen, dass der Lichttaster jeweils genau ein Dimmstart- und ein Dimmstopptelegramm sendet, und nicht wiederholt ein Dimmtelegramm. Ich wüsste nicht, wie ich das umkonfigurieren kann (am Taster geht das, Schrittweite ändern, kein Stoptelegramm, Telegrammwiederholung, aber nicht am Dimmer)

[kkreuzer]

der Lichttaster jeweils genau ein Dimmstart- und ein Dimmstopptelegramm sendet, und nicht wiederholt ein Dimmtelegramm.

Das wird das Problem sein, den die Buttons senden mit "frequency" immer neue INCREASE oder DECREASE Telegramme (als DPT 3.007 mit Schrittweite 5).
Wenn Du mit Dimmstart und -stop Telegrammen arbeitest, wird Deine GA 8/5/11 vermutlich einen anderen DPT haben. Da ich diese Variante selbst nicht verwende, bin ich aber leider überfragt, was da erwartet würde.

Die Tatsache, dass HABDroid funktioniert liegt daran, dass beim Slider immer nur Prozentwerte geschickt werden, d.h. die INCREASE/DECREASE GA wird in diesem Fall gar nicht verwendet.

Grüße,
Kai

[udo1toni]

Das wird das Problem sein, den die Buttons senden mit "frequency" immer neue INCREASE oder DECREASE Telegramme (als DPT 3.007 mit Schrittweite 5).
Wenn Du mit Dimmstart und -stop Telegrammen arbeitest, wird Deine GA 8/5/11 vermutlich einen anderen DPT haben. Da ich diese Variante selbst nicht verwende, bin ich aber leider überfragt, was da erwartet würde.

Also der Datenpunkttyp ist bei mir auch 3.007. Ich hab aber auch gar keine Ahnung, wie ich die Dimm-Befehlsart umstellen sollte, es gibt da nichts zu konfigurieren. Hier mal ein Auszug aus dem Busmonitor, 1. Telegramm: Dimmstart heller; 2. Telegramm: Dimmstopp; 3. Telegramm: Dimmstart dunker; 4. Telegramm: Dimmstopp;

07:22:59.123    2B 01 61 60 BC 11 D2 45 01 D1 00 89 9C
07:22:59.123    2B 02 00 00 CC
07:23:01.897    2B 05 A8 50 BC 11 D2 45 01 D1 00 80 95
07:23:01.897    2B 06 00 00 CC
07:23:04.340    2B 02 82 10 BC 11 D2 45 01 D1 00 81 94
07:23:04.340    2B 03 00 00 CC
07:23:07.685    2B 01 E2 B0 BC 11 D2 45 01 D1 00 80 95
07:23:07.685    2B 02 00 00 CC

Das oben ist der Inhalt der .trx-Datei, die man im Busmonitor erhält, wenn man die aufgezeichneten Telegramme speichert. Das sollten mehr oder weniger die Rohbusdaten sein, oder?
Hier eine Tabelle des Wertebereichs für DPT 3.007, die ich in der Doku eines DMX-Gateways gefunden habe:

Kanal Dimmen:     mit DPT 3.007: 4bit Wert (Dimmen) 
Mögliche Dimmwerte als 4bit Objekt: 
0  = Stopp 
1 = 100% abwärts 
2 = 50% abwärts 
3 = 25% abwärts 
4 = 12% abwärts 
5 = 6% abwärts 
6 = 3% abwärts 
7 = 1% abwärts 
8 = Stopp 
9 = 100% aufwärts 
10 = 50% aufwärts 
11 = 25% aufwärts 
12 = 12% aufwärts 
13 = 6% aufwärts 
14 = 3% aufwärts 
15 = 1% aufwärts

Die Tatsache, dass HABDroid funktioniert liegt daran, dass beim Slider immer nur Prozentwerte geschickt werden, d.h. die INCREASE/DECREASE GA wird in diesem Fall gar nicht verwendet.

Kann ich daraus ablesen, dass ich einfach den Eintrag für Increase/Decrease weglassen muss (so als könnte mein Dimmer das nicht) und openhab sendet dann auch die Ziel-Prozent-Werte? Kann ich dann noch irgendwie die Schrittweite beeinflussen?

Ich schätze, ich sollte eine Issue für Dimmen mit Start-Stop-Telegramm anlegen, oder?

[kkreuzer]

Was Du auch getan hast, hier nur als Referenz: Issue 125 - openhab - support for Dimmer with Start-Stop Telegramm - empowering the smart home - Google Project Hosting

[udo1toni]

~rotwerd~
Stimmt. Link total vergessen... :-)

[Jockel]

Genau über dieses Problem bin ich jetzt bei meinen Hager Dimmaktoren auch gestolpert. Gibt es denn ev. schon eine Planung wann das Issue 125 angegangen werden soll? Im Bugtracker steht ja nur "später".

[kkreuzer]

Nein, ich fürchte, für 1.1 werde ich auch nicht mehr die Zeit finden, das zu entwickeln. Falls einer von Euch einen Patch einreicht, bin ich aber gerne bereit, ihn zu reviewen und einzuarbeiten

[Jockel]

OK, hab den Wink verstanden

Bis Mitte Dezember wird das bei mir aber auch nichts werden, am Jahresende liegt immer zu viel an... Anfang Januar schaue ich mir das aber gerne mal an, verspreche allerdings ausdrücklich nichts! Ich muss ja als erstes mal die interne Struktur verstehen, damit hab ich mich noch kaum beschäftigt...

Immerhin hab ich die Build Umgebung installiert bekommen, ist ja mal ein Anfang

[chru]

Gibt es hierzu schon eine Lösung? Meine Dimmer funktionieren leider so auch nicht...

[lostcontrol]

Ich werde auch meine Dimmer so steuern (start/stop und nicht zyklisch) und bin da auch an eine Lösung interessiert. Falls ich inzwischen Zeit habe, werde ich mir das Thema anschauen.

Gruss,
Cyril

[Jockel]

Und nochmal Dimmer...

Ich muss gestehen, dass da bei mir auch nicht viel passiert ist. Die Entwicklungsumgebung läuft zwar und ich hab mich mal kurz damit beschäftigt, dann hatten andere Sachen aber erst mal höhere Priorität.

Im Code war mir damals vor allem nicht klar, an welcher Stelle man das Stopp-Telegramm am sinnigsten implementiert, im KNX Plugin oder doch eher in den tieferen Schichten.