LinKNX: Diskussionen zu Tipps, Tricks und Beispiele

[mumpf]

Hi allerseits,

dies soll der Diskussionsthread zu "LinKNX: Tipps, Tricks und Beispiele" sein, damit man im anderen Thread die Beispiele nicht untergehen.

Viel Spaß,
Waldemar

[dundee]

Hallo Waldemar,

sehr schöner Fred, den du da angefangen hast.
Deine Beispiele find ich überaus interessant!

Aber wäre das nicht generell eher was fürs Lexikon?

[mumpf]

Hi,

finde ich eigentlich auch - aber mein Problem ist, dass man wohl Lexikon-Artikel nicht über die Suche findet - zumindest bekomme ich das nicht hin bzw. bin zu blöd zu...

Deswegen hab ich das als normalen Thread angefangen, denn den findet man wenigstens.

Ich weiss z.B. dass es hier schon mal einen Tipps und Tricks-Artikel gab, aber ich find den nicht...

Bin gerne bereit, mich belehren zu lassen - aber eigentlich sollte man ja was haben, was sich leicht für Neulinge finden lässt. Ich würde dafür plädieren, im LinKNX-Artikel im Lexikon einen Link hierauf zu machen...

Gruß, Waldemar

[greentux]

vl. erstmal festgepinnt eine Weile entwickeln lassen und dann ins Lexikon...

[mumpf]

Hi,

ich hab im Rahmen der Tests für die Tipps und Tricks wohl einen Fehler in LinKNX gefunden - oder sagen wir mal ein Verhalten, dass nicht erwartungskonform ist...

Wäre nett, wenn das jemand noch testen könnte, damit ich ausschlißen kann, dass es an meinem System liegt. Ich würde das dann auch in die Tipps und Tricks posten...

Folgende Situation:

  <objects>
    <object id="dynamic1" gad="11/0/121" type="1.001" init="0">Dynamisches Objekt 1</object>
    <object id="dynamic2" gad="11/0/122" type="1.001" init="0">Dynamisches Objekt 2</object>
    <object id="first" gad="11/0/141" flags="crwts"/>
    <object id="second" gad="11/0/142" flags="crwts"/>
  </objects>

  <rules>
    <rule id="FunktionierendesBeispiel">
      <condition type="and">
        <condition type="object" id="dynamic1" value="1" trigger="true"/>
        <condition type="object" id="dynamic2" value="1" trigger="true"/>
      </condition>
      <actionlist type="on-true">
        <action type="set-value" id="first" value="1"/>
      </actionlist>
    </rule>

    <rule id="Fehlerbeispiel">
      <condition type="object" id="dynamic1" value="1" trigger="true"/>
      <actionlist type="on-true">
        <action type="set-value" id="second" value="1"/>
      </actionlist>
    </rule>
  </rules>

Wenn ich jetzt eine 1 auf dynamic1 sende, würde ich erwarten, dass second auf 1 gesetzt wird. Passiert aber nicht!

2012-10-12 15:57:15,998 DEBUG > KnxConnection  - Write from 1.0.254 to 11/0/121: 01
2012-10-12 15:57:15,999 DEBUG > Object  - Object (id=dynamic1): get
2012-10-12 15:57:15,999  INFO > Object  - New value on for object dynamic1 (type: 1.001)
2012-10-12 15:57:15,999 DEBUG > Object  - Calling onChange on listener for dynamic1
2012-10-12 15:57:15,999  INFO > Rule  - Evaluate rule FunktionierendesBeispiel
2012-10-12 15:57:15,999 DEBUG > Object  - Object (id=dynamic1): get
2012-10-12 15:57:15,999  INFO > ObjectValue  - SwitchingObjectValue: Compare value_m='1' to value='1'
2012-10-12 15:57:16,000  INFO > Condition  - ObjectCondition (id='dynamic1') evaluated as '1'
2012-10-12 15:57:16,000  INFO > KnxConnection  - write(gad=11/0/122, buf, len=2)
2012-10-12 15:57:16,000 DEBUG > KnxConnection  - Write request sent
2012-10-12 15:57:16,107 DEBUG > KnxConnection  - Read from 1.0.254 to 11/0/122

Im Log sieht man, dass ein Read auf dynamic2 gesendet wird, obwohl dieses object bereits mit init=0 vorbelegt ist. Dieser Read wird nicht beantwortet - und dann macht LinKNX nicht weiter! Die rule "Fehlerbeispiel" wird gar nicht evaluiert!!!

Zwar läßt sich dieses Problem in diesem Fall dadurch lösen, dass man das r-Flag an die object-Definition macht

    <object id="dynamic1" gad="11/0/121" type="1.001" init="0" flags="crwtu">Dynamisches Objekt 1</object>
    <object id="dynamic2" gad="11/0/122" type="1.001" init="0" flags="crwtu">Dynamisches Objekt 2</object>

aber grundsätzlich hat man hier das Problem, dass bestimmte Regeln nicht ausgeführt werden, weil in anderen (unabhängigen) Regeln mal ein Gerät nicht auf einen Read geantwortet hat. Weiss hier jemand Rat bzw. ist da schon jemand drüber gestolpert?

Danke und Gruß,
Waldemar

[mumpf]

Hallo Tru,

Du hast in Deinem Beispiel bei der rule immer ein init="false". Kansst Du kurz sagen, was der macht? Bzw. was ein "true" macht? Mir ist neu, dass bei der rule ein init geht...

Gruß, Waldemar

[Tru]

Mir ist neu, dass bei der rule ein init geht...

Gemäss Changelog "allow evaluation of condition to set rule's initial state (Cyrille Defranoux)" in Version 0.0.1.31. So nutze ich das neue Feature, damit jede Rule gleich beim Daemon-Start einen definierten Zustand bekommt. Mit false sollte dies eigentlich dem bisherigen Verhalten entsprechen, für true habe ich noch keinen konkreten Anwendungsfall.

Gruss, Othmar

[Tru]

Weiss hier jemand Rat

Ist mir auch nicht einsichtig. Kann es sein, dass dieses Verhalten nur nach dem Daemon-Start auftritt, aber nicht mehr beim nächsten 0->1 ? Wie sieht das Verhalten aus, wenn die beiden Rules in umgekehrter Reihenfolge definiert sind? Oder nur das Fehlerbeispiel? Meine Vermutung würde in die Richtung gehen, dass das init nicht richtig funktioniert oder dass bei Fehlerbeispiel der Wert der Condition von unknown auf true geht.

Gruss, Othmar

[mumpf]

Hi,

danke für die Antwort, aber 0.0.1.31? Gibt es die schon? Wenn ja: Wo?

Gruß, Waldemar

[Tru]

aber 0.0.1.31? Gibt es die schon?

Nicht released, aber direkt ab CVS seit gut 4 Monaten.

Gruss, Othmar

[mumpf]

Hallo Othmar,

Kann es sein, dass dieses Verhalten nur nach dem Daemon-Start auftritt, aber nicht mehr beim nächsten 0->1 ?

Das hab ich natürlich auch ausprobiert... Es bleibt beim gleichen Verhalten, nur wird das READ nicht mehr abgesetzt.

2012-10-14 16:34:32,852 DEBUG > KnxConnection  - Write from 1.0.254 to 11/0/121: 01
2012-10-14 16:34:32,852 DEBUG > Object  - Object (id=dynamic1): get
2012-10-14 16:34:32,852  INFO > Object  - New value on for object dynamic1 (type: 1.001)
2012-10-14 16:34:32,853 DEBUG > Object  - Calling onChange on listener for dynamic1
2012-10-14 16:34:32,853  INFO > Rule  - Evaluate rule FunktionierendesBeispiel
2012-10-14 16:34:32,853 DEBUG > Object  - Object (id=dynamic1): get
2012-10-14 16:34:32,853  INFO > ObjectValue  - SwitchingObjectValue: Compare value_m='1' to value='1'
2012-10-14 16:34:32,853  INFO > Condition  - ObjectCondition (id='dynamic1') evaluated as '1'

Weiter geht es nicht... Wenn ich aber dynamic1 von 1->0 setze, dann werden beide Rules getriggert, da ja bei der and-condition nur ein Objekt evaluiert wird. Somit haben auch beide rules einen gültigen Zustand, das Ganze ist unabhängig vom Startup.

Wie sieht das Verhalten aus, wenn die beiden Rules in umgekehrter Reihenfolge definiert sind? Oder nur das Fehlerbeispiel?

"Fehlerbeispiel" alleine funktioniert natürlich, hab ich auch getestet. Es klappt auch, wenn sie in umgekehrter Reihenfolge stehen, weil dann "Fehlerbeispiel" zuerst evaluiert wird, danach erst "FunktionierendesBeispiel".

Meine Vermutung würde in die Richtung gehen, dass das init nicht richtig funktioniert oder dass bei Fehlerbeispiel der Wert der Condition von unknown auf true geht.

Wie schon gesagt, ich habe es mehrmals ausprobiert, sollte also nicht am init liegen, ferner habe ich bei 1->0 im Protokoll gesehen, dass "Fehlerbeispiel" mit false evaluiert wird.

Ich kann das Problem lösen, wenn ich dynamic2 auch das r-Flag gebe, dann beantwortet linknx selbst den READ-Request und dann geht es weiter. Aber wenn mal ein Gerät kein READ-Request beantwortet, dann gehen viele rules nicht mehr, das find ich nicht so lustig.

Sollte man das als Bug auf SF melden?

Gruß, Waldemar

[netsrac]

Hab's auch mal probiert...wenn ich die beiden Rules in der Reihenfolge vertausche, dann klappt es so, wie's soll...sprich zuerste die Rule "Fehlerbeispiel" und dann "FunktionierendesBeispiel".

Schickt man mehrmals eine "1" auf dynamic1, so wird der Read Request zwar nicht mehr gesendet, die zweite Rule wird aber dennoch nicht getriggert.

Wenn ich die condition mit "dynamic2" auskommentiere, dann geht es problemlos.

Sende ich vorher auf "dynamic2" eine "0", so funktioniert es auch.

Scheinbar liegt das Problem wirklich daran, dass man von "dynamic2" keinen Init-Wert hat.

Sollte aber wirklich nicht so sein...klingt nach einem Bug. Meine Version ist auch die aus dem CVS:

linknx 0.0.1.31
- Clickatell SMS gateway enabled
- E-mail gateway enabled (with pthread support)
- MySQL support enabled
- LUA scripting support enabled

Netsrac

[mumpf]

Hi Netsrac,

danke für den Test, bei mir passiert das auch mit der 0.0.1.30. Ich werd das mal auf SF melden, kann ja nicht schaden.

Ich hab durch diese Erkenntnis schon an mehreren Stellen meine config angepasst und bereits 2 Probleme gelöst, die in die Kategorie "mystic" fallen:

• Mein Schlüsselbrett und Abwesend-Modus
  Immer nach dem restart von LinKNX musste ich alle Schlüssel mal abgenommen und wieder drangehängt haben, damit der Abwesend-Modus richtig ging.
  Jetzt ist klar: Abwesend wurde durch mehrere interne LinKNX-Objekte ermittelt. Bei allen war in den Flags kein r gesetzt und deren initiales read schlug fehl, dann lief die Abwesend-Rule nicht. Durch Schlüssel ab und dran wurden die internen Objekte beschrieben und dann lief alles wieder.
• Meldung Waschmaschine fertig
  Die funktionierte nach einen Restart von LinKNX auch erst ab dem 2. Waschgang. Hier war es der Schaltaktor der Waschmaschine, der einen Read auf der Schaltadresse nicht beantwortet hat. Hier half ein read="true" im listener, um das Problem zu beheben.

Man kann somit, wenn man den Fehler kennt, durchaus Lösungen finden, den zu umgehen. Ich find es nur blöd, dass es passieren kann, dass man irgendwann eine neue rule einfügt, um was neues zu machen, und dadurch versehentlich andere rules, die bereits funktionierten und womöglich nichts mit der neuen zu tun haben, dann kaputt macht. Und da meine config bereits knapp 3000 Zeilen hat, kann man das auch nicht so einfach rausfinden

Gruß, Waldemar

[netsrac]

Andere Frage, aber vielleicht auch ein Workaround für dieses Problem:

Ich weiß, dass ich mal irgendwo gelesen habe, das man eine Actionlist definieren kann, die beim Start von LinKNX abgearbeitet wird. Nur finden tue ich es jetzt nicht mehr...

Gruß, Netsrac

[Tru]

danke für den Test, bei mir passiert das auch mit der 0.0.1.30. Ich werd das mal auf SF melden, kann ja nicht schaden.

Verbessert sich die Situation wenn mit dem neuen Feature aus 0.0.1.31 die Rules mit init="false" gesetzt werden?

Gruss, Othmar