Proximity Sensor context Bug? Android or Tasker?

[Rich D]

@Pent..

For the most part the proximity sensor context works. With the exception of when the profile  has another context that prevents it from firing. In these cases if the second context is not true and you cover the sensor then have the other context go true the sensor context will almost always not fire.  It does seem to work the first few times after reboot or extended period of time that the profile is not triggered. The same is true if you disable a profile with just a sensor context and then enable it with the sensor covered.  This is easy to replicate with the following profile and task.

Profile: Prox Sense (482)
State: Proximity Sensor
State: Variable Value [ %Proxon ~ on ]
Enter: Prox Sense On (564)
A1: Notify [ Title:%TIMES Text:%TIME Icon:null Number:0 Permanent:Off Priority:5 ]

Prox Set (624)
A1: Variable Set [ Name:%Proxon To:on Do Maths:Off Append:Off ]
A2: Wait [ MS:0 Seconds:5 Minutes:0 Hours:0 Days:0 ]
A3: Variable Set [ Name:%Proxon To:off Do Maths:Off Append:Off ]
A4: Flash [ Text:Reset Long:Off ]

In the fist test I ran the 'Prox Set' task with the play button with the proximity sensor covered for the first 5 times and it did not fire. On the fifth time I uncovered and recovered the sensor to show it does work after the initial start of the profile.

In the second test I did a reboot and started the 'Prox Set' task from the play button with the sensor covered. This time on the first try the profile fired. Then it would not fire again with several more tries.. 

This behavior has been verified by other users with other devices.. 

One reason I am leaning toward a Tasker bug is that when I receive a call with the sensor covered (before the call started)  android will turn the screen off every time.   I realize this is a crude comparison , but its all I got...

Here are the logs from test 1 and test 2

[Rich D]

As usual forgot the specs.......  :(

I have a rooted Motorola Droid 4 / Stock ROM   / Tasker  / Version:  4.4u3m  Android version 4.1.2

[Rich D]

Bump..  not sure if you saw this one Pent....

[Rich D]

Bum, bum, ba, bump, bump.......  :)

[Rich D]

Buuuuuummmmmpppp.......

[Rich D]

And yet another bump.....

[Rich D]

Hello....????

I think this thing is broken.....

[Rich D]

Bump.... It would seem my resolve is being tested.... :)

[Scott Miller]

Maybe try using all UPPER case.....you know, SHOUT.

:-)

Scott

[Rich D]

> Maybe try using all UPPER case.....you know, SHOUT.
>

Never been much of a yeller..  :)

It is nice to see this post is not completely invisible.. Now if only Pent could see it..    :(

[Rich D]

Buuummmp....   :)

[Pent]

Sorry Rich, would've responded sooner if I'd noticed it was you posting :-)

The problem with the prox sensor is that various devices have various
different initialization behaviours. I've had to put all sorts
of hacks in to get it to work on various devices in the past and now
it's difficult to work out how changing the code will affect the various
hacks so I tend to shy away from it.

I'll have a look at your scenario when I get a chance, however my advice
would be to leave the prox context in a profile by itself and add another
profile which uses the Profile Status state as a trigger combined with
other things, rather than cause the prox sensor to be often turned on/off.

Pent

[Rich D]

> Sorry Rich, would've responded sooner if I'd noticed it was you posting :-)

Whew.. I was beginning to think you were not responding 'because' you noticed it was me..... :)

>
> The problem with the prox sensor is that various devices have various
> different initialization behaviours. I've had to put all sorts
> of hacks in to get it to work on various devices in the past and now
> it's difficult to work out how changing the code will affect the various
> hacks so I tend to shy away from it.

Well that explains the somewhat erratic behavior.

>
> I'll have a look at your scenario when I get a chance, however my advice
> would be to leave the prox context in a profile by itself and add another
> profile which uses the Profile Status state as a trigger combined with
> other things,

I tested this and it did work however the whole idea of combining the prox context with lower power hungry contexts was to save on battery. So a continuously monitoring the prox sensor kinda defeats the point.

However your advice prompted me to try another approach which actually seems to work perfectly. If I use the prox context in its own profile as you suggested I found I can turn the prox monitoring on and off in the 'set tasker preferences' action. And this works. If the prox sensor is covered and then i set the tasker prox sensor  preference  to on it will be detected as being on and the prox profile goes active every time.   So for me this issue is resolved... 

Thanks for all the great work.....  

Rich..

[Pent]

Hopefully future generations will find this answer :-)

Pent

[Graphic]

Hello Rich,

I am using JB 4.1.2 and Tasker 4.5u1 but i believe this is not relevant since i never had any problems.

 

One reason I am leaning toward a Tasker bug is that when I receive a call with the sensor covered (before the call started)  android will turn the screen off every time.

This behaviour leads me to think it is the option "Turn off screen during calls" in call settings, when you open the phone dialer and press the left lower phone button. It is not present in phone settings menu.

 

I tested this and it did work however the whole idea of combining the prox context with lower power hungry contexts was to save on battery. So a continuously monitoring the prox sensor kinda defeats the point.

It works fine for me, my proximity sensor profiles use a variable. 

When i test things i always run with priority 5 and i never let Tasker open because sometimes profiles will only fire when i go to phone desktop if i run them manually.

I tried your example and it works for me. Try this:

- Add a wait 10 seconds as 1st task

- Cover the sensor

- Run task with priority 5

- Press back until you go to phone desktop

I created proximity sensor profile for calls when i got my phone and it always worked fine unchecking "Turn off screen during calls".

Inside the profile i run 3 actions:

- Wait 500 MS (if i use a lower value it will give me problems because the speakerphone seems to take some time to activate)

- Speakerphone set on (with the conditions i need)

- Secure Settings Lock Screen (with the conditions i need)

I tried using using the action "Run Shell input keyevent 26" to turn off screen but it takes time to execute and makes the profile not work.

[Graphic]

I found I can turn the prox monitoring on and off in the 'set tasker preferences' action.

It only turns off monitoring when screen is off, it will consume battery with screen on.

I tried this again and now it fails, it happens after 1st attempt like you said and i noticed how and why it happens and a way it upates but it is not appliable for normal functioning, don't know if it's possible without Pent touching the code.

The priority and running inside Tasker don't matter.

Test this: create this task and run it manually inside Tasker,

1. Cover the sensor

2. Set %Proxon ~ on

3. Wait 1 second

4. Set %Proxon ~ off

5. Wait 1 second

6. Set %Proxon ~ on

With the sensor covered, press the capacitive button 'back' twice to go to phone home screen.

The profile updates and the sensor is working again. 

If you run this task on home screen it will only update if you go to the vars tab, and if it opens directly on vars tab you need to press other tab, then vars tab and back to home screen.

It does have something to do with variables, and the vars tab updates the sensor when back to home screen.

I actually do not have this problem because this situation would be really rare when i am in a call, but the problem is still present.

[Rich D]

>> I found I can turn the prox monitoring on and off in the 'set tasker preferences' action.
>
> It only turns off monitoring when screen is off, it will consume battery with screen on.

Ahh, yes.. forgot that was a 'display off' setting... :(

>
>
> I tried this again and now it fails, it happens after 1st attempt like you said and i noticed how and why it happens and a way it upates but it is not appliable for normal functioning, don't know if it's possible without Pent touching the code.
> The priority and running inside Tasker don't matter.

Strange, i did a few tests as you recommended before and it worked 8 times in a row. When testing inside tasker at priority 10  it would only work once or twice at the most.

>
> Test this: create this task and run it manually inside Tasker,
> 1. Cover the sensor
> 2. Set %Proxon ~ on
> 3. Wait 1 second
> 4. Set %Proxon ~ off
> 5. Wait 1 second
> 6. Set %Proxon ~ on

I will have to do some more detailed testing later..

>
> It does have something to do with variables, and the vars tab updates the sensor when back to home screen.

Curious.. if this is truly the case perhaps it can be worked around by turning on a dummy profile  with the variable then use a profile active context. (Thinking tasker variables may behave differently)  

>
> I actually do not have this problem because this situation would be really rare when i am in a call, but the problem is still present.
>

What i am looking to do is simply check to see if the proximity sensor is on from within a task. But i would like to be able to turn the monitoring on / do the check / turn monitoring off .

I will post more results when i get a chance to test in detail.... 

Thanks for all the input.