Linknx auf dem Wiregate: Regeln werden wiederholt ausgeführt

[lobo]

Hallo,

in diesem Thread: https://knx-user-forum.de/forum/%C3%...d-m%C3%B6glich hatte ich schon mal Probleme mit einer Regel in Linknx angerissen. Konkret wurde die Regel nicht korrekt ausgeführt.

Beim Testen habe ich jetzt den Fall genau umgekehrt: es werden einige Regeln häufig hintereinander ausgeführt - und ich verstehe nicht warum.

Aufgefallen ist mir zunächst beimTesten, dass ich, wenn ich folgende Regel über die Abfrage des Sonnenstandes triggere plötzlich von derselben Regel viele Antworten kommen:

Regel:

<object type="14.xxx" id="1_2_12_Azimut" gad="1/2/12" init="0">(1/2/12)Azimut</object>
<object type="14.xxx" id="1_2_13_Elevation" gad="1/2/13" init="0">(1/2/13)Elevation</object>
...
<!-- Sonnenschutz Fenster Anbau Ost -->
<rule id="SonneImBereich1-FensterOsta">
 <condition type="or">
  <condition type="and">
   <condition type="object" id="1_2_12_Azimut" value="75" op="gt" trigger="true"></condition>
   <condition type="object" id="1_2_12_Azimut" value="181" op="lt" trigger="true"></condition>
   <condition type="object" id="1_2_13_Elevation" value="5" op="gt" trigger="true"></condition>
 </condition>
 <condition type="and">
   <condition type="object" id="1_2_12_Azimut" value="180" op="gt" trigger="true"></condition>
   <condition type="object" id="1_2_12_Azimut" value="210" op="lt" trigger="true"></condition>
   <condition type="object" id="1_2_13_Elevation" value="20" op="gt" trigger="true"></condition>
  </condition>
 </condition>
<actionlist type="if-true">
 <action type="set-value" id="1_6_1_SonneBereich1-FensterOsta" value="on" />
 </actionlist>
<actionlist type="if-false">
  <action type="set-value" id="1_6_1_SonneBereich1-FensterOsta" value="off" />
  </actionlist>
</rule>

Die Ausgabe im Gruppenmonitor ist dann wie folgt:

lobo_Gruppenmonitor_TelegrammeWiederholt.PNG

Die Regel wird also 4x ausgeführt, was auch im LInknx-Log zu erkennen ist:

2021-04-09 15:47:39,918 INFO > Object - New value off for object 1_6_1_SonneBereich1-FensterOsta (type: 1.001)
2021-04-09 15:47:39,919 INFO > Rule - Evaluate rule SchattierenFensterOst
2021-04-09 15:47:39,919 INFO > ObjectValue - SwitchingObjectValue: Compare value_m='0' to value='1'
2021-04-09 15:47:39,919 INFO > Condition - ObjectCondition (id='1_6_1_SonneBereich1-FensterOsta') evaluated as '0'
2021-04-09 15:47:39,919 INFO > Rule - Rule SchattierenFensterOst evaluated as 0, prev value was 0
2021-04-09 15:47:39,919 INFO > FilePersistentStorage - Writing 'off' for object '1_6_1_SonneBereich1-FensterOsta'
2021-04-09 15:47:39,920 INFO > FilePersistentStorage - Writing log'off' for object '1_6_1_SonneBereich1-FensterOsta'
2021-04-09 15:47:39,920 INFO > Action - Execute SetValueAction: set 3_1_2_Sonne with value off

2021-04-09 15:47:39,929 INFO > Object - New value off for object 1_6_1_SonneBereich1-FensterOsta (type: 1.001)
2021-04-09 15:47:39,929 INFO > Rule - Evaluate rule SchattierenFensterOst
2021-04-09 15:47:39,930 INFO > ObjectValue - SwitchingObjectValue: Compare value_m='0' to value='1'
2021-04-09 15:47:39,930 INFO > Condition - ObjectCondition (id='1_6_1_SonneBereich1-FensterOsta') evaluated as '0'
2021-04-09 15:47:39,930 INFO > Rule - Rule SchattierenFensterOst evaluated as 0, prev value was 0
2021-04-09 15:47:39,930 INFO > FilePersistentStorage - Writing 'off' for object '1_6_1_SonneBereich1-FensterOsta'
2021-04-09 15:47:39,930 INFO > FilePersistentStorage - Writing log'off' for object '1_6_1_SonneBereich1-FensterOsta'
2021-04-09 15:47:39,931 INFO > Action - Execute SetValueAction: set 3_1_2_Sonne with value off

2021-04-09 15:47:39,940 INFO > Object - New value off for object 1_6_1_SonneBereich1-FensterOsta (type: 1.001)
2021-04-09 15:47:39,940 INFO > Rule - Evaluate rule SchattierenFensterOst
2021-04-09 15:47:39,940 INFO > ObjectValue - SwitchingObjectValue: Compare value_m='0' to value='1'
2021-04-09 15:47:39,940 INFO > Condition - ObjectCondition (id='1_6_1_SonneBereich1-FensterOsta') evaluated as '0'
2021-04-09 15:47:39,940 INFO > Rule - Rule SchattierenFensterOst evaluated as 0, prev value was 0
2021-04-09 15:47:39,941 INFO > FilePersistentStorage - Writing 'off' for object '1_6_1_SonneBereich1-FensterOsta'
2021-04-09 15:47:39,941 INFO > FilePersistentStorage - Writing log'off' for object '1_6_1_SonneBereich1-FensterOsta'
2021-04-09 15:47:39,942 INFO > Action - Execute SetValueAction: set 3_1_2_Sonne with value off

2021-04-09 15:47:39,951 INFO > Object - New value off for object 1_6_1_SonneBereich1-FensterOsta (type: 1.001)
2021-04-09 15:47:39,951 INFO > Rule - Evaluate rule SchattierenFensterOst
2021-04-09 15:47:39,951 INFO > ObjectValue - SwitchingObjectValue: Compare value_m='0' to value='1'
2021-04-09 15:47:39,951 INFO > Condition - ObjectCondition (id='1_6_1_SonneBereich1-FensterOsta') evaluated as '0'
2021-04-09 15:47:39,951 INFO > Rule - Rule SchattierenFensterOst evaluated as 0, prev value was 0
2021-04-09 15:47:39,952 INFO > FilePersistentStorage - Writing 'off' for object '1_6_1_SonneBereich1-FensterOsta'
2021-04-09 15:47:39,952 INFO > FilePersistentStorage - Writing log'off' for object '1_6_1_SonneBereich1-FensterOsta'

... auch im eig.log finde ich alle 4 Telegramme:

2021-04-09 15:47:39.914,A_GroupValue_Write,0.0.0,1/6/1,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2021-04-09 15:47:39.925,A_GroupValue_Write,0.0.0,1/6/1,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2021-04-09 15:47:39.935,A_GroupValue_Write,0.0.0,1/6/1,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2021-04-09 15:47:39.946,A_GroupValue_Write,0.0.0,1/6/1,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2021-04-09 15:47:39.957,A_GroupValue_Write,0.0.0,1/6/3,01,1,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0

... aber WARUM??

Spinne ich jetzt, oder kackt mein Wiregate ab (hat viele Jahre klaglos funktioniert und war daher sicher sein Geld wert)?

Da ich natürlich nicht jeden Tag mir die Telegramme ansehe, fällt mir schwer zu beurteilen, was diese Telegrammflut auslösen könnte. Was ich im letzten Jahr neu habe, ist:

• eine neue Fritzbox (läuft quasi nur als Internet-Router, dahinter 24 Port-Switch von Zyxel) - ist jetzt eine 6591.
• einen Raspi auf dem node-red läuft (Problem tritt aber auch bei "gezogenem" Netzwerkkabel auf.

Ach ja, wichtig wäre vielleicht zu wissen, dass ich mich üblicherweise mit der ETS über das Wiregate (Tunneling) verbinde. Das Wiregate greift dann auf einen IP-KNX-Router zu. Hierbei verwendet der eibd den einzigen Tunneling Port meiner Schnittstelle. Da sich der eibd und linknx auf demselben Wiregate befinden, vermute ich da aber kein Problem ...

Ich weiß, dass war jetzt eine ganze Menge Info, aber vielleicht hat ja jemand eine Idee, nach was ich noch schauen könnte.

Viele Grüße und danke schon mal

Stefan

[Tru]

Aufgefallen ist mir zunächst beimTesten, dass ich, wenn ich folgende Regel über die Abfrage des Sonnenstandes triggere plötzlich von derselben Regel viele Antworten kommen:

Es wäre noch interessant wie oft die Regel SonneImBereich1-FensterOsta getriggered wird. Das müsste jedes Mal der Fall sein wenn 1/2/12 oder 1/2/13 auf den Bus geschrieben wird. Vielleicht sind zu viele Trigger gesetzt? Ich bin da auch nicht so sattelfest, aber würde es nicht reichen, pro GA nur einmal einen Trigger in der ganzen Rule zu verwenden?

[lobo]

Das ist ein guter Punkt mit dem Trigger ... daran hatte ich bisher gar nicht gedacht.

Das werde ich nochmals testen und dann rückmelden, ob es was ändert, wenn ich z.B. nur auf der Elevation den Trigger setze.

Viele Grüße und danke schon 'mal,

Stefan

[mumpf]

Hi Stefan,

ich bin mir ziemlich sicher: Die 1/2/12 wird auf dem Bus nicht bestätigt, bekommt also kein ACK. Damit wird sie 4 mal wiederholt (sieht man aber nur im Busmonitor, nicht im Gruppenmonitor) und linknx reagiert dann 4 mal drauf.

Das kannst Du dadurch beheben, dass Du entweder:

• die GA 1/2/12 mit irgendeinem KNX-KO verbindest (ein Dummy genügt nicht),
• Einen LK im gleichen Segment auf "Telegramme immer bestätigen" stellst (falls Du einen LK hast)

Normalerweise bestätigt das WG alle Telegramme, deswegen vermute ich, dass da irgendwo noch ein Segmentübergang eine Rolle spielt.

Gruß, Waldemar

[lobo]

Hallo,

ich habe heute den Tag über viel getestet --- so viel, dass ich kein Land mehr sehe

Aaalso:
Wenn ich mit einem Read-Befehl auf meiner Adress 1/2/13 (Elevation) bzw. 1/2/12 (Azimut) abfrage, geschieht folgendes:

lobo_Gruppenmonitor_TelegrammeWiederholt_2.PNG

die Linknx-Regel habe ich dann entsprechend geändert, so dass trigger="true" nur noch bei Azimut, nicht mehr bei Elevation steht (zum testen):

 <rule id="SonneImBereich1-FensterOsta">
<condition type="or">
<condition type="and">
<condition type="object" id="1_2_12_Azimut" value="75" op="gt" ></condition>
<condition type="object" id="1_2_12_Azimut" value="181" op="lt" ></condition>
<condition type="object" id="1_2_13_Elevation" value="5" op="gt" trigger="true"></condition>
</condition>
<condition type="and">
<condition type="object" id="1_2_12_Azimut" value="180" op="gt" ></condition>
<condition type="object" id="1_2_12_Azimut" value="210" op="lt" ></condition>
<condition type="object" id="1_2_13_Elevation" value="20" op="gt" trigger="true"></condition>
</condition>
</condition>
<actionlist type="if-true">
<action type="set-value" id="1_6_1_SonneBereich1-FensterOsta" value="on" />
</actionlist>
<actionlist type="if-false">
<action type="set-value" id="1_6_1_SonneBereich1-FensterOsta" value="off" />
</actionlist>
</rule>

*1)

lobo_Gruppenmonitor_TelegrammeWiederholt_3.PNG

Ist also leider keine Änderung (übrigens: die Adresse 1/6/2 wird nicht bespielt, das mache ich durch die Oder-Verknüpfung - warum die anderen Regeln manchmal eine, manchmal 2 und manchmal 4 Antworten schicken ist mir nicht klar).

Damit schließe ich erst mal die "trigger="true" " - Thematik aus und habe mich den unbestätigten Telegrammen gewidmet. Zu einem späteren Zeitpunkt habe ich gewartet, bis die Wetterstation ihre zyklische Azimut und Elevationsmeldung macht (und damit wieder die obige Telegrammflut auslöst):

lobo_Gruppenmonitor_TelegrammeWiederholt_4.PNG
... und gleichzeitig auch den Busmonitor mitlaufen lassen:

lobo_Gruppenmonitor_TelegrammeWiederholt_5.PNG
Was die ganzen "ungültigen Frame" zu bedeuten haben, erschließt sich mir nicht. Es kommt aber gar nichts als "gültig" an, auch wenn ich ganz normale, bestätigte Telegramme sende. Ich vermute, dass der Busmonitor mit meiner Schnittstelle (ist im Prinzip eine Weinzierl 750 IP Router) nicht funktioniert.

Ich habe daraufhin 3 Dinge versucht:

1. Meinen Linienverstärker zu Programmieren - der steht aber überall auf "nein" bei den Einstellungen zur Wiederholung von Telegrammen. Mehr kann ich da nicht machen.
2. Die Schnittstelle versucht zu programmieren. Die hatte die PA 1.1.0 - und ich hatte versucht, sie auf 1.1.250 zu setzen, was mir nicht gelang (da ich ja gleichzeitg nur über diese Schnittstelle zugreifen kann). Jetzt wird mir die 1.1.250 in der ETS angezeigt und ich kann es nicht mehr zurück stellen, aber was soll's.
3. Das Wiregate komplett neu gestartet - auch um direkt auf die Schnittstelle per Tunneling zuzugreifen (hat nur einen Tunnel). Aber auch das hat nicht geklappt.
4. Ein Gerät gesucht, was vielleicht die GAs für Azimut und Elevation bestätigen könnte. Ich wollte eigentlich dazu mein BJ 6136 Raumpanel nehmen, aber das alte Ding kann nicht mit dem Datentyp (14.007) umgehen.

Also irgendwie bin ich kein Stückchen weiter ... habe heute den halben Tag damit verbracht, aber leider nur eine Baustelle nach der anderen aufgemacht.

Viele Grüße,

Stefan

*1): sorry, aber die Einrückungen werden irgendwie nicht mitkopiert ...

[mumpf]

Hi Stefan,

Meinen Linienverstärker zu Programmieren

OK, mit einer LV-Applikation hab ich mich noch nicht beschäftigt. Wenn man da nicht jedes Telegramm bestätigen lassen kann, dann ist das blöd. Bei einem LK geht das normalerweise.

Das Wiregate komplett neu gestartet

Meine Aussage zum Wiregate war nicht korrekt. Das bestätigt nur Telegramme, wenn es über einen UART direkt am Bus angeschlossen ist, nicht aber über eine Schnittstelle wie bei Dir (geht ja dann auch nicht, das muss dann die Schnittstelle machen).

Ich vermute, dass der Busmonitor mit meiner Schnittstelle (ist im Prinzip eine Weinzierl 750 IP Router) nicht funktioniert.

Das ist korrekt, Router können keinen Busmonitor - zumindest nicht auf der TP-Linie. Und der Busmonitor auf der IP-Linie zeigt natürlich nicht die Wiederholungen auf der TP-Linie an. Aber dem Router kannst Du sagen, dass er alle Telegramme auf der TP-Linie bestätigt. Liegt das Wiregate im selben Segment wie der Router? Wenn das WG (vom Router aus gesehen) hinter dem LV liegt, werden dessen TP-ACK wahrscheinlich nicht helfen (da hab ich aber keine Erfahrung mit).

Ich würde erstmal den Router immer ein ACK senden lassen. Und dann schauen, ob das Problem verschwindet. Wenn ja, ist alles gut, aber wahrscheinlich nur in diesem Segment.

Ist übrigens ein bekanntes Problem von LV (bzw. LK auf "Durchzug"): Das führt immer zu Telegrammwiederholungen, denn es ist nicht zu erwarten, dass alle GA immer in beiden Segmenten mit KO verbunden sind. Und dann laufen zwangsläufig GA, die auf einem Segment verknüpft sind, im anderen Segment in die Leere und werden kräftig wiederholt.

Gruß, Waldemar

[lobo]

OK - das Problem ist gelöst. Tatsächlich waren es die ganzen Trigger = true Einstellungen in Linknx, die zu dem Effekt geführt haben. Ich habe jetzt die Logik über node-red gelöst und dort fuktioniert sie ohne wiederholtes Senden:

lobo_nodered_logik_1.PNG

... andererseits kann ich das Aussenden der Logikantwort jetzt nicht mehr über die Abfrage eines Sonnenstands triggern. Da muss ich mich nochmals darum kümmern, wobei die Debug-Funktion ja eigentlich sehr gut über Node-Red funktioniert, wo man für jeden Knoten das Ergebnis der letzten Berechnung sehen kann.

Viele Grüße,

Stefan