Umschaltung Piri/manuell...

Archiv Skripte, PHP, SQL
1

ich denke mal, dass ich nicht der Einzige bin, der die folgende Aufgabe lösen möchte:

Eine Piristeuerung soll die Beleuchtung übernehmen, und zwar mit relativ kurzen Abständen. D.h. ich möchte das Licht nicht noch etliche Minuten brennen lassen, sondern dass es zügig ausgeht.
Das habe ich realisiert, indem in einem Piri-getriggerten Script (Piri hat eigene FS20-Adresse und schaltet nur über IPS) unterschieden wird in
a) Piriauslösung -> wenn Licht aus dann Licht an, sonst SetScripttimer auf 20 Sekunden
b) Timerauslösung -> Licht innerhalb 15 Sekunden runterdimmen

Das funktioniert soweit wunderbar, bei ständiger Bewegung wird der Scripttimer ständig verlängert ohne unnützen Funkverkehr, wenn die Zeit abgelaufen ist, steht man nicht sofort im dunkeln, sondern kann durch winken zum piri erneut Licht auslösen.

In verschiedenen Fällen ist es trotzdem nötig auf Dauerlicht zu stellen. Ich habe FS20Schalter, die die Beleuchtung direkt steuern (gleiche Adresse wie Dimmer).
Im Designer kann man den Beleuchtungsmodus von auto(piri) auf hand(schalter) umstellen.

Mir fällt aber noch keine Lösung ein, das über die Schalter selbst sauber zu steuern. Ich kann zwar bei Schalteraktion den piri deaktivieren und den ggfs. vom Piri gesetzten Scripttimer auf 0 setzen, dann ist „Handsteuerung“ quasi aktiviert; ich habe aber noch keine saubere Idee, wie ich den „auto“-Modus per Schalter wieder einschalten kann…
…kann mir jemand vom Schlauch helfen oder das Brett vor dem Kopf durchbohren

2

leg dir doch eine Variable „FlurAuto“ oder so an. Dein beschriebenes Script fragt diese jedes mal ab und nur wenn diese auf true steht greift dein automatismus. Ansonsten wird der PIRI ignoriert.

Dein FS20 Taster trigert nun ein anderes Script, dass das Licht auf Dauer-An schaltet und die Variable auf false setzt und damit dein Automodus abschaltet. Der Piri triggert zwar weiterhin das zugeordnete Script, dies beendet sich aber nur selbst.

Gruß,

Toni

3

ich sehe ein, dass ich mich ziemlich kompliziert ausgedrückt habe, aber genau wie Du es beschreibst, läuft es bereits.

Die Frage ist: Wie bekomme ich die Variable „Kueche.Piri.Aktiv“ WAF-kompatibel per Schalter wieder auf „TRUE“…

Ich dachte an so was wie Trigger auf Lichtschalter:


$Reaktionszeit = 10;

if (Getvalueboolean("Kueche.Deckenlampe.Status") == TRUE && (time() -Kueche.Piri.letzerEinsatz) < $Reaktionszeit) && (Kueche.Piri.letzterEinsatz > Kueche.Schalter.letzterEinsatz) {
  // hat sich wohl jemand auf den Piri verlassen, ist enttäuscht worden und drückt jetzt den Lichtschalter...
  setvalueboolean("Kueche.Piri.Aktiv",TRUE); //Script Kueche.Piri wird getriggert
  if (GetValueInteger("Sprachanweisung") == 1){
    sprich("Küchenbeleuchtung auf Bewegungsmelder umgestellt.");  //ruft Funktion für Linguatec auf
  }
  if (GetValueInteger("Sprachanweisung") == 2){
    sprich("Küchenbeleuchtung auf Bewegungsmelder umgestellt. Das Licht erlischt nach " .Getvalueinteger("Kueche.Piri.Dauer") ." Sekunden ohne Bewegung. Für Dauerlicht bitte nochmal aus - und anschalten."); 
  }
} else { //es scheint jemand Licht zu wollen, was durch den Schalter direkt erledigt wird
  setvalueboolean("Kueche.Piri.Aktiv",FALSE); //Auf "Handsteuerung" umschalten
  SetScriptTimer("Kueche.Piri", 0); // verhindern, dass ein noch laufender Timer des Piris gleich das Licht ausschaltet
  if (GetValueInteger("Sprachanweisung") == 1){
    sprich("Küchenbeleuchtung auf Handsteuerung umgestellt.");  //ruft Funktion für Linguatec auf
  }
  if (GetValueInteger("Sprachanweisung") == 2){
    sprich("Küchenbeleuchtung auf Handsteuerung umgestellt. Für Automatikbetrieb Lichtschalter " .$Reaktionszeit ." nach auslösen des Bewegungsmelders drücken. Das Licht ist dann aus kann dann per Schalter oder durch Bewegung wieder eingeschaltet werden"); 

}

setValueInteger("Kueche.Schalter.letzterEinsatz", time());

sorry- bin gerade erst in php und IPS eingestiegen - sind wahscheinlich massig Syntaxfehler drin…

Es scheint mir

a) etwas kompliziert, und
b) weis ich nicht, wie praxistauglich das ist

Ich denke doch, dass ich nicht der Einzige PIRI-Einsetzer bin, der an dieser Problematik rumknobelt…

4

Okay… gaaanz langsam. Ich bin mir nämlich immer noch nicht ganz über deinen IST-Zustand im klaren.

Du hast einen PIRI und einen Schalter. Der Einfachheit halber sollte jeder Schalter, der Piri ist ja ansich auch nur ein Schalter, ein eigenes Script bekommen. Dann hast du, wenn erstmal alles läuft, immer noch Spielraum zum optimieren. Aus zwei Scripten irgendwann ein Einziges zu machen ist oft einfacher als gleich ein „Doppeltes“ zu entwickeln.

Der Schalter ist hier die Hauptinstanz. Hat das Schalterscript die Lampe eingeschaltet, so ist das Piriscript ausser Betrieb und beendet sich lediglich selbst wenn der Piri triggert. Der Schalter ist dem Piri also bevorrechtigt.

Nur wenn das Dauerlicht per Schalterscript abgeschaltet und das Piriscript freigeschaltet wurde wird dies seine jetzt bereits funktionierende Tätigkeit aufnehmen.

Ist eigentlich recht simpel.

Schalterscript:


// hier statt "FlurLichtEingeschaltet" alternativ auf $IPS_SENDER prüfen und $IPS_VALUE auswerten. Siehe Doku
if (GetValueBoolean("FlurLichtEingeschaltet"))  
{
  // Lampe Aus, Piriscript Ein
  FS20_ SwitchMode(4711, false);
  SetValueBoolean("FlurPiriAktiv", true);
}
else
{
  // Lampe Ein, Piriscript Aus
  FS20_ SwitchMode(4711, true);
  SetValueBoolean("FlurPiriAktiv", false);
}

PiriScript:


//ganz oben einfügen
if (! GetValueBoolean("FlurPiriAktiv"))  // WICHTIG - Auf das Ausrufezeichen achten!
  Return;

// Hier dein funktionierendes PiriScript

Gruß,

Toni

5

Jetzt hat sich mein Edit mit Deiner Antwort überschnitten…

Die FS20_Switschmode-Befehle brauche is nicht, da die (Hand)Schalter die Lampen direkt steuern.

Das Problem bei Deiner Lösung tritt bei dem folgenden Szenario auf:

Piri ist aktiv, nervt aber, weil z.B. bei der Verabschiedung von Freunden doch länger gequatscht wird und man ständig winken muss, weil er das Licht ausschaltet. Wenn man dann auf Handsteuerung umschalten möchte, ist das Licht vermutlich an (weil man sich zum Lichtschalter bewegt). Dann würde Dein Script quasi nichts machen. Der FS20-Befehl entfällt (Da direkt angesteuert), sonst würde er das Licht, das dauernd an sein soll auch noch ausschalten, der Piri, der bereits aktiv ist, wird auf aktiv gesetzt…

das ! hatte ich mir schon gedacht :slight_smile:

6

Im Mitlausch-Betrieb ist es das selbe in grün. Lässt halt die Switchmodes weg.

Wenn du den Piri auch direkt auf die Lampe programmiert hast gehts so nicht. Und ich denke dann kannst du deine „Komfortschaltung“ auch vergessen…

Man könnte mit IPS auf Knopfdruck den Lampentimer auf „sehr lang“ setzen, so dass er mehrere Stunden eingeschaltet bleibt bis er wieder manuell aasgeschaltet wird. Es besteht aber die Gefahr, dass der PIRI dir diese Einstellung wieder mit 10 Sekunden überschreibt. In dem Falle darf der Piri nicht direkt die Lampe anpingen sondern IPS muss dies tun.

Edit:

Was mir grad noch einfällt. Du könntest IPS auf den PIRI lauschen lassen und immer wenn der die IPS einstellung überschreibt diese Einstellung wieder zurück-überschreiben. Aber das bedeutet reichlich, wie sagtest du so schön, „unnützen Funkverkehr“

Toni

7

neee- der Piri hat schon eine eigene Adresse, sonst könnte ich per IPS nur mir dem noch zu bauenden „FS20_HängmireinTuchüberdenPiri“ eingreifen :wink:

Man könnte mit IPS auf Knopfdruck den Lampentimer auf „sehr lang“ setzen, so dass er mehrere Stunden eingeschaltet bleibt bis er wieder manuell aasgeschaltet wird. Es besteht aber die Gefahr, dass der PIRI dir diese Einstellung wieder mit 10 Sekunden überschreibt.

Hilft mir zwar hier nicht so weiter, interessiert mich aber trotzdem ziemlich:

Soweit ich meine Forum-Recherchen verstanden habe, kann ich zwar einen Befehl an den Dimmer absetzen (z.B. FS20_Setintensity(4711, 0, $lange):wink: aber nicht den dimmerinternen Timer programmieren… habe ich das falsch verstanden?

Ich gehe stark davon aus, dass der Piri (bzw. IPS durch Trigger) das überschreiben würde, sonst wäre ein Dimmer, der versehentlich auf einen 4,5h-Timer gesetzt wurde, die nächsten 4,5h quasi unansprechbar…

Aber das nur „offThread“… das eigentliche problem war die (re)aktivierung des Pirimodus durch Schalter, die den Dimmern direkt zugeodnet sind.

Ich habe mir die bestechend einfache Logik Deines Vorschlages nochmal versucht klar zu machen - bzw. warum es in Situationen wie oben beschrieben nicht funktioniert:

Die Unterscheidung des Senders fehlt. $IPS_Sender ist immer „Variable“, insofern ist so keine Unterscheidung möglich. Man müsste die updatezeit der Lichtstatus- mit der updatezeit der piristatus-Variablen vergleichen um herauszubekommen „wer“ da das Licht einschalten will…

…mann, manchmal sind so einfache Dinge so kompliziert…

8

Oha… okay… Schritt für schritt…

Ein Dimmer hat viele Timer für Hochdimmzeit Runterdimmzeit und Einschaltzeit. Da ich selbst kein FS20 (mehr) verwende muss ich ein bissel raten jetzt. Die Einschaltdauer jedenfalls wird mit SwitchDuration beeinflusst. Ich vermute mal, dass Duration bei SetIntensity einen der anderen Timer anspricht.

Ein Timer blockiert auf garkeinen Fall dien Empfang von neuen Befehlen. Das wär mir wirklich neu. Du kannst also mit SwitchDuration durchaus einen Timer von 4,5 Stunden starten und nach 12,7 Sekunden mit SwitchMode die Lampe wieder ausschalten.

$IPS_Sender enthält den Text „Variable“ wenn der Sender eine Variable war. Hier kannst du in der Doku nachlesen, dass $IPS_Variable den Variablennamen enthält und $IPS_Value den Wert der Variablen der dein Script getriggert hat.

…mann, manchmal sind so einfache Dinge so kompliziert…

eigentlich nicht :wink:

Toni

9

ja aber neee… :wink:

Das Schalterscript wird über die Statusvariable des Dimmers (== Statusvariable des Schalters) getriggert. Die Auslösung des Scripts per Piri erfolgt deshalb, weil der Piri per FS20-Befehl die Statusvariable des Dimmers ändert- d.h. auch der Inhalt von $IPS_Variable ist immer identisch.

Wenn ich jetzt die Statusvariable der Piris als zusätzlichen Trigger einfüge denke ich, dass das nichts bringt, denn unmittelbar nach dem Trigger durch die Pirivariable erfolgt ein neuer Trigger durch die Dimmervariable (die per FS20-Befehl durch den Piri geändert wurde)… …oder wo fehlt mir der Durchblick…

10

Doch, das macht einen gravierenden Unterschied. Die beiden Scriptschnipsel, die ich gepostet hatte kannst du von zwei verschiedenen Schaltern durch zwei verschieden Variablen triggern lassen. Ich kanns nicht testen, aber das wird schon gehen…

Ist doch kein großer Aufwand… Probiers einfach mal aus.

Toni

11

Das Problem mit dem Ausprobieren liegt daran, dass ich hier gerade kein IPS habe…

Das Schalterscript wird durch Die Statusvariable des Dimmers gesetzt. Ich kann nicht unterscheiden, Ob Piri->FS20-Befehl->StatusvariableDimmer oder StatusvariableDimmer(durch IPS über RX-Instanz Schalter) geschaltet hat, weil es in jedem Fall der Trigger StatusvariableDimmer war.
Da der Piri die Statusvariable des Dimmers ganau wie der Schalter bzw. IPS über RX-Instanz, bekomme ich die Triggerauslösung des Scripts über diese Variable in jedem Fall.
Wenn ich die Statusvariable des Piri zusätzlich als Trigger verwende bekomme ich doch nur eine zusätzliche Auslösung…? …damit weis ich dann, wenn das Script definitiv vom Piri gestartet wurde, aber nicht, wann es definitiv vom Schalter gestartet wurde, denn die Triggervariable könnte genauso vom Piriscript geändert worden sein…

Was spricht gegen die o.g. Idee für das Schalterscript (getriggert durch Kueche.Piri.Status):


$Toleranz=1; //könnte ja mal gerade beim Sekundenumbruch laufen...
If !(time() - IPS_GetUpdatetime("Kueche.Piri.Status") <= $Toleranz) { //Auslösung erfolgte NICHT durch PIRI
  if (!GetValueBoolean("Kueche.Deckenlampe.Status")) { //Lampe war an, Schalter gedrückt (hat Licht ausgeschaltet)-> Piri aktivieren
    SetValueBoolean("Kueche.Piri.Aktiv", true);
  }
  else
  {
  // Lampe ist per Schalter eingeschaltet worden -> Piriscript Aus
    SetValueBoolean("Kueche.Piri.Aktiv", false);
    SetScripttimer("Kueche.Piri", 0); //ggfs. laufenden Piri-Lichtaustimer abbrechen
  } 
}

Das müsste meineserachtens funktionieren. Wenn auch nicht so sauber wie ich es mir wünsche. Die Beurteilungslogik ist hier. „Es war nicht der piri, also wird es wohl der Schalter gewesen sein“. Sauber wäre eine definitive möglichkeit zu wissen, dass es definitiv der mitgelauschte Schalter war, der auslöste.
Somit komme ich wieder zu der Idee von oben:
Wie verhält sich IPS (mitlauschend), wenn ich (bei gleicher FS20-Adresse) der TX-Instanz eine andere Variable zuordne als der RX-Instanz? Wenn die RX-StatusVariable von IPS nicht automatisch bei FS20_switchmode und anderen TX-Befehlen auch die RX-Variable setzt, kann ich im Script feststellen, dass der (mitgelauschte) Schaltbefehl definitiv vom Schalter kam- muss mich dann natürlich um den sync der RX/TX-Variablen selbst kümmern…

12

Hallo Goetz,

ich kann nur immer wieder mahnen diesen Grundsatz strikt einzuhalten:

Finger weg von Statusvariablen!

Statusvariablen sollten immer als ReadOnly-Variablen angesehen werden. Eine Statusvariable kann immer nur den Zustand ihres jeweiligen Moduls wiederspiegeln. Zu diesem Zweck darf sie nur von diesem einen Modul verändert werden, nicht von einem anderen Modul, dem Designer oder einem Skript.

Eine Statusvariable mehrfach zu verwenden mag auf den ersten Blick elegant erscheinen, führt jedoch meistens nur zu Problemen (Ursachenermittlung).

Ich schlage vor, jeden der beiden Fälle getrennt zu lösen, ohne dass es irgendwelche Berührpunkte (wie gemeinsame Variablen) gibt. Erst wenn diese zur vollen Zufriedenheit laufen, werden beide miteinander verknüpft und zwar durch zusätzliche Maßnahmen. Hier können dann auch Prioritäten eingerichtet werden (wie von Toni schon vorgeschlagen) um z.B. die Skripte gegeneinander zu verriegeln.

Gruß
HJH

13

Hallo HJH,

ich hätte die von mir verwendeten Variablen besser bezeichnen sollen:

„Kueche.Piri.Status“ ist die mit der Instanz des Piris verknüpfte Variable. Die wird Scriptmässig nicht verändert.

„Kueche.Piri.Aktiv“ ist eine globale (IPS)Variable, die dazu dient, das Piri.Script abzuarbeiten oder auch nicht (so wie Toni das weiter oben vorgeschlagen hatte). Bisher kann diese Variable über den Designer geändert werden um die Beleuchtung von „auto“ (== Pirigesteuert) auf „hand“(== Direktansteuerung über Schalter unter mitlauschen von IPS) gesetzt werden.

Edit:

Dank Deines Hinweises ist es eher so, dass ich mich nicht um den Sync der RX/TX-Variablen kümmern muss, sondern diese nur als das interpretieren, was Sie sind: Die RX-Variable gibt den Status des Schalters an, die TX-Variable den Status des Dimmers. Oder siehst Du Probleme der gleichen FS20-Adresse RX-seitig eine andere Variable zuzuordnen als TX-seitig?

Die hier diskutierte Aufgabe besteht darin, diese o.g. Variable „Kueche.Piri.Aktiv“ (und damit die Steuerung „auto/hand“) WAF-verträglich über die Schalter, die auch direkt den Dimmer steuern, zu toggeln.

Grüsse, Götz

14

Ich habe danke Parsey inzwischen mehr Klarheit über die Thematik RX/TX-Stausvariablen und werde (vermutlich am Wochenende) mal die diskutierte „Komfort-WAF-verträgliche Piri/Hand-Steuerung“ der Beleuchtung scriptmässig umsetzen und posten.

Danke für die Hilfe soweit