Ankündigung

**udo1toni** · 22.03.2019, 10:29

Ich habe meine knx Installation auf Things-Seite nach Devices getrennt definiert.
Das entspricht weitgehend der Doku. Da ich meine GA auch mit System aufgebaut habe, konnte ich beim Anlegen große Teile durch Copy&Paste und anschließenden minimalen Änderungen erreichen. Beispiel:

Code:

 Thing device hagerDim1_1_6 "DimmerBlock 2" @ "KNX" [
      address="1.1.6",
      fetch=false,
      pingInterval=600,
      readInterval=0
    ] {
          Type dimmer : ch1 "Eltern Sterne" [ switch="8/5/10",position="5.001:8/5/12+<8/5/17" ]
          Type dimmer : ch2 "Küche Decke" [ switch="4/5/0" ,position="5.001:4/5/2+<4/5/7" ]
        //Type dimmer : ch3 "Dimmer 3" [ switch="3/5/10",position="3/5/12+<3/5/17" ]
  }

Es handelt sich um einen Hager Dimmaktor mit 3 Kanälen.

Meine GA sind nach folgendem Schema angelegt: <Raum>/Funktion/Nummer(von KO abgeleitet)
Die Küche hat beispielsweise die 4, Dimmer sind als Funktion 5 angelegt und ich habe in der Küche nur einen Dimmer. Damit hat der Dimmer die GA 4/5/0 für Ein/Aus, 4/5/2 für Absolutwert setzen und 4/5/7 für Absolutwert Status. Im Thing steht also

Damit ergibt sich als Item:

Code:

 Dimmer KuecheDecke "Küche Decke" (GLights,GDimmer) {channel="knx:device:bridge:hagerDim1_1_6:ch2",autoupdate="false"}

Das habe ich so komplett durchgezogen. Things bilden die Hardware nach, Items abstrahieren sie.

**thoern** · 26.03.2019, 17:32

Vielen Dank für dein Beispiel. Baue meine Konfig gerade auf und mache das nahezu genauso wie du. Eine Sisyphus-Arbeit ist das mit den ganzen Things und Channels.

**crazyfx** · 26.03.2019, 21:38

Ich habe nur 1 Thing, im dem alle Channels drin sind. Es gibt keinen Mehrwert, wenn man alle Geräte als Things anlegt.

**udo1toni** · 26.03.2019, 23:05

Zitat von crazyfx Beitrag anzeigen

Es gibt keinen Mehrwert, wenn man alle Geräte als Things anlegt.

Das ist aber schon Ansichtssache. Ich sehe bei mir den online Status jedes Devices. Die Channel sind hierarchisch geordnet, abgestuft nach Systemen, Bussen, Devices und deren Channel, das ist mir das bisschen Mehrarbeit wert.

Obwohl ich das schon an anderer Stelle erwähnt habe: Mit VSCode und dem Plugin für openHAB, ist es wirklich angenehm, die Konfiguration über Textdateien zu erstellen. gleichartige Sequenzen der Konfiguration lassen sich bequem kopieren, gezieltes mehrzeiliges Bearbeiten der Einträge, aber vor allem das automatisierte massenhafte Anlegen zugehöriger Items und Einträge in der Sitemap oder auch die Codesnippets in den Rules machen die Arbeit wirklich einfacher.

Die Konfiguration ist durch die Things umfangreicher geworden, aber dadurch ist die Trennung zwischen Hardware und Software auch klarer.

**azzkikrboy** · 06.04.2019, 18:57

Hallo zusammen,

ich habe meine Things pro Raum aufgebaut. Das sieht dann z.B. so aus:

Code:

[SIZE=12px]Thing device EG_Kueche [
fetch=true,
pingInterval=300,
readInterval=3600
] {
Type switch : EG_Kueche_Schrank "Light" [ ga="1/1/3+<1/4/3" ]
Type switch : EG_Kueche_Band "Light" [ ga="1/1/1+<1/4/1" ]
Type dimmer : EG_Kueche_Insel "Dimmer" [ switch="1/1/0+<1/4/0", position="1/3/0", increaseDecrease="1/2/0" ]
Type rollershutter : EG_Kueche_RL1 "Shade" [ upDown="2/2/1", stopMove="2/1/1", position="2/4/1+<2/5/1" ]
Type rollershutter : EG_Kueche_RL2 "Shade" [ upDown="2/2/2", stopMove="2/1/2", position="2/4/2+<2/5/2" ]
}
Thing device EG_EZ [
fetch=true,
pingInterval=300,
readInterval=3600
] {
Type dimmer : EG_EZ_Lampe "Light" [ switch="1/1/4+<1/4/4", position="1/3/4+<1/5/4", increaseDecrease="1/2/4" ]
Type rollershutter : EG_EZ_Rollo "Shade" [ upDown="2/2/3", stopMove="2/1/3", position="2/4/3+<2/5/3" ][/SIZE]
}

Die passenden Items sehen dann so aus:

Code:

[SIZE=12px]// Küche
Switch EG_Kueche_Schrank "Küchenschrank" (gKueche) ["Lighting"] { channel="knx:device:bridge:EG_Kueche:EG_Kueche_Schrank" }
Switch EG_Kueche_Band "Küchenband" (gKueche) ["Lighting"] { channel="knx:device:bridge:EG_Kueche:EG_Kueche_Band" }
Dimmer EG_Kueche_Insel "Küche [%d %%]" (gKueche) ["Lighting"] { channel="knx:device:bridge:EG_Kueche:EG_Kueche_Insel" }
Rollershutter EG_Kueche_RL1 "Küche Rollladen [%d %%]" ["Lighting"] { channel="knx:device:bridge:EG_Kueche:EG_Kueche_RL1" }
Rollershutter EG_Kueche_RL2 "Küchentür Rollladen [%d %%]" ["Lighting"] { channel="knx:device:bridge:EG_Kueche:EG_Kueche_RL2" }
// Esszimmer
Dimmer EG_EZ_Lampe "Esszimmer [%d %%]" (gEZ) ["Lighting"] { channel="knx:device:bridge:EG_EZ:EG_EZ_Lampe" }
Rollershutter EG_EZ_Rollo "Esszimmer Rollladen [%d %%]" ["Lighting"] { channel="knx:device:bridge:EG_EZ:EG_EZ_Rollo" }[/SIZE]

**udo1toni** · 06.04.2019, 22:00

Allerdings kannst und solltest Du die Parameter fetch und pingInterval weg lassen, da sie ohnehin ignoriert werden (address nicht gesetzt)

**Christian2409** · 09.06.2019, 16:03

Hallo zusammen,
Ich glaube ich stehe auf dem Schlauch oder habe noch ein grundsätzliches Vertständnisproblem.

Meine things Datei sieht so aus:
Bridge knx:ip:bridge [
ipAddress="192.168.178.99",
portNumber=3671,
localIp="192.168.178.21",
type="TUNNEL",
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=1,
localSourceAddr="0.0.0"
]
{
Thing device generic [
address="0.0.0",
fetch=false,
pingInterval=300,
readInterval=3600
] {
Typeswitch: light_buero "light_buero" [ ga="3/1/0" ]
Typeswitch: light_esszimmer "light_esszimmer" [ ga="2/1/1" ]
}
}

Und meine items so:
Switch light_buero "Büro"<light> { channel="knx:device:bridge:generic:light_buero" }
Switch light_esszimmer "Esszimmer"<light> { channel="knx:device:bridge:generic:light_esszimmer" }

Jetzt hab ich leider das folgende Problem:
Wenn ich das Esszimmer Licht über die Openhab App einschalte, dann geht das Esszimmer Licht und auch das Büro Licht an.
Wenn ich das Büro Licht einschalte dann geht nur das Büro Licht an und das ist auch gut so.

Warum gehen in meinem Fall das Esszimmer und das Büro Licht gleichzeitig an?

Danke schon mal für einen Hinweis.

**Christian2409** · 10.06.2019, 12:46

Sorry für die Verwirrung.... mein Problem was nach einem Neustart plötzlich verschwunden.
Funktioniert alles ohne Probleme.

**JoergA** · 10.06.2019, 22:54

Hallo zusammen,

bitte noch einmal für Dummies wie mich.

welche Vorteile habe ich, wenn ich die Things alle manuell anlege und dann trotzdem noch items benötige? Das ist doch dann doppelt??
OK, ich habe auch einige Things (z.B. Gardena Binding) die aber von den Bindings auch gefunden wurden und ich diese halt manuell angelegt habe um einen besseren Überblick zu behalten.

aber warum Things und Items??

viele Grüße,
Jörg

**udo1toni** · 11.06.2019, 09:01

Die Things sind eine Abstraktionsschicht innerhalb openHAB.

Früher musstest Du Hardware über die openhab.cfg definieren, oft gab es keine Möglichkeit, ein Binding mehrfach zu verwenden, da dies explizit vorgesehen sein musste.
Anschließend musstest Du Hardwareinformationen in die Items konfigurieren.

Jetzt wird die Hardware im Thing definiert (eine Bridge ist auch nur ein Thing), jedes Binding kann beliebig oft verwendet werden, die Abstraktion geschieht im Thing. Es bleiben also nur noch Channel, die auf die Items abgebildet werden müssen.

Das mag für den Anwender erst mal wie unnötige Zusatzarbeit aussehen, aus Programmierersicht wird damit aber vieles leichter, und an einigen Stellen werden Dinge erst möglich, z.B. Autokonfiguration und Autodiscovery wären ohne Things gar nicht möglich.

Verwende zum bearbeiten der Textdateien VSCode, der nimmt Dir 90% der Arbeit ab (z.B. kann man mit 3 Klicks für alle Channel eines Things auf einen Schlag Items erzeugen - und das Ergebnis ist besser als man es sich erhoffen würde).

**Juergen151** · 10.09.2019, 22:28

Hallo Zusammen,

bin gerade an der Umstellung auf openhab 2.4 auf raspberry pi 3b, hmm ich habe meine Things so angelegt wie azzkikrboy, was mich etwas stört man muss nun wirklich alle KNX-Devices manuell eingeben und mit der Things verknüpfen ?

Ich habe zum testen zwei Schalter angelegt, funktioniert beim einschalten, jedoch gibt es beim ausschalten eine deutliche Verzögerung von 5 Sekunden bist die Leuchte aus geht, hab ich da was übersehen woher kommt das ? Ein merkwürdiger Fehler.

Interessanterweise funktionieren unter der Basic UI nun die beiden Schalter meiner bisherigen Sitemap-Datei openhab 1.7 die dort komplett dargestellt ist, bzw. ebenfalls mit der Verzögerung beim ausschalten.

Mfg Jürgen

**udo1toni** · 11.09.2019, 10:30

Du kannst den knx Bus als ein Thing betrachten, oder als mehrere Things, das bleibt Dir überlassen. Wenn Du den Bus als ein Thing betrachtest, darfst Du natürlich keine Konfiguration für das Device angeben. (address, fetch, pingInterval und readInterval).

Falls Du einzelne GA trotzdem pollen möchtest (readIinterval!=0), musst Du all die Channel, die das betrifft, möglichst in einem Thing bündeln, denn der Parameter readInterval wird nun mal per Thing gesetzt (Hintergrund hierzu: Pollen ist bei knx normalerweise nicht notwendig, es gibt aber Devices, die weder bei Werteänderung noch zyklisch senden können. Diese müssen dann gepollt werden, aber das betrifft dann auch alle GA dieses Devices.)

Die Organisation als einzelne Devices bedeutet, dass Du an dieser Stelle innerhalb openHAB eine Abbildung Deines knx Busses vor Augen hast. Letztlich ist die Frage, ob Du darin für Dich einen Vorteil siehst, oder nicht. Ich habe etliche identische Devices, und ich habe meinen knx Bus irgendwann mal "generalüberholt", dabei habe ich ein System für alle Adressen angewendet, so dass ich nun tatsächlich einen großen Nutzen aus der Device-Organisation ziehe, indem ich ein Device anlege, es kopiere und anschließend nur Teile der GA anpassen muss, plus Label - die Channel sind als Channel beschriftet, nicht in ihrer konkreten Funktion, so dass ich hier nichts anfassen muss.

Eine merkliche Zeitverzögerung darf nicht auftreten, das spricht für einen Konfigurationsfehler.
Verstehe ich Dich richtig, dass Du zur Zeit mehrere openHAB Instanzen parallel laufen hast? Das war bei mir bis Anfang der Woche auch der Fall (und zwar seit OH2.0, also mindestens 3 Jahre!!!), ich hatte aber nie die von Dir beschriebenen Probleme.

Es kann schnell passieren, dass der knx Bus durch unglückliche Konfiguration geflutet wird, dann kann selbst das Schalten am Lichtschalter stark verzögert sein. Leider kann man nicht pauschal sagen, woran es nun konkret liegt, ohne die Anlage im Detail zu kennen, geht da nichts.
Ich hatte anfangs bei mir auch auf knx-Seite Fehler in der Konfiguration, die sich aber erst bemerkbar machten, als ich die ersten Schritte Richtung SmartHome ging, damals noch mit LeibNIX, später mit einem HS-Klon in einer VM)

**Juergen151** · 11.09.2019, 12:23

Hallo Toni,

Danke für die ausführliche Antwort, bei mir läuft seit 6 Jahren openhab 1.7 auf Raspberry 1b völlig problemlos ca 32 Teilnehmer auf dem Bus, parallel Openhab 2.4 auf Raspi 3b seit 3 Tagen.

Der Raspi 1b läuft verzögerungsfrei keine Probleme auf dem Bus, nur die 2.4er hat das Problem mit der Verzögerung, evt. war ich auch etwas zu schnell ich habe vom 1.7er alle Rules, items, sitmaps, peristance auf den neuen rüber kopiert, wahrscheinlich liegts daran, ich werde heute Abend erst mal alles löschen was nicht diese beiden neu angelegten Schaltfunktionen betrifft.

Das mit dem kopieren der Devices ist eine gute Idee, ich berichte dann noch mal !

Mfg Jürgen

**Juergen151** · 11.09.2019, 23:14

Hallo Toni,

zur Verzögerung gibt es eine Fehlermeldung im openhab.log, verstehe aber nicht wo der Fehler liegt :

2019-09-12 00:09:31.698 [WARN ] [net/IP Tunneling 192.168.178.35:3671] - response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 1.0.16->0/0/11 L_Data.req, low priority hop count 6 repeat, tpdu 00 80
at tuwien.auto.calimero.knxnetip.ClientConnection.doE xtraBlockingModes(ClientConnection.java:244) ~[255

rg.openhab.binding.knx:2.4.0]
at tuwien.auto.calimero.knxnetip.ConnectionBase.send( ConnectionBase.java:258) ~[255

rg.openhab.binding.knx:2.4.0]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send( KNXnetIPTunnel.java:178) ~[255

rg.openhab.binding.knx:2.4.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend( KNXNetworkLinkIP.java:243) ~[255

rg.openhab.binding.knx:2.4.0]
at tuwien.auto.calimero.link.AbstractLink.send(Abstra ctLink.java:351) ~[255

rg.openhab.binding.knx:2.4.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendReq uestWait(KNXNetworkLinkIP.java:222) ~[255

rg.openhab.binding.knx:2.4.0]
at tuwien.auto.calimero.process.ProcessCommunicatorIm pl.write(ProcessCommunicatorImpl.java:401) ~[255

rg.openhab.binding.knx:2.4.0]
at tuwien.auto.calimero.process.ProcessCommunicatorIm pl.write(ProcessCommunicatorImpl.java:359) ~[255

rg.openhab.binding.knx:2.4.0]
at org.openhab.binding.knx.internal.client.AbstractKN XClient.sendToKNX(AbstractKNXClient.java:453) ~[255

rg.openhab.binding.knx:2.4.0]
at org.openhab.binding.knx.internal.client.AbstractKN XClient.writeToKNX(AbstractKNXClient.java:413) ~[255

rg.openhab.binding.knx:2.4.0]
at org.openhab.binding.knx.internal.handler.DeviceThi ngHandler.lambda$7(DeviceThingHandler.java:229) ~[255

rg.openhab.binding.knx:2.4.0]
at org.openhab.binding.knx.internal.handler.DeviceThi ngHandler.withKNXType(DeviceThingHandler.java:124) [255

rg.openhab.binding.knx:2.4.0]
at org.openhab.binding.knx.internal.handler.DeviceThi ngHandler.withKNXType(DeviceThingHandler.java:118) [255

rg.openhab.binding.knx:2.4.0]
at org.openhab.binding.knx.internal.handler.DeviceThi ngHandler.handleCommand(DeviceThingHandler.java:22 4) [255

rg.openhab.binding.knx:2.4.0]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.Abstrac tInvocationHandler.invokeDirect(AbstractInvocation Handler.java:153) [102

rg.eclipse.smarthome.core:0.10.0.oh240]
at org.eclipse.smarthome.core.internal.common.Invocat ionHandlerSync.invoke(InvocationHandlerSync.java:5 9) [102

rg.eclipse.smarthome.core:0.10.0.oh240]
at com.sun.proxy.$Proxy130.handleCommand(Unknown Source) [255

rg.openhab.binding.knx:2.4.0]
at org.eclipse.smarthome.core.thing.internal.profiles .ProfileCallbackImpl.handleCommand(ProfileCallback Impl.java:75) [109

rg.eclipse.smarthome.core.thing:0.10.0.oh240]
at org.eclipse.smarthome.core.thing.internal.profiles .SystemDefaultProfile.onCommandFromItem(SystemDefa ultProfile.java:49) [109

rg.eclipse.smarthome.core.thing:0.10.0.oh240]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.Abstrac tInvocationHandler.invokeDirect(AbstractInvocation Handler.java:153) [102

rg.eclipse.smarthome.core:0.10.0.oh240]
at org.eclipse.smarthome.core.internal.common.Invocat ion.call(Invocation.java:53) [102

rg.eclipse.smarthome.core:0.10.0.oh240]
at java.util.concurrent.FutureTask.run(FutureTask.jav a:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker( ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2019-09-12 00:09:34.715 [WARN ] [net/IP Tunneling 192.168.178.35:3671] - response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 1.0.16->0/0/11 L_Data.req, low priority hop count 6 repeat, tpdu 00 80
at tuwien.auto.calimero.knxnetip.ClientConnection.doE xtraBlockingModes(ClientConnection.java:244) ~[255