openHAB2 Dimmer funktioniert nicht richtig

[jazer]

Item

// Dimmer AN/AUS+Status, Relativ, Absolut+Status
Dimmer elternbereichBettBeleuchtung             "Licht Bett"             (Lights,first_floor) [ "Lighting" ] { knx="10/2/51+10/2/71, 10/2/62, 10/2/61+10/2/72" }

Sitemap

Switch    item=elternbereichBettBeleuchtung             label="Bett"
Slider    item=elternbereichBettBeleuchtung             label="Dimmer"

Ich komme hier nicht weiter. Sag mir doch mal, ob es bei euch zuverlässig funktioniert die Leuchten einzuschalten und zu dimmen.
Bei mir wird der AN/AUS Status nicht richtig angezeigt, auch der Dimm-Regler funktioniert nicht richtig. D.h. einstellen geht aber die Anzeige des Reglers nicht.

[udo1toni]

Also grundsätzlich sollte der Dimmer funktionieren.
Es kommt darauf an, welchen Dimmer Du hast, bzw. wie Du dimmst. Es gibt drei verschieden Möglichkeiten, einen Dimmer direkt zu steuern:

1. absolutes Dimmen, das heißt der gewünschte Prozentwert wird gesetzt.
2. relatives Dimmen mit Telegrammwiederholung
3. relatives Dimmen mit Start-Stopp-Telegramm *)

Erfahrungsgemäß ist in knx-Installationen meist die 3. Variante im Einsatz, das heißt, es wird zu Beginn des langen Tastendrucks ein Start-Telegramm gesendet und wenn man loslässt, wird ein Stopp-Telegramm gesendet. Dieses Steuerverfahren beherrscht openHAB nicht, macht aber nichts, denn Absolutwertdimmen funktioniert zuverlässig.

Dazu wird der Dimmer folgendermaßen konfiguriert:

Dimmer elternbereichBettBeleuchtung "Licht Bett" (Lights,first_floor) [ "Lighting" ] { knx="10/2/51+<10/2/71, 5.001:10/2/61+<5.001:10/2/72" }

Es wird also keine Adresse für relatives Dimmen angegeben. Das kleiner-Zeichen bewirkt, dass openHAB beim Systemstart versucht, von der darauf folgenden Adresse den Status zu ermitteln (Read Request).
Die Angabe des DPT (5.001: Absolutwert Dimmen, 8-Bit, 0%-100%) ist in diesem Fall zwingend notwendig, da openHAB sonst keine korrekte Zuordnung der GA vornehmen kann.

*) Um ganz korrekt zu sein, gibt es gar kein Stopptelegramm für relatives Dimmen. Relatives Dimmen wird über ein 4-Bit-Telegramm gesteuert, das MSB bestimmt die Richtung (1 -> heller, 0 -> dunkler), die 3 LSB bestimmen die Schrittweite 0 bis 7, dabei ist 0 0% und 7 100%. 0% wird dann zum Stoppen des Dimmvorgangs benutzt.

[udo1toni]

Ach so, zur Ergänzung: INCREASE und DECREASE funktionieren dann natürlich nicht (das kommt z.B. in der Classic UI zum tragen, dort gibt es keine Slider), man kann sich aber mit einer Rule behelfen, die aus den relativen Steuerinformationen einen Absolutwert macht und den zum Dimmer schickt. Oder man verzichtet auf relatives Dimmen...

[scope]

Hallo zusammen,

ich hoffe, es ist ok, wenn ich mich an dieses Thema anhänge - versuche mich auch gerade an der Einrichtung der Dimmer.

Meine Gruppenadressen für den gewünschten Dimmkanal sind:

1/1/4 Schalten (Ein/Aus 1 Bit)
1/2/4 Rückmeldung Schalten (Ein/Aus 1 Bit)
1/3/4 Dimmen relativ (+/- 4 Bit)
1/4/4 Dimmen Wert (Dimmwert 1 Byte)
1/5/4 Rückmeldung Wert (Dimmwert 1 Byte)

Folgendes habe ich für das Item konfiguriert:

//Dimmer Lighting_OG_Child_North "D [%s %%]" <dimmablelight> {knx="1/1/4+<1/2/4, 1/3/4, 1/4/4+<1/5/4"}
Dimmer Lighting_OG_Child_North "D [%s %%]" <dimmablelight> {knx="1/1/4+<1/2/4, 5.001:1/4/4+<5.001:1/5/4"}

Beide Varianten sollten im Bezug auf openHAB identisch sein, oder? Da openHAB relatives Dimmen dieser Art nicht unterstützt, kann man die mittlere Gruppenadresse weglassen, muss dann aber den DPT von den folgenden Adressen angeben, damit richtig zugeordnet wird, korrekt?

In der Sitemap habe ich dann einfach:

Slider item=Lighting_OG_Child_North

Im Prinzip funktioniert alles, jedoch gibt es einen unschönen Effekt in der iOS-App und auf der WebGUI:

Ausgangszustand ist "Kanal ist aus". Nun schiebe ich den Slider in die Mitte. Das Licht fängt an hochzudimmen. Der Slider springt dann auf 100% und am Ende des Dimmvorgangs auf den richtigen Wert.

Auf dem Bus passiert dabei folgendes:

dimmer.png
Sobald der Dimmer anfängt hochzudimmen, gibt es erstmal den Status, dass der Kanal nun "aktiv" ist. Dies interpretiert openHAB aber, als wäre der Kanal gerade auf 100% gedimmt worden - der Status in der App wird somit angepasst. Ist nach wenigen Sekunden der Dimmvorgang abgeschlossen, so kommt vom Dimmaktor sauber die Rückmeldung über den aktuellen Wert. Der Slider springt somit wieder zurück, nun auf den richtigen Wert.

Hier nun meine Fragen:

1. Wie kann ich das Verhalten korrigieren?
2. Gibt es die Kombination aus Slider / Switch? D.h. ein GUI-Element, mit dem ich sowohl dimmen wie auch direkt an/aus schalten kann? Das war der Grund, für den Dimmer auch die Schaltadressen einzutragen
3. Die Anzeige in % wird nicht angezeigt - ist das bei einem Slider generell so? Eigentlich sollte die Prozentzahl ja neben dem "D" stehen, oder? Evtl. habe ich etwas falsch konfiguriert?

Vielen Dank für eure Hilfe!

Viele Grüße

Nico

[udo1toni]

Das Verhalten ist schon korrekt so. Du könntest natürlich die Rückme-GA 1/2/4 weg lassen. Dann sollte der Slider nicht mehr springen. Ob das andere Seiteneffekte hat, weiß ich nicht. Mich hat das Springen des Sliders nie gestört.
Den Dimmwert siehst Du, wenn Du im Label numerische Werte anzeigen lässt: "Dimmer [%d%%]" oder (falls immer noch nichts zu sehen ist) "Dimmer [%f.0%%]"

[scope]

Hi Udo,

vielen Dank für die Antwort.
Ich habe jetzt die Rückmelde GA für Schalten rausgenommen. Der Aktor schickt ja auch immer einen Prozent-Status - müsste also auch so gehen. So springt der Slider zumindest nicht mehr.

Den Dimmwert in Prozent bekomme ich nicht zur Anzeige... Habe vermeintlich alles versucht: [%s], [%d], [%f.0]... Sowohl beim Item wie auch in der Sitemap.
Bei meinen anderen Tests wird der [xxx]-Wert immer rechts angezeigt - da ist ja aber der Slider. Geht es vielleicht deshalb nicht?

Viele Grüße

Nico

[scope]

Hi again,

jetzt spinnt der Slider schon wieder

Ich wollte "nur" zusätzlich zu dem Dimmer-Item noch ein Switch-Item dazu haben, damit man nicht immer den Slider fürs normale Schalten nehmen muss:

Items

Dimmer Lighting_OG_Child_North_S "OG Kind Norden" <dimmablelight> {knx="1/1/4, 5.001:1/4/4+<5.001:1/5/4"}
Switch Lighting_OG_Child_North_D "OG Kind Norden" <light> {knx="1/1/4+<1/2/4"}

Sitemap

Slider item=Lighting_OG_Child_North_S
Switch item=Lighting_OG_Child_North_D

Wenn ich nun den Slider von "0" auf z.B. die hälfte hochziehe, dann springt der Switch sofort auf an (das Aktiv-Telegramm, welches zuvor den Slider ja kurz auf 100% gedreht hat). Gleichzeitig springt der Slider auf "0" - und sobald der Dimmer fertig ist und einen %-Status verschickt wieder auf den eingestellten Wert.

Das der Slider beim Setting zuvor auf "100%" springt, kann ich nachvollziehen. Aber wieso der Slider auf "0" springt, obwohl er auf das Telegramm gar nicht hören sollte, das ist mir schleierhaft...

Jemand eine Idee?

Viele Grüße

Nico

[udo1toni]

Argh...

Ich hatte schon wieder aus den Augen verloren, dass es um OH2 geht, und damit natürlich auch um die Basic UI. Da gibt es einen Issue, dass die Werte bei Slidern (und Switches) nicht angezeigt werden, obwohl sie im Label konfiguriert sind. Sorry, hatte ich komplett verdrängt...

Bezüglich des Schalters: Das ist die Kehrseite, wenn Du die Rückmeldung für den Schalter nicht im Dimmer Item drin hast. Normalerweise könntest Du nämlich einfach ein Switch Widget in Verbindung mit dem Dimmer Item nutzen, aber vermutlich wird das wegen der fehlenden Rückmeldung nicht korrekt angezeigt werden, wenn Du den Slider verwendest.
Du verwendest dieselbe GA in zwei verschiedenen Items. Das ist ... suboptimal ...
Ich will nicht behaupten, dass das nicht funktionieren kann, aber es gibt damit immer wieder Probleme (entsprechende Berichte gibt es zuhauf hier und im englischen Forum), ich möchte also dringend davon abraten, dieselbe GA in verschiedenen Items zu verwenden. Die einzige mir bekannte Ausnahme sind Jalousien, bei denen die Step-GA für das Stoppen der Auf/Ab-Fahrt genutzt, gleichzeitig aber auch für das Verstellen der Lamellen benötigt wird - da kommt man also nicht um die doppelte Vergabe herum, dafür gibt es da auch immer wieder Schwierigkeiten...

Falls die Kopplung Dimmer item mit Switch Widget wider Erwarten nicht funktioniert, müsstest Du ein ungebundenes Item verwenden, welches Du dann natürlich mit einer entsprechenden Rule aktualisieren musst, wenn der Slider bedient wird. Umgekehrt muss eine andere Rule dafür sorgen, dass der Dimmer ein ON/OFF-Kommando gesendet bekommt, wenn das ungebundene Item geschaltet wird.

[scope]

Moin Udo,

vielen Dank für den Nachtrag - hab schon an mir gezweifelt
Wie sieht es denn bei openHAB mit Updates aus? Gibt es da viele kleine Releases, oder wird da erstmal gesammelt und dann gibt es ein größeres Update?
Ich kann natürlich auch einfach mal die Snapshot-Version nehmen - mit Docker ja kein Problem.

Mit "Switch Widget in Verbindung mit dem Dimmer" meinst Du, dass ich das gleiche Item einfach zweimal in der Sitemap positioniere - einmal als Switch und einmal als Dimmer? Daran hab ich gar nicht gedacht - aber ist ja logisch, denn der Dimmer hat ja auch ON/OFF als Komponente.

Das teste ich gleich mal

Vg
Nico

[mawa]

OpenHab2 hat auch Nightly Builds (Snapshots).

Auf welcher Hardware / System hast du Openhab drauf?

Siehe auch hier:
http://docs.openhab.org/installation...l-installation

[scope]

Moin,

läuft momentan auf einer ZOTAC ZBOX CI321 nano.
Hab CentOS 7 drauf und nutze das offizielle openHAB docker image.

Vg
Nico

[udo1toni]

Mit Docker kenne ich mich leider gar nicht aus. Prinzipiell gibt es aber

• offizielle Releases (bei debian unter stable gelistet), dort gibt es unregelmäßig große Updates und
• nightly builds (bei debian unter unstable gelistet), dort gibt es fast täglich kleine Updates.

openHAB ist eine Java-Anwendung, die grundsätzlich einfach aus einem Zip-Archiv entpackt werden kann und auf jeden System läuft, welches eine aktuelle Java-Engine hat und bestimmte Mindestvoraussetzungen erfüllt, also z.B. minimal 256 MByte RAM (eher 512MByte, je mehr, desto mehr Spaß... )

Für verschiedene Paketmanager werden Pakete gebaut bzw. der entsprechende Prozess ist in Vorbereitung.
Für apt (debian und z.B. Ubuntu) werden bei Updates jeweils automatisch .deb Installationspakete gebaut.
Für yast (rpm, also z.B. Suse), ist eine entsprechende Automatik in Vorbereitung (soweit ich das mitbekommen habe)
Für yum, also z.B. CentOS ist mir bisher nichts bekannt, es sollte aber auch hier kein Problem sein, etwas dazu einzurichten (muss halt jemand machen, vorzugsweise jemand, der sich gut mit den entsprechenden Mechanismen auskennt...)
Ob für Docker ein build-Mechanismus für beide Varianten läuft, weiß ich nicht.

In der Tendenz sind die nightly Builds sehr stabil, aber es kommt auch mal vor, dass ein Build nicht sauber läuft (vielleicht ~10%? Keine Ahnung, ob es dazu irgendwo eine Statistik gibt) Natürlich ist man nicht gezwungen, upzudaten, nur wenn man auf eine neue Funktion scharf ist oder etwas nicht richtig funktioniert, wird das Update angestoßen, je nach Installation über die entsprechenden Mechanismen.