KNX 2.x Binding verfügbar!

[udo1toni]

Wenn Du mehrere Things verwenden willst, musst Du schon jedem Device einen anderen Namen geben!
Strukturiert sähe das so aus:

Bridge knx:ip:bridge "KNX IP Tunnel" [
    ipAddress="192.168.3.15",
    portNumber=3671,
    localIp="192.168.3.202",
    type="TUNNEL",
    readingPause=50,
    responseTimeout=10,
    readRetriesLimit=3,
    autoReconnectPeriod=1,
    localSourceAddr="0.0.0"
]
{
    Thing device Temp[COLOR=#FF0000]1[/COLOR] "KNX Tempregler [COLOR=#FF0000]1[/COLOR]" [
        address="1.1.11",
        fetch=true,
        pingInterval=300 [COLOR=#FF0000]//,[/COLOR]
[COLOR=#FF0000]//[/COLOR]      readInterval=3600
    ]
    {
        Type number : [COLOR=#FF0000]Temperature[/COLOR] "Temperature 1" [ ga="9.001:<1/7/0" ]
    }
    Thing device Temp[COLOR=#FF0000]2[/COLOR] "KNX Tempregler [COLOR=#FF0000]2[/COLOR]" [
        address="1.1.12",
        fetch=true,
        pingInterval=300 [COLOR=#FF0000]//,[/COLOR]
[COLOR=#FF0000]//[/COLOR]      readInterval=3600
    ]
    {
        Type number : [COLOR=#FF0000]Temperature[/COLOR] "Temperature 2" [ ga="9.001:<1/7/1" ]
    }
}

Jedes Thing muss einen eindeutigen Namen haben. Bei den Labeln bin ich mir nicht sicher, ob die zwingend eindeutig sein müssen, aber da die Label das Sortierkriterium sind und von VSCode verwendet werden, um eindeutige Itemnamen zu erzeugen (wenn man ganze Things auf einmal als Items anlegen lässt), ist es mehr als sinnvoll, hier eindeutig zu bleiben.
Im Gegensatz dazu kann aber der einzelne Channel eines Things immer den gleichen Namen haben. Wenn man mehrere identische Devices hat, dann sind auch die Channel jeweils identisch.
Probiere erst mal, ob die Temperaturen bei Wertänderung automatisch auf dem Bus landen. readInterval ist ein hässlicher Hack, der nur bei sehr wenigen Devices wirklich notwendig ist - normalerweise sollte ein Temperatursensor bei Wertänderung senden, alternativ zyklisch. Nur falls beide Optionen nicht funktionieren, wäre der Read Request sinnvoll (dann aber sicher nicht stündlich )
Weiterhin Obacht was die Hierarchie betrifft! Alle Things befinden sich exakt eine Klammerebene unter der Bridge, alle zu einem Thing gehöredenen Channel befinden sich exakt eine Klammerebene unter dem Thing.

[typoon007]

Hallo,

ich bin neu hier,

kann mir jemand die Syntax erklären wie man mehr wie einen KNX Baustein in die knx.things einträgt?

so wie nachfolgend geht es bei mir nicht

Danke



Bridge knx:ip:bridge "KNX IP Tunnel" [

ipAddress="192.168.3.15",

portNumber=3671,

localIp="192.168.3.202",

type="TUNNEL",

readingPause=50,

responseTimeout=10,

readRetriesLimit=3,

autoReconnectPeriod=1,

localSourceAddr="0.0.0"




]

{

{ Thing device Temp "KNX Tempregler" [ address="1.1.11",fetch=true,pingInterval=300,readI nterval=3600 ]




{

Type number : Temperature "Temperature" [ ga="9.001:<1/7/0" ]

}

}

{ Thing device Temp "KNX Tempregler" [ address="1.1.12",fetch=true,pingInterval=300,readI nterval=3600 ]




{

Type number : Temperature1 "Temperature1" [ ga="9.001:<1/7/1" ]

}

}

}

[udo1toni]

Ich würde mal zusammenfassend vermuten, dass die items das Verhalten von Aktoren, die control-items dagegen das von Sensoren im KNX-Sinne abbildet.

Nö.
Naja, Ja und Nein. Temperaturen werden z.B. durchaus in openHAB ankommen, obwohl sie nicht als number-control, sondern als number definiert sind.

Wenn OH komplett stateless ist, kann es im KNX Sinne auch nur einen Sensor darstellen, aber keinen Aktor (der kennt ja einen Status)

Nochmal Nö. openHAB selbst ist stateless, hat aber sehr wohl einen Speicher, um die Status zu halten (nämlich den openHAB Bus, welcher durch die Items definiert ist) Aber im eigentlichen Sinne wird openHAB selbst kein Aktor sein, sondern die Aufgabe (Schalten und behalten) an ein Binding übergeben, welches sich dann darum kümmert. Dass openHAB sich dennoch intern die Status merk, ist einfach ein Zugeständnis an Zuverlässigkeit und Geschwindigkeit - wäre ja doof, wenn jedesmal, wenn ein Status benötigt wird, openHAB extern nachfragen müsste. Stattdessen verfolgt es sämtliche Änderungen.

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.

Hab ich eigentlich geschrieben: control nimmt keine Befehle von openHAB entgegen, sendet sie aber. Nicht-control sendet keine Befehle an openHAB, nimmt sie aber entgegen. Ein Channel der Form

Type switch : ch1 "Name" [ga="1/1/1 + <1/1/2"]

steht für einen Aktor, der seine Befehle über GA 1/1/1 entgegen nimmt und seinen Status über GA 1/1/2 mitteilt.

[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.

[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]

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]

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]

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]

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.

[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

[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

[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.

[udo1toni]

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

[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]

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