Doppelte Telegramme auch mit KNX2

[Jockel]

Hallo zusammen,

Nach dem Umstieg auf das KNX2 Bindingen haben meine Regeln mit einem "received command" trigger nicht mehr funktioniert. Die meisten Regeln konnte ich umstellen, aber nicht alle, da z.B. ein Stop Telegram den Status der Rolläden ja nicht ändert.

Als workarround habe ich, wie empfohlen, diese GAs zusätlich als -control Typ angelegt, z.B.:

Thing device knx-1_1_76 [
...
    ] {
        Type rollershutter-control   : Rollaeden_EG_Taster                              "Taster Rolläden EG"                             [ upDown="0/4/20", stopMove="0/4/21" ]
...
    }

Thing device generic [
     ] {
...
        Type rollershutter           : Rollaeden_EG                                    "Rolläden EG"                                     [ upDown="0/4/20", stopMove="0/4/21", position="0/4/22" ]
...

Rollershutter Rollaeden_EG                      "Rolläden EG"                                                    (gZentral_Rollaeden)                                           { channel="knx:device:bridge:generic:Rollaeden_EG" }
Rollershutter Rollaeden_EG_Taster               "Rolläden EG"                                                                                                                   { channel="knx:device:bridge:knx-1_1_76:Rollaeden_EG_Taster" }

Damit funktionieren die Regeln wieder, aber genau für diese Items kommt es jetzt wieder zu doppelten Telegrammen:

|27.10.2018 19:17:50 |3674 |low |0 |SF |6 |1.1.76 (Tastsensor 4fach Universal TSM) |0/4/20 GA (Rolläden EG (auf/ab)) |Down|
|---|---|---|---|---|---|---|---|---|
|27.10.2018 19:17:50 |3674 |low |0 |SF |6 |1.1.241 |0/4/20 GA (Rolläden EG (auf/ab)) |Down|

Ob es denn Aktor stört kann ich noch nicht sagen, auf jeden Fall ist es aber unschön. Zu einem echten problem wurde es, als ich einmal eine zweite openHAB Instanz zu Testzwecken gestartet habe und die sich gegenseitig mit maimaler Datenrate solche Telegramme geschickt haben (ohne das eine Regel aktiv war)

Gibt es vielleicht eine Möglichkeit das zu unterbinden?

Viele Grüße,
Jockel

[4media]

Das war noch ein Fehler der *-control Channels algemein.
Habe das gerade im Zuge der Erweiterung für GroupValueResponse mit behoben.
Siehe: https://github.com/openhab/openhab2-addons/pull/4258

Ich würde mich freuen, wenn Du mit testen würdest. Ein fertig kompiliertes Bining findest Du dort auch.

Beste Grüße
lewie

[Jockel]

Ich hab es eben mit dem M5 Build getestet, der M6 scheint bei mir nicht fehlerfrei zu starten.

Mit dem neuen KNX Binding ist der Fehler nicht mehr aufgetreten, sieht gut aus. Und vielen Dank für das Beseitigen des Fehlers, der hat mir schon ein paar mal Probleme bereitet!

Ich werde das Ganze weiter beobachten und mich wieder melden, sollte doch noch irgendwelche Probleme auftreten!

Viele Grüße,
Jockel

[4media]

Freut mich!

Das KNX2 Binding ist noch neu, und die Materie nicht wenig komplex. Die KNX Logik sauber mit der von openHAB zusammen zu bringen ist meines erachtens aber recht gut gelungen. In kleinen Schritten wird das Bundle immer perfekter.

Beste Grüße
lewie

[Jockel]

Das das ein komplexes Unterfangen ist, kann ich mir sehr gut vorstellen! Ich bin selbst SW-Entwickler, aber ohne jede Kenntnis in Java und OSGI, komme aus der C/C++ Ecke, bei openHAB kann ich die Komplexität des gangen nur bewundernd zur Kenntnis nehmen aber leider nicht helfen...

Mit dem neuen KNX Binding bin ich jetzt leider doch noch auf ein Problem gestoßen...

Ich habe folgende Regel:

 [COLOR=#c586c0]rule[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#ce9178]"Set kitchen blind to nearly down"[/COLOR]
  [COLOR=#c586c0]when[/COLOR]
  [COLOR=#d4d4d4]    [/COLOR][COLOR=#6a9955]//KNX 1.x: Item Rollaeden_gesamt received command or Item Rollaeden_EG received command[/COLOR]
  [COLOR=#d4d4d4]    [/COLOR][COLOR=#569cd6]Item[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#4ec9b0]Rollaeden_gesamt[/COLOR][COLOR=#d4d4d4]        received command or[/COLOR]
  [COLOR=#d4d4d4]    [/COLOR][COLOR=#569cd6]Item[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#4ec9b0]Rollaeden_gesamt_Taster[/COLOR][COLOR=#d4d4d4] received command or[/COLOR]
  [COLOR=#d4d4d4]    [/COLOR][COLOR=#569cd6]Item[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#4ec9b0]Rollaeden_EG[/COLOR][COLOR=#d4d4d4]            received command or[/COLOR]
  [COLOR=#d4d4d4]    [/COLOR][COLOR=#569cd6]Item[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#4ec9b0]Rollaeden_EG_Taster[/COLOR][COLOR=#d4d4d4] received command[/COLOR]
  [COLOR=#c586c0]then[/COLOR]
  [COLOR=#d4d4d4]    logInfo([/COLOR][COLOR=#ce9178]"blinds rules"[/COLOR][COLOR=#d4d4d4], [/COLOR][COLOR=#ce9178]"Kitchen blinds rule was triggered, cmd: "[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#d4d4d4]+[/COLOR][COLOR=#d4d4d4] receivedCommand)[/COLOR]
    [COLOR=#d4d4d4]    [/COLOR][COLOR=#c586c0]if[/COLOR][COLOR=#d4d4d4] (receivedCommand [/COLOR][COLOR=#d4d4d4]==[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#b5cea8]DOWN[/COLOR][COLOR=#d4d4d4]) {[/COLOR]
  [COLOR=#d4d4d4]        [/COLOR][COLOR=#c586c0]if[/COLOR][COLOR=#d4d4d4] (([/COLOR][COLOR=#4ec9b0]Rolladen_Kueche_links[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#d4d4d4]state) [/COLOR][COLOR=#d4d4d4]!=[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#b5cea8]100[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#d4d4d4]&&[/COLOR][COLOR=#d4d4d4] ([/COLOR][COLOR=#4ec9b0]Rolladen_Kueche_rechts[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#d4d4d4]state [/COLOR][COLOR=#d4d4d4]!=[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#b5cea8]100[/COLOR][COLOR=#d4d4d4])) {[/COLOR]
  [COLOR=#d4d4d4]            [/COLOR][COLOR=#4ec9b0]Rollaeden_Kueche[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#d4d4d4]sendCommand([/COLOR][COLOR=#b5cea8]40[/COLOR][COLOR=#d4d4d4])[/COLOR]
  [COLOR=#d4d4d4]            logInfo([/COLOR][COLOR=#ce9178]"blinds rules"[/COLOR][COLOR=#d4d4d4], [/COLOR][COLOR=#ce9178]"Blinds are going down, moved kitchen blinds to 70%"[/COLOR][COLOR=#d4d4d4])[/COLOR]
  [COLOR=#d4d4d4]        }[/COLOR]
  [COLOR=#d4d4d4]    } [/COLOR][COLOR=#c586c0]else[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#c586c0]if[/COLOR][COLOR=#d4d4d4] (receivedCommand [/COLOR][COLOR=#d4d4d4]==[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#b5cea8]UP[/COLOR][COLOR=#d4d4d4]) {[/COLOR]
  [COLOR=#d4d4d4]        [/COLOR][COLOR=#4ec9b0]Rollaeden_Kueche[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#d4d4d4]sendCommand([/COLOR][COLOR=#b5cea8]UP[/COLOR][COLOR=#d4d4d4])[/COLOR]
  [COLOR=#d4d4d4]        logInfo([/COLOR][COLOR=#ce9178]"blinds rules"[/COLOR][COLOR=#d4d4d4], [/COLOR][COLOR=#ce9178]"Blinds are going up, moved kitchen blinds to 0%"[/COLOR][COLOR=#d4d4d4])[/COLOR]
  [COLOR=#d4d4d4]    }[/COLOR]
  [COLOR=#c586c0]end[/COLOR]

Die Regel hat bislang problemlos funktioniert, zunächst auch nach dem Update auf das neue Binding, heute morgen dann allerdings nicht mehr. Ich hab dann ein wenig getestet und bin dabei zu folgendem Ergebnis gekommen:

Meine Tastsensoren senden bei Rolläden zunächst ein "Stop" und dann das Up/Down Telegramm, z.B.:

24.11.2018 16:17:17,3674,low,0,SF,6,1.1.76,Tastsensor 4fach Universal TSM,0/4/21,Rolläden EG (stop),1.010,00,Stop
24.11.2018 16:17:17,3674,low,0,SF,6,1.1.76,Tastsensor 4fach Universal TSM,0/4/20,Rolläden EG (auf/ab),1.008,00,Up

Damit sollte die Regel eigentlich bei jedem Verfahren der Rolläden zwei mal getriggert werden, einmal für Stop und einmal für das eigentliche Verfahren.

Im Fehlerfall wurde die Regel aber nur einmal für das Stop Telegram getriggert. Das konnte ich beliebig oft wiederholen und wurde uach durch das erneute laden der .rules Daei nicht geändert:

2018-11-24 16:17:26.042 [INFO ] [.smarthome.model.script.blinds rules] - Kitchen blinds rule was triggered, cmd: STOP

Nach einem Neustart von openHAB hat es dann zunächst so funktioniert wie erwartet:

2018-11-24 16:42:28.809 [INFO ] [.smarthome.model.script.blinds rules] - Kitchen blinds rule was triggered, cmd: STOP
2018-11-24 16:42:29.207 [INFO ] [.smarthome.model.script.blinds rules] - Kitchen blinds rule was triggered, cmd: UP

Allerdings nur genau 1x, ab der zweiten Betätigung des Tasters wurde die Regel wieder nur durch das Stop-Telegram getriggert.


In der anderen Richtung ist es ähnlich, der Tastsensor sendet wieder die beiden folgenden Telegramme (wobei mir jetzt nicht klar ist, warum auf der 0/4/21 dabei eine "1" und nicht eine "0" gesendet wird, aber das wird an der Konfiguration des Tasters liegen):

24.11.2018 17:12:56,3674,low,0,SF,6,1.1.76,Tastsensor 4fach Universal TSM,0/4/21,Rolläden EG (stop),1.010,01,Start
24.11.2018 17:12:56,3674,low,0,SF,6,1.1.76,Tastsensor 4fach Universal TSM,0/4/20,Rolläden EG (auf/ab),1.008,01,Down

openHAB triggert zunächst wieder wie erwartet:

 Kitchen blinds rule was triggered, cmd: MOVE
2018-11-24 17:03:56.102 [INFO ] [.smarthome.model.script.blinds rules] - Rollaeden_EG_Taster reiceived command
2018-11-24 17:03:56.102 [INFO ] [.smarthome.model.script.blinds rules] - Kitchen blinds rule was triggered, cmd: DOWN

Bei allen weiteren Versuchen aber wieder nur auf das erste Kommando vom Tastsensor:

2018-11-24 17:12:10.214 [INFO ] [.smarthome.model.script.blinds rules] - Kitchen blinds rule was triggered, cmd: MOVE

Das Thing für den Taster mit dem ich getestet habe ich wie folgt definiert:

  [COLOR=#569cd6]Thing[/COLOR][COLOR=#d4d4d4] device knx[/COLOR][COLOR=#d4d4d4]-[/COLOR][COLOR=#d4d4d4]1_1_76 [[/COLOR]
 [COLOR=#d4d4d4]] {[/COLOR]  ...
  [COLOR=#4ec9b0]Type[/COLOR][COLOR=#d4d4d4] rollershutter[/COLOR][COLOR=#d4d4d4]-[/COLOR][COLOR=#d4d4d4]control [/COLOR][COLOR=#c586c0]:[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#4ec9b0]Rollaeden_EG_Taster[/COLOR][COLOR=#d4d4d4] [/COLOR][COLOR=#ce9178]"Taster Rolläden EG"[/COLOR][COLOR=#d4d4d4] [ upDown[/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#ce9178]"0/4/20"[/COLOR][COLOR=#d4d4d4], stopMove[/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#ce9178]"0/4/21"[/COLOR][COLOR=#d4d4d4] ][/COLOR]
  ...
  [COLOR=#d4d4d4]}[/COLOR]

Viele Grüße,
Jockel

[Höhlenbär]

Ich denke du solltest in der Rule nicht
received command verwenden sondern
received update Vermutlich wird der Zustand bei received command zwischen gespeichert und dann wird nicht getriggert.

[Jockel]

Bei rollershutter items wird eine "received update" Regel z.B. bei einem "Stop" Kommando nicht getriggert, daher ist das in diesem Fall nicht das selbe.

Ähnliches gilt beim Verfahren, in der Endlage meldet der Aktor zwar irgendwann die Position, aber nicht zwischendurch (blöder Aktor, ich weiß). Wenn die Rollade also z.B. von 1/3 auf 2/3 verfahren wird, gibt es keinen "update" trigger.

Und bislang hat es ja funktioniert, ich vermute, da ist nur ein kleiner Fehler bei der letzten Anpassung des Bindings reingerutscht.

[Höhlenbär]

(blöder Aktor, ich weiß).

Macht das nicht jeder Aktor so?
Wann hast Du denn geupdatet ?

[Jockel]

Keine Ahnung, ich dachte manche Aktoren würden auch die Zwischenpositionen als Prozentwert melden.

Aktuell verwende ich die Testversion oben aus dem Posting von 4media vom 22.11.

[udo1toni]

ich dachte manche Aktoren würden auch die Zwischenpositionen als Prozentwert melden.

Das ist eher unüblich. Es gibt Aktoren, die man so konfigurieren kann, aber man bekommt natürlich eine höhere Buslast, und wozu? Damit man in der UI eine Anzeige aktualisiert bekommt, die auch nicht "pünktlich" aktualisiert.
Also, ich kann da ehrlich gesagt außer dem eigenen "geil, gell?" keinen vernünftigen Grund finden...

[Jockel]

Ich würde es mir manchmal für meine Logiken wünschen, z.B. die Position in 10% Schritten. AberDu hast natürlich recht, wirklich notwendig ist es nicht, bislang geht es auch so.

Was bei meinen Hager Aktoren zusätzlich blöd ist, dass die Position (oben, unten, Zwischenposition) als 2 Bit in einem Objekt zusammen mit anderen Statuswerten gesendet wird. Man muss alsoerst mal umrechnen, bevor mab sie verwenden kann. Aber, gut, dass hat jetzt nichts mit dem eigentlichen Problem zu tun und tauschen werde ich die Aktoren deswegen sicher auch nicht.

[udo1toni]

Ob es für zwei Bit interessant ist, weiß ich nicht, aber bei meinen Gira RTR habe ich ein ähnliches Problem mit der Rückmeldung der Betriebsart, das habe ich wie folgt gelöst:

var tmp = Heat_FF_Bath_Opmode.state as DecimalType        //lese empfangenen Wert als Dezimalzahl
  var state = tmp.toBigDecimal.toBigInteger                    //schreibe den Dezimalwert als (Big)Integer nach state
  if (state.testBit(0) )                                     //teste Bit 0
  if (state.testBit(1) )                                     //teste Bit 1
  if (state.testBit(2) )                                     //teste Bit 2
  if (state.testBit(3) )                                     //teste Bit 3

Dieses Codesnippet ist noch aus dem OH1.8 System, vielleicht muss der Code also etwas angepasst werden.

[Jockel]

Danke für den Hinweis, die testBit() Methode kannte ich noch nicht, mit der Bitweisen Und-Verknüpfung geht es aber auch!