Dummy GA funktioniert nicht mit openHAB

[Peiper]

Hallo,

ich habe mir mit openHAB 2.4 eine Alarmanlage gebaut, welche über ein switch item aktiviert/deaktiviert werden kann.

Switch Alarmanlage_Aussenhuelle "Alarmanlage Außenhülle [MAP(de.map):%s]" <siren> {channel="knx:device:bridge:generic:PS_Alarmanlage_Aussenhuelle"}

Um das item auch über einen KNX Taster steuern zu können habe ich in der ETS dafür eine Pseudogruppenadresse erstellt (6/3/0) und diese mit dem Schalten Objekt und der Status LED des Tasters verknüpft.

Zusätzlich habe ich dann das entsprechende Thing mit einem switch-control noch erstellt:

Type switch-control : PS_Alarmanlage_Aussenhuelle "Alarmanlage Außenhülle" [ ga="1.001:6/3/0" ]

Sobald ich den switch in der BasicUI nun aktiviere, geht der switch nach gefühlt einer Millisekunde wieder auf aus, das Logfile sagt dazu:

2020-04-21 15:20:39.268 [ome.event.ItemCommandEvent] - Item 'Alarmanlage_Aussenhuelle' received command ON
2020-04-21 15:20:39.276 [nt.ItemStatePredictedEvent] - Alarmanlage_Aussenhuelle predicted to become OFF

Auf dem KNX Bus kommt das "Ein" für die GA allerdings an, ich sehe es im Gruppenmonitor und auch an der Taster LED.

Was mache ich falsch?

[udo1toni]

Wie sieht denn das Thing aus?

[Peiper]

Hier der relevante Teil aus der Thing Config:

Bridge knx:ip:bridge [
ipAddress="192.168.10.3",
portNumber=3671,
localIp="192.168.10.3",
type="TUNNEL",
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=1,
localSourceAddr="1.1.111"
] {
Thing device generic [
address="1.1.101",
fetch=true,
pingInterval=300,
readInterval=3600
] {
...
Type switch-control : PS_Alarmanlage_Aussenhuelle "Alarmanlage Außenhülle" [ ga="1.001:6/3/0" ]
...
}
}

[Tokamak]

Ein -control ist dafür gedacht, einen Aktor zu simulieren. Der hat einen Status und kann ihn senden, wird aber selbst nicht aktiv. So, wie du das modelliert hast, kannst du den switch-control nur über den Taster steuern.

Formal müsstest du mit zwei Switches arbeiten, einem Switch, den du in OH nutzt, und einem Switch-control, das über KNX kommt.

In deinem Fall sollte allerdings ein postUpdate() anstelle des sendCommand() funktionieren. Das heißt, du aktualisierst den Status des in OH simulierten Aktors, den OH dann ebenso auf den Bus sendet, sofern er sich ändert.

Persönlich finde ich das Auftrennung von "normalen" und "control" Items unglücklich. Es hat mir schon einiges an Kopfzerbrechen bereitet.

[udo1toni]

Persönlich finde ich das Auftrennung von "normalen" und "control" Items unglücklich. Es hat mir schon einiges an Kopfzerbrechen bereitet.

Ja, das ist so eine Sache. Ich denke, das war eine Verzweiflungstat. *.control Channel schicken empfangene Telegramme als command auf den openHAB Bus, die ohne -control schicken empfangene Telegramme als update.
Deshalb wird eine Rule nur bei einem -control Channel auf received command triggern, während sie bei nicht-control Channeln nur auf changed oder received update triggert.

Vor dieser Trennung musste man sich als knx-Anwender darum keine Gedanken machen, was eventuell bei dem Einen oder Anderen zu ein bisschen Schludrigkeit geführt haben könnte Andererseits funktionieren seitdem die Trigger so, wie sie eigentlich gedacht sind und es kommt nicht mehr zu seltsamen Effekten auf dem Bus (es sei denn, man hat sich komplett verrannt...)

[Peiper]

In deinem Fall sollte allerdings ein postUpdate() anstelle des sendCommand() funktionieren. Das heißt, du aktualisierst den Status des in OH simulierten Aktors, den OH dann ebenso auf den Bus sendet, sofern er sich ändert.

Verstehe ich es richtig, dass du vorschlägst für das switch Item "Alarmanlage_Aussenhuelle" eine Rule zu verwenden (aktuell verwende ich ja keine)?

Und in dieser Rule dann per postUpdate den Status ändern?

[Tokamak]

Sorry. Ich hatte überlesen, dass du das über das BasicUI gemacht hast.

Das switch-control brauchst du, da ein normales Item einen Read-Requst auf dem KNX-Bus nicht beantwortet.

Auf der anderen Seite reagiert ein switch-control nicht auf sendCommand(). Damit ist es für das BasicUI nicht zugänglich.

Ich habe das so gelöst (ohne Gewähr, dass das die beste Lösung ist):

2 Items pro GA, ein normales, ein Control. Bei dir wäre das

Type switch-control : PS_Alarmanlage_Aussenhuelle_Control "Alarmanlage Außenhülle Control" [ ga="1.001:6/3/0" ]
Type switch : PS_Alarmanlage_Aussenhuelle "Alarmanlage Außenhülle" [ ga="1.001:6/3/0" ]

und

Switch Alarmanlage_Aussenhuelle "Alarmanlage Außenhülle [MAP(de.map):%s]" <siren> {channel="knx:device:bridge:generic:PS_Alarmanlage_Aussenhuelle"}
Switch Alarmanlage_Aussenhuelle_Control "Alarmanlage Außenhülle [MAP(de.map):%s]" <siren>{channel="knx:device:bridge:generic:PS_Alarmanlage_Aussenhuelle_Control", autoupdate="false"}

Dann kannst du im BasicUI Alarmanlage_Aussenhuelle nutzen, um die Alarmanlage zu steuern. Die Kommandos werden auf den Bus gesandt.

Allerdings, und das halte ich für falsch, wird dadurch Alarmanlage_Aussenhuelle_Control nicht gepflegt. Das heißt, wenn du ein ON über Alarmanlage_Aussenhuelle sendest, bleibt Alarmanlage_Aussenhuelle_Control trotzdem OFF.

Daher benötigst du eine Rule wie

rule ""
when
    Item Alarmanlage_Aussenhuelle received command
then
    Alarmanlage_Aussenhuelle_Control.postUpdate(receivedCommand)
end

damit beim Abfragen der GA 6/3/0 OH mit dem korrekten Status antwortet.

Ob das der beste Weg ist, weiß ich nicht. Vielleicht machen es andere anders, das würde ich gerne lernen 🙃

Da OH für diese GA / das Item der Master ist, solltest du des Weiteren über Persistenz nachdenken, damit OH beim Neustart den Status der Alarmanlage kennt (Restore on Startup mit MapDB).

[Peiper]

Vielen Dank für den Input, habe das jetzt mal so wie von dir vorgeschlagen umgesetzt.

Allerdings funktioniert es noch nicht wie gewünscht. Es ist weiterhin so, dass sobald der Swicht in der BasicUI auf ON gestellt wird, dieser sofort wieder auf OFF zurück schnappt. Das Logfile sagt dazu:

2020-04-25 13:32:41.097 [ome.event.ItemCommandEvent] - Item 'Alarmanlage_Aussenhuelle' received command ON
2020-04-25 13:32:41.122 [nt.ItemStatePredictedEvent] - Alarmanlage_Aussenhuelle predicted to become OFF

Warum ist das so?

[Peiper]

Ergänzung: der KNX Taster funktioniert mit der neuen Einstellung wie er soll. Nur wie gesagt der BasicUI Switch gibt zwar das Kommando korrekt auf den KNX Bus weiter, springt aber selbst immer wieder beim Betätigen von ON auf OFF.

Genauso springt der Switch in der BasicUI (wenn er vorher über den KNX Taster auf ON gesetzt wurde) beim setzen auf OFF direkt wieder auf ON um:

2020-04-25 14:14:51.240 [ome.event.ItemCommandEvent] - Item 'Alarmanlage_Aussenhuelle' received command OFF
2020-04-25 14:14:51.273 [nt.ItemStatePredictedEvent] - Alarmanlage_Aussenhuelle predicted to become ON
2020-04-25 14:14:51.298 [vent.ItemStateChangedEvent] - Alarmanlage_Aussenhuelle_Control changed from ON to OFF

[Peiper]

Mit folgender Config scheint es nun zu funktionieren:

*.things

Type switch-control : PS_Alarmanlage_Aussenhuelle_Control "Alarmanlage Außenhülle Control" [ ga="1.001:6/3/0" ]

*.items

Switch Alarmanlage_Aussenhuelle "Alarmanlage Außenhülle [MAP(de.map):%s]" <siren> 
Switch Alarmanlage_Aussenhuelle_Control "Alarmanlage Außenhülle [MAP(de.map):%s]" <siren> {channel="knx:device:bridge:generic:PS_Alarmanlage _Aussenhuelle_Control", autoupdate="false"}

*.rules

rule "RULE_Update_Alarmanlage_Aussenhuelle_Status"
when
Item Alarmanlage_Aussenhuelle received command
then
Alarmanlage_Aussenhuelle_Control.postUpdate(receiv edCommand)
end
rule "RULE_Update_Alarmanlage_Aussenhuelle_Control_Stat us"
when
Item Alarmanlage_Aussenhuelle_Control received command
then
Alarmanlage_Aussenhuelle.postUpdate(receivedComman d)
end

Frage mich, ob das nicht noch etwas einfacher geht...?

[Tokamak]

Mit folgender Config scheint es nun zu funktionieren: ...

Ich hatte gehofft, dass man mit meinem Vorschlag auf die zweite Rule verzichten kann.

Bei mir ist das immer gleich gelöst: Ich lege bei GAs, die ich synchron in OH und KNX halten möchte und wo - wie bei dir über Basic UI und den Taster - auf beiden Seiten aktiv auf den Bus gesendet wird, zwei Types in Things und je Type ein Item an, nach festem Namensschema. Das ist komplexer als in deiner Lösung, da du nur mit dem einen -control - Type auskommst, wenngleich du auch die beiden Items brauchst, um das sendCommand() in postUpdate() zu übersetzen.

Durch das feste Namensschema habe ich die Möglichkeit, beim System Started auf der Suche nach solchen Item-Paaren durch die ItemRegistry zu laufen. Aus den gefundenen Item-Paaren baue ich Gruppen auf, die ich in allgemeinen Rules mit "Member of..." ähnlich wie deine abfackele. Allerdings habe ich drei Rules. Vielleicht reichen auch deine zwei.

Wenn ich Zeit und Muße habe, schaue ich mir an, ob ich das nicht auch bei mir vereinfachen kann. Vermutlich klappt das bei allen Items, wo Status und Kommado im Prinzip gleich sind, also etwa Switch-Items und Number-Items.

Bei Rollershutter-Items sind die Kommandos UP und DOWN (oder Position), der Status aber nur die Position, das heißt, 0 bis 100. Daher wird man wohl zwingend zwei Einträge in der .things benötigen, um UP und DOWN vom KNX-Bus empfangen und auf den KNX-Bus senden zu können.

Frage mich, ob das nicht noch etwas einfacher geht...?

Vermutlich nicht. Richtig nachvollziehen kann ich die Lösung nach wie vor nicht.

Mein Ansatz wäre gewesen, den KNX- mit dem openHAB-Bus 1:1 zu integrieren, also so zu tun, als ob es ein Bus wäre. In der Things-Datei hätte man die Types / GAs mit den KNX-Flags versehen können, wobei vielleicht sogar das L-Flag gereicht hätte. Nur mit L-Flag würde dann OH auf einen Read-Request antworten.

Ohne L-Flag wird in OH nur mit sendCommand() auf den KNX-Bus geschickt, mit L-Flag zusätzlich auch mit postUpdate(). Wenn man sendCommand() noch beeinflussbar hätte machen wollen, hätte man auch noch das S-Flag umsetzen können. Das heißt, nur mit S-Flag sendet sendCommand() auf den KNX-Bus.

Allerdings, auf solch eine Lösung wäre vermutlich jeder Entwickler gekommen. Es muss also Gründe geben, warum es derzeit so ist, wie es ist.