2 Bedingungen per ODER verknüpfen

[stbi]

Tach,

ich hatte vor, mein Profil zum automatischen Ein-/Ausschalten von W-LAN um eine zusätzliche Bedingung zu erweitern. Und zwar soll der Enter-Task zum Einschalten von W-LAN aktiv sein, wenn das Display eingeschaltet ist ODER das Handy aufgeladen wird.

Füge ich nun die Bedingung "State: Power [ Source:Any ]" zum Profil hinzu ...

Profile: Wifi automatisch schalten
        State: Display State [ Is:On ]
        [COLOR="Blue"]State: Power [ Source:Any ][/COLOR]

Enter: WifiOnEx
        ...

Exit: WifiOffEx
        ...

... dann scheinen beide Bedingungen aber per UND miteinander verknüpft zu werden, d.h. der Enter-Task wird nur ausgeführt, wenn das Display eingeschaltet UND das Handy aufgeladen wird, was natürlich Quatsch mit Soße ist.

Meine Idee war jetzt, einfach beide Bedingungen zu invertieren und Enter- und Exit-Task zu vertauschen, was nach Boolscher Logik auf Dasselbe hinauskommen müßte -- aber ist das tatsächlich die übliche Vorgehensweise, oder gibt es auch eine "elegantere" Möglichkeit, die mehrere Bedingungen per ODER zu verknüpfen?

 

[germanos]

Hallo stbi,

von der Logik her hast du Recht. Auch wenn ich nicht verstehe, warum du ggf. WLAN bei Display-On irgendwo in der Pampa einschalten möchtest

Andere Variante:

Profile "DspOn": State: Display on
Enter: WiFi on
Exit : -kein Task-

+

Profile "Power": State: Power any
Enter: WiFi on
Exit : -kein Task-

+

Profile: State: NOT Profile active: "DspOn/Power"
Enter: WiFi Off
Exit : -kein Task-


Was nun eleganter oder leichter verständlich ist, dürfte eher persönliche Geschmackssache sein.

 

[stbi]

Hi Germanos,

Auch wenn ich nicht verstehe, warum du ggf. WLAN bei Display-On irgendwo in der Pampa einschalten möchtest

OK, dann erkläre ich das mal kurz:

Der Enter-Task "WiFi on" schaltet WLAN sowieso nur dann ein, wenn sich das Gerät in der Nähe bekannter Funkzellen befindet (also z.B. zu Hause oder in der Firma), und läßt es nur dann an, wenn es sich dort mit einem bekannten WLAN-Netz verbinden konnte. D.h. "in der Pampa" wird WLAN bei eingeschaltetem Display je nach Location entweder gar nicht erst eingeschaltet, oder nur ganz kurz.

Die neue ODER-Bedingung "Power" soll bewirken, daß WLAN auch eingeschaltet ist, während ich das Handy nachts zu Hause lade. In dieser Zeit soll dann die App dailyme die abonnierten Serien herunterladen. So möchte ich verhindern, daß die App die Downloads startet, während ich das Handy im Akkubetrieb und über WLAN aktiv benutze. Dazu habe ich dailyme so eingestellt, daß Downloads nur im WLAN-Betrieb und bei 100% Akkukapazität erfolgen.

Andere Variante:

[...]

Was nun eleganter oder leichter verständlich ist, dürfte eher persönliche Geschmackssache sein.

OK, d.h. es gibt tatsächlich keine "richige" Möglichkeit, sondern nur solche "Workarounds"... schade eigentlich, aber egal, immerhin geht es ja "irgendwie"... Danke für Deinen Input.

 

[mobil_z]

Ich habe solche Sachen über eine (globale) Variable gelöst.

Also ein neues Profil, das nur den Lademodus abgefragt und dann entsprechend die Variable %Charge=1 setzt.

Das hat für mich den Vorteil, dass ich das zusätzlich über "IF/IF NOT Variable..." in anderen Tasks oder auch als Status in Profilen auswerten kann.
Zudem wird dadurch die Gefahr verringert, dass sich diverse Profile rein aus technischen Laufzeitgründen im Ablauf überschneiden, was dann entgegen der programmierten Logik seltsame Effekte hervorrufen kann.

 

[stbi]

Ich habe solche Sachen über eine (globale) Variable gelöst.

Also ein neues Profil, das nur den Lademodus abgefragt und dann entsprechend die Variable %Charge=1 setzt.

Hmm, und wie reagierst Du auf Änderungen dieser Variable?

In meinem Fall wären es ja dann 2 Variablen, auf die das Profil reagieren müßte: %Charge und %Display. Der Enter-Task müßte also losrennen, wenn %Charge=1 oder %Display=1 ist. Was wäre der Vorteil gegenüber dem direkten Abfragen des Status?

 

[mobil_z]

Der Vorteil von Variablen ist für mich, dass ich sie auch innerhalb von tasks auswerten kann.

Zu deiner Zielstellung gibt es z.B. ein Problem, was daran liegt, Tasker beim beenden eines Profils den Ausgangsstatus für WiFi wieder herstellt, auch ohne Ausgangs-Task.
Szenario:

Disp ist an - Wifi an
Während dessen: Gerät lädt - WiFi (bleibt) an
Dann Disp aus - WiFi aus (vorheriger Zustand bei Verlassen des Disp-Status) obwohl Gerät noch lädt.

Der ursprüngliche Beitrag von 08:54 Uhr wurde um 09:19 Uhr ergänzt:

Ich habs mal zusammengeschrieben, wie es laufen sollte.
Inhalt kopieren, als XML speichern und in Tasker importieren.

<TaskerData sr="" dvi="1" tv="4.0u2">
<Profile sr="prof153" ve="2">
<cdate>1367910120164</cdate>
<clp>true</clp>
<edate>1367910548560</edate>
<id>153</id>
<mid0>174</mid0>
<mid1>262</mid1>
<State sr="con0">
<code>123</code>
<Int sr="arg0" val="1"/>
</State>
</Profile>
<Profile sr="prof195" ve="2">
<cdate>1367910246388</cdate>
<clp>true</clp>
<edate>1367910472588</edate>
<id>195</id>
<mid0>196</mid0>
<mid1>202</mid1>
<State sr="con0">
<code>10</code>
<Int sr="arg0" val="0"/>
</State>
</Profile>
<Project sr="proj0">
<cdate>1330603220795</cdate>
<name>Testbereich</name>
<pids>195,153</pids>
<tids>202,196,262,174</tids>
<Img sr="icon" ve="2">
<nme>hd_content_merge</nme>
</Img>
</Project>
<Task sr="task174">
<cdate>1367910128680</cdate>
<edate>1367910437690</edate>
<id>174</id>
<Action sr="act0" ve="3">
<code>425</code>
<Int sr="arg0" val="1"/>
</Action>
<Action sr="act1" ve="3">
<code>547</code>
<Str sr="arg0" ve="3">%Disp</Str>
<Str sr="arg1" ve="3">1</Str>
<Int sr="arg2" val="0"/>
<Int sr="arg3" val="0"/>
</Action>
</Task>
<Task sr="task196">
<cdate>1367910254746</cdate>
<edate>1367910313678</edate>
<id>196</id>
<Action sr="act0" ve="3">
<code>425</code>
<Int sr="arg0" val="1"/>
</Action>
<Action sr="act1" ve="3">
<code>547</code>
<Str sr="arg0" ve="3">%Charge</Str>
<Str sr="arg1" ve="3">1</Str>
<Int sr="arg2" val="0"/>
<Int sr="arg3" val="0"/>
</Action>
</Task>
<Task sr="task202">
<cdate>1367910327489</cdate>
<edate>1367910472588</edate>
<id>202</id>
<Action sr="act0" ve="3">
<code>425</code>
<lhs>%Disp</lhs>
<op>2</op>
<rhs>1</rhs>
<Int sr="arg0" val="0"/>
</Action>
<Action sr="act1" ve="3">
<code>547</code>
<Str sr="arg0" ve="3">%Charge</Str>
<Str sr="arg1" ve="3">0</Str>
<Int sr="arg2" val="0"/>
<Int sr="arg3" val="0"/>
</Action>
</Task>
<Task sr="task262">
<cdate>1367910489187</cdate>
<edate>1367910548560</edate>
<id>262</id>
<Action sr="act0" ve="3">
<code>425</code>
<lhs>%Charge</lhs>
<op>2</op>
<rhs>1</rhs>
<Int sr="arg0" val="0"/>
</Action>
<Action sr="act1" ve="3">
<code>547</code>
<Str sr="arg0" ve="3">%Disp</Str>
<Str sr="arg1" ve="3">0</Str>
<Int sr="arg2" val="0"/>
<Int sr="arg3" val="0"/>
</Action>
</Task>
</TaskerData>

 

[stbi]

Moin zusammen,

o-ha, wo issn der eine Beitrag? - Wollte gerade antworten, daß da ja genau die von mir eingangs vorgeschlagene Umgehungslösung ist.

Der Vorteil von Variablen ist für mich, dass ich sie auch innerhalb von tasks auswerten kann.

Mache ich da, wo ich es brauche, ja auch. Z.B. setze ich eine Variable %NearKnownCell auf "yes", wenn ich mich in der Nähe einer bekannten Mobilfunkzelle befinde, oder "no", wenn nicht. Der Task "WifiOnEx" schaltet dann W-LAN nur dann ein, wenn diese Variable auf "yes" steht. Allerdings ist diese Variable kein Auslöser, um irgendwas zu schalten, deshalb genügt es, nur den Zustand der Variablen innerhalb von Tasks auszuwerten. Bei Display und Power genügt das nicht, bzw. bringt mir keinen Vorteil.

Zu deiner Zielstellung gibt es z.B. ein Problem, was daran liegt, Tasker beim beenden eines Profils den Ausgangsstatus für WiFi wieder herstellt, auch ohne Ausgangs-Task.

Szenario:

Disp ist an - Wifi an
Während dessen: Gerät lädt - WiFi (bleibt) an
Dann Disp aus - WiFi aus (vorheriger Zustand bei Verlassen des Disp-Status) obwohl Gerät noch lädt.

Das passiert aber so nicht, wie Du es beschrieben hast - WiFi bleibt auch an, wenn das Gerät geladen wird und nach einer Zeit das Display ausgeht. Erst wenn beide Bedingungen erfüllt sind (Power ab UND Display aus), wird der Task zum Ausschalten von WiFi ausgeführt. (Dieser schaltet WiFi in meinem Fall übrigens nicht sofort aus, sondern erst nach einer Verzögerung von 2 Minuten).

 

[mobil_z]

Das passiert aber so nicht, wie Du es beschrieben hast - WiFi bleibt auch an, wenn das Gerät geladen wird und nach einer Zeit das Display ausgeht. Erst wenn beide Bedingungen erfüllt sind (Power ab UND Display aus), wird der Task zum Ausschalten von WiFi ausgeführt. (Dieser schaltet WiFi in meinem Fall übrigens nicht sofort aus, sondern erst nach einer Verzögerung von 2 Minuten).

Wenn du keinen Exit-Task anlegst, stellt doch Tasker das vorherige Setup wieder her, wenn ich nicht irre.
Du löst das Ausschalten über eine separate Auswertung, was dann mit dem automatischen Rücksetzen durch Tasker kollidieren könnte.

Wenn du es so machst, wie ich oben zusammengschrieben habe, also über Exit-Tasks zu jedem Status und gegenseitiger Variablen-Abfrage, sparst du dir auf jeden Fall die dritte Auswertung.

...aber es gibt wie immer viele Wege...
Ich bevorzuge diesen, denn im Laufe der Jahre habe ich diverse Projekte, auch für Zeitsteuerung/Auto/Navi/BT/Ladung usw kombiniert, da hat es sich für mich bewährt, immer wiederkehrende Dinge als globale Variable abzulegen und schnell und einfach an jedem Ort in den Tasks auszuwerten.
Die oftmals seltsamen Auswirkungen bei Überschneidungen von Profilen konnte ich damit am besten minimieren.

Der ursprüngliche Beitrag von 11:00 Uhr wurde um 11:01 Uhr ergänzt:

Dieser schaltet WiFi in meinem Fall übrigens nicht sofort aus, sondern erst nach einer Verzögerung von 2 Minuten.

Was mir dazu noch einfällt:
Was passiert bei dir, wenn sich innerhalb der 2 min Verzögerung ein Status wieder ändert?
Wird dann das Abschalten trotzdem vorgenommen?

...könne man umgehen, wenn man zum Ende der Wartezeit nochmals die Variablen prüft, ob das noch relevant ist.

Mit diesem WAIT-Befehl hat es so seine Tücken, denn der Task läuft danach weiter, egal, ob die Ausgangsbedingungen noch erfüllt sind oder nicht.

 

[stbi]

Moin mobil_z,

Wenn du keinen Exit-Task anlegst, stellt doch Tasker das vorherige Setup wieder her, wenn ich nicht irre.

Keine Ahnung; in meinem Wifi-Profil verwende ich einen Enter- und einen Exit-Task.

Aber stimmt: ein anderes Profil von mir, das bei eingestöpseltem Headset alle Benachrichtigungstöne ausschaltet (wenn ich Musik höre, will ich nicht durch Töne belästigt werden!), besteht nur aus einem Enter-Task und stellt nach Beendigung des Zustandes (Headet eingestöpselt) den Ausgangszustand (Töne wieder an) von selber wieder her. Hier besteht der Enter-Task aber auch aus nur einer einzigen Aktion, nämlich dem Einschalten des Silent Mode. Wie es sich aber bei komplizierteren Tasks verhält, wo das Einschalten irgendwelcher Funktionen von einer Reihe anderer Bedingungen abhängt, habe ich bisher noch nicht getestet.

Was passiert bei dir, wenn sich innerhalb der 2 min Verzögerung ein Status wieder ändert?
Wird dann das Abschalten trotzdem vorgenommen?

Natürlich nicht. Der Enter-Task killt den Exit-Task und umgekehrt - somit gibt es keine Konflikte. Das Profil habe ich bisher über 1 Monat täglich in Benutzung und bisher funktioniert es perfekt.

...könne man umgehen, wenn man zum Ende der Wartezeit nochmals die Variablen prüft, ob das noch relevant ist.

Ja, das wäre eine Möglichkeit, finde ich aber zu umständlich, weil man dabei zu viel beachten muß. Wenn man z.B. später noch eine weitere Variable hinzufügt, muß man daran denken, sie dort auch noch abzufragen. In meinem Fall (also ohne Variablen) brauchte ich nach Hinzufügen der zusätzlichen Bedingung "Power Any" (mit negierter Logik und vertauschten Enter- und Exit-Tasks, um das "ODER" zu simulieren) an den Tasks selbst überhaupt nichts zu ändern.

Mit diesem WAIT-Befehl hat es so seine Tücken, denn der Task läuft danach weiter, egal, ob die Ausgangsbedingungen noch erfüllt sind oder nicht.

Deswegen ja das gegenseitige Gemetzel. Damit das gegenseitige Killen funktioniert, ist es allerdings notwendig, in den Profil-Eigenschaften die Option "Enforce Task Order" zu deaktivieren. (Details zu meinem Wifi-Profil siehe hier.)

 

[Servernexus]

Eine Oder Verknüpfung in dem Sinn gibt es nicht.
Aber die gleiche Wirkung erzielst Du wenn du 2 Bedingungen verknüpfst allerdings mit Negierung. Beispiel a oder b=c ist das gleiche wie a nicht und b nicht ist gleich c nicht. Das heist also du musst die Kontext auf nicht abfragen und den Task der ausgeführt werden soll in den Exit Task packen. Hoffentlich verständlich ausgedrückt.

 

[Rak]

Ist das nicht das, was stbi bereits so macht - siehe erster Beitrag letzter Absatz?

 

[Servernexus]

sorry in der Schnelle überlesen.

 

[salti]

Ich hätte einfach 2 Profile mit den gleichen Tasks erstellt

Gruß
Salti

 

[stbi]

Die wären sich aber gegenseitig ins Gehege gekommen...

--
Getapadingst von meinem Bums