LinKNX: Diskussionen zu Tipps, Tricks und Beispiele

[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]

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

[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.

[mumpf]

Cool, meine Idee war komplizierter...

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

Gruß, Waldemar

[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

[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.

[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]

Ein copy & paste kurz vor Mitternacht.

[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]

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]

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.

Prinzipiell schon, wenn man allerdings richtig zählt und die Fernbedienung der Haube versteckt, sollte das funktionieren.

Meine Haube geht bei Spannungsverlust auf aus, somit kann ich sie bei Bedarf nullen.

Folgenden Ansatz habe ich jetzt mal:

      <object type="5.xxx" id="andere.haube.haube_stufe_ist" gad="3/6/0" log="true" init="persist">Haube Stufe Ist</object>
      <object type="5.xxx" id="andere.haube.haube_stufe_soll" gad="3/6/1" log="true" init="persist">Haube Stufe Soll</object>
      <object type="1.001" id="andere.haube.haube_taster_plus" gad="3/6/2" log="true" init="persist">Haube Taster Plus</object>
      <object type="1.001" id="andere.haube.haube_taster_minus" gad="3/6/3" log="true" init="persist">Haube Taster Minus</object>

<rule id="haube_plus">
  <condition type="and">
    <condition type="or">
      <condition type="object" id="andere.haube.haube_stufe_ist" trigger="true" />
      <condition type="object" id="andere.haube.haube_stufe_soll" trigger="true" />
    </condition>
    <condition type="object-compare" id="andere.haube.haube_stufe_soll" id2="andere.haube.haube_stufe_ist" op="gt" />
  </condition>
  <actionlist type="if-true">
    <action type="set-value" id="andere.haube.haube_taster_plus" value="on" />
    <action type="set-value" id="andere.haube.haube_taster_plus" value="off" delay="200ms" />
    <action type="formula" id="andere.haube.haube_stufe_ist" x="andere.haube.haube_stufe_ist" c="1" delay="400ms" />
  </actionlist>
</rule>

<rule id="haube_minus">
  <condition type="and">
    <condition type="or">
      <condition type="object" id="andere.haube.haube_stufe_ist" trigger="true" />
      <condition type="object" id="andere.haube.haube_stufe_soll" trigger="true" />
    </condition>
    <condition type="object-compare" id="andere.haube.haube_stufe_soll" id2="andere.haube.haube_stufe_ist" op="lt" />
  </condition>
  <actionlist type="if-true">
    <action type="set-value" id="andere.haube.haube_taster_minus" value="on" />
    <action type="set-value" id="andere.haube.haube_taster_minus" value="off" delay="200ms" />
    <action type="formula" id="andere.haube.haube_stufe_ist" x="andere.haube.haube_stufe_ist" c="-1" delay="400ms" />
  </actionlist>
</rule>

Auf der Kommandozeile geht das schon mal, ich bau jetzt noch Rules, um die Taster und LED's zu mappen und programmier das mal in die Komponenten.

[lordhelmchench]

Hallo Zusammen

Ich kann hier leider noch nicht viel zu betragen, da meine Installation erst in ca. 2 Monaten zum fliegen kommt, aber ich wollte mich einmal für diesen Thread bedanken und das geteilte Wissen bedanken (Wie auch sonst in dem Forum, aber dieser Thread ist für mich sehr nützlich). Ich habe hier viel gelernt und bin gespannt, was dann in der Realität dann alles funktioniert... :-)

Gruss und schönen Abend
Stef

[johnnychicago]

Zeit vergleichen

Hallo --

Ich wollte einige meiner Rules etwas flexibler gestalten und Zeiten vergleichen. Eigentlich dachte ich, sowas sollte funktionieren:

<condition type="object" id="test.time_now" op="lt" value="22:00:00" />

oder so was:

<action type="set-value" id="test.timeset" value="22:00:00" />

Tut es aber anscheinend nicht. Was mache ich denn bei der Syntax falsch?

Ich hab's auch mit hour="22" min="0" probiert, tat's aber auch nicht.

Kann mich jemand da mal dezent anschubsen, bitte?

[Michixx]

Linknx bleibt stehen

Hallo zusammen,

ich weiß jetzt nicht mehr weiter.
Leider bleibt mein Linknx ca. alle 6 Std. stehen, das war früher auch schon so, allerdings erst alle 2,5 Tage, keine Ahnung warum.

Jetzt ist mir aufgefallen, je mehr 1-Wire Sensoren ich anschließe desto früher bleibt Linknx stehen.
In dem Logfile steht dann natürlich auch nicht mehr warum.

Als OS benutze ich Debian auf einem Raspberry , mit eibd und der CometVisu.
Der eibd und die CometVisu laufen weiter, auch wenn Linknx stehen geblieben ist.
Die 1-Wire Sensoren sind über einen 1-Wire USB Adapter DS9490R angeschlossen.
Linkx schreibt mir die Temperaturwerte eigentlich nur auf den Bus, bzw. von der Außentemperatur (Siemens Kombisensor) und vom RTR im Wohnzimmer in ein rrd.

Meine linknx.xlm und die linknx.log habe ich angehängt.
Als Beispiel das bash script vom Arbeitszimmer, das sieht so bei den anderen Sensoren entsprechend equivalent aus.

#!/bin/bash
cd /home/rrdtool
# Read temperature from sensor Arbeitszimmer
tempread=`cat /mnt/1wire/28.B3B100040000/temperature`
 
OBJECTID="Arbeitszimmer_Temperatur"
printf '<write><object id="%s" value=%s /></write>\4' "$OBJECTID" "$tempread" | netcat localhost 1028 > /dev/null 2>&1

Vielleicht kann mir da einer von Euch etwas helfen.

Gruß
Michi

[panzaeron]

Hallo Michi,

du könntest zum Testen noch am Beginn und Ende des Shell-Skripts eine Ausgabe in eine zweite Log-Datei machen. Dann siehsteht du ob sich das Skript aufhängt. Zusätzlich kannst du noch in linknx.xml den Loglevel auf Debug setzen vielleicht sieht man denn mehr. Ansonsten fällt mir nichts auf