von OpenHAB 1.8 auf OpenHAB 2.3 ... keine Rollershutter und keine Thermofühlerdaten

[PSch]

Moin zusammen,

nach 1,5 Jahren Abstinenz wegen akutem Zeitmangel will ich mich jetzt mal langsam an den Upgrade von Openhab 1.8 auf die aktuelle 2.x Version wagen. Hauptthemen (und Bindings) sind derzeit das KNX und Homematic Binding. Die Probleme gibts bei KNX. Installiert ist derzeit:

1. Busch Jäger 6186/32 IP Gateway (für mein Verständnis ist der "nur" zu einer Tunnelverbindung fähig. IP ist 192.168.102.138
2. ein Openhab 1.8 mit eibd. IP ist 192.168.102.160, Config eibd: EIBD_OPTS=ipt:192.168.102.138 -D -T -S -d -i
3. ein Openhab 2.3 mit knxd. IP ist 192.168.152.231, Config knxd: KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -u /tmp/eib -D -T -S -b ipt:192.168.102.160"
Für mein Verständnis ist somit OpenHAB 1.8 für den produktivbetrieb aktiv (zum Erhalt des WAF) und 2.3 hängt "hinter" 1.8

Soweit so gut. Nach dem üblichen rumüben mit neuer Software hat es dann geschlagene 4 Tage gedauert, bis es geklappt hat, die knx.things, knx.items und knx.sitemap so zu konfigurieren, dass ich einen der Aktoren schalten konnte. Ich bin recht guter Dinge, dass ich es hinbekomme, dass auch für die anderen Schaltaktoren konfiguriert zu bekommen. ABER....

Ich habe es weder geschaft, die Thermosensoren aus den Schaltern auszulesen noch einen der RolloAktoren zu betätigen.

Bei den Thermosensoren vermute ich, dass die Kaskadierung der beiden Openhabs da das Problem sein könnte...das muß ich mal ausprobieren, aber die Rollos sollten für mein Empfinden nicht wirklich anders als ein Lichtschalter funktionieren.

Hier mein knx.things Ausschnitt:

Code: Alles auswählen

Bridge knx:ip:bridge [ 
    ipAddress="127.0.0.1", 
    portNumber=3671, 
    localIp="192.168.152.231", 
    type="TUNNEL", 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=1,
    localSourceAddr="0.0.0"
] {
    // wenn ich es richtig verstanden habe, ist der "Thing" Teil für KNX total egal?
    // und ich könnte alle switches und rollershutter unter ein und demselben Thing 
    // definieren, auch wenn sie da garnicht dazugehören?
    Thing device generic [
        address="1.1.6",
        fetch=false,
        pingInterval=300,
        readInterval=3600
    ] {

        Type switch        : 1G_KX_Buero_DL_sw   "Bürolampe" [ ga="0/0/7+<0/6/7"]   
        Type number        : 1G_KX_Buero_Th_se   "Temperatur" [ ga="0/5/2"]     
        Type rollershutter : 1G_KX_Buero_Ro_Ac   "Rollershut" [ upDown="0/2/6",stopMove="0/2/7"] 
        
        // die Version mit [ upDown="0/2/6+0/2/7"] hab ich auch probiert...geht aber auch nicht. 0/2/6 ist die "kurz drücken" Gruppe, 0/2/7 die 
        // "lange drücken" Version. Wie man sieht, keine KNX Motoren sondern nur Jalousie Aktoren mit Standard Rohrmotoren.
    }  

} 

Und die Items:

Code: Alles auswählen

Switch        1G_KX_Buero_DL_sw  "BÜrolicht"                                 { channel="knx:device:bridge:generic:1G_KX_Buero_DL_sw"}
Number        1G_KX_Buero_Th_se  "Temperatur"                                { channel="knx:device:bridge:generic:1G_KX_Buero_Th_se"}
Rollershutter 1G_KX_Buero_Ro_Ac  "Rollo"                                     { channel="knx:device:bridge:generic:1G_KX_Buero_Ro_Ac"}

Dazu hab ich mal versuchsweise ein HABPanel gebaut und der Switch funktioniert auch fein, Es gibt aber keine Thermosensor Ausgabe (auch keinen eintrag im Event Log) und der Rollershutter ignoriert das Drücken der Tasten vollständig...dafür gibt es aber Einträge im Event Log.

So z.B.:

Code: Alles auswählen

2018-10-04 22:46:38.131 [ome.event.ItemCommandEvent] - Item '1G_KX_Buero_Ro_Ac' received command UP
2018-10-04 22:46:38.133 [vent.ItemStateChangedEvent] - 1G_KX_Buero_Ro_Ac changed from 100 to 0
2018-10-04 22:46:44.508 [ome.event.ItemCommandEvent] - Item '1G_KX_Buero_Ro_Ac' received command UP

Ich vermute mal, dass ich da irgendwo ziemlich auf der Leitung stehe, aber vielleicht kann mich da mal jemand in die richtige Richtung schubsen.

Außerdem würde mich interessieren, was in der KNX Doku unter den "Default DPT" zu verstehen ist. Muß ich die benutzen? Wenn sie default sind, ja eher nicht, und wenn sie nicht default sind...wo bekomme ich die richtigen her? Und was verbirgt sich überhautp dahinter. Wie mappen die auf die KNX Adressen und Gruppen?

Gruß
Peter Schauder

[udo1toni]

Hallo und herzlich willkommen,

prima, dass Du schon ausführlich aufgeschrieben hast, wie Du alles konfiguriert hast.
Dein knx/IP Gateway ist ja schon ein wenig älter insofern denke ich, dass sie tatsächlich nur einen Tunnel bietet. Vermute ich richtig, dass Du eibd als Konzentrator nutzt, sprich, damit mehrere Instanzen gleichzeitig den Tunnel nutzen können? Vor dem Umstieg wären das dann openHAB1.8 und ETS?

Zum testen möchte ich empfehlen, knxd mal auszuklammern und openHAB2.3 direkt mit eibd zu koppeln, also im Thing

Code: Alles auswählen

ipAddress="192.168.102.160"

Wobei da gleich eine Frage auftaucht, nämlich, ob Du nur ein nicht den üblichen Netzklassen entsprechendes Netz hast, oder ob da ein Router beteiligt ist (192.168.102.x und 192.168.152.y sind üblicherweise zwei Klasse-C Netze)

Allerdings kann ich mir nicht vorstellen, dass die Kaskadierung ernsthaft Einfluss haben kann (in der beschriebenen Form, dass nur eine Teilmenge der Kommunikation fehlschlägt - knx ist da digital, entweder es geht, oder es geht nicht )

Bei knx2 gibt es zwei Möglichkeiten, Things zu betrachten:

1. knx als Ganzes ist ein Thing
   Das bedeutet, es gibt keine physikalische Adresse und damit auch keinen Parameter, der sinnvoll für dieses Thing zu setzen ist (abgesehen von readInterval, was aber vermieden werden sollte)
2. jedes knx Device ist ein Thing.
   Da jedes Device einzeln gelistet ist, kann man auch die physikalischen Adressen hinterlegen, man kann die Devices anpingen lassen (dann wird der Status des Device bei Timeout des Pings auf OFFLINE gesetzt - trotzdem werden die entsprechenden GA an den Bus gesendet, soll heißen, auch ein als OFFLINE angezeigtes Device kann trotzdem gegenüber openHAB agieren und reagieren.
3. Man könnte auch zu einer Mischform greifen, oder auch mehrere Things nach 1. definieren.
   Das hat den Vorteil, dass man spezielle GA in einem Thing zusammenfassen kann. Wenn man z.B. Sensoren hat, die zwar lesbar sind, aber von sich aus weder zyklisches Senden noch Senden bei Wertänderung unterstützen, kann man den Parameter readInterval nutzen, um diese GA zyklisch auszulesen. Dies ist auch der einzige Grund, diesen Parameter ungleich 0 zu setzen.

Das den default DPT betrifft, ist das einfach der DPT der normalerweise verwendet wird. Ein Number Item kann ein Integer wert sein, eine Prozentzahl oder auch ein Float Wert

[PSch]

Moin Udo1Toni,

prima, dass Du schon ausführlich aufgeschrieben hast, wie Du alles konfiguriert hast.

Ja, schon, aber nicht ausführlich genug, wie du gleich sehen wirst.

Wobei da gleich eine Frage auftaucht, nämlich, ob Du nur ein nicht den üblichen Netzklassen entsprechendes Netz hast, oder ob da ein Router beteiligt ist (192.168.102.x und 192.168.152.y sind üblicherweise zwei Klasse-C Netze)

Ja, zwei Sub-Netze. Firewall ist derzeit noch auf Durchzug. Siehst du, schon eine Information die fehlte:-)

Allerdings kann ich mir nicht vorstellen, dass die Kaskadierung ernsthaft Einfluss haben kann (in der beschriebenen Form, dass nur eine Teilmenge der Kommunikation fehlschlägt - knx ist da digital, entweder es geht, oder es geht nicht )

Bei knx2 gibt es zwei Möglichkeiten, Things zu betrachten: ...

Ja, das hatte ich nach viel lesen im WWW auch gefunden. Allerdings ist mir nicht klar, warum die Doku darauf nicht hinweist. Sie vermittelt eher den Eindruck, dass das alles definiert werden muß: Jede Hardwareadresse, jeder Parameter. Funktioniert hat es aber erst ohne ... Da sollte vielleicht noch ein Spruch in die Dokumentation eingefügt werden.

Das den default DPT betrifft, ist das einfach der DPT der normalerweise verwendet wird. Ein Number Item kann ein Integer wert sein, eine Prozentzahl oder auch ein Float Wert

Irgendwo hatte ich gefunden, dass ich (möglicherweise in einer älteren KNX-Binding-Version) bei mehr als einer Gruppenadresse im Befehl die weiteren Adresse mit dem DPT angegeben werden müßten...ist das noch notwendig? Und muß ich mir das wie einen Type-Cast vorstellen?

So, das eigentliche Problem ist aber durch die bisher in 1.8 verwendete 2-stufige Gruppenadresse. Für mich war eine Ergänzung durch eine führende Null naheliegend (spätere Umfragen in der Familien schlugen auch angehängte Nullen vor). Aber niemand ist darauf gekommen, dass die Null in die Mitte muß. Naja, ein Bustrace hat es dann gezeigt, wie KNX das gerne haben möchte.

Mein Vorschlag dazu wäre: ein Hinweiß, wie die Adressen umgesetzt werde, an prominenter Stellein der Doku könnte hier helfen. Wenn man weiß, wo das Problem liegt, sieht man zwar, dass in den Beispielen der mittlere Adressteil Null ist...aber das weiß man eben erst hinterher.

Somit ist mein Problem gelöst, viel neues Wissen erlangt, eine hilfreiche Antwort aus dem Forum erhalten; alles gut gelaufen:-)

Danke für deine Hilfe,
Peter

[udo1toni]

Die Gruppenaddressen sind in openHAB grundsätzlich 3-stufig anzugeben, mit der Ausnahme, dass Du, wenn Du die aktuelle Nightly Version installierst auch frei addressieren kannst.
Das Problem dabei ist, dass freie GA Schreibweise erst mit ETS5 Einzug hielt, zweistufige Schreibweise ist seit ETS4 möglich, und ehrlich gesagt finde ich das ziemlichen Mist, weil es einfach eine weitere Fehlerquelle ist. Die GA sind 16 Bit *), die sich bei dreistufig so aufteilen: 5/3/8 also 0-63/0-7/0-255 in dezimaler Schreibweise. Zweiteilige GA sind so aufgeteilt: 5/11 also 0-63/0-2047. Wenn Du eine zweiteilige GA mit dem zweiten Teil > 255 hast, steht bei der dreiteiligen GA in der Mitte keine 0 mehr.

Wie gesagt, mit der Nightly sollte sowohl 5/3/8 als auch 5/11 als auch 16 als Adressschreibweise möglich sein, aber es ist nur eine weitere Fehlerquelle.

Mit der stable version bin ich mir nicht 100% sicher, wie sich knx2 verhält, da ich eine Nightly Version verwende. es war eine Zeit lang notwendig, den DPT mit anzugeben, wenn man mehrere GA auf einem Parameter konfigurieren wollte, also z.B.

Code: Alles auswählen

Type switch : meinSwitch "Switch" [ga="1.001:1/1/1+<1/1/2"]

statt

Code: Alles auswählen

Type switch : meinSwitch "Switch" [ga="1/1/1+<1/1/2"]

*) Anfangs waren nur 15 Bit nutzbar, GA mit gesetztem MSB hatten eine Sonderfunktion, hat mit dem Routing zu tun... ich erinnere mich nicht mehr so genau... Es gibt alte Devices, die nur 15 Bit als GA unterstützen.