Hello everyone,
I want an event to trigger such that whenever a text is shared from any app (context) by using the SHARE button , say Chrome browser or Opera mobile, a sound should PLAY (task). how do I achieve the event trigger?
Many thanks for helping.
The plugin AutoInput has a "UI Action" Event trigger, that you can configure to detect anything that is clicked on in the AI, then in the linked task you can check its "name" or "id" in the variable %aitext or %aiid,
However, to prevent the Event from triggering anytime you press anything all day long, you should add an "App" context to the Profile to constrain it to a list of particular apps (even if its 10 different ones etc) since you'll also need to figure out in those apps if the Share button(s) have a common/same name or ID, or if in the Task you're going to need to look for one of several values in those variables mentioned above.
Ratchet_Guy said:
The plugin AutoInput has a "UI Action" Event trigger, that you can configure to detect anything that is clicked on in the AI, then in the linked task you can check its "name" or "id" in the variable %aitext or %aiid,
However, to prevent the Event from triggering anytime you press anything all day long, you should add an "App" context to the Profile to constrain it to a list of particular apps (even if its 10 different ones etc) since you'll also need to figure out in those apps if the Share button(s) have a common/same name or ID, or if in the Task you're going to need to look for one of several values in those variables mentioned above.
Click to expand...
Click to collapse
Thank you for the reply.
I actuallly succeded doing the thing with Autoshare. [https://play.google.com/store/apps/details?id=com.joaomgcd.autoshare&hl=en]
1. Taker> Event> Plugin> Autoshare> Command=android.intent.action.SEND (rest all parameters default)
2. Taker> Task> Alert> Beep.
So, whenever I share any data, I automatically hear a beep!
Many thanks!
I would like to change my audio profiles based on different situations:
Audioprofile Normal
Normal audiosettings at daytime, when car is not connected and no meeting in calendar.
Audioprofile Night.
Silent audiosettings at nighttime, but only when I'm at home and car is not connected.
Audioprofile Car
Audioprofile in car when connected to bluetooth. Overwrites every other audioprofile.
Audioprofile Silent
Audioprofiles for meetings and special locations.
Every state has his own variable, like the daytime, the bluetooth connection, my location etc..
So I tought I could combine the variable states in a profile with "Variable Value" and the operator AND:
"[email protected]"
Variable Value
%Day=1
AND
%Meeting=1
AND
%Car=0
Enter Task=Audioprofile Silent
But I read this in the Tasker Wiki:
...
Warning: if you want to trigger on a variable and then take some action which sets the thing the variable represents you should use the Variable Set event instead. A Variable Value state will cause complications when the state exits and tries to restore the value again.
...
With "Variable Set" I can only query the value of one variable. That's not enough for my profiles.
How could I do this? Is the warning still valid?
JasMan78 said:
I would like to change my audio profiles based on different situations:
Audioprofile Normal
Normal audiosettings at daytime, when car is not connected and no meeting in calendar.
Audioprofile Night.
Silent audiosettings at nighttime, but only when I'm at home and car is not connected.
Audioprofile Car
Audioprofile in car when connected to bluetooth. Overwrites every other audioprofile.
Audioprofile Silent
Audioprofiles for meetings and special locations.
Every state has his own variable, like the daytime, the bluetooth connection, my location etc..
So I tought I could combine the variable states in a profile with "Variable Value" and the operator AND:
"[email protected]"
Variable Value
%Day=1
AND
%Meeting=1
AND
%Car=0
Enter Task=Audioprofile Silent
But I read this in the Tasker Wiki:
...
Warning: if you want to trigger on a variable and then take some action which sets the thing the variable represents you should use the Variable Set event instead. A Variable Value state will cause complications when the state exits and tries to restore the value again.
...
With "Variable Set" I can only query the value of one variable. That's not enough for my profiles.
How could I do this? Is the warning still valid?
Click to expand...
Click to collapse
What i would do create individual profiles based on time of day, power supply connection, wifi network connection, bluetooth device connection, etc. Each one of those trigger their own individual task which:
1. Sets a specific variable to "1".
2. Sets other settings specific to that profile (if needed).
3. Performs a separate task that change common settings all profiles share.
Then create exit tasks for each profile to:
1. Set specific variables to "0".
2. Set other settings specific to that profile no longer being active (if needed).
3. Performs that same separate task that changes common settings all profiles share.
The common task should be set up with a series of if/else statements for each condition you want. So if variables time of day and home wifi connected are "1", do this, else do nothing. if car Bluetooth connected set to "1", do this, else do nothing. Etc etc etc.
LeftyGR said:
What i would do create individual profiles based on time of day, power supply connection, wifi network connection, bluetooth device connection, etc. Each one of those trigger their own individual task which:
1. Sets a specific variable to "1".
2. Sets other settings specific to that profile (if needed).
3. Performs a separate task that change common settings all profiles share.
Then create exit tasks for each profile to:
1. Set specific variables to "0".
2. Set other settings specific to that profile no longer being active (if needed).
3. Performs that same separate task that changes common settings all profiles share.
The common task should be set up with a series of if/else statements for each condition you want. So if variables time of day and home wifi connected are "1", do this, else do nothing. if car Bluetooth connected set to "1", do this, else do nothing. Etc etc etc.
Click to expand...
Click to collapse
Thank you for your answer.
That could be a way to do it. I must think about it.
But is the warning still valid? I've a lot of profiles which base on variable states. I never have had any problems with them.
JasMan78 said:
Thank you for your answer.
That could be a way to do it. I must think about it.
But is the warning still valid? I've a lot of profiles which base on variable states. I never have had any problems with them.
Click to expand...
Click to collapse
I could be wrong, but I think it is saying not to trigger based on a variable. Meaning, a variable set to x causes y to happen. You can have a profile set a variable, but can get problems if a variable triggers a profile.
At least I think that's what it's saying...lol
That's exactly what I'm doing. A variable is set to 1, and a profile gets active because it checks the state "Variable Value" of this variable. This works fine for me, also the exit task as soon as the value is not longer 1.
The advantage of this method is, that I need only one profil which checks my location, appointments, bluetooth connection, etc.. The profile then sets the variable e.g. $Appointment to 1, and I can work with this variable in any other profile where I need to check if I've an appointment. If the name of the calendar change, I need only to change the name of the calendar in one profile.
And I can simply combine different variables to complex profiles.
Also, the wiki is old-ish, and not really all that up to date. So it is possible tasker has been updated to fix that issue since it was posted.
I found a good solution for me.
I've created a Tasker task, which checks the needed variables and executes the associated audio profile.
E.g. if %Day=1 then execute the task "Profil Normal", if %BluetoothConnected=Car then execute the task "Profil Car".
To execute the task I created Tasker profiles with the event "Variable Set" for every variable, which I query to choose the right audio profile. I left the value field emtpy, so everty time the variable changed the profile executes my task.
Now every time one of this variables changes, the task, which checks the values of the variables and calls the audio profile task, is executed.
Hi,
I'm new to tasker, i downloaded it like a week ago. So any help will be apreciated.
I want to know if it is possible to make some contexts to trigger a profile (trigger contexts), while others not (they must be true for the profile to get activated, but they must not trigger it (state contexts)).
For example, i want to try this:
- When waze is active and at certain locations (like my home), run and intent to cleanly exit waze.
This is intented so when i arrive at destination, waze gets closed automatically. The problem arises if i'm at home and then open waze to drive somewhere, then it gets closed immediatly. Therefore, i'd like that only the location context triggers the profile.
Is this even possible? I want to create other profiles and task under this premise too.
Regards
Make a profile that only activates on location.
Make a second, separate profile for Waze running.
Method 1:
1. Give a custom name to the Waze profile (necessary), e.g. "Waze is Running".
2. Set the Waze profile to run a dummy task like "wait 10 milliseconds".
3. In the first step of your location task, add a Task > Stop > if %PACTIVE doesn't match regex .*Waze is Running.*
4. After this first step, the location task has to stop Waze.
Alternatively, instead of adding a Task > Stop, you can put the "if condition" in the step that closes Waze. Just change it from "doesn't match regex" to "matches regex".
Method 2:
1. Waze profile sets a global variable like %Waze to yes or 1 when Waze is running (enter task)
2. Waze profile clears the global variable when Waze quits (exit task)
3. Location profile checks %Waze instead of checking %PACTIVE
%PACTIVE contains a list of all currently active profiles, but you can only check for those profiles to which you've given a custom name.
Ok, thanks. I had already started with method 2, the only thing i was missing was the third step.
I think this is a task for the state event "Variable Set". As soon as an variable has changed, the task will be executed once. There is no exit task.
Example:
1. Create profiles which set your location to a variable, e.g. %Location
2. New Profile with event "Variable Set" and the variable %Location
3. If %Location change, execute Task which checks if %Location is equal Home or not. If Home, kill Waze. If not, do nothing.
4. When you are at home and start Waze, it will not get killed because the variable %Location has not changed. Therefore the profile will not be triggered. Only when you left home the variable changes and the task will be executed. When you come back to your home, the task will be executed again.
Thanks!! , this is more consistent and more easily applied to others profiles given the way I handle my profiles and tasks.
Hello guys,
I'm trying to do this in Tasker:
AFTER display OFF
WAIT for x seconds
CHECK if screen OFF
IF yes, activate Power Save task (Kernel Plugin)
IF no, do nothing.
Do this every time display is turned off.
Any help on how to go about it would be appreciated, thanks!
I guess you know about event screen off already...use it. In the task:
WAIT xx
IF current profile is still active:
do your stuff with your plugin
alienyd said:
IF current profile is still active
Click to expand...
Click to collapse
https://tasker.dinglisch.net/userguide/en/variables.html
Checking %PACTIVE can be useful. I have started using it instead of custom global variables, so that I don't need Tasker running in the foreground. The typical recommendation is to match the following, which does not update if you ever happen to change the profile name.
%PACTIVE ~ *,Profile Name,*
In this case there's also a Tasker variable to check, so just testing the following is another possibility.
%SCREEN ~ off
alienyd said:
I guess you know about event screen off already...use it. In the task:
WAIT xx
IF current profile is still active:
do your stuff with your plugin
Click to expand...
Click to collapse
alluringreality said:
https://tasker.dinglisch.net/userguide/en/variables.html
Checking %PACTIVE can be useful. I have started using it instead of custom global variables, so that I don't need Tasker running in the foreground. The typical recommendation is to match the following, which does not update if you ever happen to change the profile name.
%PACTIVE ~ *,Profile Name,*
In this case there's also a Tasker variable to check, so just testing the following is another possibility.
%SCREEN ~ off
Click to expand...
Click to collapse
Thanks a lot for replying guys!
Now, if I understand it right, this should do the trick. (check attached pic please)
Any corrections to be made?
I think a * is typically used before and after the comma to allow the possibility of multiple active profiles, similar to the example.
Sharan A. said:
Thanks a lot for replying guys!
Now, if I understand it right, this should do the trick. (check attached pic please)
Any corrections to be made?
Click to expand...
Click to collapse
I have a question: why do you need both %SCREEN and %PACTIVE? imo PACTIVE should already be enough, it checks if all conditions for your profile still meet after the wait. These conditions are of course not limited to screen state only like the SCREEN. Of course you can use SCREEN. I just prefer PACTIVE for its flexibility.
Also, you should really consider enclosing profile name in the *, as it could eventually come to the point that you have more than one active profile at the same time. Therefore I would recommend ~*Profile_name* too. I never had any problem NOT including the commas though.
alluringreality said:
I think a * is typically used before and after the comma to allow the possibility of multiple active profiles, similar to the example.
Click to expand...
Click to collapse
alienyd said:
I have a question: why do you need both %SCREEN and %PACTIVE? imo PACTIVE should already be enough, it checks if all conditions for your profile still meet after the wait. These conditions are of course not limited to screen state only like the SCREEN. Of course you can use SCREEN. I just prefer PACTIVE for its flexibility.
Also, you should really consider enclosing profile name in the *, as it could eventually come to the point that you have more than one active profile at the same time. Therefore I would recommend ~*Profile_name* too. I never had any problem NOT including the commas though.
Click to expand...
Click to collapse
Oh okay, I didn't see the star in the link that was provided I guess. Will include that.
@alienyd So I re thought about it and now I think, in my case, just the SCREEN usage will be enough.
I have some confusion regarding PACTIVE. Should I match it to the profile that I WANT to activate or is it something else?
Edit: Finally got it working! Check pic please.
http://pasteboard.co/BgYZ2sOC8.png
Thanks again for your support guys!
Sharan A. said:
Oh okay, I didn't see the star in the link that was provided I guess. Will include that.
@alienyd So I re thought about it and now I think, in my case, just the SCREEN usage will be enough.
I have some confusion regarding PACTIVE. Should I match it to the profile that I WANT to activate or is it something else?
Edit: Finally got it working! Check pic please.
http://pasteboard.co/BgYZ2sOC8.png
Thanks again for your support guys!
Click to expand...
Click to collapse
Hi,
just to clear things up, and also to share this trick, which I think is very helpful when using Tasker:
As explained, PACTIVE checks if a profile is active - not only enabled, but all conditions are met.
Imagine this scenario, you have a profile triggered, but want to make sure it was not an accident, like covering proximity, turning upside down, screen on/off.
You have a wait at the beginning of the task of that profile, so when the profile is triggered, first it does nothing, then rechecks if itself is still qualified to run.
Of course it can be used to check other profiles, but I'm just talking about this self checking case here.
alienyd said:
Hi,
just to clear things up, and also to share this trick, which I think is very helpful when using Tasker:
As explained, PACTIVE checks if a profile is active - not only enabled, but all conditions are met.
Imagine this scenario, you have a profile triggered, but want to make sure it was not an accident, like covering proximity, turning upside down, screen on/off.
You have a wait at the beginning of the task of that profile, so when the profile is triggered, first it does nothing, then rechecks if itself is still qualified to run.
Of course it can be used to check other profiles, but I'm just talking about this self checking case here.
Click to expand...
Click to collapse
Oh so that means
%PACTIVE ~ *, profile that I want enabled when screen off (power save),*
So in this case, first it's going to wait x seconds, then it'll check if Display is still OFF (by checking if display off profile is active) and finally it'll run the task that I want. Correct?
Sharan A. said:
Oh so that means
%PACTIVE ~ *, profile that I want enabled when screen off (power save),*
So in this case, first it's going to wait x seconds, then it'll check if Display is still OFF (by checking if display off profile is active) and finally it'll run the task that I want. Correct?
Click to expand...
Click to collapse
no, what you are having is already correct I think.
I was just trying to explain how use PACTIVE in general, not only in your case.
The idea is, when profile A is active, have it do nothing first, than recheck if profile A is still active, to make sure that it was not triggered by mistake, than carry out its actions.
So if you have something like:
(Screen-off-profile)
IF screen is off
DO:
wait
check again, Screen-off-profile is still active? (not accidentally turned off)
do the rest
alienyd said:
no, what you are having is already correct I think.
I was just trying to explain how use PACTIVE in general, not only in your case.
The idea is, when profile A is active, have it do nothing first, than recheck if profile A is still active, to make sure that it was not triggered by mistake, than carry out its actions.
So if you have something like:
(Screen-off-profile)
IF screen is off
DO:
wait
check again, Screen-off-profile is still active? (not accidentally turned off)
do the rest
Click to expand...
Click to collapse
Oh yeah that's what I meant, thanks! Pretty neat trick ?
How about this? Screen off set variable myDISPLAY=off, on screen on set variable myDISPLAY=on
On your profile set an if action
if variable value myDISPLAY=off then...
loogielv said:
How about this? Screen off set variable myDISPLAY=off, on screen on set variable myDISPLAY=on
On your profile set an if action
if variable value myDISPLAY=off then...
Click to expand...
Click to collapse
Thanks, though I've got it working by just using SCREEN!
Sharan A. said:
Oh yeah that's what I meant, thanks! Pretty neat trick ?
Click to expand...
Click to collapse
I tend to stay away from wait tasks as it's a battery CRUSHER and basic bad programming.
Instead, set low lvl variables such as myDISPLAY=off/on/locked/unlocked and myPHONESTATUS=in call/offhook etc and do variable value checks. Or do variable events and activate your profile on the variable set
And then on your low lvl profiles set their priority to extremely high, and add stop actions for entry and exit tasks so that way you're never waiting. Avoid wait tasks and you'll see your battery life jump immediately. Also never do app contexts, as app polling will crush battery too
loogielv said:
I tend to stay away from wait tasks as it's a battery CRUSHER and basic bad programming.
Instead, set low lvl variables such as myDISPLAY=off/on/locked/unlocked and myPHONESTATUS=in call/offhook etc and do variable value checks. Or do variable events and activate your profile on the variable set
Click to expand...
Click to collapse
Is there any battery efficient alternative to WAIT? I'd like to have a window of time before power saver activates.
Sharan A. said:
Thanks, though I've got it working by just using SCREEN!
Click to expand...
Click to collapse
Awesome. Just remember, screen not on isn't the same as screen off, and screen unlocked isn't the same as screen on. I mean those are obvious, but unlocked is an instant event, and sometimes fails to register, especially on a screen off then user turns it right back on. Sometimes Tasker believes the screen is still off, especially if the screen wasn't unlocked, which it wouldn't need to be if it wasn't off for longer than half a second
---------- Post added at 07:09 AM ---------- Previous post was at 07:06 AM ----------
Sharan A. said:
Is there any battery efficient alternative to WAIT? I'd like to have a window of time before power saver activates.
Click to expand...
Click to collapse
Then set TIMERACTIVATE or some such variable to %TIMES+60 (ONE minute from now) and make it activate on a time context of %TIMERACTIVATE
then you're having zero impact on your battery because it's ticking the seconds already built-in, and monitored with %TIMES
Oh yeah, and then set your power saving profile, and your screen on profile to clear the TIMERACTIVATE variable, which in essence disables the profile (it can never activate without the variable set) and your screen off profile to set the variable. Bam. Zero impact
loogielv said:
Then set TIMERACTIVATE or some such variable to %TIMES+60 (ONE minute from now) and make it activate on a time context of %TIMERACTIVATE
then you're having zero impact on your battery because it's ticking the seconds already built-in, and monitored with %TIMES
Oh yeah, and then set your power saving profile, and your screen on profile to clear the TIMERACTIVATE variable, which in essence disables the profile (it can never activate without the variable set) and your screen off profile to set the variable. Bam. Zero impact
Click to expand...
Click to collapse
I'm sorry but is it possible to show this procedure in Tasker? I'm kinda confused since I'm still a newbie. ?
I'm going to guess loogielv may be talking about doing something similar to the following links. In there they use two profiles for their operation. They use one profile to set a time to a global user variable, and they have a second profile activate based on that global user variable.
http://www.pocketables.com/2016/08/tasker-timers.html
http://www.notenoughtech.com/tasker/tasker-timers/
Personally I got away from using global user variables, because the way I was using them required having Tasker running in the foreground. I prefer being able to leave that option off. I would guess Tasker could potentially miss the sort of event mentioned in the links above when not running in the foreground.
I'm not sure if there are ways to do what loogielv was talking about using a local (lowercase) user variable, or if there's another option that would allow me to not use "Wait" and continue to keep from running in the foreground. I figure a loop could potentially use more battery to perform than Tasker's wait. Based on the action descriptions, maybe "Wait Until" could be more battery efficient than "WAIT". It looks like there's also an AutoTools Wait, which the description compares to Tasker's "Wait Until". That's all I could come up with for trying to keep from running in the foreground.
alluringreality said:
I'm going to guess loogielv may be talking about doing something similar to the following links. In there they use two profiles for their operation. They use one profile to set a time to a global user variable, and they have a second profile activate based on that global user variable.
http://www.pocketables.com/2016/08/tasker-timers.html
http://www.notenoughtech.com/tasker/tasker-timers/
Personally I got away from using global user variables, because the way I was using them required having Tasker running in the foreground. I prefer being able to leave that option off. I would guess Tasker could potentially miss the sort of event mentioned in the links above when not running in the foreground.
I'm not sure if there are ways to do what loogielv was talking about using a local (lowercase) user variable, or if there's another option that would allow me to not use "Wait" and continue to keep from running in the foreground. I figure a loop could potentially use more battery to perform than Tasker's wait. Based on the action descriptions, maybe "Wait Until" could be more battery efficient than "WAIT". It looks like there's also an AutoTools Wait, which the description compares to Tasker's "Wait Until". That's all I could come up with for trying to keep from running in the foreground.
Click to expand...
Click to collapse
So, Wait>10 seconds>Until SCREEN ~ off
Correct?
For my waits that last a few minutes I was thinking of setting a local variable (lowercase) to %TIMES + X. Then I was going to use the "Wait Until" action to check if %TIMES was greater than my variable. That way there would always be an end to the "Wait Until" action.
My understanding, based on items like the following, is that if you were to just check for screen off at 10 seconds with "Wait Until" it would keep checking every 10 seconds if the screen was on. Personally that would seem like a potentially bigger issue than using "Wait".
https://www.reddit.com/r/tasker/comments/3cdtjz/can_someone_explain_the_wait_until_task_to_me_it/
EDIT: I see that checking on %qtime has been suggested as another way to keep "Wait Until" from going endlessly, yet %qtime could be interrupted by other tasks
https://www.reddit.com/r/tasker/com...it_until_action_wait/?st=izr2om1x&sh=42e0ae24
http://tasker.dinglisch.net/userguide/en/variables.html