Docker Image OpenHab 3 - KNX

[piggituX]

Hallo,

ich habe lange OH2 benutzt als Installation auf einem cubietruck, nach einem Crash bin ich dann umgestiegen auf eine Intel NUC J3455 und steuere über knxd via Crontab meine Busfähigen Geräte (Jalousien und Lampen) . Meine Frau wünscht sich nun wieder mehr Komfort via Smartphone. Da auf der NUC einige Docker Container laufen dachte ich mir, lege ich das OH3 auch dazu.

grundlegend funktioniert das über OH3 und dem KNX Binding. Ich habe zwar auch das Problem das mir das Thing KNX/IP Gateway als "Online", Thing Device als "Offline" angezeigt werden, aber die Channel kann ich ganz normal nutzen, bis auf eine kleine / grosse Verzögerung.

Wenn ich über OH3 einen Switch schalte an und danach wieder aus hab ich ca. 2 sec Verzögerung bis der Aktor reagiert, Lasse ich eine Jalousie fahren ist es ganz schlimm. Das führte bei meinem nächtlichen Testlauf, nachdem ich ca 20 mal geklickt hatte weil nichts passierte, das meine Jalousien eine AmokFahrt hinlegten, und ich in den Keller rennen musste, um das IP Gateway aus dem Netz zu nehmen.

hab ich irgendwo eine Konfig Issue oder ist die Intel NUC mit dem Docker Container OB3 überfordert ?

Betreibt noch wer eine Docker Variante in ähnlicher Konstellation.

cYa thom

[zeebee]

Wird ein Config-Problem sein. Auf meinem Raspi 4 habe ich openHab 3.0.1 auch als Container laufen, gibt keine Probleme. Ich würde mal schauen was der Gruppenadressenmonitor in ETS sagt. Ansonsten poste doch mal Screenshots von deiner Config in openhab. Ich habe bei mir z.B. nur die Gruppenadressen eingetragen, keine physikalischen Adressen der Aktoren.

[piggituX]

Hi,

danke für die Info, ok hab die HW Addresse rausgelassen und siehe da es ist Online

UID: knx:device:0e4a92065e
label: TastSensor3 Kitchen
thingTypeUID: knx:device
configuration:
pingInterval: 600
readInterval: 0
fetch: false
bridgeUID: knx:ip:e65f3111
location: Kitchen
channels:
- id: WallLight_Kitchen
channelTypeUID: knx:switch
label: WallLight Kitchen
description: ""
configuration:
ga: 1/1/36
- id: TableLight_Kitchen
channelTypeUID: knx:switch
label: TableLight Kitchen
description: ""
configuration:
ga: 1/1/35
- id: RollerShutter1_Kitchen
channelTypeUID: knx:rollershutter
label: Jalousie 1 Kitchen
description: ""
configuration:
upDown: 2/1/0
stopMove: 2/2/0
- id: RollerShutter3_Kitchen
channelTypeUID: knx:rollershutter
label: Jalousie 3 Kitchen
description: ""
configuration:
upDown: 2/1/7
stopMove: 2/2/7
- id: RollerShutter2_Kitchen
channelTypeUID: knx:rollershutter
label: Jalousie 2 Kitchen
description: ""
configuration:
upDown: 2/1/1
stopMove: 2/2/1

Mich wundert, wieso die Quell Addresse 15.15.255 ist, da ich doch im Binding eine freie BusAddresse der Line getragen habe, sieht wie nen Broadcast aus ?

und noch das Video, sieht wie ein Prellen aus, beim 3. Klick reagiert dann der Bus, mache ich das via CLI über den KNXD mittels groupswrite reagiert der Aktor direkt auf "on" oder "off"

https://piggitux.ignorelist.com:8085/Switch_Click.mp4

busmonitor.png

[zeebee]

Klar, wenn keine physikalische Adresse eingegeben ist, ist das Ding immer online . Das Video geht bei mir übrigens nicht, keine Verbindung zum Server.

Code sieht bei mir nicht viel anders aus:

UID: knx:device:d3ad671196:7bf476fb4d
label: KNX_Rolladen
thingTypeUID: knx:device
configuration:
pingInterval: 600
readInterval: 0
fetch: false
bridgeUID: knx:ip:d3ad671196
channels:
- id: Rolladen_OG_Buero
channelTypeUID: knx:rollershutter
label: Büro
description: ""
configuration:
upDown: 3/3/60
stopMove: 3/3/61
position: 3/3/63
- id: Rolladen_OG_Kinderzimmer_Ost
channelTypeUID: knx:rollershutter
label: Kinderzimmer Ost
description: ""
configuration:
upDown: 3/3/40
stopMove: 3/3/41
position: 3/3/43

Verbindest du openHab über knxd? Vielleicht liegt es daran...? Ich nutze einen meiner vier Tunnel dafür:

UID: knx:ip:d3ad671196
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
useNAT: false
readRetriesLimit: 3
ipAddress: 192.168.xxx.xxx
localIp: 192.168.xxx.xxx
autoReconnectPeriod: 60
type: TUNNEL
localSourceAddr: 0.0.0
readingPause: 50
portNumber: 3671
responseTimeout: 10

Hast du auch andere Software die per IP zugreift? Evtl. alle Tunnel belegt? Kannst du nachschauen wie es da bei dir auf der KNX-Seite aussieht? Ich rate ehrlich gesagt gerade ein bissle ins blaue. Evtl. kannst du auch mal Node-Red testen, ob da das gleiche Fehlerbild auftritt.

[piggituX]

Hi,

nein habe ich nicht , mein knxd läuft über USB, darüber programmiere ich auch die Aktoren, das IP Gateway ist ausschliesslich für die Automation

UID: knx:ip:e65f3111
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
useNAT: false
readRetriesLimit: 3
ipAddress: 192.168.xxx.xxx
localIp: 192.168.xxx.xxx
autoReconnectPeriod: 60
type: TUNNEL
localSourceAddr: 1.0.162
readingPause: 50
portNumber: 3671
responseTimeout: 10

Nachtrag: lasse ich die "localSourceAddr" leer dann gehts ohne Verzögerung.... mmh nun würde ich gern mal wissen, wieso das so ist.


cYa

[zeebee]

War die 1.0.162 wirklich ein freier Tunnel?

[piggituX]

ja hatte die 1.0.162 nur in der ETS als Dummy Adresse eingetragen, aber das hat ja nix mit dem Bus zu tun. 1.0.161 ist das KNX IP Device über die es programmiert wird (IP Addresse), und die KNXD hat die 1.0.170.

nun schickt OH3 über die 1.0.174 laut BusMonitor. "strange"

[zeebee]

Bei meinem MDT IP Interface kann ich per Webinterface schauen, welche Tunnel-Adressen wirklich da/frei sind. Kannst du das auch?
Bildschirmfoto 2021-02-06 um 13.39.27.png