OpenHAB 2.4.0, OneWire digitalio auf KNX bringen

[Pontius Pilatus]

Hallo zusammen,

ich versuche OneWire 2-fach digital I/O mit OpenHAB an meine KNX-Installation zu bekommen. Wenn ich sie als Output konfiguriere kann ich mit einem KNX Schreibtelegramm den Wert festlegen. Soweit ok.
Wenn ich allerdings die Eingänge als Inputs konfiguriere werden lediglich die Zustände im OpenHAB selbst aktualisiert. Er sendet einfach kein Telegramm auf den KNX-Bus. Außerdem reagiert er nicht sofort auf den Pegelwechsel am Eingang.
Meine Fragen dazu:

1. Wie müssen Thing und Item konfiguriert sein, damit er den geänderten Zustand auf den KNX bringt?
2. Wie klein kann man die Refresh - Zeit des OneWire-Things einstellen, ohne das System lahm zu legen?
3. Wie bekomme ich OpenHAB dazu, dass er auch auf KNX-Lesetelegramme seinen Item-Zustand mitteilt?

Vielen Dank für eure Hilfe...

Ciao, PP

[udo1toni]

Zu 3): openHAB2.4 bietet diese Option meines Wissens noch nicht. in openHAB2.5 (die unstable oder nightly Version) antwortet openHAB auf Read Requests seitens knx Bus, sofern es sich um einen *-control Channel handelt. Die Status-GA (auf der openHAB den Status sendet) muss die erste angegebene GA für den Parameter sein, also z.B.

type dimmer-control : myDimmer "Mein Dimmer" [ switch="1/1/2+1/1/4", position="1/1/12+1/1/14", increaseDecrease="1/1/22" ]

openHAB empfängt auf allen angegebenen GA Befehle, sendet aber nur auf 1/1/2 und 1/1/12, egal, über welche GA ein Read Request kommt (gleiches Verhalten wie bei knx Devices!)

zu 2) Dazu kann ich leider nichts beitragen, ich habe kein OneWire

zu 1) Allgemein sollte die Kopplung zweier Systeme funktionieren, indem die Channel mit dem selben Item gelinkt werden:

Dimmer myDimmer "Mein Dimmer" { channel="onewire:..", channel="knx:..." }

Allerdings klappt das eventuell nur, wenn die Reihenfolge der Links korrekt ist. in openHAB2.5 gibt es das Modell der Profile, mit dem man erzwingen kann, dass ein Item einem anderen Item folgt (innerhalb einer Item Definition auch auf Channel bezogen. Ich bin mit nicht zu 100% sicher, dass das schon mit 2.4 funktioniert.

Ich hab jetzt mehrfach auf OH2.5 hingewiesen, muss aber gleich wieder abbremsen, denn es hat gerade einen Merge gegeben, der noch zu einem Schluckauf führt, sprich, gerade jetzt ist es keine gute Idee, auf nightly zu wechseln... Ich gehe aber davon aus, dass die Probleme in ein bis zwei Wochen behoben sind, dann sollte die nightly Version wieder genauso zuverlässig funktionieren wie vor dem Merge...

[Pontius Pilatus]

Vielen Dank für den Hinweis mit dem Profile. Wenn ich den KNX-Channel auf "follow" stelle, antwortet er sogar auf Read-Telegramme. Allerdings knallt er im Sekundentakt den unveränderten Wert des Inputs auf den Bus, egal welchen Wert ich beim OneWire-Thing bei Refresh setze :-(
Ich bin seit letztem Sonntag auf "last stable".

Kann ich ihn Werte nur bei Änderung senden lassen?

[udo1toni]

Das sollte eigentlich so sein. Ich arbeite bisher noch nicht mit Profilen, kann also nur Theorie beisteuern...

[Pontius Pilatus]

Schade, es lässt sich nicht bremsen, sondern müllt mir jetzt den Bus zu. Ich habe mich entschieden, dass ich zwei Items für solche Kontakte erzeuge. Eine "Number" verbunden mit dem 1Wire Channel und einen "Switch", der mit einem "switch-control" verbunden ist. Außerdem erzeuge ich eine passende Rule, die bei Änderung am Eingang das KNX-Item entsprechend setzt. Das hat prototypisch gerade funktioniert und sendet auch brav auf den Bus.

Glücklicherweise generiere ich mir die Configs aus meiner ETS-Konfiguration, da muss ich das nicht händisch pflegen.
Hoffentlich werden dieser Ansatz nicht zu einem Performance-Problem....

Ciao, PP

[udo1toni]

Wenn Du es richtig machst, ist das kein Thema. Richtig heißt in diesem Zusammenhang, Du verwendest ein Namenssystem, eine oder zwei Gruppen und eine Rule. Damit werden alle Itempaare abgewickelt. Sieht so aus:
Items

Group:Contact oneWireContacts
Group:Contact knxContacts
Contact owContact_01 "1. OW Kontakt" (oneWireContacts) { ... }
Contact owContact_02 "2. OW Kontakt" (oneWireContacts) { ... }
Contact owContact_03 "3. OW Kontakt" (oneWireContacts) { ... }
Contact knxContact_01 "1. knx Kontakt" (knxContacts) { ... }
Contact knxContact_02 "2. knx Kontakt" (knxContacts) { ... }
Contact knxContact_03 "3. knx Kontakt" (knxContacts) { ... }

und dazu diese Rule:

rule "proxy from ow to knx"
when
    Member of oneWireContacts changed
then
    knxContacts.members.filter[ m|m.name.contains(triggeringItem.name.split("_").get(1)) ].head.sendCommand(triggeringItem.state)
end

Im Einzelnen:

• triggeringItem enthält das Item, welches die Rule getriggert hat. Dies ist ein Member der Gruppe oneWireContacts.
• triggeringItem.name ist enstprechend der Name des Items
• name.split("_") teilt den Namen an der angegebenen Zeichenkette (und lässt diese in den Teilstrings aus, sprich, der _ ist nicht mehr vorhanden)
• .get(1) ist der 2. Teilstring (der 1. Teilstring wäre .get(0))
• knxContacts.members ist eine Liste aller Member der Gruppe knxContacts
• .filter[ ] filtert diese Liste und gibt wieder eine Liste zurück
• m| bedeutet, die member der Liste werden nachfolgend einzeln als item m "untersucht"
• m.name.contains() bedeutet, der angegebene String muss im Namen des Items vorkommen
• .head gibt den ersten Eintrag der gefilterten Liste als Item zurück

[Pontius Pilatus]

Wow, wusste nicht, das die Rules so "mächtig" sind. Meine Items und so sind schon im existierenden Namensraum nach Gebäude/Geschoss/Raum/Funktion gefangen. Aber da ich wie gesagt die Config generiere, ist es kein Problem eigene Rules zu haben. Zumal von den 1W-IO Ports habe ich nur 14. Es funktioniert jetzt auch mit akzeptablen Einschränkungen. 1W I/O --> KNX muss ich anders handhaben, als KNX --> 1W I/O

Ich sehe auch komisches Verhalten des KNX Bindings. Ein simpler switch-control mit einem Switch Item und ohne weitere Channels sendet beim Schalten auf der OH GUI diese endlosen ein/aus Orgien auf den Bus, außer ich konfiguriere ihn mit autoupdate="false", dann sendet er beim Umschalten überhaupt nicht mehr. Das scheint kaputt zu sein. Es wäre gut, wenn sich das Binding auch wie ein KNX-Gerät verhalten würde und nicht versuchen würde schlauer zu sein als nötig. Und DPTs habe ich jetzt oft weggelassen, weil das auch dazu führen kann, dass ohne jede Meldung einfach etwas nicht durchgereicht wird. Ich hoffe ja so ein bisschen auf die nächste OH-Version....

Ciao

[udo1toni]

Ich hoffe ja so ein bisschen auf die nächste OH-Version....

Mach Dir da mal nicht zu viele Hoffnungen, Fehlverhalten kann nur abgestellt werden, wenn es dazu dokumentierte Issues gibt.

[JNK]

Ich halte das KNX Verhalten auch für kaputt.