LinKNX: Diskussionen zu Tipps, Tricks und Beispiele

[toggle]

Wie erwähnt, solange man den Zustand der Dunstabzugshaube nicht ermitteln kann, kann es Störungen bzw. Diskrepanzen zwischen Sollwert und Istwert geben. Z.B. wenn eine simulierte Betätigung nicht angenommen wurde oder wenn jemand die Tasten manuel betätigt.

[johnnychicago]

Hallo --

Ich kann die Logik nachvollziehen, brauche also pro Taster eine Rule, die ich mit der GA des Tasters auslöse. Die Idee, dass man allerdings immer 'über los gehen' soll, gefällt mir nicht so ganz.

Ich versuche gerade, eine Logik mit der formula-action zu finden. So ganz durch bin ich noch nicht.

Folgender Ansatz: eine GA hat die aktuelle Lüfterstufe von 0 bis 4, eine GA kriegt per Tastendruck die zu erreichende Lüfterstufe, auch von 0-4.

Die Rule macht eine Evalution Stufe_soll-Stufe_ist (trigger auf change einer der beiden). Wenn das Ergebnis positiv ist, wird einmal am Plus-Relais gewackelt und Stufe_ist um eins höher gesetzt. Wenn das Ergebnis negativ ist, umgekehrt.

Damit müsste sich die Sache eigentlich durch mehrmaligen Aufruf durchhangeln. Helfer-Rules müssen die jeweiligen Tasten auf Stufe_soll mappen, und können auch die LED's an den Tastern schalten. Was mir momentan noch nicht klar ist, ist was passiert, wenn man während der Ausführung der Rule noch eine Taste drückt.

Und in Code gegossen ist das Ganze natürlich noch nicht.

[toggle]

Ein copy & paste kurz vor Mitternacht.

[mumpf]

Hi,

beim obigen Beispiel muss man aufpassen, dass die actions nicht so stehen bleiben! Die werden parallel - also quasi gleichzeitig - ausgeführt! Somit bei der unteren action einen passenden delay einfügen.

Gruß, Waldemar

[toggle]

Da es keine Rückmeldung von der Dunstabzugshaube gibt, wäre meines Erachtens jedesmal ein Zurücksetzen in einen definierten Zustand notwendig. D.h. immer die "-" Taste n Mal aktivieren und erst dann x Mal die "+" Taste (n ist die Anzahl der Stufen). Ein Beispiel:

<condition type="object" id="stufe2" value="on" trigger="true" />
<actionlist>
   <action type="cycle-on-off" id="dunstabzug_minus" on="200ms" 
off="200ms" count="4" />
   <action type="cycle-on-off" id="dunstabzug_plus" on="200ms" 
off="200ms" count="2" delay="1600ms" />
</actionlist>

Es gibt zwei (möglicherweise akzeptable) Nachteile: die Verzögerung wegen Zurücksetzen und den akustischen Effekt, weil zuerst immer abgeschaltet wird. Man müßte noch die richtige Dauer der Impulse (on/off) ermitteln, die von der Dunstabzugshaube akzeptiert werden.

EDIT: Wenn der Aktor den Strom messen kann, könnte man eventuell die aktuell eingestellte Stufe über den Verbrauch ermitteln und entsprechende Bedingungen formulieren.

EDIT2: Delay eingefügt.

[johnnychicago]

Dunstabzugshaube

Hallo --

Ich möchte meine Dunstabzugshaube an den Bus bringen und habe sie jetzt schon mal vorbereitet, indem ich parallel zu den + und - Tastern an der Haube einen Schaltaktor angeschlossen habe. So kann ich Tastendrücke simulieren und die Haube stufenweise hoch- und runterschalten.

Nun möchte ich aber die Schaltstufe direkt auswählen. Wenn ich z.B. die Haube auf Stufe 3 haben will, möchte ich einen Taster drücken, und den Aktor daraufhin 3x kurz die +-Taste antippen lassen. Wenn ich dann auf 1 zurückschalte, möchte ich auf Tastendruck den Aktor 2x auf - anziehen lassen. Ich möchte also das hin- und herschalten zwischen Schaltstufen auf die korrekte Anzahl von Ein-Ausschalt-Vorgängen im Aktor umrechnen.

Hat jemand schon sowas in linknx verwirklicht? Man könnte das ganze mit einem Haufen Rules zwischen allen möglichen Kombinationen abdecken, aber irgendwie scheint mir das nicht sehr smart zu sein. Das geht doch bestimmt auch einfacher, oder?

cu
.\\arc

[mumpf]

Cool, meine Idee war komplizierter...

Hat den üblichen Nachteil, dass frühestens nach 1 Sekunde geschaltet wird. Klasse Lösung,

Gruß, Waldemar

[toggle]

Ich habe eine Alternative gefunden:

[SIZE=3]  <rule id="Guard1">
    <condition type="object" id="input" value="on" trigger="true" />
    <actionlist type="if-true">
        <action type="set-rule-active" active="yes" rule-id="SecondClick1" />
        <action type="set-rule-active" active="no" rule-id="SecondClick1" delay="1" />
        <action type="set-value" id="2_1_0" value="0" delay="1"/>
    </actionlist>
  </rule>
  <rule id="SecondClick1" [COLOR=Red]active="false"[/COLOR]>
    <condition type="object" id="input" value="on" trigger="true" />
    <actionlist type="if-true">
        <action type="set-value" id="2_1_1" value="0" />
        <action type="cancel" rule-id="Guard1" />
        <action type="set-rule-active" active="no" rule-id="SecondClick1" />
    </actionlist>
  </rule>[/SIZE]

Sie funktioniert aber natürlich nur, wenn "input" stateless ist (Flag "s").

EDIT: Initialisierung (active="false") hinzugefügt.

[toggle]

Ich hätte gleich die nächste Frage.

Ich wollte ein Multi-Click-Verhalten implementieren, d.h. wenn ein Taster innerhalb einer vorgegebenen Zeit mehrfach gedrückt wird. Beispiel:
einmal drücken - Aktion A
zweimal innerhalb einer Sekunden drücken - Aktion B (ohne Aktion A)
dreimal innerhalb von zwei Sekunden drücken - Aktion C (ohne A und B)

Mein erster Gedanke war time-counter und set-rule-active zu benutzen. Aber auf den zweiten Blick habe ich erkannt, dass time-counter sich ganz anders verhält, wie ich bräuchte.

Gibt es irgendwelche Vorschläge?

Gruß
Peter

[mumpf]

Guten Morgen, Peter!

Da stimme ich Dir voll zu, ich halte es auch für einen Fehler. Das aktuelle Verhalten hätte man besser über ein

<rule type="static">
  ...
  <actionlist type="true">
    ...
  </actionlist>
  <actionlist type="false">
    ...
  </actionlist>
</rule>

ausdrücken können.

Aber ich nutze linknx nicht wegen der "schönen" Sprache, sondern wegen der Zuverlässigkeit und der asynchronen Abarbeitung: Es gibt keine Abstürze und da alle actions parallel laufen, gibt es auch keine Verzögerungen, weil gerade was anderes läuft. Mir ist das wichtig. Und der Regelbasierte Ansatz (sag was Du willst und nicht wie es zu realisieren ist) ist zumindest für mich recht eingängig, auch wenn es (wie in Deinem Beispiel) kleine "Macken" gibt.

Gruß, Waldemar

[toggle]

Danke für die "späte" Antwort!

Ich finde dieses "versteckte" Verhalten sehr gewöhnungsbedürftig (falls es sich um keinen Bug handelt). Eine klare, eindeutige Sprache wäre mir lieber. Je mehr zusätzliche "Dimensionen" man sich denken muß, desto höher die Wahrscheinlichkeit einen Fehler zu machen, weil man etwas nicht berücksichtigt hat. Bei 4 Objekten und 4 Rules ist es noch überschaubar ...

Viele Grüße
Peter

[mumpf]

Hallo Peter,

Du beschäftigst Dich in Deinem ersten Beitrag gleich mit hartem Tobak

Ich hatte das auch mal so ausprobiert - mit dem gleichen Ergebnis. Ich halte es für einen Fehler, aber man kann die Doku auch folgendermaßen interpretieren:

Nicht jede actionlist ist statisch oder dynamisch, sondern immer die ganze Rule. Soweit ich mich an meine Tests erinnere, ist eine Rule statisch, sobald auch nur eine actionlist mit if-true oder if-false drin ist. Dein Beispiel ist somit auf jeden Fall statisch und dann wird einfach jede true-actionlist (auch die on-true) bzw. jede false-actionlist in Abhängigkeit von der Bedingung ausgeführt.

Du kannst aber das was Du möchtest
(4 verschiedene Übergänge
0->1
1->0
x->1
x->0)
erreichen, indem Du 2 rules draus machst: eine statische (mit den beiden if-xxx) und eine dynamische (mit den beiden on-xxx).

<rules>
  <rule id="Test-static">
    <condition type="object" id="input" value="on" trigger="true" />
    <actionlist type="if-true">
        <action type="set-value" id="2_1_0" value="1" />
    </actionlist>
    <actionlist type="if-false">
         <action type="set-value" id="2_1_1" value="0" />
    </actionlist>
  </rule>
  <rule id="Test-dynamic">
    <condition type="object" id="input" value="on" trigger="true" />
    <actionlist type="on-true">
         <action type="set-value" id="2_1_5" value="0" />
    </actionlist>
    <actionlist type="on-false">
         <action type="set-value" id="2_1_6" value="0" />
    </actionlist>
  </rule>
</rules>

Ich hoffe, das ist nicht zu kompliziert erklärt, auch ich bin wohl etwas müde...

Gute Nacht, Waldemar

[toggle]

on-true, on-false, if-true, if-false

Hallo zusammen,

ich wollte die Ausführung von verschiedenen Aktionslisten nachvollziehen und habe dafür folgendes ausprobiert:

[SIZE=2]<objects>
        <object type="1.001" id="2_1_0" gad="2/1/0" flags="cwuts" log="true">obj0</object>
        <object type="1.001" id="2_1_1" gad="2/1/1" flags="cwuts" log="true">obj1</object>
        <object type="1.001" id="2_1_5" gad="2/1/5" log="true">obj5</object>
        <object type="1.001" id="2_1_6" gad="2/1/6" log="true">obj6</object>
        <object type="1.001" id="input" gad="2/1/33" flags="cwuts">input</object>
</objects>
<rules>
  <rule id="Test">
    <condition type="object" id="input" value="on" trigger="true" />
    <actionlist type="if-true">
        <action type="set-value" id="2_1_0" value="1" />
    </actionlist>
    <actionlist type="if-false">
         <action type="set-value" id="2_1_1" value="0" />
    </actionlist>
    <actionlist type="on-true">
         <action type="set-value" id="2_1_5" value="0" />
    </actionlist>
    <actionlist type="on-false">
         <action type="set-value" id="2_1_6" value="0" />
    </actionlist>
  </rule>
</rules>[/SIZE]

Wenn ich nun mehrmals 0 oder 1 hintereinander mit groupswrite auf "input" sende, dann werden immer beide true bzw. beide false Aktionen ausgeführt unabhängig vom Zustand der rule.

[SIZE=2]2013-05-30 00:13:35 [ INFO] Object: New value off for object input (type: 1.001)
2013-05-30 00:13:35 [ INFO] Rule: Evaluate rule Test
2013-05-30 00:13:35 [ INFO] ObjectValue: SwitchingObjectValue: Compare value_m='0' to value='1'
2013-05-30 00:13:35 [ INFO] Condition: ObjectCondition (id='input') evaluated as '0'
2013-05-30 00:13:35 [ INFO] Rule: [COLOR=Red]Rule Test evaluated as 0, prev value was 0[/COLOR]
2013-05-30 00:13:35 [ INFO] Action: [COLOR=Blue]Execute SetValueAction: set 2_1_1 with value off[/COLOR]
2013-05-30 00:13:35 [ INFO] KnxConnection: write(gad=2/1/1, buf, len=2)
2013-05-30 00:13:35 [ INFO] Object: New value off for object 2_1_1 (type: 1.001)
2013-05-30 00:13:35 [ INFO] Action: [COLOR=Blue]Execute SetValueAction: set 2_1_6 with value off[/COLOR]
2013-05-30 00:13:36 [ INFO] Object: New value off for object 2_1_1 (type: 1.001)
2013-05-30 00:13:36 [ INFO] Object: New value off for object input (type: 1.001)
2013-05-30 00:13:36 [ INFO] Rule: Evaluate rule Test
2013-05-30 00:13:36 [ INFO] ObjectValue: SwitchingObjectValue: Compare value_m='0' to value='1'
2013-05-30 00:13:36 [ INFO] Condition: ObjectCondition (id='input') evaluated as '0'
2013-05-30 00:13:36 [ INFO] Rule: [COLOR=Red]Rule Test evaluated as 0, prev value was 0[/COLOR]
2013-05-30 00:13:36 [ INFO] Action: [COLOR=Blue]Execute SetValueAction: set 2_1_1 with value off[/COLOR]
2013-05-30 00:13:36 [ INFO] KnxConnection: write(gad=2/1/1, buf, len=2)
2013-05-30 00:13:36 [ INFO] Object: New value off for object 2_1_1 (type: 1.001)
2013-05-30 00:13:36 [ INFO] Action: [COLOR=Blue]Execute SetValueAction: set 2_1_6 with value off[/COLOR]
2013-05-30 00:13:36 [ INFO] Object: New value off for object 2_1_1 (type: 1.001)
2013-05-30 00:13:41 [ INFO] Object: New value on for object input (type: 1.001)
2013-05-30 00:13:41 [ INFO] Rule: Evaluate rule Test
2013-05-30 00:13:41 [ INFO] ObjectValue: SwitchingObjectValue: Compare value_m='1' to value='1'
2013-05-30 00:13:41 [ INFO] Condition: ObjectCondition (id='input') evaluated as '1'
2013-05-30 00:13:41 [ INFO] Rule: [COLOR=Red]Rule Test evaluated as 1, prev value was 0[/COLOR]
2013-05-30 00:13:41 [ INFO] Action: [COLOR=Blue]Execute SetValueAction: set 2_1_0 with value on[/COLOR]
2013-05-30 00:13:41 [ INFO] KnxConnection: write(gad=2/1/0, buf, len=2)
2013-05-30 00:13:41 [ INFO] Object: New value on for object 2_1_0 (type: 1.001)
2013-05-30 00:13:41 [ INFO] Action: [COLOR=Blue]Execute SetValueAction: set 2_1_5 with value off[/COLOR]
2013-05-30 00:13:41 [ INFO] KnxConnection: write(gad=2/1/5, buf, len=2)
2013-05-30 00:13:41 [ INFO] Object: New value off for object 2_1_5 (type: 1.001)
2013-05-30 00:13:41 [ INFO] Object: New value on for object 2_1_0 (type: 1.001)
2013-05-30 00:13:41 [ INFO] Object: New value off for object 2_1_0 (type: 1.001)
2013-05-30 00:13:42 [ INFO] Object: New value on for object input (type: 1.001)
2013-05-30 00:13:42 [ INFO] Rule: Evaluate rule Test
2013-05-30 00:13:42 [ INFO] ObjectValue: SwitchingObjectValue: Compare value_m='1' to value='1'
2013-05-30 00:13:42 [ INFO] Condition: ObjectCondition (id='input') evaluated as '1'
2013-05-30 00:13:42 [ INFO] Rule: [COLOR=Red]Rule Test evaluated as 1, prev value was 1[/COLOR]
2013-05-30 00:13:42 [ INFO] Action: [COLOR=Blue]Execute SetValueAction: set 2_1_0 with value on[/COLOR]
2013-05-30 00:13:42 [ INFO] KnxConnection: write(gad=2/1/0, buf, len=2)
2013-05-30 00:13:42 [ INFO] Object: New value on for object 2_1_0 (type: 1.001)
2013-05-30 00:13:42 [ INFO] Action: [COLOR=Blue]Execute SetValueAction: set 2_1_5 with value off[/COLOR]
2013-05-30 00:13:42 [ INFO] Object: New value on for object 2_1_0 (type: 1.001)[/SIZE]

Vielleicht bin ich zu müde, um einen Denk-/Schreibfehler zu erkennen. Testsystem: Ubuntu VM mit linknx 0.1.30.

[mumpf]

OK, ich habe folgendes gemacht:

    <ioports>
      <ioport id="lirc" type="tcp" host="w.x.y.z" port="nnnn" permanent="true"/>
    </ioports>

Ich denke, die Deklaration ist selbsterklärend, host, port und id musst Du anpassen - das kommt in die services section. Permanent=true ist nötig, weil Du Daten empfangen willst, wenn Du nur senden willst, kann man permanent auch auf false lassen.

Die Rules sehen dann so aus (hier ein toggle meiner Stehlampe von der Fernbedienung aus):

    <rule id="FernbedienungGreenOn" init="false">
      <condition type="and">
        <condition type="ioport-rx" ioport="lirc" expected="0000001488b30000 00 KEY_GREEN" trigger="true"/>
        <condition type="object" id="Stehlampe" value="off"/>
      </condition>
      <actionlist>
        <action type="set-value" id="Stehlampe" value="on"/>
      </actionlist>
    </rule>

    <rule id="FernbedienungGreenOff" init="false">
      <condition type="and">
        <condition type="ioport-rx" ioport="lirc" expected="0000001488b30000 00 KEY_GREEN" trigger="true"/>
        <condition type="object" id="Stehlampe" value="on"/>
      </condition>
      <actionlist>
        <action type="set-value" id="Stehlampe" value="off"/>
      </actionlist>
    </rule>

Die condition ist immer true, wenn der expected-string über den port gelesen wird. Der String muss eindeutig sein und wird immer vom Anfang der Zeile an betrachtet. Sprich die eigentliche Nachricht bei mir ist

0000001488b30000 00 KEY_GREEN irgendeinweitererhexwert

und ich muss auf den Teil in expected prüfen, einfach KEY_GREEN wird nicht erkannt. Den String hab ich direkt aus der telnet-Ausgabe.

Hoffe, das reicht für den Anfang, sonst melde Dich einfach...

Gruß, Waldemar

[netsrac]

LinKNX: Diskussionen zu Tipps, Tricks und Beispiele

Kannst Du denn mit telnet über irgendeinen port die Nachrichten mitlesen, die IRTrans sendet?

Ja, das tut IRTrans auch - wäre also sehr an Deinen Beispielen interessiert....

Danke....netsrac