Openhab 2 PaperUI -- KNX Anfängerfragen

[Carsten86]

Hallo Knx User.

Ich lese hier schon seit einigen Monaten fleißig mit nur leider komme ich einfach nicht weiter.

Kurz vorweg.
Ich habe meinen Eltern eine Logitech Harmony eingerichtet, damit sie nicht mehr 10 Fernbedienungen haben müssen. Ich konnte alle Fernbedienungen ersetzen bis auf die vom Beamerlift (da Somfy ja nicht IR ist).
Aber da wollte ich nicht aufgeben. Nach einiger Recherche kam ich dann auf Openhab 2 in Verbindungen mit einem RFXtrx433E. Nach einigen Wochenenden und sehr viel googlen und probieren habe ich es dann tatsächlich irgendwann zum laufen gebracht und nun kann auch der Beamerlift mit der Harmony gesteuert werden.
Der Aufwand nur für den Beamerlift ist natürlich ein bisschen viel und jetzt will ich einfach noch ein paar KNX Dinge versuchen mit einzubinden. ( z.B. Die Rolläden)

Dank des Forums habe ich unseren Elektriker gebeten die alte ComPort KNX Schnittstelle durch eine IP Schnittelle zu ersetzen. Es wurde dann ein "Hager TYF120"
Mir war auch bewusst, dass das nur ein Gateway mit nur einer Verbindung und kein Router ist. Eine ETS Lizenz, wenn ich das richtig heraus gelesen habe, ist ja auch nicht zwingend notwendig, wenn man nur bereits bestehende Geräte ansteuern möchte.

Nun zum eigentlichen Thema. Das ist vermutlich eine der simpelsten Basic Aufgaben für einige von Euch. Ich möchte mit Openhab 2 eine KNX Treppenbeleuchtung an und aus schalten können :-), damit ich zumindest mal eine kleinen Erfolg habe und ich sehe, das irgendwas mit der IP-Schnittstelle geht.

Ich denke, das die KNX-IP-Schnittstelle bereits unter Openhab 2 mit dem Binding richtig funktioniert. Sie wird als online angezeigt und auch in der ETS Demo wird sie gefunden.

In meinem angehängten Screenshot habe ich jetzt noch ein paar mehr Infos für Euch. Eigentlich weiß ich hier nur nicht genau was ich bei den beiden "?" eintragen muss.

Oben im Bild ist der Ausschnitt aus der KNX Dokumentation mit der besagten Treppen LED, die ich mir zum testen herausgesucht habe.
Ein Taste unten an der Treppe 1.2.25 und eine oben 1.2.12 die jeweils die Gruppenadresse 1/12 ansteuern.


Und wie gesagt würde ich das gerne alles im Paper UI machen und nicht mit einer Extra extra thing- und item-File usw.

Vielen, vielen Dank schonmal im Voraus.

Carsten

[udo1toni]

Das Problem ist hier, dass openHAB ausschließlich mit dreistufigen Gruppenadressen arbeitet, während Deine Dokumentation mit zweistufigen Gruppenadressen arbeitet.

Schau mal hier: https://knx-user-forum.de/forum/%C3%...a-b-nach-a-b-c und hier https://www.smarthometools.de/produkt/gatool/ gibt es ein Tool zum umrechnen (hab's aber nicht ausprobiert)

Weiterhin sollte eigentlich das Device ONLINE angezeigt werden, allerdings möchte ich das eher als Schönheitsfehler sehen, soweit ich weiß, hat das keine Auswirkungen auf die Funktion des Items.

Um knx und openHAB2 mittels knx2 Binding erfolgreich zu nutzen, ist es notwendig, ein bisschen Hintergrundwissen anzusammeln, welches oft nicht mal bei den Leuten vorhanden ist, die eine ETS Lizenz ihr Eigen nennen :

1. Grundsätzlich "gehören" die Gruppenadressen den Aktoren (Du hast die GA aus der Tabelle bei einem Schalter entnommen). das macht zunächst keinen Unterschied (außer, dass die physikalische Adresse eine andere ist), es ist aber wichtig, um zu verstehen, wie knx funktioniert.
   Der Taster an der Wand sendet an die GA 1/12 den Befehl ON, daraufhin schaltet der Aktor auf ON. Ein anderer Taster schickt ebenfalls auf GA 1/12 den Befehl OFF, daraufhin schaltet der Aktor auf OFF.
2. In einer konventionellen knx Anlage (d.h. ohne umfangreiche vorhandene Visualisierung) fehlen meist viele der notwendigen Rückmelde-GA.
   Du kannst die Trial-Version der ETS verwenden, um hier nachzubessern, allerdings musst Du Dir darüber im Klaren sein, dass Dir Dein Elektriker dann keine Gewährleistung mehr gibt (die kann ja aber auch shcon abgelaufen sein). Da die ETS light nur 5 Devices unterstützt, musst Du die Anlage Stück für Stüpck konfigurieren, sparst dafür aber auch eine Menge Geld
   Konkret sollte der Schaltbefehl 1/12 ON nicht nur den Aktor dazu bewegen, dass der Ausgang auf ON wechselt, sondern zusätzlich sollte der Aktor eine andere GA (meinetwegen 1/512) ebenfalls auf ON schalten. Diese GA folgt immer dem Ausgang des Aktors, wenn der Aktor z.B. mittels Zeitglied selbständig wieder auf OFF wechselt, wird kein Befehl 1/12 OFF gesendet, sehr wohl aber ein 1/512 OFF.
3. openHAB ist darauf angewiesen, den genauen Zustand jedes Aktors zu kennen. Bei Schaltaktoren mag noch der Schaltbefehl ausreichen (falls keine Szenen oder Zentral-GA verwendet werden, die sonst in OH nachgebildet werden müssten), spätestens bei Dimmern muss aber die konkrete Dimmposition bekannt sein (also wieviel % Helligkeit die Lampe hat), bei Rollläden wäre die echte Position interessant, und zum exakten Ansteuern muss openHAB auch die Möglichkeit haben, einen exakten Helligkeitswert oder eine Position zu schreiben. Deshalb sind die Rückmelde-GA nicht optional sondern eine zwingende Voraussetzung!
4. Wenn openHAB Schaltbefehle als Befehl empfangen soll, muss die entsprechende GA mit einem *-control Channel verbunden werden, auch wenn sie vielleicht schon in openHAB als normaler Channel vorhanden ist.

Es gibt noch einige Spezialitäten innerhalb knx, die dann mehr oder weniger große Auswirkungen auf die openHAB-Seite haben können, also, ob das Ganze so funktioniert, wie man sich das vorstellt.


Achso, fast vergessen... Die Location kann leer bleiben. Sie bewirkt lediglich, dass in Paper UI auf der Control-Seite eine Unterseite mit dieser "Überschrift" erzeugt wird, auf der dann alle Things mit dieser Location liegen.
Nachdem Du den Channel konfiguriert hast, musst Du den Channel auch noch mit einem Item verlinken, damit der Channel auch auf der Control-Seite gezeigt, und überhaupt in openHAB verfügbar ist.

[Carsten86]

Wow, ganz lieben Dank schon einmal für die äußerst ausführlichen Beschreibungen und Erklärungen. Ich habe gerade sehr viel zutun und komme somit vermutlich erst wieder am Wochenende an ObenHab. Aber jetzt habe ich ja schon mal wieder ein paar Ansatz Punkte.

Damit ich am Wochende mal weiter testen kann...
Was kann ich denn genau bei diesem Feld eintragen:
"Configure Parameters for the Thing"
muss hier dann eine physikalische Adresse rein?
Man findet sehr viel über Openhab aber noch nicht so viel mit PaperUi.

Ach ja und die GA 1/12 müsste dann zu 1/0/12 werden, wenn ich das richtig gemacht habe.

Ich werde am Wochenende nochmal intensiv weitermachen und dann werden sicher noch einige Fragen auftauchen.

[udo1toni]

"Configure Parameters for the Thing"

Du kannst Dir aussuchen, ob Du jedes Device im knx System als Thing anlegst, oder nur ein einziges "Generic Thing" verwendest. Du könntest auch beide Varianten mischen jedenfalls musst Du nichts eintragen, außer einem eindeutigen Namen für das Thing und die zu nutzende Bridge - schließlich könnte man ja mehrere knx-Systeme verwenden wollen.
Wenn Du jedes Device einzeln anlegst, kannst Du die physikalische Adresse angeben und mit dem Interval bestimmen, dass openHAB in regelmäßigen Abständen prüft, ob Kommunikation mit dem Device möglich ist. Dann bekommst Du eine Anzeige, ob das Device ONLINE oder OFFLINE ist. Das ist allerdings noch nicht ganz zuverlässig, vermutlich, weil die Datenpakete sehr niedrig priorisiert sind. Du kannst pro Device bestimmen, ob openHAB in regelmäßigen Abständen versucht, per Read Request den Status der auslesbaren Channels abzurufen. Das kann bei Sensoren nötig sein, die kein zyklisches Senden unterstützen, ist aber mehr der Holzhammer. Wenn Fetch aktiviert ist, versucht openHAB, mehr über das Device herauszubekommen (Seriennummer, Hersteller, Modell, Programmmaske...) das kann funktionieren, kommt aber sehr auf die Hardware an. Location hatte ich oben schon erklärt.

Ach ja und die GA 1/12 müsste dann zu 1/0/12 werden, wenn ich das richtig gemacht habe.

Das müsste stimmen. Rechnen müsste eigentlich erst bei GA */256 - 2047 nötig sein.

[Carsten86]

Oh man...

irgendwie glaube ich immer mehr, das es mir einfach noch zu sehr an den Basics fehlt. Das ich das mit dem RFXCom Transceiver überhaupt hinbekommen habe ist ja schon ein wunder. Ich dachte auch, wenn ich das mit dem RFXCom hinbekomme, sollte das mit dem KNX eher ein Kinderspiel sein.
Ich habe 65 Tabs offen alles mit Openhab, Knx usw. und ich habe immer noch keinen Plan wie ich eine simple Lampe an und aus machen kann

Jetzt hätte ich dann doch nochmal kurz ein paar Grundsatzfragen.

Ist es überhaupt möglich ohne jegliche Nutzung und Kenntnisse der ETS zumindest die Basics wie Rollläden und Lichter (auch mit Dimmfunktion) per Openhab2 PaperUI vernünftig zu konfigurieren und zu schalten? Natürlich immer unter der Voraussetzung das eine vernünftige Dokumentation vorliegt.
Ich schreibe hier bewusst mit "PaperUI". Damit meine ich das alles nur mit den Dropdowns und Feldern konfiguriert werden kann, die mir PapierUi liefert. Das heißt ohne die Erstellung von ".thing", ".items" & ".sitemaps"- Files in den jeweiligen Ordnern.

Sollte das alles machbar sein, würde ich gerne die schon im Anfangspost erwähnte Treppenbeleuchtung an und as schalten können. ( Dann weiß ich wenigstens, dass zumindest die Kommunikation zwischen Openhab und KNX IP-Schnittelle läuft und funktioniert. Außerdem hab ich dann mal ein kleines Erfolgserlebnis

Sehe ich das richtig, dass die physikalische Adresse eine Adresse für die KNX Hardware ist. Egal ob das jetzt z.B. eine Taster oder eine Wetterstation ist.

Die Gruppenadresse ist dann für das anzusteuernde Gerät. In meinem Fall eine LED Beleuchtung an der Treppe.

Heißt in meinem Fall (siehe Anhang im ersten Post): Taster 1.1.12 und 1.2.25 schalten die Led 1/12 (für Openhab 1/0/12)

Meine Denkweise: Da mich ja in diesem Fall die Taster (also die physikalischen Adressen) hier nicht interessieren, muss ich Openhab nur sagen, dass ein "Thing" mit einem Channel Switch die 1/0/12 schalten soll???

Kurz noch die Vorgehensweise:
Bei "Things" ein "KNX Device" hinzufügen

- Name: z.B. EG LED Treppenbeleuchtung
- Thing ID: so lassen wie es ist.
- Bridge Selection: Hier das KNX/IP Gateway auswählen

- Configuration Parameters
-Adress: Dieses Feld habe ich noch nicht verstanden und noch nirgends herausgefunden, was hier rein soll oder kann. Hat das was mit KNX zutun oder mit Openhab?
- Fetch: Hier hattest Du ja gesagt, das man es anmachen kann oder nicht. Je nach Gerät werden hier extra Infos herausgelesen.
- Interval: Lass ich erstmal auf "600"
- Interval (rechts): Erstmal lassen :-)

Wenn ich das Thing fertig habe, wähle ich es aus und klicke bei Channels auf das blaue "+"

- Channel type: Hier würde ich jetzt Switch wählen.
- Channel ID: Hier bin ich mir leider auch nicht ganz sicher, aber ich glaube hier kann ich auch irgendetwas eintragen. Das ist dann der sichtbare Name des Switches
- Label: auch erstmal egal

- Channel configuration
- Adress: (Hier muss doch jetzt die Gruppenadresse des Beleuchtung hin, also 1/0/12 oder 1.0.12?

Anschließend auf Save.
Da ich bei
- Configuration
-System
- Item Linking den "Simple Mode" an habe wird mir ja somit gleich automatisch ein Item erstellt mit dem Switch

Und leider tut sich hier dann nichts:

Sorry, dass ich das jetzt doch so bis ins kleinste Detail beschrieben habe aber ich denke nur dann kann man vielleicht erkennen, wo bei mir die Schwachstelle/Schwachstellen sind.

Carsten

[udo1toni]

Also, grundsätzlich kannst Du knx2 komplett mit Paper UI konfigurieren. Du musst nicht unbedingt ETS Kenntnisse haben, aber es hilft halt ungemein. Ich könnte jetzt rum ätzen wegen der vernünftigen Dokumentation, denn egal, was der Handwerker für eine Ansicht nutzt, Gruppenadressen sollten grundsätzlich in 3er Schreibweise angeben. Das ist einfach Standard, und die meisten Systeme setzen immer noch die dreiteilige Schreibweise voraus.

Was Deine Vermutungen betrifft, hast Du einen Teil ganz richtig verstanden (die physikalische Adresse gehört zum Device, also der Taster an der Wand hat eine, der Dimmer im Zählerschrank hat eine, das IP Gateway hat eine, der 4-fach Rolladenaktor hat eine.

Die Gruppenadresse (GA) ist aber nicht ein anzusteuerndes Gerät.

Jedes Device hat mindstens ein, meist aber mehrere Kommunikationsobjekte (KO). Ein Dimmer hat beispielsweise mindestens ein KO zum Ein- und Ausschalten, ein KO zum Dimmen (dabei wird die Dimmrichtung mit in dem KO übertragen), ein KO um den Zustand zurückzumelden,, ein KO um den absoluten Dimmlevel zu melden, ein KO um einen absoluten Dimmbefehl anzunehmen, dann kommen noch mehrere KO für Szenensteuerung, Treppenhausschaltung, Vorrangschaltung, Alarmmeldungen dazu (was da geht, hängt vom Device und vor allem vom Hersteller ab)

Alle Geräte innerhalb knx kommunizieren im Normalbetrieb ausschließlich über GA. Das heißt, alles, was über den Bus passiert, ist in GA organisiert.
Dabei gibt es verschiedene Formate für die Daten, die mit einer GA übertragen werden. Zuerst einmal die Anzahl der verwendeten Bits (1,2,4,8,16,32,112, eventuell hab ich noch ein paar vergessen). Bei 1-Bit gibt es nicht viel zu beachten, es gibt letztlich nur zwei Zustände, und ob man das als ON/OFF, OPEN/CLOSED, UP/DOWN interpretiert, spielt letztlich keine Rolle. Bei allen mehrbittigen DPT kommen aber noch viel mehr Interpretationsmöglichkeiten hinzu, die teilweise inhaltlich unterschiedlich interpretiert werden müssen, z.B. kann ein 8-Bit Wert vom Typ Integer sein, er kann ein Vorzeichen (-128 - +127) haben oder auch nicht (0 - 255), es kann aber auch ein Prozentwert gemeint sein, und dieser wiederum könnte von 0-255% gehen (in 1% Schritten) oder von 0-100% (in ~ 0,4% Schritten). Es könnten aber auch 8 einzelne Bits sein, die komplett unterschiedliche Bedeutungen haben, oder, oder, oder... Es gibt eine Übersicht der DPT, ist echt lustig... da kommt einiges zusammen, so ca. 400 verschiedene Typen sind "üblich" bzw. gebräuchlich. Die Liste wird aber regelmäßig überarbeitet und erweitert.
openHAB unterstützt nur einen kleinen Teil der DPT, das deckt aber erfahrungsgemäß nahezu 100% dessen ab, was in Privathaushalten anzutreffen ist.

Jedes KO hat Flags, über die das Kommunikationsverhalten gesteuert werden kann, Kommunikation, Lesbar, Schreibbar, Aktualisierbar, Übertragbar, Initialisierbar. Wenn das K-Flag gesetzt ist, findet Kommunikation mit dem Bus statt, sonst nicht. Ist das L-Flag gesetzt, antwortet dieses KO auf Read Requests. Dieses Flag darf deshalb nur bei einem KO pro GA gesetzt sein. Im Normalfall ist dies dann ein Rückmelde-KO eines Aktors oder auch das KO, welches einen Sensorwert enthält (z.B. die gemessene Raumtemperatur). Ist das S-Flag gesetzt, übernimmt das Device jeden Wert, der auf dieses KO geschrieben wird. ISt das A-Flag gesetzt, tut er das auch, wenn eine Antwort auf einen Read Request auf diesem KO landet. Mit gesetztem Ü-Flag sendet dieser KO auch selbst Daten. Das I-Flag sorgt dafür, dass das KO beim Initialisieren versucht, den aktuellen Status über einen Read Request zu erfragen.

Jedes Device kann auf jedem KO mehrere GA halten, aktive Kommunikation (Senden, Abfragen) geschieht aber immer auf der ersten eingetragenen GA.

Ich denke, Dir schwirrt schon seit dem dritten Absatz der Kopf, und danach ist es nicht besser gewworden. Am ehesten kann die mögliche Komplexität einer knx-Installation erahnen, wenn man weiß, dass große Firmen ihre gesamten Liegenschaften mit knx steuern, ganze Bürohochhäuser komplett mit knx gesteuert werden...

Letztlich kommt über eine GA von irgendeinem Device ein Befehl, jedes Gerät, welches auf dieser GA zuhört (mindestens S-Flag und K-Flag gesetzt) wird daraufhin in seinem Speicher den Status für sein mit der GA verbundenes KO dem Befehl entsprechend setzen. Ob das nun ein Taster ist, der im Toggle-Betrieb läuft und deshalb wissen muss, ob er beim nächsten Drücken nun einen Ein- oder Ausschaltbefehl senden muss, oder ein Aktor, an dessen Ausgang eine LED angeschlossen ist, spielt keine Rolle.

Nun wieder zurück zum eigentlichen Problem.

Einer der Vorzüge der Textkonfiguration ist, dass man es so schön hier posten kann. Aber ich versuche es in Paper UI-Sprech...

1. Bridge definieren.
   - localIp ist die IP-Adresse des Rechners, auf dem openHAB läuft. Hier kommt zwingend die echte IP rein, nicht localhost, nicht der FQDN, nicht 127.0.0.1, sondern z.B. 192.168.178.100, falls das die IP ist, unter der Du auch Paper UI öffnen kannst..
   - Ip ist die IP des knx Gateway. hier kann auch der FQDN rein, falls Du im LAN Namensauflösung hast.
   - type ist TUNNEL
   - port ist 3671 (default)
   - die restlichen Einträge können auch auf default Werten bleiben.
   Anschließend muss die Bridge ONLINE angezeigt werden, im logfile könnte man, wenn man den Log-Level auf Trace setzt, die Kommunikation mit dem knx Bus sehen (jeder Tastendruck auf knx-Seite, jede übertragene Temperatur, usw.)
2. Thing definieren.
   Wie erwähnt musst Du für ein Thing nur den Namen definieren und das Thing der Bridge zuordnen. Alle anderen Einträge kannst Du ignorieren. Das Thing sollte umgehend ONLINE angezeigt werden (das ist aber nur Fake, weil es keine echte Hardware gibt, die hier ausgeweret wird)
3. Channel definieren.
   Im Thing kannst Du beliebig viele Channel anlegen.
   Für jeden Channel musst Du den Typ auswählen, z.B. Switch für einen Schaltkanal.
   Zu jedem Channel muss mindestens eine 3-teilige GA angegeben werden, also z.B. 1/0/12. Da es sich um einen Switch Channel handelt, kann openHAB auf diesem Channel nur Befehle senden. Wenn eine weitere GA eingetragen ist, können auf dieser GA Statusmeldungen empfangen werden, also, wenn der Aktor meldet, dass er jetzt die LED eingeschaltet hat. Das läuft aber zwingend auf einer anderen GA.

Wenn Du Simple Mode aktiviert hast, sollte es anschließend auch noch ein Item mit lächerlich kompliziertem Namen geben, welches mit dem Channel verlinkt ist. Weiterhin sollte das Thing mitsamt Channel in Paper UI Control auftauchen, falls Du eine Location gesetzt hast, auf der Unterseite mit dem Location-Namen.
Die LED sollte dann auch von openHAB aus geschaltet werden können.

Wenn das nicht funktioniert, musst Du leider in den sauren Apfel beißen und lernen, wie man das knx-Binding im Log auf TRACE setzt, damit Du im Log nachschauen kannst, welche GA openHAB empfängt, wenn Du den Taster drückst:

In der Karaf Konsole einloggen (auf welchem Rechner läuft openHAB?) - unter Linux wäre das openhab-cli console (und anschließend habopen als Passwort)
log:set TRACE org.openhab.binding.knx
logout

Das Log lässt sich in der Datei openhab.log nachlesen (unter Linux z.B. in /var/log/openhab2/openhab.log)

[Carsten86]

Unglaublich

Das war auf jeden Fall schon wieder sehr aufschlussreich. Natürlich sind in den ersten 3 Abschnitten sehr viele Infos mit denen ich jetzt noch nicht soviel anfangen kann, aber über das ein oder andere werde ich sicher in naher Zukunft noch stolpern. Gerade wenn es z.B. an Jalousien gehen sollte.

Zu den 3 Schritten mit Paper UI würde ich eigentlich sagen, dass ich das alles so dann richtig gemacht habe. Aber die LED macht leider gar nichts.

Ich habe mich dann mal an den sauren Apfel gemacht und auch rein gebissen.
Über den Windows Rechner mit Putty auf die Synology
hier dann: ssh -p 8101 openhab@localhost
Password: habopen
Anschließend:
log:set TRACE org.openhab.binding.knx
und:
logout

Das scheint auch funktioniert zu haben. So sieht jetzt ein Teil der Log aus:

2018-06-15 10:03:46.295 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/1'
2018-06-15 10:03:46.331 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/20'
2018-06-15 10:03:46.375 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/37'
2018-06-15 10:03:46.421 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/50'
2018-06-15 10:03:47.287 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/4'
2018-06-15 10:03:56.361 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/4'
2018-06-15 10:04:06.370 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/4'
2018-06-15 10:04:15.410 [DEBUG] [.knx.handler.AbstractKNXThingHandler] - Polling individual address '1.1.90'
2018-06-15 10:04:16.343 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/1'
2018-06-15 10:04:16.379 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/20'
2018-06-15 10:04:16.416 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/37'
2018-06-15 10:04:16.453 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/50'
2018-06-15 10:04:17.279 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/4'
2018-06-15 10:04:26.361 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/4'
2018-06-15 10:04:47.518 [DEBUG] [.knx.handler.AbstractKNXThingHandler] - Polling individual address '1.1.90'
2018-06-15 10:05:19.631 [DEBUG] [.knx.handler.AbstractKNXThingHandler] - Polling individual address '1.1.90'
2018-06-15 10:05:26.355 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/4'
2018-06-15 10:05:37.350 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/4'
2018-06-15 10:05:46.284 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/1'
2018-06-15 10:05:46.320 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/20'
2018-06-15 10:05:46.356 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/37'
2018-06-15 10:05:46.408 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/50'
2018-06-15 10:05:47.274 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/4'
2018-06-15 10:05:47.620 [TRACE] [.internal.handler.DeviceThingHandler] - Handling command 'OFF' for channel 'knx:device:ca97e4eb:LED'
2018-06-15 10:05:47.692 [WARN ] [calimero.link.192.168.2.76:3671     ] - negative confirmation of 1/0/12: 2e00bde0ffff080c010080
2018-06-15 10:05:47.693 [DEBUG] [nx.internal.client.AbstractKNXClient] - Wrote value 'OFF' to datapoint 'command DP 1/0/12 'knx:ip:28ebf958', DPT id 1.001, low priority' (0. attempt).
2018-06-15 10:05:51.740 [DEBUG] [.knx.handler.AbstractKNXThingHandler] - Polling individual address '1.1.90'
2018-06-15 10:05:56.347 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/4'
2018-06-15 10:06:07.347 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/4'
2018-06-15 10:06:09.525 [TRACE] [.internal.handler.DeviceThingHandler] - Handling command 'ON' for channel 'knx:device:ca97e4eb:LED'
2018-06-15 10:06:09.596 [WARN ] [calimero.link.192.168.2.76:3671     ] - negative confirmation of 1/0/12: 2e00bde0ffff080c010081
2018-06-15 10:06:09.597 [DEBUG] [nx.internal.client.AbstractKNXClient] - Wrote value 'ON' to datapoint 'command DP 1/0/12 'knx:ip:28ebf958', DPT id 1.001, low priority' (0. attempt).
2018-06-15 10:06:16.308 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/1'
2018-06-15 10:06:16.352 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/20'
2018-06-15 10:06:16.388 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/37'
2018-06-15 10:06:16.425 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/50'
2018-06-15 10:06:17.272 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.90' to '9/0/4'

Die 1.1.90 ist die Wetterstation die wohl ständig ihre Daten übermittelt.

Der Handling command 'ON' und 'OFF' kommt, wenn ich in Openhab das Licht steuern will.
Aber das "negative confirmation" sieht ja nicht gut aus. Irgendwas scheint da ja etwas nicht zu klappen.

Ach ja und wenn ich das her richtig vertanden habe:

wenn man den Log-Level auf Trace setzt, die Kommunikation mit dem knx Bus sehen (jeder Tastendruck auf knx-Seite, jede übertragene Temperatur, usw.

...müsste ja, wenn ich den echten Wandtaster der LED drücke das auch in der log File erscheinen. Aber selbst da tut sich leider gar nichts.

[udo1toni]

...müsste ja, wenn ich den echten Wandtaster der LED drücke das auch in der log File erscheinen. Aber selbst da tut sich leider gar nichts.

Genau das müsste auf jeden Fall passieren. Jetzt habe ich aber ein ganz anderes Problem. DieWetterstation hat die physikalische Adresse 1.1.90, die Taster haben aber die physikalische Adresse 1.2.12 und 1.2.25, das bedeutet, ihr habt mindestens mehrere Linien, vermutlich aber gar mehrere Bereiche. Dann werden eventuell die GA gefiltert. Das knx-IP-Gateway muss an einer Stelle im knx-System eingebunden sein, wo alle GA ungefiltert entlang marschieren, sonst kann es ja keine Nachrichten empfangen und versenden.

[Carsten86]

Oh nein, das klingt jetzt erstmal gar nicht gut.

Aber das würde für mich dann folgendes Bedeuten?:
Das Gateway hängt zwar in unserem "Elektokeller",man kann zwar von da aus auch alles mit der ETS einstellen, aber an dieser Postion laufen dann nicht mehr alle internen Ströme zusammen? Und das wieder rum liegt dann vermutlich an den "Verteilern"? Im Anhang habe ich sie blau umkreist.

Was habe ich den jetzt noch für Optionen? Oder ist das einfach alles nicht so möglich und ich bin ein bisschen zu leichtsinnig an die ganze Sache heran gegangen.

[udo1toni]

Die Frage ist, wie die beiden Linien zusammengeführt sind. Sitzt dort nur ein Linienkoppler (naja, zwei, pro Linie einer), sollte es eigentlich keine Schwierigkeiten geben. Sitzt dort aber ein Bereichskoppler, dann ist in diesem eine Filtertabelle hinterlegt, was dazu führt, dass alle Gruppentelegramme, die nicht in der 2. Linie gebraucht werden, gefiltert werden.
Da Dein Gateway in der Linie 1.1. angeschlossen ist, sieht es den gesamten Datenverkehr dieser Linie. Die Linie 1.2. ist aber quasi unsichtbar, es sei denn, Du hast Zentralbefehle oder z.B. einen Taster in 1.2., der die Heizung steuert (die in 1.1. angeschlossen ist).
Man kann diese Filtertabellen auch auf Durchzug stellen, je nach Größe der Installation kann das aber wieder zu Problemen mit dem Datendurchsatz führen.
Es gibt mehrere Möglichkeiten, damit umzugehen.

1. Man setzt knx/IP-Router ein. Damit wird der Backbone vom knx (also die Linie 1.) von TP auf Ethernet umgestellt. Das ist teuer. Die Filtertabellen müssen trotzdem deaktiviert sein.
2. Du setzt pro Bereich ein eigenes Gateway ein, also in Deinem Fall (zumindest, was ich aus dem Plan sehen kann) ein 2. Gateway. openHAB2 kann dank knx2 Binding auch mit mehreren knx Gateways umgehen. Das ist nicht sehr elegant. Außerdem musst Du beim Anlegen eines Geräts in openHAB immer darauf achten, dass Du es dem richtigen Gateway zuordnest. Die Gateways müssen dort montiert werden, wo die beiden Linien zusammengeführt sind, alternativ muss man entsprechend Ethernetkabel verlegen.
3. Du deaktivierst einfach die Filtertabelle und schaust, wie die Busauslastung aussieht, ob es zu spürbaren Verzögerungen bei der Bedienung kommt (ausschließlich knx, also ohne openHAB gestartet zu haben)

Da Du keine ETS hast, läuft jede der Optionen auf einen Besuch Deines Elektrikers hinaus.