openhabforum.de

Hallo und danke zunächst mal für die diversen Tips:
Ergänzend noch 1-2 Informationen und folgend das Feedback zu den auf Euren Ratschlag hin unternommenen Aktionen:
1.) Ja, die Adresse entspricht der korrekten physikalischen (habe ich beim Schaltaktor auch, geht dort)
2.) Das "fetch" habe ich nun mal auf "false" gesetzt - Ich hatte der Doku entnommen, dass man das setzen könnte um damit ggf. wenn unterstützt erweiterte "Thing properties" wie Firmware-Version, ... lesen zu können ... (wenn nicht dauerhaft in HAB gespeichert, scheint das aber auch ohne "fetch=true" zu funktionieren (durch Neustart von HAB getestet)) -> Wofür ist die "Fetch-Option" dann überhaupt gedacht?
3.) Die bridgeUID und die UID des Things sind bei mir identisch, ist hier hier ein copy-paste-Fehler in's Forum, sorry. (Dass man die Id frei setzten kann hatte ich gelesen und bei den meisten Geräten dann auch umgesetzt, die der Bridge habe ich aber im ursprünglichen kryptischen Code gelassen)
-> Ich habe nur MDT KNX Geräte (Bridge, Aktoren, Dimmer, ein paar Taster)
4.) Die DPT habe ich aktuell "belassen", wie auch beim funktionierenden Schaltaktor ..., die Bridge ebenfall nicht neu angelegt.
5.) Nicht alle Kommentare waren im "Original-Thing" "raus" - ich habe nun mal alle gelöscht ...
BTW: Gibt es "korrekt bezeichnete" Kommentare, die man gefahrlos in Things / Items einfügen kann? Wenn ja, welche Syntax (z.B. wäre interessant ganze Blöcke voranlegen zu können, aber z.B. noch nicht "scharf" zu schalten, weil z.B. noch nicht klar ist, was mal an den Kanal dran kommt ...)?
6.) Mit den 2-3 Änderungen von oben scheint der Dimmer grundsätzlich ansprechbar, insofern schonmal herzlichen Dank, ich bin einen großen Schritt weiter. Ob nun ein Kommentar oder das Fetch das Ganze geärgert hat, weiß ich aktuell noch nicht, muss ich ggf. nochmal testen ...
7.) In meiner Konfig gibt's nur eine Rückmelde-GA für Dimmer (zumindest im HAB), scheint also okay zu sein (siehe 6) )

Vllt. sind noch 2-3 Fragen erlaubt um es besser und schöner machen:
- Ist meine Ansicht richtig, dass ich mir für Dimmer die "dec / inc" GA im ETS und auch in HAB sparen kann (wenn ich nicht über KNX-Taster dimmen möchte - wenn kämen außer der GUI in meinem Fall nur noch Modbus-Geräte als "Sender" in Frage, deren Registerwert würde aber dann eh von HAB interpretiert und an die KNX-Dimmer weitergeleitet - also wohl auch Absolutwerte ...)

- Speziell @int5749: Richtig, das "Binding: Item an Thing" steht in der Tat nicht in der Text-Konfig des Items.
Ich würde ja prinzipiell gerne mehr über Textfiles konfigurieren wollen, aber da fehlen mir aktuell entweder gute Beispiele oder in den bisher von mir gefundenen Unterlagen zum mehr oder weniger aktuellen oHAB3.x entsprechende Hinweise an welcher Stelle welche Dateien liegen sollen.
Nachdem mein "Erstversuch" gescheitert war, mir per Textfile Things und Items anzulegen, die ich dann auch irgendwie in die / eine GUI bekomme, ist bei mir im Moment so ein Mischmasch entstanden, der zum ersten Test geht aber
a) nicht schön zu pflegen ist, sich
b) nicht so schön auf viele Kanäle skalieren lässt wie über Texteditoren
und c) beim Anlegen auch noch einiges an Zeit kostet, weil man zwar "grafische Hilfe bekommt", aber eben nicht "copy und paste" nutzen kann ...
Resultat:
- Ich habe mir nun über den webserver (http://openhabian:8080/settings/things/) die "Things" für Bridge und KNX-Aktoren angelegt, und über "Channels" bzw. "Code" diesen Things die passenden "Channels" zugewiesen. Die angelegte Konfig findet sich aber z.B. nicht unter "/etc/openhab/things/" wenn man direkt auf dem Server schaut ...
(Ein Erstversuch die Things dort einzeln anzulegen, funktionierte bei mir nicht, bzw. ich habe die nicht einzeln "zugreifbar" bekommen...)
Umgekehrt konnte ich unter "/etc/openhab/items" eine (einzige) Datei anlegen, in die ich Gruppen und "devices" eingetragen habe (gekürztes Beispiel folgt): Resultat, der oHAB aktualisiert "sofort" die Items, und ordnet diese auch entsprechenden Gruppen zu, wenn ich nun "manuell" über die Webserver-Konfig-Seite entweder den Items die Thing-Channels zuweise oder aber den Thing-channels ein freies gewünschtes Item.

Diese genannten Kopplungen finde ich aber anschließend auf dem Server selber nicht wieder - auf jeden Fall stehen sie nicht in der besagten "haus.items"-Datei unter /etc/openhabian!

Außerdem baut mit oHAB daraus auch schon eine "automatisch" vorsortierte "Sitemap", die ich dann per Handy-App oder über Browser aufrufen kann ...
Umgekehrt habe ich meinen ersten Ansatz, mir so eine "Kachel-basiertes" Layout als UI zu bauen, zunächst mal aufgegeben
- erstens bräuchte ich da vermutlich eine schöne Vorlage, um per Texteditor effektiv arbeiten zu können, das alles über grafische Frontend zu machen, ist mir zu mühsam
- zweitens ist mir bisher völlig unklar, wie ich da nun dynamische Grafiken rein bekomme und vor allem die Kopplung zu Befehlen / Stati, wie sie die entsprechenden HAB-items tragen ...

Aber ich kann und will auch nicht alles auf einmal, die technische Möglichkeit überhaupt Visualisieren und Steuern zu können, ist mir zunächst wichtiger als z.B. so ein "modernes Paper-UI", welches sich ggf. noch dynamisch an verschiedene Bildschirmauflösungen anpasst ...
Gleiches gilt z.B. für das "poweroutlet-Icon", welchem man bisher kaum ansehen kann, ob diese "AN" oder "AUS" sein sollen - bei Gelegenheit werde ich mal versuchen mir Icons zu bauen, bei denen nicht nur ein winziger Punkt sondern z.B. die komplette Mitte der Steckdose dann rot / grün eingefärbt wird ...

BTW: Das "Standard-Item", dass nun für die Dimmer in der GUI angelegt wird, ist so ein einfacher "Slider" - wofür ist dann noch die "On / Off" Option?
Ich kann zwar einen Schalter als zusätzliches Item definieren und dann der On/Off-Option des Dimmers zuordnen, damit erreiche ich dann aber auch nur genau dass, dass das Licht aus beliebiger Helligkeit komplett ausgeschaltet wird oder eben von 0 auf 100% ein - das könnte ich ja über den Slider auch hinbekommen, oder? Interessanter wäre dann noch so ein Feature, dass mit so einem "Schalter" der zuletzt genutzte Helligkeitswert angefahren wird ... -> Dann müsste ich mir aber wohl eine Variable (auch ein Thing?!? Verzeiht meine ggf. inkorrekte Ausdrucksweise) bauen, die sich den Wert "merkt" und das Schalter-Item dann nicht auf das Thing der On/Off-GA sondern irgendwie auf die besagte Speichervariable verlinken, richtig?

ist jetzt "off-Topic":
An anderer Stelle im Forum ( viewtopic.php?t=6369 ) habe ich gefunden, dass die relevanten Files auf dem Linux-Server an folgenden Stellen liegen sollen:

[openHAB3-userdata]
path=/var/lib/openhab

[openHAB3-conf]
path=/etc/openhab

[openHAB3-app]
path=/usr/share/openhab

[openHAB3-logs]
path=/var/log/openhab

Wie schon genutzt, sollten wohl meine "Items", ... unter /etc/... abgelegt werden. Aber kann ich da z.B. beliebig viele "items-Dateien" ablegen oder müssen alle Items in eine Datei?
Wo sind die über die Web-Konfig generierten Devices bzw. Things? Wo die "Bindings" bzw. "links" heißen sie ja? Kann / muss ich die tatsächlich direkt mit in die *.items-Datei eintragen oder kann / muss die auch irgendwo "separat" liegen?
Werden diese Links an mehreren Stellen eingetragen?
Oder irgendwo in Textform die erstellten "Devices" bzw. Things auslesen und dann nochmal per Text-File neu anlegen?

Ich habe z.B. in den oben angegeben Verzeichnissen schon mal per "find" und "grep" nach "AKD" gesucht, was ja irgendwo als UID für meine KNX-Dimmer auftauchen müsste, bin aber so nicht fündig geworden

Viele Fragen...
Speicherort für Textkonfiguration: Unter /etc/openhab/ findest Du eine Ordnerstruktur, dort gibt es für jede "Sorte" Konfigurationsdateien einen Ordner. In dem Ordner kannst Du dann jeweils beliebig viele Dateien anlegen, allerdings muss jeweils die Dateiendung passen. Z.B. /etc/openhab/items/my.items für eine Datei, in der Items definiert werden, oder /etc/openhab/things/http.things für eine Datei, in der Things definiert werden. Der Name legt nahe, dass in der Datei nur things des http Addons gespeichert werden, der Name ist aber rein willkürlich gewählt, man kann dort alle things unterbringen, nur ein einziges Thing, mit http addon, mit beliebigen anderen addons... spielt keine Rolle, nur die Endung .things muss zwingend stimmen.
Man muss außerdem zwei Dinge verstehen: Konfigurationen, die mit textdateien eingepflegt werden, sind in der GUI nur lesbar, aber nicht änderbar. Konfigurationen, die man per GUI anlegt, tauchen in den Textdateien nicht auf.

Das Format einer thing Definition ist in der Doku beschrieben. Leider gibt wa naturgemäß bei jedem Addon andere Parameter, die zu setzen sind. Eine Onlinehilfe wirst Du für die Textkonfiguration vermutlich nicht finden.

Die INCREASE/DECREASE GA brauchst Du in openHAB eigentlich gar nicht. Früher (tm) gab es keinen Slider, stattdessen wurden Dimmer mit UP/DOWN-Knopf gerendert. Abgesehen davon kann es passieren, dass man mit einer Tastwippe aus knxheraus ein anderes Gerät steuern möchte (ich z.B. steuere Mediaplayer an, kurzer Druck rechts -> Titel vor, kurzer Druck links -> Titel zurück, Drücken und halten links -> leiser, Drücken und halten rechts -> lauter.
damit das geht, muss man mindestens vier Befehle umsetzen, das sind ON/OFF und INCREASE/DECREASE.
Natürlich kann es auch vorkommen, dass man von openHAB aus ein Gerät steuern möchte, dann gilt sinngemäß das Gleiche.

In der GUI siehst Du übrigens keine Items, sondern Widgets. Ein Item ist die Schnittstelle zum openHAB Bus, in dem geräteunabhängig Zustände gespeichert werden und Befehle angenommen oder weitergeleitet werden.

Ein Dimmer Item kann die Befehle ON, OFF, INCREASE, DECREASE und die Zahlen 0 - 100 als Befehl entgegen nehmen. der Status eines Dimmer items ist immer eine Zahl zwischen 0 und 100 einschließlich. Man kann den Status aber auch als ON/OFF Wert interpretieren

Ich greif das "alte" Thema mal nochmals auf.
Gibt es nicht mal die Möglichkeit, einfach ein komplettes Dimmer (Muster)-Beispiel aus KNX und OH zu veröffentlichen?
Auf der einen Seite die KO's und GA's und auf der anderen Seite die Channels, Items und eventuell auch Gruppen.

Ich habe das Gefühl, dass "das Rad" immer wieder neu erfunden wird.

Schönen Abend

Torsten

Wieso Rad neu erfinden?

Gegeben: ein Dreifach Dimmer (in diesem Fall ein Hager TXA213), die interessanten Kommunikationsobjekte für Kanal1 Der TXA213 bringt über 30 Kommunikationsobjekte für den einzelnen Dimmerkanal mit, die fürs Dimmen wichtigen sind aber alle unterhalb der 10, weshalb ich hier meine bevorzugte Adressierung verwende, die letzte Stelle der GA bekommt das KO, für Kanal 2 und 3 werden jeweils 10 dazu gezählt, also als Schaltbefehle 1/1/0, 1/1/10 und 1/1/20. Das ergibt für openHAB ein knx Thing mit drei Dimmer Channels: Das sind drei knx Dimmer, aus openHAB-Sicht vollständig abgebildet.
Warum kein increaseDecrease? Weil der Dimmer mit Start-Stopp-Dimming arbeitet, das unterstützt openHAB nicht. Abgesehen davon sollte man Dimmer mit exakten Werten ansteuern, wenn das möglich ist.
Warum keine Rückmeldung für switch? Weil ein Item (bzw. an dieser Stelle der Channel) nur einen Status haben kann. openHAB wird intern den Status passend zur Verfügung stellen, aber wir wollen den Absolutwert sehen, keine ON/OFF Rückmeldung.

Der Dimmer Channel wird mit einem Dimmer Item verlinkt. Im Dimmer Item wird über die Metadaten autoUpdate=false gesetzt, damit nur ankommende Rückmeldungen vom Bus zu einem Status Update führen.
Das Dimmer Item kann mit einem Slider Widget verlinkt werden, wahlweise auch mit einem Switch Widget.
Wird im Switch Widget ON gesendet, so schaltet der Dimmer auf den Vorgabe-Einschaltwert (parametrierbar, fixer Wert 1 % bis 100 % oder letzter Wert vor dem Ausschalten)
Wird im Switch Widget OFF gesendet, so schaltet der Dimmer aus.
Wird über das Slider Widget ein Wert eingestellt, so wird dieser Wert an den Dimmer gesendet und der Dimmer wechselt auf die Helligkeit.
Wird die Dimmhelligkeit geändert, so sendet der Dimmer (!) seinen aktuellen Status am Ende des Dimmvorgangs (sowohl KO 7 als auch KO 8), was openHAB ans Dimmer Widget und ans Switch Widget weiterleitet.
Das Switch Widget wechselt bei 0 % auf OFF, bei jedem anderen Wert auf ON.
Der Slider springt auf die neue Helligkeit (0 % - 100 %)

Ein Wandtaster mit ein-Flächen-Bedienung (halt ein einfacher Taster) soll Kanal 1 steuern und wird für den Kurzen Tastendruck mit Toggle und den GA 1/1/0,1/1/7 programmiert, das heißt, der Taster erfährt vom Dimmer, welchen Schaltzustand der Dimmer gerade hat (ON oder OFF). Dadurch kann der Taster das Licht immer beim ersten Druck aus- bzw. einschalten, egal von wo der vorige Schaltbefehl kam (incl. Zeitfunktionen, Szenen, was auch immer den Dimmkanal steuern kann).
Für den langen Tastendruck wird Start-Stopp-Dimming mit der GA 1/1/1 konfiguriert, das heißt, die Taste sendet bei langem Tastendruck abhängig von der Dimmrichtung 15 oder 7, beim Loslassen 8 oder 0. Der Dimmer startet den Dimmvorgang beim Empfang von 15 oder 7 und stoppt den Dimmvorgang bei Empfang von 8 bzw. 0.

Ich sehe nicht, wo man da was erfinden könnte/sollte/müsste, es gibt nicht all zu viel Spielraum, das korrekt zu konfigurieren.

Es gibt evtl. auch Dimmer, die anders zu konfigurieren sind, das sind aber dann spezielle Geräte, z.B. DALI Gateways. da haben sich schon verschiedene Firmen ausgetobt.

Hallo Udo,

danke für dein Beispiel.
Bei Increase/decrease ist mir folgender Gedanke gekommen.
Wenn auf die GA für relatives Dimmen einfach ein eigener Channel "thing number" erstellt wird.
In einer Regel muss dann nur bei einem "update" der Wert zum aktuellen Dimmwert addiert/subtrahiert werden und damit der
absolute Dimmwert an den Dimmer gesendet werden. Zulässige Werte eben zwischen 0 und 100.
Damit sollte doch auch ein relatives Dimmen umgesetzt werden können ?

Nein.
relatives Dimmen in knx ist komplett unspezifisch (bzw. es kommt sehr auf die Hardware an, wie sie auf die verschiedenen Kommandos reagiert)
Das relative Dimmkommando ist vier Bit groß, also ein Nibble (ober ein half Byte). Das MSB gibt die Dimmrichtung an (also heller oder dunkler), die dre LSB codieren die Schrittweite, wobei diese in Stufen zwischen 111 -> 100% bis 0% -> 000 (Stopp) gehen. Aber probiere mal, was passiert, wenn Du ide Schrittweite änderst (indem Du im Gruppenmonitor der ETS den Befehl sendest... Kein mir bekannter Taster kann damit umgehen, openHAB schon gar nicht).
Das Ergebnis wird mit sehr hoher Wahrscheinlichkeit in zwei Varianten ausfallen.
Variante 1: Der Dimmer dimmt bei einmaligem Senden eines Wertes ungleich 1000 bzw. 0000 üder die vollen 100 %, bis der Wert 1000 bzw 0000 gesendet wird. (das heißt Start-Stop-Dimming
Variante 2: Der Dimmer dimmt immer noch ein kleines Stückchen, unabhängig von der Schrittweite, der Taster muss also den Dimmbefehl ständig wiederholen. Die Schrittweite spielt dabei genauso wenig eine Rolle wie beim Start-Stop-Dimming.
Ursprünglich war wohl mal die Idee, über die Schrittweite tatsächlich zu begrenzen, um wie viel die Helligkeit sinken/steigen darf, bis die Taste erneut gedrückt werden muss, das habe ich aber bisher noch nirgends so realisiert gesehen (und ich empfände es auch als komplett unintuitiv).

openHAB dimmt absolut (und das ist gut so).
Wenn man einen Dimmer partout relativ ansteuern möchte, dann kann man das emulieren: Jedes Mal, wenn das Proxy Item meinDimmerProxy den Befehl INCREASE empfängt, wird die aktuelle Helligkeit von meinDimmer um 5 angehoben (mit Obergrenze 100).
Jedes Mal, wenn das Proxy Item meinDimmerProxy den Befehl DECREASE empfängt, wird die aktuelle Helligkeit von meinDimmer um 5 abgesenkt (mit Untergrenze 0).
Alle anderen Befehle werden 1:1 durchgeleitet.

MAn braucht dafür keinen zusätzlichen Channel und es bringt auhc nichts, einen zusätzlichen Channel für diesen Zweck zu definieren, denn das eigentlihce Problem hängt ja nicht aam INCREASE/DECREASE Befehl, sondern am Unvermögen, diese Befehle korrekt umzusetzen, was vor allem die Implementation in knx selbst verursacht. Aber man kann das halt sehr einfach über eine kleine Rule gerade rücken.

Auf der anderen Seite sehe ich absolut keine Notwendigkeit mehr für diese Bedienform, es gibt Slider, Drehknöpfe, Setpoints, whatever, alles viel sinnvoller, als die ungenaue Steuerung über virtuelle Knöpfe am Bildschirm, die niemals genauso funktionieren können wie Wandtaster, weshalb es auch sinnvoller ist, bessere Bedienelemente zu nutzen. Die Umsetzung über eine Rule stammt aus meinem openHAB 1 System, dort gab es in der Classic UI (die hieß damals natürlich nicht so) keinen Slider. GreenT hatte einen Slider, dafür fehlten dort andere Funktionen und GreenT wurde dann leider nicht mehr weiter entwickelt, entsprechend war das relative Dimming über Rules die einzige Möglichkeit.

In der Gegenrichtung (ein knx Taster sendet INCREASE/DECREASE, was in openHAB dann als Befehl verwendet wird) funktioniert es hingegen super, auch mit Start-Stop-Dimming, wobei man dann im Channel die Frequency setzen muss, also wie häufig der Befehl an den Bus weitergegeben wird, denn von knx kommt ja nur zu Beginn ein Start, und zum Ende ein Stop-Befehl. Es ist hier auch zwingend, dass man einen dimmer-control Channel verwendet, denn es gibt keinen Status INCREASE/DECREASE (eigentlich nicht mal ON/OFF), man kann ide Rule also nur sinnvoll auf reveiced command triggern lassen, dazu muss das datentelegramm aber auch als Command verstandne werden (und dafür gibt es ja die *-control Channel)