Ankündigung

**greentux** · 07.04.2013, 20:19

Irgendwas verstehe ich nicht Robert.
Duschlicht:
1. wenn Vorlauf > 30° sperre PM
2. wenn Vorlauf < 28° dann entsprerre PM

Was genau fehlt jetzt.

**Robert** · 07.04.2013, 21:44

Hi.

Sperren würde ich ungern. Was wenn der PM vorher gesperrt war? Verhalten zu Anfang und Ende der Sperre muss parametriert werden. Bestenfalls ist das Licht bei Beginn der Sperre schon an, aber was am Ende? Genau für sowas ist ja der Triggereingang: um eine vom PM nicht zu erfassende Präsenz zu signalisieren.

Mittlerweile habe ich die Doku diesbezüglich noch mal durchforstet: normal die Temp-GA empfangen und verarbeiten. Bei größer-gleich 30°C dann zwei Action: set-value auf PM-Trigger und zudem send-read-request mit delay von 50 Sekunden auf Temp-GA. Dann sollte der Spaß ja zyklisch weitergehen bis Temp kleiner 30°C. Kommt das hin?

Grüße
Robert

**greentux** · 07.04.2013, 21:50

Mmmh, ich leb mit dem Sperren-Szenario seit nem halben Jahr problemlos.
Ich komme ins Bad. Licht an, Zirkulation (manchmal an), gehe unter die Dusche, drehe auf. PM sperrt für 15 min, Licht bleibt an, Extra farbiges Duschlicht geht noch an.
Ich höre auf zu duschen und nach 15 min gehts Duschlicht aus, sowie die Sperre...
Aber ja, ggf gibts Situationen, wo das nicht passt...

**mumpf** · 08.04.2013, 00:35

Zitat von Robert Beitrag anzeigen

Mittlerweile habe ich die Doku diesbezüglich noch mal durchforstet: normal die Temp-GA empfangen und verarbeiten. Bei größer-gleich 30°C dann zwei Action: set-value auf PM-Trigger und zudem send-read-request mit delay von 50 Sekunden auf Temp-GA. Dann sollte der Spaß ja zyklisch weitergehen bis Temp kleiner 30°C. Kommt das hin?

Hallo Robert,

leider klappt das nicht! Nehmen wir an, die Temp ist 35°C. Dann wird die Rule mit der Condition > 30°C true und macht ihre Actions. Nach 50 Sec. kommen z.B. 34°C. Das ist immer noch >30°C, die Rule ist noch immer true. Folglich werden nicht erneut die Actions ausgeführt. Eine alternative sind hier statische objekte und rules (s-Flag und if-true/if-false bei actionlists).

Aber eigentlich müsste das doch nicht sein, oder? Warum alle 50 Sek. nach Temp. pollen? Ist das nur, um den PM nachzutriggern? Da gäbe es ein Pattern:

Code:

<rule id="count0" init="false">
	<condition type="and">
		<condition type="object" id="toggle" value="0" trigger="true"/>
		<condition ... hier die condition die bestimmt wie lange das läuft ... trigger="true"/>
	</condition>
	<actionlist>
		<action type="toggle-value" id="toggle" delay="50"/>
		<action ... hier weitere actions ... />
	</actionlist>
</rule>
<rule id="count1" init="false">
	<condition type="and">
		<condition type="object" id="toggle" value="1" trigger="true"/>
		<condition ... hier die condition die bestimmt wie lange das läuft ... trigger="true"/>
	</condition>
	<actionlist>
		<action type="start-actionlist" rule-id="count0" list="true"/>
	</actionlist>
</rule>

Das coding oben macht alle 50 Sek. was, und nur so lange wie eine bestimmte condition true ist (z.B. Deine Temp > 30°C). Verwende ich bei mir immer, wenn ich einen Timer haben will, den ich ein- und ausschalten kann.

Vielleicht hilft es ja.

Zu Deinen anderen Punkten kann ich noch nicht sagen, ich habe sie noch nicht wirklich verstanden... ist aber auch schon spät...

Gruß, Waldemar

**Robert** · 08.04.2013, 22:39

Hi!

Danke erstmal für das Feedback!

das Duschlicht funktioniert jetzt ganz gut:

Code:

    <rule id="regel_duschlicht">
      <!-- wenn Vorlauf über 30°C dann PM periodisch triggern -->
      <condition type="object" id="temperatur_elternbad_dusche_vorlauf" op="gte" value="30.0" trigger="true"/>
      <actionlist type="if-true">
        <!-- <action type="cancel" rule-id="regel_duschlicht"/> -->
        <action type="set-value" id="praesenzmelder_elternbad_mastertrigger" value="1"/>
        <action type="send-read-request" id="temperatur_elternbad_dusche_vorlauf" delay="50s"/>
      </actionlist>
      <actionlist type="if-false">
        <action type="cancel" rule-id="regel_duschlicht"/>
      </actionlist>
    </rule>

Allerdings: wenn die Temperatur während der 50sec z.B. mehrfach gesendet werden, werden mehrere per delay verzögerte "send-read-request" in die Warteschlange geschrieben. Um das zu verhindern, dachte ich ich könnte mit type="cancel" die noch wartenden Actions der Rule pro-forma immer abbrechen. Scheinbar wirkt das Cancel aber auch auf die (zeilenmäßig) nachfolgenden Anweisungen: das "set-value" wird ausgeführt, das mit "delay" verzögerte "read-request" aber wird gar nicht ausgeführt! Ist das ein Bug oder ein Feature? Eigentlich sollte "cancel" doch nur bereits vorgesehene Actions abbrechen, oder?

Zum Nachtlicht: Scheint sehr ähnlich dem problem von mode etwas weiter vorne im thread zu sein: mehrere mögliche Trigger, ich will aber abhängig vom Trigger nur eine dem einzelnen Trigger zugeordnete Action ausführen.
Ich habe zehn Lampen/EVGs, die in der Nacht nur gedimmt angeschaltet werden sollen. Dafür muss je Lampe die Schalt-GA (DPT 1.xxx) überwacht werden, und wenn die Lampe eingeschaltet wird und der Nachtmodus aktiv ist auf eine entsprechende Dimm-GA ein Dimmwert geschrieben werden. Bisher konnte ich das mit einer "Logik"/Plugin für alle zehn Lampen erschlagen. Geht sowas auch mit Linknx oder muss ich für jede Lampe eine (kurze) eigene Regel anlegen? Oder eben LUA?

Als Referenz das alte Plugin (KEIN Linknx!):

Code:

$plugin_info{$plugname.'_cycle'} = 0;

my $nachtmodus_ga = "0/4/3";

my %lights = ("1/2/61"  => {name => "Schlafzimmer",        dimm_level => 30, dimm_ga => "1/2/63"  },
              "2/1/1"   => {name => "Flur EG",             dimm_level => 40, dimm_ga => "2/1/3"   },
              "2/1/153" => {name => "Flur EG Eingang",     dimm_level => 40, dimm_ga => "2/1/155" },
              "2/1/156" => {name => "Flur EG Sued",        dimm_level => 40, dimm_ga => "2/1/158" },
              "2/1/159" => {name => "Flur EG Nord",        dimm_level => 40, dimm_ga => "2/1/161" },
              "2/2/1"   => {name => "Flur DG",             dimm_level => 40, dimm_ga => "2/2/3"   },
              "2/2/4"   => {name => "Flur DG Treppe+Nord", dimm_level => 40, dimm_ga => "2/2/6"   },
              "2/2/11"  => {name => "Elternbad",           dimm_level => 40, dimm_ga => "2/2/13"  }, 
              "2/2/162" => {name => "Flur DG Treppe",      dimm_level => 40, dimm_ga => "2/2/164" },
              "2/2/165" => {name => "Flur DG Sued",        dimm_level => 40, dimm_ga => "2/2/167" },
              "2/2/168" => {name => "Flur DG Nord",        dimm_level => 40, dimm_ga => "2/2/170" });
  

$plugin_subscribe{$nachtmodus_ga}{$plugname} = 1;

if ($msg{'apci'} eq "A_GroupValue_Write" and $msg{'dst'} eq $nachtmodus_ga) {
  # abhängig vom Nachtmodus Gruppenaddressen abonnieren
  if (int($msg{'data'}) eq 1) {
    foreach my $ga (keys %lights ) {
      $plugin_subscribe{$ga}{$plugname} = 1;
    }
    return "Nachtmodus AN";
  } else {
    foreach my $ga (keys %lights) {
      delete($plugin_subscribe{$ga}{$plugname}); 
    }
  }
    return "Nachtmodus AUS";
}

if ($msg{'apci'} eq "A_GroupValue_Write" and int($msg{'data'}) eq 1) {
  my $ga = $msg{'dst'};
  my $dimm_ga = $lights{$ga}{"dimm_ga"};
  my $dimm_level = $lights{$ga}{"dimm_level"};
  knx_write($dimm_ga, $dimm_level, "5");
  return $ga."->".$dimm_ga."=".$dimm_level;
}
return 0;

Ansonsten bin ich echt sehr glücklich mit Linknx! Bis auf solche Sonderfälle konnte ich die Sachen sehr kompakt und übersichtlich migirieren!

An dieser Stelle auch noch mal vielen Dank an mumpf für das xsd! Das macht das erstellen von XML-Definitionen wirklich zum Vergnügen und verhindert Fehler!

Grüße
Robert

**mumpf** · 09.04.2013, 09:33

Hallo Robert,

Du darfst Dir die Ausführung der actions in linknx nicht als linearen Prozess vorstellen! Sie werden alle parallel ausgeführt. Es ist somit keine "Queue", sondern es sind verschiedene Threads, die möglicherweise schlafen (bei delay).

Konkret gibt es bei Dir folgenden Effekt:

alle 3 actions (cancel-action, set-value-action, read-request-action) werden gestartet.
die cancel-action sucht jetzt alle threads, die schlafen und von der rule erzeugt worden sind
gleichzeitig schreibt die set-value-action ihren Wert auf den Bus
gleichzeitig wird die read-request-action schlafend markiert, da sie ja ein delay hat

Die Schleife, die in der cancel-action die schlafenden Threads durchsucht, wird somit sehr sicher auch die gerade erzeugte read-request-action finden und auch mit canceln. Somit kannst Du das nicht einfach so machen.

Ich hab mal so ein Problem gehabt und es irgendwie gelöst, aber da muss ich zu Hause nachschauen und kann Dir erst heute Abend was dazu schreiben.

Gruß, Waldemar

P.S.: Freut mich, dass Du das xsd nutzt und es als hilfreich empfindest, ich könnte nicht mehr ohne... mit welchem xml-Editor arbeitest Du denn?

**Robert** · 10.04.2013, 16:32

Hi!

Ich benutze Visual Studio 2008 Pro.

Habe jetzt bezüglich der actions noch mal eine Nachfrage:

Innerhalb meiner TV-Regel verwende ich copy-value, um z.B.den Zustand des Präsenzmelder-Sperrobjektes vor dem aktivieren der Szene zu sichern, um ggfl. nach Beendigung der Szene (TV aus) diesen automatisch zu restaurieren. "Anschließend" sperre ich den pm natürlich.

Code:

  <objects>
    <!-- Objekte für Szene TV) -->
    <object id="szene_tv_pm_sperre_vorher" type="1.001" init="off">Zustand der Präsenzmelder-Sperre vor der Szene TV</object>
    <object id="szene_tv_rs_position_vorher" type="5.001" init="request">Zustand der Raffstore-Position vor der Szene TV</object>
    <object id="szene_tv_rs_lamelle_vorher" type="5.001" init="request">Zustand der Raffstore-Lamelle vor der Szene TV</object>
    <object id="szene_tv_rs_automatik_vorher" type="1.001" init="request">Zustand der Raffstore-Automatik vor der Szene TV</object>
    <object id="beleuchtung_wohnzimmer_couch_kamin_gesamt_schalten" gad="2/1/21" type="1.001" init="request" flags="ctu">Beleuchtung Wohnzimmer Couch+Kamin gesamt Schalten</object>
    <object id="steckdose_wohnzimmer_stehlampe_schalten" gad="3/1/3" type="1.001" init="request" flags="ctu">Steckdose Wohnzimmer Couch Ader 2 (sw) Stehlampe Schalten</object>
    <object id="raffstore_wohnzimmer_west_tv_position" gad="4/1/193" type="5.001" init="request" flags="cwtu"><listener gad="4/1/213" read="true"/>Raffstore Wohnzimmer West TV Position</object>
    <object id="raffstore_wohnzimmer_west_tv_lamelle" gad="4/1/194" type="5.001" init="request" flags="cwtu"><listener gad="4/1/214" read="true"/>Wohnzimmer West TV Lamelle</object>
    <object id="raffstore_wohnzimmer_west_tv_automatik" gad="4/1/202" type="1.001" init="request" flags="cwtu"><listener gad="4/1/218" read="true"/>Wohnzimmer West TV Automatik</object>
    <object id="praesenzmelder_wohnzimmer_tv_helligkeitsobjekt" gad="5/1/11" type="1.001" init="request" flags="cwu">Präsenzmelder Wohnzimmer TV Helligkeitsobjekt</object>
    <object id="praesenzmelder_wohnzimmer_tv_trigger" gad="5/1/12" type="1.001" init="request" flags="ctf">Präsenzmelder Wohnzimmer TV Trigger</object>
    <object id="praesenzmelder_wohnzimmer_tv_sperre" gad="5/1/13" type="1.001" init="request" flags="cwtu">Präsenzmelder Wohnzimmer TV Sperre</object>
    <object id="stromwert_multimedia_tvpvr" gad="6/0/1" type="9.xxx" init="request" flags="cwu">Stromwert Multimedia TV/PVR</object>
    <object id="wetter_helligkeit_west" gad="6/3/157" type="9.xxx" init="request" flags="cwu">Wetter Helligkeit West</object>
  </objects>

    <rule id="regel_szene_tv_beleuchtung">
      <condition type="and">
        <condition type="object" id="stromwert_multimedia_tvpvr" op="gte" value="0.9" trigger="true"/>
        <condition type="object" id="praesenzmelder_wohnzimmer_tv_helligkeitsobjekt" value="1" trigger="true"/>
      </condition>
      <actionlist type="on-true">
        <!-- sichern der Zustände vor Aktivierung der Szene -->
        <action type="copy-value" to="szene_tv_pm_sperre_vorher" from="praesenzmelder_wohnzimmer_tv_sperre"/>        
        <action type="set-value" id="steckdose_wohnzimmer_stehlampe_schalten" value="1"/>
        <action type="set-value" id="praesenzmelder_wohnzimmer_tv_sperre" value="1" delay="150ms"/>
        <action type="set-value" id="beleuchtung_wohnzimmer_couch_kamin_gesamt_schalten" value="0" delay="200ms"/>
      </actionlist>
      <actionlist type="on-false">
        <action type="conditional">
          <!-- falls PM vorher nicht gesperrt war, Sperre wieder zurücksetzen! -->
          <condition type="object" id="szene_tv_pm_sperre_vorher" value="0"/>
          <action type="set-value" id="praesenzmelder_wohnzimmer_tv_sperre" value="0"/>
          <action type="set-value" id="praesenzmelder_wohnzimmer_tv_trigger" value="1" delay="100ms"/>
        </action>
        <action type="set-value" id="steckdose_wohnzimmer_stehlampe_schalten" value="0"/>
      </actionlist>  
    </rule>

Frage: muss ich da unbedingt beim Sperren mit einem delay arbeiten, oder kann ich mich darauf verlassen, dass das copy-value (ggfl. benötigt das ja einen read-request!) immer vor dem set-value aufgerufen wird?
Teilweise könnte ich die Sache umgehen, wenn ich mit einer action type="conditional" erst den Wert (erzwungenermaßen) abfrage und dann mit set-value de-facto alle Werte manuell setze. Allerdings kommt das der Klarheit der Regel nicht gerade zu Gute.

Code:

      <actionlist type="on-true">
       <action type="conditional">
          <condition type="object" id="praesenzmelder_wohnzimmer_tv_sperre" value="0"/>
          <action type="set-value" id ="szene_tv_pm_sperre_vorher" value="0"/>
        </action>
        <action type="conditional">
          <condition type="object" id="praesenzmelder_wohnzimmer_tv_sperre" value="1"/>
          <action type="set-value" id ="szene_tv_pm_sperre_vorher" value="1"/>
          <action type="set-value" id="praesenzmelder_wohnzimmer_tv_sperre" value="0"/>
        </action>
        <action type="set-value" id="steckdose_wohnzimmer_stehlampe_schalten" value="1"/>
        <action type="set-value" id="beleuchtung_wohnzimmer_couch_kamin_gesamt_schalten" value="0"/>
      </actionlist>
      <actionlist type="on-false">
        <action type="conditional">
          <condition type="object" id="szene_tv_pm_sperre_vorher" value="0"/>
          <action type="set-value" id="praesenzmelder_wohnzimmer_tv_sperre" value="0"/>
        </action>
      <action type="set-value" id="praesenzmelder_wohnzimmer_tv_trigger" value="1"/>
      <action type="set-value" id="steckdose_wohnzimmer_stehlampe_schalten" value="0"/>
      </actionlist>

Bisher habe ich in den Logs den Eindruck, als ob die "Actions" doch der Reihenfolge nach abgearbeitet würden und somit die Delays größtenteils entfallen könnten?

Ansonsten bin ich von linknx restlos begeistert - die obige TV-Regel funktioniert nach ersten Tests perfekt. Gleiches habe ich auch für die Verschattung beim TV-Gucken vorbereitet (Glotze steht bei uns vor einem bodentiefen Fenster).

Grüße
Robert

**netsrac** · 10.04.2013, 19:08

LinKNX: Diskussionen zu Tipps, Tricks und Beispiele

Hat jemand eigentlich Aktionen in LinKNX die mit dem IRTrans LAN zusammen arbeiten?!

Würde es einerseits gerne für die Statuserkennung nutzen (sehen ob TV oder Receiver) eingeschaltet sind. Zusätzlich würde ich gerne bei "Zentral Aus" entsprechende Befehle senden.

Desweiteren bin ich noch auf der Suche nach Ideen, was man noch so alles mit dem IRTrans und LinKNX anstellen kann.

Gruß, netsrac

**mumpf** · 10.04.2013, 19:10

Hi Robert,

zuerstmal: Alles was ich hier sage, ist entweder "Erfahrung", Beobachtung oder angelesenes Wissen - ich weiß nicht exakt, wie linknx actions prozessiert - ich hab es nicht programmiert.

Allerdings habe ich gelesen, dass man annehmen sollte, dass alle actions in einer actionlist parallel abgearbeitet werden. Ich hatte auch schon Fälle, bei denen ich aufeinanderfolgende formula-actoins hatte, bei der die 2. Formel das Ergebnis der 1. weiterverarbeitet hat und die erst zuverlässig funktionierten, wenn ich bei der 2. Formel ein delay von 25ms eingefügt hatte.

Ich bin mir auch sicher, dass wenn eine action ein read-request intern macht, die anderen sicherlich weiterlaufen und nicht warten. Allerdings ist auch hier meine Beobachtung die, dass gar kein read-request gemacht wird, sondern mit dem gerade vorhandenem Wert agiert wird, da dieser ja irgendwann "vorher" - also vom letzten write - gesetzt worden ist. Und wenn der Wert noch nie gesetzt worden ist, gibt es zwar einen read-request, aber hier gibt es immer wieder ein komisches Verhalten (hab auch schon einen Bug bei den linknx-Jungs gemeldet). Ich hab mir für linknx eigens eine rule für die Initialisierung ausgedacht, damit ich mich nicht auf das Init-Verhalten von linknx verlassen muss und zumindest die Option habe, es anders zu machen.

Ansonsten mach ich auch sehr vieles mit linknx und bin auch begeistert, denn ich halte es für besser und einfacher, über Regeln zu formulieren, was ich will, statt über Algorithmen das wie zu implementieren. Aber ich nutze durchaus auch Wiregate-Plugins für einige Sachen: RRDs wegschreiben, Abfrage vom Google-Kalender, RFID-Erkennung sind Beispiele, die über einen Algorithmus einfacher zu lösen sind.

Zu Deinem Beispiel oben: Solange es zuverlässig läuft, würde ich es so lassen - also quasi sequentiell. Und wenn Du feststellst, dass sporadisch nicht läuft, würde ich die Logs durchgehen und checken, ob sich das Verhalten mit Parallelität erklären lässt - wenn ja, kannst Du immer noch delays oder ähnliches einführen.

Gruß, Waldemar

**mumpf** · 10.04.2013, 19:19

Zitat von netsrac Beitrag anzeigen

Hat jemand eigentlich Aktionen in LinKNX die mit dem IRTrans LAN zusammen arbeiten?!

Hi netsrac,

ich hab zwar kein IRTrans, aber ich werte lirc aus, das sind auch LAN-basierte Messages. Kannst Du denn mit telnet über irgendeinen port die Nachrichten mitlesen, die IRTrans sendet? Wenn ja, kann ich hier gerne mal ein paar Beispiele reinstellen, denn dann wird es wohl auch mit linknx klappen.

Gruß, Waldemar

**netsrac** · 10.04.2013, 20:05

LinKNX: Diskussionen zu Tipps, Tricks und Beispiele

Zitat von mumpf Beitrag anzeigen

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

**mumpf** · 10.04.2013, 20:45

OK, ich habe folgendes gemacht:

Code:

    <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):

Code:

    <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

Code:

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

**toggle** · 29.05.2013, 23:23

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:

Code:

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

Code:

[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** · 30.05.2013, 00:39

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

Code:

<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** · 30.05.2013, 08:35

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

Ankündigung

LinKNX: Diskussionen zu Tipps, Tricks und Beispiele

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar