KNX 2.x Binding verfügbar!

[Höhlenbär]

Was ist die 5/3/0 für eine GA?

Das ist eine Zentralfunktion Beim Schalten über diese GA bekommt die Visu es nicht mit. Leider haben noch nicht alle Aktoren bei mir eine Statusobjekt.
Ein ähnliches Problem habe ich bei den Jalousieaktoren welche kein Rückmeldeobjekt haben. Dort gibt es die GA und die Zentralfunktion.
Da habe ich das Problem das beim Fahren über die Zentralfunktion die Visu dies nicht mitbekommt. Wie löst ihr das ?

[udo1toni]

Wenn das in diesem Thread falsch ist, bitte verschieben aber die meisten Anderen beziehen sich noch nicht auf das neue Binding.

Verschieben ist hier nicht üblich, soweit ich weiß, gibt es auch keinen zuständigen Moderator.
Allerdings hindert Dich niemand, ein neues Thema zu öffnen...

Das ist eine Zentralfunktion Beim Schalten über diese GA bekommt die Visu es nicht mit. Leider haben noch nicht alle Aktoren bei mir eine Statusobjekt.

Das ist immer wieder ein Problem, was von den Anwendern nicht richtig wahrgenommen wird. Eine simple knx Testinstallation mag ohne Rückmeldeobjekte auskommen, spätestens mit einer Visu ist die Rückmeldung nicht optional. Man kann zwar Zentralfunktionen mit den Channels koppeln, aber das ist nicht das Gleiche wie eine aktive Rückmeldung. Was passiert wenn eine Szene aufgerufen wird?
Das Gleiche gilt für die Schalter an der Wand.
Der korrekte Aufbau ist also:
1. Im Aktor die Schalt-GA mit dem Schaltkanal verbinden. Zentralbefehle als weitere GA eintragen.
2. Pro Schaltkanal eine eigene Rückmelde-GA anlegen und lesbar setzen (L-Flag bzw. R-Flag im englischen Sprachraum). Dimmer haben zwei Rückmeldekanäle, einer ON/OFF, ein weiterer 0-100%
3. Wandtaster (speziell solche mit Zustandsanzeige,aber auch solche, die toggeln) bekommen die Rückmelde-GA als 2. GA eingetragen. Damit bekommen sie immer den aktuellen Schaltzustand des Aktors mit.
4. In openHAB wird die Schalt-GA und zusätzlich die Rückmelde-GA (mit <) eingetragen. Damit erhält auch openHAB immer den aktuellen Zustand, unabhängig davon, wie der Aktor gesteuert wurde. Durch das < kann openHAB beim Start den Status aktiv erfragen, sonst müsste jeder Aktor einmal geschaltet werden, damit openHAB den korrekten Zustand kennt. Bei Dimmern reicht die Rückmeldung des Dimmwertes (ON/OFF wird davon abgeleitet).

[jo3ran]

Hallo zusammen,

ich habe mit meinem Testaufbau (Schaltaktor für Steckdose, Taster und Präsenzmelder) das neue Binding zum Laufen gebraucht. Allerdings wird der Status vom Aktor nicht eingelesen, so dass bei Aktivierung der Dose über PM oder Taster in der OpenHab Visualisierung der Switch aus bleibt.

In der ETS habe ich das KO zum Schalten auf 1/0/1 und den Status des Ausgangs auf 1/1/1. Im Item habe ich über die Paper UI die zugehörige GA in der Form angegeben: 1/0/1+<1/1/1. Ein- und Ausschalten funktioniert, aber der Status wird nicht abgefragt. Wäre über Euren Input dankbar.

[udo1toni]

Hast Du in ETS auch das L-Flag auf dem Statusobjekt des Aktors gesetzt? (Also das, was auf 1/1/1 gelinkt ist)

[jo3ran]

Hast Du in ETS auch das L-Flag auf dem Statusobjekt des Aktors gesetzt? (Also das, was auf 1/1/1 gelinkt ist)

Hi, danke für den Hinweis. Ja, auf der 1/1/1 die nur den Ausgang (KO 49 Status Schalten) enthält, ist KLÜ gesetzt.

Habe jetzt noch mal ein bisschen probiert. 2 Dinge: Im Browser der Sitemap steht die ganze Zeit "Offline: Warte auf Verbindung". Wenn ich dann per Taster das Licht einschalte, bleibt der Switch aus. Sobald ich manuell die Seite neulade, springt er aber korrekt auf ein. Wahrscheinlich muss ich zum Refresh-Verhalten der Sitemap noch ein bisschen recherchieren.

[udo1toni]

Alte Regel bei Software: Reboot tut gut. In diesem Fall reicht auch ein Neustart von openHAB.

[huwi07]

Hallo und einen schönen Abend

habe nach einigen Versuchen festgestellt das nur 3 stufige Gruppenadressen funktionieren, ist das so oder habe ich etwas übersehen es wäre sehr mühsam alles von 2 stufig umrechnen zu müssen.

[theneon]

Hi , so bin jetzt auch auf knx2 binding . Aber leider nicht wirklich stabil nach ein paar Stunden verabschiedet sich das Binding :

2018-04-16 11:33:51.463 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2018-04-16 11:33:51.475 [DEBUG] [.internal.handler.DeviceThingHandler] - Thing 'knx:device:knxgw:1-1-45' received a Group Write telegram from '1.1.6' for destination '6/4/34'
2018-04-16 11:33:51.475 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:knxgw is disconnecting from the KNX bus
2018-04-16 11:33:51.499 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:knxgw is connecting to the KNX bus
2018-04-16 11:33:51.505 [DEBUG] [binding.knx.internal.client.IPClient] - Establishing connection to KNX bus on 192.168.90.7:3671 in mode TUNNEL.
2018-04-16 11:33:51.516 [ERROR] [NXnet/IP Tunneling 192.168.90.7:3671] - establishing connection failed, null
2018-04-16 11:33:51.521 [DEBUG] [nx.internal.client.AbstractKNXClient] - Error connecting to the bus: null
java.lang.InterruptedException: null
        at java.lang.Object.wait(Native Method) ~[?:?]
        at tuwien.auto.calimero.knxnetip.ConnectionBase.waitForStateChange(ConnectionBase.java:541) ~[?:?]
        at tuwien.auto.calimero.knxnetip.ClientConnection.connect(ClientConnection.java:190) ~[?:?]
        at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.<init>(KNXnetIPTunnel.java:159) ~[?:?]
        at org.openhab.binding.knx.internal.client.IPClient.getConnection(IPClient.java:107) ~[?:?]
        at org.openhab.binding.knx.internal.client.IPClient.createKNXNetworkLinkIP(IPClient.java:90) ~[?:?]
        at org.openhab.binding.knx.internal.client.IPClient.establishConnection(IPClient.java:77) ~[?:?]
        at org.openhab.binding.knx.internal.client.AbstractKNXClient.connect(AbstractKNXClient.java:178) ~[?:?]
        at org.openhab.binding.knx.internal.client.AbstractKNXClient.connectIfNotAutomatic(AbstractKNXClient.java:164) ~[?:?]
        at org.openhab.binding.knx.internal.client.AbstractKNXClient.readNextQueuedDatapoint(AbstractKNXClient.java:272) ~[?:?]
        at org.openhab.binding.knx.internal.client.AbstractKNXClient.lambda$1(AbstractKNXClient.java:199) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
        at java.lang.Thread.run(Thread.java:745) [?:?]
2018-04-16 11:33:51.701 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:knxgw is disconnecting from the KNX bus

würde behaupten es sollte sich ja dann automatisch reconnecten. Macht es aber leider nicht

[PascalTurbo]

Ich hab auch mal angefangen, mir das KNX 2.0 Binding anzuschauen, nachdem ich die OpenHAB 2 Migration nun schon ein gutes Jährchen vor mir her schiebe (1.X läuft ja ). Hab es natürlich erstmal über die UI versucht, aber damit werd ich nicht warm. Für ne kleine Spiel-Installation mag das zwar reichen, aber wenn ich mir vorstelle, meine Komplette Installation da rein zu übertragen - viel zu unübersichtlich und kompliziert.
Dazu ein paar Fragen:

a) Verliere ich Funktionalität, wenn ich Config-Files pflege statt die UI zu nutzen?
b) Wozu muss ich die HW-Adresse eines Aktors angeben?
c) Muss ich wirklich für jede Funktionalität zuerst ein Thing und dann ein item anlegen - also alle Arbeit doppelt machen?

Viele Grüße
Pascal

[udo1toni]

Zu a): Außer, dass Du die Konfiguration über die UI dann nur anschauen, aber nicht bearbeiten kannst, sollte es keinen Unterschied geben.
Zu b): Nein. Du kannst sogar alle Channel in einem einzigen Thing anlegen, dann betrachtest Du halt Den gesamten knx Bus als ein Gerät. Die Geräte einzeln anzulegen hat aber durchaus Vorteile, was die Übersichtlichkeit betrifft.
Zu c): Wenn Du VSCode mit dem openHAB Plugin verwendest, reicht es, die Things und Channels anzulegen. Anschließend kannst Du über das Kontextmenü in der Things-Liste zu einzelnen Channels oder auch allen Channels eines Things automatisch Items erzeugen lassen. Naturgemäß wird VSCode dabei die Itemnamen und jegliche Konfiguration aus den Channels oder/und dem Thing erzeugen. Tipp: Lege erstmal ein Thing mit einem oder zwei Channels an und probiere beide Varianten aus, um zu veerstehen, welche Auswirkungen die verschiedenen Teile der Thing-Definition haben. Wenn Du diese Erkenntnisse beim Anlegen der Things/Channels berücksichtigst, musst Du anschließend weniger Änderungen an den Items vornehmen (z.B. Label anpassen, icons und Gruppen hinzufügen usw.).

Wichtig zu wissen ist, dass sich knx2 in einem Punkt komplett anders verhält, als knx1. unter knx2 gibt es jeweils zwei Channeltypen, z.B. switch und switch-control. Der Unterschied besteht darin, dass switch Status Updates vom Bus empfängt, aber keine Kommandos empfängt, während switch-control Kommandos empfängt, aber keine Status-Updates bekommt.

Wo also bisher ein Item der Form

Switch MeinLicht "Licht ist [%s]" {knx="1/1/1+<1/1/2"}

ausreichte, um zum einen den Zustand des Lichts zu sehen, zum anderen aber auch jeden Schaltbefehl vom Bus zu empfangen, reicht das unter knx2 unter Umständen nicht mehr aus. Wenn es keinen Aktor gibt, der das Kommando als Status auf den Bus sendet, gibt es auch kein Status Update. received command wird auf keinen Fall getriggert. Man muss also Trigger in den Rules anpassen, eventuell muss man identische GA in zwei Channels anlegen, der eine (switch) ist dann die Lampe bzw. der Aktor, der die Lampe schaltet, der andere (switch-control) ist der Schalter, der der Schaltbefehl sendet.
Ein Item, welches mit einem switch-control Channel verlinkt ist, empfänt die Kommandos und kann seinerseits den Status auf den Bus senden.

Was zunächst sehr kompliziert wirkt, ist, wenn man genau darüber nachdenkt, eigentlich der korrekte Weg, dies zu lösen. openHAB kann nun auch als Gerät gegenüber dem knx Bus auftreten, auch wenn man natürlich keine Verknüpfungen mittels ETS vornehmen kann.

Besonders kommt dieser Unterschied bei Datum & Zeit zum Tragen. openHAB ist hier für den knx Bus normalerweise die Uhr, während alle anderen Geräte am Bus ihre Zeitinformation von openHAB bekommen. das bedeutet also, dass die Datum&Zeit Channel als datetime-control angelegt werden müssen, damit openHAB die ntp-Updates auf den knx Bus schicken kann.

[zaphood]

Hi Udo1toni,

danke für die Erklärung, mal wieder ein kleines bisschen mehr verstanden (so richtig steige ich beim Zweck der Zweiteilung noch immer nicht durch).
Vielleicht kannst du mir helfen mal Licht in folgende Situation zu bringen:

Schaltaktor, Kanal 1, ga 1/1/8 / Rückmeldung 1/4/8 -> Licht im Wohnzimmer
-> in der knx.things steht dann da "Type switch : Channel_25 "Wohnen Wandlampe West Links" [ ga="1/1/8+<1/4/8" ]" und
-> in der knx.items "{ Licht_WoZi_Wandlampe_West channel="knx:device:KNXRouter:Jung230816:Channel_2 5" } "

Physischer Tastsensor Taste 1, ga 1/1/8 sendend (soll Licht schalten)
-> den gibt es in der knx.items bislang nicht, wozu auch?

OH2 als Visu
- In der Sitemap angelegt als "Switch Item=Licht_WoZi_Wandlampe_West". Geht soweit. Allerdings werden immer mal wieder die Icons falsch animiert (Licht aus, Icon noch gelb. Oder Dimmer auf 100% dennoch Icon gedimmt. Bisher keine Logik dahinter gesehen)

Wenn ich deine Aussage richtig verstehe, müsste ich den Tastsensor ebenfalls anlegen und seine Kanäle aber als -control definieren (zusätzliche GA?). Dann in OH2 das Switch Item mit dem -control Item verbinden, nicht mit dem bisherigen?
Oder genügt es, das -control Item einfach so anzulegen (ohne den Tastsensor) damit OH2 als "aktives KNX Device" funktioniert?

Ich bin hier echt verwirrt; denn der Taster in der OH2-Visu dürfte doch gar keine Kommandos verschicken können laut der oben stehenden Beschreibung... warum geht das Licht dann dennoch an?

[udo1toni]

so richtig steige ich beim Zweck der Zweiteilung noch immer nicht durch

Aus Gründen Im Ernst: in openHAB kam das Konzept der Things dazu. Things sind die Entsprechung der Hardware.

Wenn ich deine Aussage richtig verstehe, müsste ich den Tastsensor ebenfalls anlegen und seine Kanäle aber als -control definieren (zusätzliche GA?).

Nein, das hast Du falsch verstanden. Grundsätzlich ist es nicht notwendig, Schalter anzulegen.
Der Normalfall ist, dass Du alle Aktoren als Things anlegst und die Channel entsprechend als Items einträgst.

Wenn auf knx-Seite Schaltbefehle kommen, werden diese im Gegensatz zu knx1 nicht in openHAB sichtbar, einzig die Rückmeldung des Aktors, dass er seinen Schaltzustand geändert hat, kommt in openHAB an.
Nun stell Dir vor, Du hast einen nicht-knx Aktor, den Du bisher parallel zu einem knx-Aktor hast schalten lassen. War bisher kein Problem, weil jeder Schaltbefehl als Schaltbefehl in openHAB an die verlinkten Bindings weitergereicht wurde. Das ist jetzt nicht mehr das Fall.

Ich bin hier echt verwirrt; denn der Taster in der OH2-Visu dürfte doch gar keine Kommandos verschicken können laut der oben stehenden Beschreibung... warum geht das Licht dann dennoch an?

Weil das Licht innerhalb knx geschaltet wird. Das Licht geht ja auch an, wenn openHAB gar nicht läuft.

Warum ich "Channel_25" zusammenschreibe und nach der Speicherung ein Blank zwischen 2 und 5 steht entzieht sich mir leider :-)

Weil Du den Code nicht als Code markiert hast

Switch Licht_WoZi_Wandlampe_West { channel="knx:device:KNXRouter:Jung230816:Channel_25" }

[zaphood]

Aus Gründen Im Ernst: in openHAB kam das Konzept der Things dazu. Things sind die Entsprechung der Hardware.

Nein, das hast Du falsch verstanden. Grundsätzlich ist es nicht notwendig, Schalter anzulegen.
Der Normalfall ist, dass Du alle Aktoren als Things anlegst und die Channel entsprechend als Items einträgst.

Äh, falsches Gleis...ich meinte nicht Things und Items (das habe ich verstanden, finde es immer noch idiotisch für KNX aber akzeptiere dass es eben "so sein muss, damit es dem Konzept entspricht" :-))
Ich rede von der Zweiteilung in items und -control-items ;-)

Wenn auf knx-Seite Schaltbefehle kommen, werden diese im Gegensatz zu knx1 nicht in openHAB sichtbar, einzig die Rückmeldung des Aktors, dass er seinen Schaltzustand geändert hat, kommt in openHAB an.

Hab ich ja auch verstanden, DASS es so ist. Nur warum das so gemacht wurde, hat sich mir noch nicht erschlossen...

Nun stell Dir vor, Du hast einen nicht-knx Aktor, den Du bisher parallel zu einem knx-Aktor hast schalten lassen. War bisher kein Problem, weil jeder Schaltbefehl als Schaltbefehl in openHAB an die verlinkten Bindings weitergereicht wurde. Das ist jetzt nicht mehr das Fall.

Genau. Und schon haben wir einen funktionalen Nachteil, dessen Sinn ich nicht verstehe.

Weil das Licht innerhalb knx geschaltet wird. Das Licht geht ja auch an, wenn openHAB gar nicht läuft.

Äh, ne, andersrum..ich frage ja gerade weshalb ich AUS OH2 SCHALTEN kann, obwohl der betreffende Switch KEIN -control-item ist.

Weil Du den Code nicht als Code markiert hast

Switch Licht_WoZi_Wandlampe_West { channel="knx:device:KNXRouter:Jung230816:Channel_25" }

Ok, angewandte Blödheit meineseits, sorry :-)

[udo1toni]

Äh, falsches Gleis...

Ah. Damit war dann natürlich meine Erklärung für die Katz...

Was die Zweiteilung betrifft, kann ich nur mutmaßen, dass die Programmierer es nicht hinbekommen haben, dass es keine Echos auf dem Bus gibt (das war ein großes Problem mit OH2 und knx1). Ich verstehe die Interna nicht (vermutlich, weil ich nicht durchblicke, welche Codeteile an welcher Stelle eine Rolle spielen), aber es ist wohl nicht so ganz einfach für OH2, zu entscheiden, welche Nachrichten ursprünglich von openHAB stammen, und welche vom Binding kommen.
Man muss dabei im Hinterkopf haben, dass openHAB stateless arbeitet (Items speichern zwar Status, aber das Design ist stateless, so dass openHAB z.B. bei Empfang einer Nachricht nicht weiß, dass es diese Nachricht vor einer Millisekunde selbst geschickt hat).

Normale knx Channel nehmen ausschließlich Befehle entgegen und schicken im Gegenzug ausschließlich Statusnachrichten. knx-Conrol-Channel schicken nur Befehle und nehmen nur Statusnachrichten entgegen.
Deshalb kannst Du locker aus openHAB mit einem MyKnxItem.sendCommand(irgendeinBefehl) die knx-Seite steuern. openHAB agiert hier nicht als gesteuertes Gerät, sondern als "Schalter", der natürlich den aktuellen Zustand auswertet.
Wenn aber ein knx Schalter ein Nicht-knx-Gerät steuern soll, muss openHAB stellvertretend die Rolle eines Aktors übernehmen, dafür dienen die Control Channel.

Ich finde diesen breaking change auch sehr unschön. Momentan habe ich auch das Phänomen, dass überhaupt keine Status in knx2 ankommen, bei Systemstart werden auch keine Status empfangen. Da openHAB2 bei mir noch nicht produktiv läuft, habe ich aber noch nicht viel Energie investiert, z.B. habe ich bisher nicht die Schnittstelle (Weinzierl 730) neu gestartet.

[zaphood]

Zum ersten Mal eine Erklärung für die Zweiteilung der items gelesen (wenn auch auf Vermutung basierend :-)) die mir einleuchtet. Danke dafür !

Ich würde mal zusammenfassend vermuten, dass die items das Verhalten von Aktoren, die control-items dagegen das von Sensoren im KNX-Sinne abbildet.
Wenn OH komplett stateless ist, kann es im KNX Sinne auch nur einen Sensor darstellen, aber keinen Aktor (der kennt ja einen Status)

Bleibt die Frage, warum man in der OH2 Visu ein Switch-Item schalten kann, das nur als item angelegt, wurde. Wie schon in meinen vorherigen Post geschrieben, dürfte das doch nur gehen, wenn ich das als control-item anlege.



BTW: Ich habe wieder auf KNX 1 umgestellt, nachdem die 2er Version im Laufe einer Woche immer mehr Seltsamkeiten entwickelt hat, bis dann zum Schluss ein paar GA's komplett ignoriert wurden (Befehle und Stati blieben in OH2 und gingen nicht mehr auf den Bus. Selbes Phänomen auch in die andere Richtung). Statuswerte vom Bus wurden auf einmal völlig falsch (!) übergeben: Alle Positionen meiner Rollläden die !=100% waren, sind nur noch als "0" bei OH2 angekommen (wohlgemerkt von verschiedenen Aktoren die auch noch von verschiedenen Herstellern stammen). Im KNX Monitor habe ich die korrekten Werte gesehen. Strange.

Lustig ist auch, dass GA's die mit "ga=<x/x/x" definiert sind ja explizit gelesen werden sollen, für diese aber Stati dennoch nicht gelesen werden und vor allem beim Systemstart viel Verkehr auf dem Bus abgeht, aber seltsamerweise viele Stati dennoch fehlen (und ja, die entsprechenden GA sind korrekt mit "L" geflaggt).


Nach dem Einspielen des Backups und Umstellung auf das alte Binding ging alles problemlos. Scheint als ob KNX2 noch lange nicht ausgereift ist. Diese unlogischen und erratischen Fehlerbilder machen das Debugging sicher schwer. Ist irgendwie ungeschmeidig, wenn in der Community die Antworten auf entsprechende Supportanfragen mehr auf "kann nicht sein" und "hast du falsch verstanden" abzielen als auf systematische Suche nach möglichen Bugs.