LinKNX: Diskussionen zu Tipps, Tricks und Beispiele

[mumpf]

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

[mumpf]

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

[netsrac]

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

[Robert]

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.

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

      <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

[mumpf]

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]

Hi!

Danke erstmal für das Feedback!

das Duschlicht funktioniert jetzt ganz gut:

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

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

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:

<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

[greentux]

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

[Robert]

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]

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

Was genau fehlt jetzt.

[Robert]

Hallo linknx-Experten!

Anlässlich des Bedarfs von Fenster-Logiken ("and" aller Fensterzustände) und Tagesfalle für die Haustür habe ich mich mal mit linknx auseinander gesetzt. Vorige Logiken funtkionieren so gut bzw. übersichtlich, das ich nun gerne einige Logiken die ich momentan als Perl-Plugins auf einem Communitygate habe portieren möchte, um da mal wegzukommen. Leider beinhalten diese beiden Plugins "Kniffe", die ich nicht direkt in linknx finde:

1. "Duschlicht"
Onewire-Tempsensor an der Duschleitung sorgt dafür, dass bei warmen Vorlauf das Licht nicht ausgeht (triggert den PM, der dann die Helligkeit regelt).
Logik: Wenn Temp>30°C, dann trigger PM und rufe dich alle 50 sec auf. Bei jedem Aufruf wird der aktuelle Wert abgefragt. Falls unter 30°C wird das zyklische Pollen und Triggern beendet.
Frage: wie zwinge ich linknx den Wert neu abzurufen? Die Zeit setze ich mit einem timer mit "every" zusammen mit der Temperatur in eine "and" condition? Problem: dann würde die Logik womöglich IMMER alle 50sec aufgerufen?

2. "Nachtlicht"
Wenn das "Nachtlicht" per GA aktiviert wurde, werden ca. 10 verschiedene Schalt-GAs abonniert. Kommt ein Schaltbefehl, wird auf eine Dimm-GA ein Dimmwert nachgesendet. In Perl habe ich dafür einen Hash, der je Schaltaddresse, Dimmwert und -GA enthält. Per Schleife wird aboniert und bei Empfang können automatisch dank des Hashes die Dimmparameter der betroffenen Schaltaddresse zugeordnet werden. Brutal würde ich jetzt ca. 10 eigene Rules machen? Geht das eleganter? Zudem: Tagsüber müssten die GAs gar nicht evaluiert werden - kann ich irgendwie verhindern, dass die Logiken überhaupt ausgeführt werden?

Zusatz:
obige Tagesfallenfunktion: die GA "haustuer_oeffnungsimpuls" geht beim öffnen kurz auf 1 und dann wieder 0. Ich rätsel, ob ich die Funktionalität irgendwie in eine Logik bekomme?

    <rule id ="haustuer_tagesfalle_ein">
      <condition type="and">
        <!-- wenn die Tür zwischen 7:00 und 20:55 geöffnet wird, wird die Tagesfalle aktiviert -->
        <condition type="timer" trigger="false">
          <at hour="7" min="0"/>
          <until hour="20" min="55"/>
        </condition>
        <condition type="object" id="haustuer_oeffnungsimpuls" value="1" trigger="true"/>
      </condition>
      <actionlist type="on-true">
        <action type="set-value" id="haustuer_tagesfalle_aktiviert" value="1"/>
      </actionlist>
    </rule>
    <rule id ="haustuer_tagesfalle_aus">
      <!-- um 21:00 Tagesfalle deaktivieren -->
      <condition type="timer" trigger="true">
        <at hour="21" min="0"/>
      </condition>
      <actionlist type="on-true">
        <action type="set-value" id="haustuer_tagesfalle_aktiviert" value="0"/>
      </actionlist>
    </rule>

Zuletzt: obwohl ich bei meinen Fenster-Objekten überall init="request" gesetzt habe, werden die GAs beim Starten von linknx nicht abgefragt, sondern erst wenn das erste Fenster seinen Zustand verändert?

Tipps zu einzelnen Punkten würden mir auch schon sehr helfen! Vielen Dank!

Grüße
Robert

[mumpf]

Hi,

hier soll ja Zeit gemessen werden - da kenne ich nichts in linknx. Ich habe es auch noch nicht geschafft, einen Timer per condition zu starten oder zu stoppen.

Zum Brainstorming: Das Einzige, was ich mir vorstellen könnte, ist einen Timer z.B. alle 200ms feuern zu lassen, der über and-conditions passende Start- und Stop-Bedingungen und Fahrtrichtung einen Zähler hoch- bzw. runterzählt. Von diesem Zähler kann man dann weitere Infos ableiten.

Allerdings führt das bestimmt zur hoher Last im linknx...

Keine Ahnung, wie man das sonst machen könnte.

Gruß, Waldemar

[netsrac]

[WARNUNG]Sinnfreies Komplettzitat des unmittelbar vorhergehenden Beitrags gelöscht.

Forenregeln beachten![/WARNUNG]


Die Frage ist doch, kann ich einen Timer auslösen, wenn die Jalousie ein "Start" Telegramm bekommt und diesen Timer stoppen, sobald ein Stop-Signal kommt oder die maximale Fahrtdauer x überschritten ist...

Wenn man da hätte, wäre das ja schonmal ein guter Start :-)

[Merlin123]

Das habe ich mich auch schon gefragt, aber außer der Idee, erst eine definierte Position (z.B. ganz oben) anzufahren und von dort aus zeitgesteurt weiterzumachen hab ich auch keinen Plan...

Deswegen habe ich das auch noch nicht umgesetzt.

[netsrac]

Moin Jungs,

ich bin am überlegen, ob es mittelt LinKNX möglich ist, dumme Jalousieaktoren besser zu machen, da meine Aktoren nur Auf, Zu und Stop kennen. Jedoch bekomme ich weder die aktuelle Position, noch kann ich eine Position anfahren.

Die Idee ist folgende: Man müsste ab dem Start-Kommando einfach die Zeit zählen, bis entweder die vorgegebene Laufzeit erreicht ist oder ein Stop-Kommando gesendet wird und somit sollte sich ja halbwegs die aktuelle Position ermitteln lassen.

Zusammen damit sollte man in der Lage sein, eine Zielposition anzufahren. Also einfach die aktuelle Position mit der Zielposition vergleichen und daraus die Fahrtrichtung und Fahrtzeit berechenen.

Jemand 'ne Idee?!


gruß, Netsrac