KNX-Monitoring in ETS mit openHAB server

[bigblue1735]

Hi, leider ist für mich der openHAB server noch ein Rätsel. Ich habe es jetzt hinbekommen, dass der Server eine Verbindung zu oneWire und KNX aufbaut. Es werden auch die Werte in einer selbst erstellen GUI angezeigt, soweit alles gut.

Ich möchte jedoch, dass der openHAB - Server die 1Wire Werte an den KNX-Bus sendet. Laut Anleitung soll dies mit dem Mapping der Items ans KNX und oneWire automatisch geschehen. Allerdings sehe ich in der ETS weder um Bus noch im Gruppenmonitor eine Nachricht.

Wenn ich dann im Gruppenmonitor ein Lese auf die Temeraturadresse ausführe, bekomme ich keine Werte angezeigt. Wenn ich jedoch in das LOG den openHab schaue sieht es eigentlich gut aus.

Wie kann ich am einfachsten erkennen dass alles so klappt wie es soll?

2015-12-14 21:18:01.728 [INFO ] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] link 127.0.0.1:3671: send message to 0/2/0, wait for confirmation
2015-12-14 21:18:01.729 [DEBUG] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] link 127.0.0.1:3671: cEMI L-Data.req from 0.0.0 to 0/2/0, low priority hop count 6 repeat tpdu 00 80 0c 20
2015-12-14 21:18:01.729 [DEBUG] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] KNXnet/IP Tunneling 127.0.0.1:3671: sending cEMI frame, wait for cEMI.con, attempt 1
2015-12-14 21:18:01.729 [INFO ] [runtime.busevents             ] - Temperature_1 state updated to 21.125
2015-12-14 21:18:01.729 [INFO ] [tuwien.auto.calimero          ] - [KNXnet/IP receiver] link 127.0.0.1:3671: confirmation of 0/2/0
2015-12-14 21:18:01.729 [DEBUG] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] link 127.0.0.1:3671: send to 0/2/0 succeeded
2015-12-14 21:18:01.730 [DEBUG] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] process link 127.0.0.1:3671: group write to 0/2/0 succeeded
2015-12-14 21:18:02.891 [INFO ] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] link 127.0.0.1:3671: send message to 0/2/1, wait for confirmation
2015-12-14 21:18:02.892 [DEBUG] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] link 127.0.0.1:3671: cEMI L-Data.req from 0.0.0 to 0/2/1, low priority hop count 6 repeat tpdu 00 80 0c 20
2015-12-14 21:18:02.892 [DEBUG] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] KNXnet/IP Tunneling 127.0.0.1:3671: sending cEMI frame, wait for cEMI.con, attempt 1
2015-12-14 21:18:02.892 [INFO ] [tuwien.auto.calimero          ] - [KNXnet/IP receiver] link 127.0.0.1:3671: confirmation of 0/2/1
2015-12-14 21:18:02.892 [INFO ] [runtime.busevents             ] - Temperature_2 state updated to 21.125
2015-12-14 21:18:02.892 [DEBUG] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] link 127.0.0.1:3671: send to 0/2/1 succeeded
2015-12-14 21:18:02.892 [DEBUG] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] process link 127.0.0.1:3671: group write to 0/2/1 succeeded
2015-12-14 21:18:04.055 [INFO ] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] link 127.0.0.1:3671: send message to 0/2/2, wait for confirmation
2015-12-14 21:18:04.056 [DEBUG] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] link 127.0.0.1:3671: cEMI L-Data.req from 0.0.0 to 0/2/2, low priority hop count 6 repeat tpdu 00 80 0c 33
2015-12-14 21:18:04.056 [DEBUG] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] KNXnet/IP Tunneling 127.0.0.1:3671: sending cEMI frame, wait for cEMI.con, attempt 1
2015-12-14 21:18:04.056 [INFO ] [tuwien.auto.calimero          ] - [KNXnet/IP receiver] link 127.0.0.1:3671: confirmation of 0/2/2
2015-12-14 21:18:04.057 [DEBUG] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] link 127.0.0.1:3671: send to 0/2/2 succeeded
2015-12-14 21:18:04.057 [DEBUG] [tuwien.auto.calimero          ] - [EventAdmin Async Event Dispatcher Thread] process link 127.0.0.1:3671: group write to 0/2/2 succeeded
2015-12-14 21:18:04.057 [INFO ] [runtime.busevents             ] - Temperature_3 state updated to 21.5

[thoern]

Vielleicht solltest du mal deine Items-Konfiguration posten...

[bigblue1735]

Hier der wesentliche Teil der Config.

Number Temperature_1    "Temperature [%.1f °C]" <temperature>    (HW_Temp1)    { knx="0/2/0", onewire="deviceId=10.48DA82020800;propertyName=temperature" }
Number Temperature_2    "Temperature [%.1f °C]" <temperature>    (HW_Temp2)    { knx="0/2/1", onewire="deviceId=10.B33F82020800;propertyName=temperature" }
Number Temperature_3    "Temperature [%.1f °C]" <temperature>    (HW_Temp3)    { knx="0/2/2", onewire="deviceId=10.F3F382020800;propertyName=temperature" }
Number Temperature_4    "Temperature [%.1f °C]" <temperature>    (HW_Temp4)    { knx="0/2/3", onewire="deviceId=28.807AEE060000;propertyName=temperature" }

[thoern]

Hi,

für mich bedeutet diese Art von Konfiguration folgendes:

• das Item "Temperature_1" kann vom KNX über 0/2/0 gesetzt werden. Außerdem kann "Temperature_1" über das onewire-Device 0.48DA82.... gesetzt werden.
• setzt OpenHAB den Wert von "Temperature_1" wird dieser Wert an KNX 0/2/0 gesendet und ggf. and das onewire-device 0.48DA82.... (falls das Onewire-Binding überhaupt das Senden von Werten an einen Temp-Sensor unterstützt - was ich nicht glaube)

Du gehst aber davon aus, dass ein empfangener Wert vom OneWire-Device 0.48DA82.... direkt auf KNX 0/2/0 gesendent wird. Da wäre ich mir nicht so sicher, dass das so direkt und ohne Umwege geht. Cool wäre es natürlich!

Ich möchte jedoch, dass der openHAB - Server die 1Wire Werte an den KNX-Bus sendet. Laut Anleitung soll dies mit dem Mapping der Items ans KNX und oneWire automatisch geschehen.

Wo genau steht das denn in welcher Anleitung?

Gruß,
thoern

[udo1toni]

Das weiterleiten in beide Richtungen sollte definitiv funktionieren. Beispiel:

DateTime Date "Zeit [%1$td. %1$tB %1$tY %1$tT]" <calendar> { ntp="Europe/Berlin:de_DE", knx="10.001:15/7/10" }

sendet bei jedem Refresh (eingestellt in der openhab.cfg, default 15 min) ein Zeittelegramm auf den knx-Bus. Funktioniert bei mir zuverlässig seit Jahren.
Spaßeshalber könntest Du mal das knx-Binding hinter das onewire-Binding schreiben, aber eigentlich sollte die Reihenfolge keine Rolle spielen.

[thoern]

Jetzt wo ich das mit dem ntp-Binding sehe fällt es mir auch wieder ein

@bigblue: welche KNX-Geräte verstecken sich denn hinter deinen Gruppenadressen? Flags richtig gesetzt?

Gruß

[bigblue1735]

Hinter den Gruppenadressen sind keine Geräte. Ich habe bisher nur ein Testbrett und bin dabei mir diverse Server anzuschauen. Bisher habe ich smarthome.py genommen. Dort funktioniert es direkt ohne Probleme. 1Wire und KNX eingerichtet, die 1Wire Sensoren werden ausgelesen und die Werte werden auf den KNX - Bus gesendet. Ich kann in der ETS die Telegramme sehen und wenn ich die Gruppenadresse abfrage bekomme ich die Werte angezeigt, alles bestens.

Da ich selbst Java - Entwickler bin und ich zufällig hier im Forum auf openHAB aufmerksam gemacht wurde, habe ich mir dass dann auch mal angeschaut und stehe jetzt vor dem beschriebenen Problem. Aufgrund der guten Erfahrungen mit smarthome.py habe ich mich entschlossen 1Wire Temperatursensoren zu nutzen anstelle von KNX. Daher ist es unabdingbar, dass diese Sachen reibungslos funktionieren.

*Edit*
Vielleicht stimmt was mit der Zuordnung der Datentypen nicht. Ich werde heute Abend noch mal den Datentyp hinzufügen, mal sehen ob das was hilft.

[thoern]

Hinter den Gruppenadressen sind keine Geräte.

Ach so. Na dann geht das nicht. OpenHAB "hält" selbst keine Gruppenadressen. Es sendet nur an oder empfängt von entspr. KNX-Geräten. Die Geräte halten die GA, nicht openHAB.

Gruß,
thoern

[udo1toni]

OpenHAB "hält" selbst keine Gruppenadressen. Es sendet nur an oder empfängt von entspr. KNX-Geräten.

Allerdings sollte openHAB unabhängig vom Vorhandensein von Geräten die Daten an den knx-bus durchreichen - und damit sollten die Daten im Gruppenmonitor angezeigt werden.

Wie ist die ETS denn mit openHAB verbunden? Wie sieht das Testbrett aus?

Eventuell muss auch tatsächlich der DPT mit angegeben werden, weil openHAB sonst nicht weiß, wie es das Mapping ausführen soll.

[thoern]

Allerdings sollte openHAB unabhängig vom Vorhandensein von Geräten die Daten an den knx-bus durchreichen - und damit sollten die Daten im Gruppenmonitor angezeigt werden.

Ja, aber so macht der TO das ja nicht. Er sendet einen Lese-Request hin und dann anwortet natürlich keiner - was ja logisch ist. OpenHAB jedenfalls wird darauf nicht antworten - das wäre aber das, was der TO erwartet....

[bigblue1735]

Hi, die ETS ist auch per eibd angebunden. Ich nutze eine MDT USB-Schnittstelle. Mit dem eibd und der ETS gibt es auch keinerlei Probleme. Diese kombination habe ich auch für den smarthome.py Server genommen, bei dem die Weiterleitung der 1Wire - Werte nach KNX problemlos geklappt hat. Wobei der smarthome.py auf einen anderen Port zugegriffen hat als der openHAB server. Vielleicht liegt auch da einfach das Problem.

Aktuell besteht das Testbrett aus:
- MDT Spannungsversorgung,
- MDT USB-Interface
- MDT 12Fach Aktor mit Stromsensor
- MDT Tasterinterface 8-Fach mit LED

Nebenbei läuft der owfs Server für den 1Wire Bus, der ja ohne Probleme zu funktionieren scheint, da alle Systeme die Daten abfragen können.

Ich verstehe die Problematik leider noch nicht. Auch das Verhalten dass hinter jeder Adresse ein Gerät sein muss leuchtet mir nicht ein. Wenn ich also die Uhrzeit auf dem Bus für diverse logiken brauche, dann muss ich also ein Gerät haben das mir die Uhrzeit anzeigt?

Wie gesagt openHAB ist aktuell noch ein Buch mit 7 Siegeln für mich. Mit dem smarthome.py hatte ich das system in 1h am laufen alles ohne Probleme. Leider habe ich jetzt die Anleitung der KNX Einbindung schon 100x durchgelesen und kann den Fehler leider nicht sehen. Ich habe genau wie in der Anleitung den item File ausgebaut mit diesem Ergebniss. Wenn es irgendwo noch eine Doku gibt, dann lasst es mich bitte wissen.

Danke für die Hilfe.
Alex

[thoern]

Ich verstehe die Problematik leider noch nicht.

Ich glaube die Ursache ist ein grundsätzliches Missverständnis der KNX-Kommunikation.

Auch das Verhalten dass hinter jeder Adresse ein Gerät sein muss leuchtet mir nicht ein.

Naja, Daten auf den Bus zu senden, ohne dass sich irgendein Gerät dafür interessiert, macht nicht wirklich Sinn. Ist ungefähr so, wie die Telefonnummer eines nicht vorhandenen Anschlusses zu wählen.

Wenn ich also die Uhrzeit auf dem Bus für diverse logiken brauche, dann muss ich also ein Gerät haben das mir die Uhrzeit anzeigt?

Nein, das muss nicht zwingend ein Gerät sein das die Uhrzeit anzeigt, aber irgendein Gerät, das sich für die Uhrzeit interessiert, sollte am Bus sein - sonst sind wir wieder beim Wählen der Nummer des nicht vorhandenen Telefonanschlusses

Bei KNX ist das wie folgt:

Einer KNX-Gruppenadresse sind mindestens 1 oder mehrere Geräte zugeordnet. Schickst du an diese Gruppe einen Lese-Request wird nur das bzw. werden nur die Geräte antworten, die das Lese-Flag gesetzt haben.
Kein Gerät, keine Antwort auf Lese-Request.
Normalerweise setzt man in einer Gruppe nur bei einem Gerät das Lese-Flag - in der Regel bei einem Aktor.

Lässt du den Busmonitor dauerhaft mitlaufen, solltest du sehen, dass die Werte der OneWire-Sensoren auf dem KNX-Bus ausgegeben werden.
Auf explizite Lese-Anforderungen (Read-Requests) wirst du dennoch keine Antwort bekommen, da es keine Geräte gibt, die in der jeweiligen Gruppe Mitglied sind und das Lese-Flag für Leseanforderungen gesetzt haben.

Ich kenne smarthome.py nicht. Mich würde es aber sehr wundern, wenn es auf explizite Read-Requests antwortet. In diesem Falle würde sich die Kombination aus smarthome.py und eibd wie ein echtes KNX-Gerät verhalten.

Gruß,
thoern

[udo1toni]

Nein, grundsätzlich muss kein Gerät vorhanden sein, wenn allerdings GA gelesen werden sollen, muss es ein Gerät geben, das sich für die Antwort verantwortlich fühlt
openHAB antwortet nie auf Leseanforderungen, sondern sendet nur Updates und Commands auf den Bus, denn openHAB ist kein normaler Busteilnehmer.

Die ETS bietet einen Gruppenmonitor, der alle empfangenen GA anzeigt, der sollte von openHAB gesendete Telegramme anzeigen.
Zum Test könntest Du ein Switch-Item anlegen und den Switch über die UI umschalten, dann müsste entsprechend die GA im Gruppenmonitor auftauchen.
Falls das nicht funktioniert, liegt das vermutlich daran, dass sich ETS und openHAB beim Zugriff auf den eibd in die Quere kommen.
Ich hatte vor längerer Zeit auch eibd als Schnittstelle in Betrieb, da hatte ich mit dem Parallelzugriff mit der ETS Probleme, allerdings nur im Zusammenhang mit der Programmierung von Geräten. Ich musste zum Programmieren also immer openHAB beenden.
Da ich aber ohnehin eine IP-Schnittstelle auf dem Wunschzettel hatte...

Was die Uhrzeit auf dem Bus betrifft: Sofern die Logik im Bus verbaut ist, wird ja ohnehin ein Gerät vorhanden sein, welches die Uhrzeit verarbeitet. Wenn die Logik in openHAB steckt, gehen nur die Schaltsignale auf den Bus. Oder Du hast Zeitschaltuhren, z.B. im Heizungssteller, die benötigen dann natürlich die Zeitinformation über den Bus. Wenn Du einfach nur die Uhrzeit auf den Bus sendest, wirst Du sie im Gruppenmonitor der ETS sehen können. Abrufen der Zeit durch eine Leseanforderung wird aber nicht funktionieren.
Bezogen auf die Temperaturwerte: Solange Du kein Gerät am knx-Bus hast, welches die Temperaturwerte annimmt, eine Anzeige zum Beispiel, solange kannst Du nur mit dem Gruppenmonitor der ETS überprüfen, ob die Telegramme gesendet werden.

Mein Tipp für's Einsteigen in openHAB wäre, zunächst mit der Demo zu beginnen und erstmal nur ein oder zwei Items einzubauen, für die es auch Hardware gibt. Das sollte locker in 5 Minuten zu erledigen sein, vom Ende aller notwendigen Downloads bis zur laufenden UI. Ich gebe aber zu, dass es schon lange her ist, dass ich die entsprechenden Anleitungen gelesen habe. Wichtig ist eigentlich nur, in kleinen Schritten voranzugehen und z.B. mit nur einem oder zwei Bindings zu beginnen. Sobald die laufen, kann dann Schritt für Schritt alles weitere dazu kommen.
Was Anleitungen betrifft, da gibt es einige in englisch und ansonsten noch mindestens eine in deutsch, je aktueller die Bindings sind, desto wahrscheinlicher ist aber die einzige vernünftige Doku die im Git-Wiki (die Seite ist überhaupt eine der wichtigsten Anlaufstellen, wie ich finde) Daneben sind natürlich noch die openHAB Community und dieses Forum zu nennen.

EDIT: mal wieder zu langsam...

[udo1toni]

Ich kenne smarthome.py nicht. Mich würde es aber sehr wundern, wenn es auf explizite Read-Requests antwortet. In diesem Falle würde sich die Kombination aus smarthome.py und eibd wie ein echtes KNX-Gerät verhalten.

Naja, das kann schon sein, der HS von Gira antwortet auch auf Leserequests, wenn die Flags entsprechend gesetzt sind. Wenn man z.B. Logikfunktionen als Module einbaut, könnte man dieses Modul auch als virtuelles Gerät betrachten, da kann dieses Verhalten schon sinnvoll sein.

[bigblue1735]

Vielen Dank für die vielen Infos. Ich werde mir das am WE noch mal genauer anschauen (schaffe es diese Woche nicht mehr) und werde berichten.

Vielen Dank für die Hilfe.
Alex