openhabforum.de

Hallo zusammen,

das folgende Verhalten ist in meinen Augen falsch, zumindest überraschend.

Für jeden Raum und das gesamte Haus habe ich KNX-seitig jeweils einen mehrstufigen Zentral-Aus (nur Lichter aus, Steckdosen und Lichter aus, Steckdosen, Lichter und Geräte aus). Jede Stufe hat eigene 1-Bit-GAs.
Die Zentral-Aus triggere ich bisher über KNX-Taster. Dies soll nach wie vor möglich sein. Zusätzlich möchte ich einen Zentral-Aus über OH schicken können.

Dazu habe ich Paare von Channels und Items definiert, etwa:

Code: Alles auswählen

Thing knx:device:bridge:Anwesenheit "Anwesenheit" (knx:ip:bridge) [
    fetch=false
] {
    Type switch : Grg_Anw_Stufe_1 "Anwesenheit Stufe 1 Garage" [ ga="0/1/5" ]
    Type switch-control : Grg_Anw_Stufe_1_Ctrl "Anwesenheit Stufe 1 Garage" [ ga="0/1/5" ]
    ...

und

Code: Alles auswählen

Switch Anw1_Grg "Anwesenheit Stufe 1 Garage [%s]" { channel="knx:device:bridge:Anwesenheit:Grg_Anw_Stufe_1" }
Switch Anw1_Grg_Ctrl "Anwesenheit Stufe 1 Garage [%s]" { channel="knx:device:bridge:Anwesenheit:Grg_Anw_Stufe_1_Ctrl", autoupdate="false" }

Wenn 0/1/5 über einen KNX-Taster gesendet wird, erhält Anw1_Grg_Ctrl in OH einen Update. In OH sende ich mittels Anw1_Grg.sendCommand(OFF).

Durch eine zentrale Rule werden Updates auf Items, die ein Ctrl-Item haben, auch auf das Ctrl-Item geschickt, um es aktuell halten zu halten (leider macht das OH nicht selbst).
Auf Grund des Anw1_Grg.sendCommand(OFF) wird daher automatisch ein

Code: Alles auswählen

	Anw1_Grg_Ctrl.postUpdate(OFF)

ausgeführt. Damit kann ich nur auf das Ctrl-Item reagieren, ohne mir Gedanken darüber zu machen, ob es über KNX oder OH geändert wurde:

Code: Alles auswählen

rule
when
	Item Anw1_Grg_Ctrl  received update
then
...

Das funktioniert bei den RollerShutterItems für unsere Jalousien ganz famos.

Beim Switch läuft es offensichtlich anders. Das obige Anw1_Grg_Ctrl.postUpdate(OFF) führt zu einem GroupValueWrite auf dem KNX-Bus:

GroupValueWrite.png

Das ist meines Erachtens aus mehreren Gründen falsch, zumindest so nicht spezifiziert:

Ein postUpdate() sollte nicht auf den KNX-Bus durchschlagen. Nur sendCommand() schickt auf den KNX-Bus.
Nach meinem Verständnis sollte ein Control-Item nur auf ein GroupValueRead reagieren. Ein GroupValueWrite wird - zumindest bei den RollerShutterItems - durch das autoupdate="false" verhindert.

Verstehe ich was muss, oder ist das Verhalten beim switch-control falsch? Wie kann ich ein Switch-Ctrl-Item aktuell halten, ohne dass ein Upate auf den KNX-Bus geschickt werden?

Tokamak hat geschrieben: ↑22. Okt 2019 11:53 Wenn 0/1/5 über einen KNX-Taster gesendet wird, erhält Anw1_Grg_Ctrl in OH einen Update.

Nein, da es sich um einen *-control Channel handelt, kommt in diesem Fall command an (received command triggert, received update triggert nicht)

Durch eine zentrale Rule werden Updates auf Items, die ein Ctrl-Item haben, auch auf das Ctrl-Item geschickt, um es aktuell halten zu halten (leider macht das OH nicht selbst).

Warum sollte es auch, schließlich handelt es sich um zwei unterschiedliche Items. openHAB kann das aber trotzdem tun (ohne Rule), nämlich mittels Profiles (vorausgesetzt, Du nutzt eine einigermaßen aktuelle Version von openHAB, ich mir nicht nicht sicher, ob OH2.4 das schon kann, auf jeden Fall geht es seit OH2.5-M1 (OH2.5-M4 ist aktuell)

Beim Switch läuft es offensichtlich anders. Das obige Anw1_Grg_Ctrl.postUpdate(OFF) führt zu einem GroupValueWrite auf dem KNX-Bus

das hat nichts mit dem Switch zu tun, sondern mit dem *-control. knx2 arbeitet funktionsgerichtet (wenn ich das mal so nennen darf), die "normalen" Channel haben einen Aktor oder Sensor im knx Bus. openHAB sendet Befehle (z.B. UP/DOWN) und empfängt Status (z.B. 0 und 100). Rules triggern nicht auf received command, sondern nur auf received update oder changed.
Die *-control Channel haben den Aktor oder Sensor per Definition auf openHAB-Seite, womit openHAB Befehle empfängt und Status auf den Bus sendet.
Die Umsetzung, postUpdate() direkt auf den Bus durchzureichen, ist auf den ersten Blick falsch, oder zumindest ungewöhnlich, letztlich aber korrekt, da jede Statusänderung an knx weitergereicht werden soll.

Das führt zu einem stark veränderten Verhalten bei einem Wechsel von knx1 zu knx2, und Du bekommst das zu spüren.

Ich verstehe aber ehrlich gesagt nicht so ganz, was das Ganze überhaupt soll. Ich habe ebenfalls Zentral Aus Funktionen, aber ich benötige keine extra Channel dafür.

Ich habe erst mit OH2.4 und KNX 2 angefangen und bin daher nicht mit KNX 1 in Berührung gekommen.

Von der Stable 2.4 wechsle ich erst dann zur einer 2.5, wenn sich was am KNX-Verhalten ändert. Lewie sprach in einem Thread davon, dass er die KNX-Flags in OH einführen will. Ich hoffe, dass damit die unseligen -controls der Vergangenheit angehören.

Warum sollte es auch, schließlich handelt es sich um zwei unterschiedliche Items.

Das meinte ich nicht.

Wenn ein KNX-Taster das OFF (oder ON) sendet, erhält Anw1_Grg_Ctrl das Command OFF (bzw. ON), wie du auch schriebst. Wenn ich hingegen ein Anw1_Grg.sendCommand(OFF) absetze, um auf den KNX-Bus zu schreiben, reagiert Anw1_Grg_Ctrl nicht, weder auf "received command" noch auf "received update". Es wird nicht aktualisiert.
Das halte ich nicht nur für inkonsistent, sondern falsch.
Das sind die zwei Items, von denen ich sprach, die nicht miteinander gekoppelt sind, obwohl sie die gleiche GA bedienen.

Damit hat man das Problem, dass man eigentlich noch ein drittes Item benötigt, mit dem man sich das letzte Command merken muss, das vom KNX- oder OH-Bus kam, um das aktuell wirksame Command zu kennen.

Oder man trickst in dem Wissen, dass ein Anw1_Grg_Ctrl.postUpdate() auf den KNX-Bus gesendet wird, wohingegen mit "Anw1_Grg_Ctrl received command" auf den KNX-Bus reagiert wird.

Drei Items für eine 1-Bit-GA ist nun wirklich übertrieben, ein Item mit Tricks ist im Programmcode nicht schlüssig.

Wenn man schon zwischen Aktor und Sensor unterscheiden wollte, wäre es dennoch richtig gewesen, dass ein sendCommand() auf dem einen als received command auf dem anderen ankommt - analog beim Update.

Nein, genau diese Schleife sollte ja damit verhindert werden. Ich denke, das Problem ist hier, welcher Channel zuerst angelegt ist (aber das ist nicht 100% sicher, also folgende Aussage mit Vorsicht genießen):
es gab mit knx1 auch Leute, die dieselbe GA untereschiedlichen Items zuordneten. Sendend ist das kein Problem, empfangen wurde die Nachricht aber immer nur auf einem der Items. das hängt damit zusammen, dass das Addon beim Empfang einer GA eine Tabelle durchsucht, bis es die GA gefunden hat. Dann schickt es die Message an das betreffende Item weiter und bricht die Suche ab, schließlich kostet die Suche in Tabellen Rechenzeit. Damit wird aber nur dasjenige Item die GA empfangen, welches zuerst in der Liste steht. Vermutlich wird also das Item, über das die NAchricht gesendet wird, zuerst in der Liste stehen. openHAB merkt, dass es die Nachricht vom selben Item geschickt hat und verwirft das Telegramm.
Man mag das Verhalten falsch finden, aber zumindest ist es erklärbar.

Nochmal: Ich nutze auch knx Gruppen, und ich brauche nur ein Item pro GA, keine zwei Items und erst recht keine drei Items.

Natürlich kann man auf einer alten Version stehen bleiben, darf sich dann aber auch nicht wundern, wenn die Entwicklung vielleicht schon weiter ist

udo1toni hat geschrieben: ↑22. Okt 2019 17:03 Man mag das Verhalten falsch finden, aber zumindest ist es erklärbar.

Ist eine Erklärung, wobei die Tabellen sicher nicht stumpfsinnig durchgegangen werden, sondern gehasht sein dürften. Daher handelt es sich eher um eine Annahme ("der erste Treffer reicht") als um technische Notwendigkeit. Wie dem auch sei, muss ich damit leben.

Meine Lösung ist nun, nur noch das command durchzureichen. Empfängt das an den KNX-Bus sendende Item ein Command, wird es automatisch per Rule auch an das passende Ctrl-Item geschickt. So empfängt das Ctrl-Item immer das Command, egal, ob es vom KNX- oder vom OH-Bus kommt. Ich muss nun schauen, ob das auch bei NumberItems funktioniert, z.B. die Lüftungsstufe, die über KNX-Sensoren eingestellt werden kann.
Ein Status-Update gebe ich hingegen nicht mehr weiter.

Ich nutze auch knx Gruppen, ...

Was meinst du damit? Hast du einen Link?

Natürlich kann man auf einer alten Version stehen bleiben, darf sich dann aber auch nicht wundern, wenn die Entwicklung vielleicht schon weiter ist

Klar geht es weiter, und ich finde den Einsatz der Entwickler großartig.

Meine Rules sind generisch. Bisher frage ich fast ausschließlich mit "Member of" ab. Die Gruppen fülle ich meist im "System started" anhand von Item-Namen-Prä- und Suffixen und Tags, die ich pflege. Des Weiteren laufen zig Timer, die aktuelle Werte für das GUI berechnen oder Werte vom KNX-Bus holen und sich dafür selbst reschedulen, um nur wirklich vitale Rules mit cron zu starten.
Daher kämpfe ich mit vielen Laufzeitproblemen durch parallel laufende Threads und Timer-Lambdas, u.a. auch damit, dass etwa group.members nicht thread-safe zu sein scheint, aber auch Bugs, die ich in den Tiefen von OH vermute, da sie nur sporadisch und nicht reproduzierbar auftreten.

Daher möchte ich derzeit nicht auf Betas wie die 2.5-Milestones zurückgreifen - es sei denn, sie bieten mir bei der KNX-Anbindung oder bei parallelen Threads einen großen Vorteil.

Tokamak hat geschrieben: ↑23. Okt 2019 08:31
udo1toni hat geschrieben: ↑22. Okt 2019 17:03 Ich nutze auch knx Gruppen, ...
Was meinst du damit? Hast du einen Link?

Naja, Zentral aus z.B., und Raum Aus. Solche Kommunikationsobjekte haben per Definition keinen Status, obwohl man natürlich auf solchen Tasten ebenfalls eine Rückmeldung definieren kann - alle Leuchten verODERt - sobald alle Leuchten aus sind, erlischt auch die Kontrollleuchte. Logischerweise kommt in diesem Fall (wie eigentlich immer) die Rückmeldung über eine eigene GA.

Axo... das ist klar. Nur eine GA.

Ich meinte, dass ich mehrere Items benötige, um das letzte Command zu kennen, das wirksam wurde:

Das "To-KNX-Item", das man nutzen muss, um das Command aus dem GUI auf den KNX-Bus zu senden.
Das "From-KNX-Item", das man nutzen muss, um das gleiche Command in OH zu empfangen, das etwa durch einen Taster auf den KNX-Bus gesendet wurde.

Ein "was war das letzte Command"-Item, da ich sowohl OFF als auch ON sende, also sowas wie

Code: Alles auswählen

rule when
	Item ToKNXItem received command or
	Item FromKNXItem received command
then
	WasWarDasLetzteCommandItem.postUpdate(receivedCommand)
end

Ich dachte, es gibt eine Möglichkeit in OH, zumindest das WasWarDasLetzteCommandItem nicht zu benötigen.

Wie erwähnt, da ich nun eine Rule a la

Code: Alles auswählen

rule when
	Item ToKNXItem received command
then
	FromKNXItem.sendCommand(receivedCommand)
end

habe, ist das FromKNXItem immer aktuell. Das wird auch mit RestoreOnStartup persistiert.

openhabforum.de

KNX2: switch-control-Item.postUpdate() sendet auf KNX-Bus

KNX2: switch-control-Item.postUpdate() sendet auf KNX-Bus

Re: KNX2: switch-control-Item.postUpdate() sendet auf KNX-Bus

Re: KNX2: switch-control-Item.postUpdate() sendet auf KNX-Bus

Re: KNX2: switch-control-Item.postUpdate() sendet auf KNX-Bus

Re: KNX2: switch-control-Item.postUpdate() sendet auf KNX-Bus

Re: KNX2: switch-control-Item.postUpdate() sendet auf KNX-Bus

Re: KNX2: switch-control-Item.postUpdate() sendet auf KNX-Bus