I give up: AutoRemote->Tasker

[technogeezer]

I posted this to the Tasker forum but so far no one has been able to help.

I have two tablets and a smart phone and I see this on all three.  I have tried different algorithms and approaches and all have the same result.

On one tablet, I have Tasker programmed with a task to send eight consecutive HTTP GET messages to AutoRemote on the second tablet.  On the second tablet is AutoRemote and Tasker.  I have a tasker profile that simply triggers on AutoRemote events and appends "%DATE %TIME %armessage" to a file.  I have a similar setup between the first tablet and my smart phone.

The problem is that Tasker is getting repeated messages and (rarely) missing messages entirely.  For example, the first tablet sends the following message data (omitting the entire command for clarity).

data 1 on
data 2 on
data 3 on
data 4 on
data 1 off
data 2 off
data 3 off
data 4 off

The AutoRemote log shows exactly the same thing as above, every time.  However, the Tasker profile-generated log has this (or similar).

data 1 on
data 1 on
data 2 on
data 4 on
data 1 off
data 2 off
data 3 off
data 3 off

This message jumbling is random.  Obviously, AutoRemote is correctly receiving the data, so the entire internet path from the first tablet to the destination devices is eliminated as a suspect.

Here's the profile 'description'.

Profile: Named (70)
        State: AutoRemote [ Configuration:pwd ]
Enter: Update (48)
        A1: Write File [ File:log.txt Text:%DATE %TIME, %armessage Append:On Add Newline:On Continue Task After Error:On ]

The Tasker log shows everything processing correctly and no errors

A question that comes to mind is, how often can AutoRemote send a message to Tasker?  Is there a FIFO or do I need to implement one?

This is driving me crazy!  I'm having a very difficult time believing this is happening only to me.  Has anyone else seen this?

Thanks

[João Dias]

I'll try to replicate this situation but I'm curious: why aren't you using normal AutoRemote messages but rather HTTP GETs?

--
You received this message because you are subscribed to the Google Groups "joaomgcd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joaomgcd+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[technogeezer]

On Tuesday, March 4, 2014 12:16:46 PM UTC-6, joaomgcd wrote:

I'll try to replicate this situation but I'm curious: why aren't you using normal AutoRemote messages but rather HTTP GETs?

Not sure what you are referring to here but I'll try to explain.  On the first tablet I use the HTTP:GET task in Tasker to send "http://goo.gl/<very long ID><my data>" to the second device.  If I use a browser and go to my device's unique AutoRemote webpage, there is a window containing a URL that I can copy and use directly in a Tasker HTTP:GET action.  (But I'd bet you already knew that!)

Or am I misunderstanding?  Are you saying AutoRemote can send as well as receive?

Further, my test setup is simulating a situation where I'm using external hardware which is capable of sending HTTP:GET but not capable of running AutoRemote/Tasker.  The first tablet takes the place of this hardware.  Please note again that the AutoRemote log is ALWAYS correct.

In any case, thanks for your help!

[João Dias]

Yes, AutoRemote can send messages as well as notifications from Tasker. :) That's the "normal" way of doing it. Check the plugins category in the Tasker actions.

If the AutoRemote logs are always correct then that's a good start. I'll try replicating this situation tomorrow. Thanks for the feedback.

[João Dias]

Do you use EG?

Can you try doing this python script in EG while having the AutoRemote plugin installed?

from time import sleep

for x in range(0,10):

    eg.plugins.AutoRemote.SendMessage("","","YOUR LONG KEY HERE", "log=:=test" + str(x))

    sleep(1)

eg.plugins.AutoRemote.SendMessage("","","YOUR LONG KEY HERE", "sendlog")

Then check if Tasker executes things in order (like by writing a log file with %arcomm) and always for the correct values?

I just tried replicate your situation with this but couldn't do it, sorry!

Let me know if you need more help.

Hope this helps figuring stuff out.

[technogeezer]

No, I do not run anything on a PC.  Is it necessary to send messages via AR?  The log shows AR always receives the commands.  They are simply not transferred to Tasker correctly.

I think the queue mechanism between AR and Tasker is highly suspect.  Is there a difference between sending messages via AR and sending via HTTP:GET?  Could there be a synchronization problem on just my platforms (Samsung, Sony and LG)?  Could there be malware on my android devices sucking up CPU cycles and interfering with my processes?  :)

I have tried turning off all other Tasker profiles.  The Tasker log never shows an error.  What else could it be?

I have been experimenting and now find that I get incorrect messages even if I send a single message.  The incorrect message is always the last one missed, even if it's been a day since the last message.  This happens about 80% of the time which, unfortunately, renders AR useless to me.

TX message 1
RX message 1
wait 10 minutes
TX message 2
RX message 1
wait 10 minutes
TX message 3
RX message 2
wait 10 minutes
TX message 4
RX message 4
etc

Is there a way for the user to flush the AR/Tasker queue?  I find that if I reset my device, the first few transfers are always correct.

Thanks

[technogeezer]

Is there anything else I can do to help you help me?

Thanks

[João Dias]

Can you please export the exact profile you're using to do that and let me know the exact messages you're sending? I really can't replicate the situation.

Thanks

[technogeezer]

I very much appreciate your attempting to help me with this unique (and frustrating) issue.

The receiving profile is in my original post above.

This is my current task for sending test data.

SendData (80)
           A1: HTTP Get [ Server:Port:https://autoremotejoaomgcd.appspot.com Path:sendmessage?key=<blah>&message=data 1 on Attributes: Cookies: Timeout:10 Mime Type: Output File: ]

Note that in practice the HTTP:GET messages are sent from a non-phone, non-tablet device connected to the internet.  The above action is simply an easy way to test this functionality since the results are the same as when using the device.  I wonder if the spaces should be %20.  Hmmm...

Thanks so much!

[João Dias]

I thought of something that might be important: what Tasker version are you using?

Thanks

João

--
You received this message because you are subscribed to the Google Groups "joaomgcd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joaomgcd+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[technogeezer]

It would be whatever version was last auto updated on my phone and tabs.

V4.2u3m

Thanks

[João Dias]

Ok.

I've been banging my head against this all day and I think I've finally figured it out.

Can you try this version please?

https://dl.dropboxusercontent.com/u/9787157/apk/AutoRemoteFull.apk

Thanks and hope it works.

João

[technogeezer]

Here's the AR log,

In - 2014-03-11 16:05:23.329 - Received Message from Unknown: Text: "lights 4 off"
In - 2014-03-11 16:05:21.207 - Received Message from Unknown: Text: "lights 3 off"
In - 2014-03-11 16:05:19.010 - Received Message from Unknown: Text: "lights 2 off"
In - 2014-03-11 16:05:16.828 - Received Message from Unknown: Text: "lights 1 off"
In - 2014-03-11 16:05:14.675 - Received Message from Unknown: Text: "lights 4 on"
In - 2014-03-11 16:05:12.492 - Received Message from Unknown: Text: "lights 3 on"
In - 2014-03-11 16:05:10.339 - Received Message from Unknown: Text: "lights 2 on"
In - 2014-03-11 16:05:10.172 - Received Message from Unknown: Text: "lights 1 on"

Here's the tasker log,

3-11-2014 16.05, lights 1 on
3-11-2014 16.05, lights 2 on
3-11-2014 16.05, lights 4 on
3-11-2014 16.05, lights 4 on
3-11-2014 16.05, lights 1 off
3-11-2014 16.05, lights 3 off
3-11-2014 16.05, lights 3 off

It appears the behavior has changed. Previously, entries would repeat. Now they seem to be missed. It's almost as if the entries formerly were late but now they are early. It seems you are close to the problem.

I'm sorry this is such a frustrating issue.

HTH,
Thanks

[João Dias]

Ok, let's give this another try: https://dl.dropboxusercontent.com/u/9787157/apk/AutoRemoteFull.apk

Does it work now? :)

Thanks

[technogeezer]

Success! At least I didn't see any failures during my testing and believe me I tried to make it fail, stacking up ten messages at once.

I can't say for certain yet that the issue is resolved but so far I can certainly say it looks good!

May I ask for a brief description of what the problem was?

Thanks so much!

[technogeezer]

Well darn. I just tried it again and it failed. The AR is the same as previously and here is the Tasker log.

3-12-2014 15.50, lights 1 on
3-12-2014 15.50, lights 1 on
3-12-2014 15.50, lights 2 on
3-12-2014 15.50, lights 3 on
3-12-2014 15.50, lights 4 on
3-12-2014 15.50, lights 1 off
3-12-2014 15.50, lights 2 off
3-12-2014 15.50, lights 3 off

Sorry,
Thanks

[João Dias]

Ok, again.... https://dl.dropboxusercontent.com/u/9787157/apk/AutoRemoteFull.apk

I think I've found a way to find out if the problem is from AutoRemote or Tasker itself.

I've added a new variable that you can use:  %artime

This will let us know the time that the profile was matched and the action triggered supposedly.

If this value always has the correct time, then the problem is in AutoRemote and I have to keep looking.

If this value sometimes has an earlier incorrect time then Tasker is the problem.

Let's see what happens.

Thanks

[technogeezer]

In - 2014-03-13 15:40:28.399 - Received Message from Unknown: Text: "lights 4 off"
In - 2014-03-13 15:40:26.289 - Received Message from Unknown: Text: "lights 3 off"
In - 2014-03-13 15:40:24.194 - Received Message from Unknown: Text: "lights 2 off"
In - 2014-03-13 15:40:22.064 - Received Message from Unknown: Text: "lights 1 off"
In - 2014-03-13 15:40:19.954 - Received Message from Unknown: Text: "lights 4 on"
In - 2014-03-13 15:40:17.836 - Received Message from Unknown: Text: "lights 3 on"
In - 2014-03-13 15:40:15.666 - Received Message from Unknown: Text: "lights 2 on"
In - 2014-03-13 15:40:15.404 - Received Message from Unknown: Text: "lights 1 on"

3-13-2014 15.40, Thu Mar 13 15:40:15 CDT 2014, lights 1 on
3-13-2014 15.40, Thu Mar 13 15:40:17 CDT 2014, lights 2 on
3-13-2014 15.40, Thu Mar 13 15:40:20 CDT 2014, lights 2 on
3-13-2014 15.40, Thu Mar 13 15:40:22 CDT 2014, lights 3 on
3-13-2014 15.40, Thu Mar 13 15:40:24 CDT 2014, lights 4 on
3-13-2014 15.40, Thu Mar 13 15:40:26 CDT 2014, lights 1 off
3-13-2014 15.40, Thu Mar 13 15:40:28 CDT 2014, lights 2 off
3-13-2014 15.40, Thu Mar 13 15:40:30 CDT 2014, lights 3 off

I'm curious. I wouldn't have thought something like this would be time dependent. With the proper signals, i.e. data_ready, data_accepted, time really shouldn't play a role.

But hey, I'm just guessing. ;)

Thanks

[João Dias]

The time was just a way to debug if Tasker was storing the wrong values. :) Need to look at this again.

Thanks

[technogeezer]

I should note that I am noticing Tasker running oddly.  For example, if I tap a task icon on my home screen, sometimes it takes several seconds before the task's scene will open.  Other times, the scene opens nearly instantaneously. This random slowness occurs on many Tasker related operations, even when opening the Tasker app itself. This occurs on all three devices.

Thanks

[technogeezer]

I uninstalled and then reinstalled Tasker, and the slowness is now gone.  Unfortunately, the issue with AR remains.

Thanks

[João Dias]

Thanks for the feedback. Still trying to figure out what the problem is.

On Tue, Mar 18, 2014 at 2:15 PM, technogeezer <spider...@gmail.com> wrote:

I uninstalled and then reinstalled Tasker, and the slowness is now gone.  Unfortunately, the issue with AR remains.

Thanks

[technogeezer]

Have you been able to reproduce the problem?

Thanks

[João Dias]

Nope, not yet.

On Tue, Mar 18, 2014 at 6:37 PM, technogeezer <spider...@gmail.com> wrote:

Have you been able to reproduce the problem?

Thanks

[technogeezer]

I am stumped.  For me, it happens almost every time.  On my scene, I've put a test button that sends the commands to AR using HTTP:GET messages.  I press the button and four sets of on/off are sent.  I can see the results in real time.  At least one command of the eight is missed every time.

Do you think it would help to uninstall and reinstall AR?  Doing that for Tasker helped.  Will reinstalling AR otherwise harm anything?

Thanks

[Mike Wilson]

Not sure if this is related or not, but it sounds like it could be.  I'm trying to use AR between my Galaxy S4 and my Nexus 7.  Sometimes it works fine, but most of the time I have a wide range of problems:  messages not going through(i.e.retry until failure), messages, sent but not received (as shown by in/out toasts), message seemingly stuck in space somewhere only to show up in bunches at some later time, and so on).

In my case, I'm trying to communicate exclusively through Bluetooth by tethering my tablet to my phone.  I have wifi disabled in AR for both devices and have checked all the preference boxes that tell AR to skip using wifi.  But just a minute ago, the pair got into some sort of messaging war (which seemed to be an example of the piled up messages) even though the Bluetooth tethering was not active and, in fact, Bluetooth was completely disabled on the tablet, so it had to be going through wifi.

I never see any errors in the Tasker log, and the AR logs show nothing other than the expected sucess/no success listings.

I'm a bit stumped too.  When it works, it works well, it just doesn't seem to be consistent.

Thanks.

Mike

[Mike Wilson]

I should have mentioned that I'm just using plain AR messages, not HTTP.

[technogeezer]

Thanks for your input. At least I'm not alone seeing these symptoms.

I should try using AR to send the messages, just to see if there's a difference.

Thanks

[technogeezer]

I tried using the AR plugin to send the messages but I get the same error.

Thanks

[Mike Wilson]

Well, I seem to have made a bit of progress, but I think part of the problem might have been the environment I was working in.  I discovered that the "message war" I mentioned earlier was due to a Tasker profile that monitors my Bluetooth connection to my phone; it was constantly triggering, even though the connection had been made and was solid. 

 

However, this was in my office, where the wireless access point for the internet sits about three feet above my workstation.  At home, where I have somewhat weaker signal, things were working much better.  I'm still having a few failures (primarily messages sent, but not received) but I'd estimate I had about an 80% success rate.

I had heard that the Nexus sometimes has interference problems between Bluetooth and WiFi and I wonder if that might not have been a contributing factor, even though WiFi was technically turned off.  I'll test this hypothesis in the morning. 

 

[technogeezer]

On Wednesday, March 19, 2014 11:24:04 AM UTC-5, Mike Wilson wrote:

Not sure if this is related or not, but it sounds like it could be.  I'm trying to use AR between my Galaxy S4 and my Nexus 7.  Sometimes it works fine, but most of the time I have a wide range of problems:  messages not going through(i.e.retry until failure), messages, sent but not received (as shown by in/out toasts), message seemingly stuck in space somewhere only to show up in bunches at some later time, and so on).

Mike,

You probably know this but that last symptom you mention above, with messages arriving in bunches at a later time - that is not uncommon on the internet.  I see delays of varying lengths all the time, from almost instantaneous to ten seconds or more.  It depends on the traffic at every router/server/computer your message passes through.  I've also heard of Google difficulties with different ports or some such.

The reason I know my issue is related to AR/Tasker is because my AR-triggered Tasker task writes all incoming messages to a file which I then compare to the AR log.  For me, the AR log is *always* correct but the %armessage variable written to the log by the Tasker task is often incorrect.

HTH

[Mike Wilson]

Yes, I've experienced that as well.  I was hoping that since I was using a direct Bluetooth tether to communicate that the messages would pass directly between the devices, but it seems that isn't the case.

This, morning I can't seem to connect from the tablet to the phone.  The tablet says it sent the message but it doesn't arrive at the phone.  But going from the phone to the tablet is working.  New day, new problem.

[Mike Wilson]

And...now it's gone the other way; the table can send messages to the phone, but messages sent from the phone never arrive at the tablet.

[Federico]

I also experience this bug.

AutoRemote logs have the correct message in them, but Tasker is usually one step behind.

I mean: I have to send the same message to AR a couple of times to get it in Tasker, otherwise I pretty always get the previous one.

AR logs, as said, are ok (different -correct- message every time).

I noticed that if I keep the AutoRemote App in the foreground the problem is somehow reduced.

[technogeezer]

I should add that having purchased AR in January, I don't remember any issues at all until mid February.  IIRC, there were two each AR and Tasker updates within a few days of each other.  I'm guessing something in one of those updates broke AR->Tasker handshaking under certain circumstances.

Thanks

[fede...@quagliata.org]

technogeezer wrote:

> I should add that having purchased AR in January, I don't remember any issues at all until mid February.  IIRC, there were two each AR and Tasker updates within a few days of each other.  I'm guessing something in one of those updates broke AR->Tasker handshaking under certain circumstances.
>
> Thanks

Yeah, pretty much the same bug timeline for me.

[technogeezer]

Hi joaomgced,

Are you working on this?  Is there a status?

I fully understand that three customers may not be enough critical mass to justify spending a lot of time on a problem you can't reproduce.

Please let me know the status of this issue so I can pursue other means if necessary.

Thanks

[João Dias]

Yes, I am, sorry.

I still haven't figured it out, but I'll keep trying. Sorry about that. I've recently found a bug in a part of my code that might influence it. I'll send a version with the fix tomorrow to see if it changes anything.

[João Dias]

Ok, here's a new verison. Please let me know if this one works (fingers crossed)

https://dl.dropboxusercontent.com/u/9787157/apk/AutoRemoteFull.apk

[technogeezer]

Thanks for the update. Unfortunately, there are still errors. It took several tries but once the first error occurred, several more followed.

HTH,
Thanks

[João Dias]

Ok, new try

https://dl.dropboxusercontent.com/u/9787157/apk/AutoRemoteFull.apk

Btw, do you know how to look at logcat? Can you maybe see if you can check the AutoRemote logcats?

Thanks and again, sorry for this.

Thanks

[technogeezer]

Hi joaomgcd,

Sadly, this was the worst yet, failing immediately and often, as much as three out of four messages.

No, I do not know how to look at logcat but if you point me to a wiki or similar I can figure it out.  I know what logcat is from reading the android sdk but how do I access it for AR?

Thanks

[João Dias]

I think you can only look at app's logcats if you have root. Do you have root?

Also, if you send messages 10 seconds apart, does it work properly?

[technogeezer]

No, I am not rooted but I do have eclipse/SDK on my computer.  I've been reading a bit but I still don't understand how I can look at AR's logs.

I ran five groups of eight messages with ten seconds between each message without a single error.  That was more than enough repetitions to get errors with previous versions.  OTOH, all the tests on previous versions were conducted with no waits between messages.

Thanks

[João Dias]

Thanks again.

If you run the Eclipse Android Development version, choose window from the menu above -> Show View-> Other -> and filter by "logcat".

The run AutoRemote and (hopefully) you should start seeing some logs appear in the logcat window.

Can you see that?

[technogeezer]

OK, I'll try that when I get some time.  What am I looking for?  In my experience, those logs can be fairly large, too large to post here!

Thanks

[João Dias]

Anything that comes from AutoRemote will be useful, so where the application is "com.joaomgcd.autoremote".

On Tue, Apr 1, 2014 at 11:59 AM, technogeezer <spider...@gmail.com> wrote:

OK, I'll try that when I get some time.  What am I looking for?  In my experience, those logs can be fairly large, too large to post here!

Thanks

--

[technogeezer]

DDMS was the only way I could connect to a device.  Even then, my tablet was not recognized.  My phone was recognized but running my AR test did not dump anything with 'autoremote' in it.  No application ever showed up in logcat.  Am I doing something wrong?

The last version of AR that you posted works for my current application, i.e. as long as there is a good delay between messages.  It doesn't really give me a warm-n-fuzzy feeling, though.  :(

What else can I do?

Thanks

[João Dias]

Thanks for testing again.

There's another user that said that the latest version fixed these problems for him. You are absolutely sure that you have the latest version from here right? https://dl.dropboxusercontent.com/u/9787157/apk/AutoRemoteFull.apk

I just hoped that logcat would show AutoRemote messages but apparently that's not the case. I'll try and see what's up. thanks!

João Dias

[technogeezer]

Yes, I am absolutely certain I have the version you specify.  I can see it in my downloads folder.

I want to reiterate that this latest version works perfectly as long as there is ample time between messages.  It is only when messages are sent in rapid succession that errors occur.  Messages are dropped or repeated.  However, messages are always in roughly the correct order.

Thanks

[João Dias]

Even if you have it in your download folder, you need to re-download the file to make sure that you got the latest version. :) Can you please just try re-downloading again today just to make extra sure? Thanks!

[technogeezer]

I downloaded from your link above.  The file was saved as, "AutoRemoteFull-1.apk".  The new file was exactly the same size as the older one. The install executed with no error.

I then verified that as long as there is ample time between messages, all messages are received perfectly.  If messages are sent in rapid succession, many are missing or repeated but the order is roughly correct.

Thanks

[João Dias]

thanks. I guess I'll have to keep digging then. Sorry!

[Hussain]

What is the Collision Handling status in your task? If it has been set to 'Abort New Task', can you change it to 'Run Both Together'? I think that should resolve your issue. I had a similar problem and upon deeper information, I realised that my task's Collision Handling was to blame.

[Federico]

I tried to change Collision Handling.

I still have the same problem as technogeezer and waiting between messages helps.

I confirm I also don't see anything in logcat from autoremote except for the GCM event.

[João Dias]

Do you guys have Logcat set to verbose? I set the messages to that level.

[technogeezer]

Verbose is my default setting.

I changed the collision handling for this task to 'Run Both Together' as Hussain suggested above.  So far, all messages are received and in the correct order.

I am using the same test as I reported in my original post above.  There is no waiting between messages.  The test consists of running a task that sends eight messages in rapid succession using HTTP:GET.

In addition, as a 'worst case scenario' I started my test task and once I saw the first message arrive I started the task again.  All sixteen messages were received and in the correct order.  I performed this procedure many times with no errors.

Does this qualify as 'fixed'?

Thanks

P.S. Federico, did you install the latest .apk above?

[João Dias]

Well, it looks like everything's working right? :) that is great news!! That's a huge weight off my back right there!

[technogeezer]

Yes, all appears to be well.  However, and not to ruin your day, but the fix does appear to require that last .apk that you posted above.  Do you intend to include that change in an actual release?

Thanks

[João Dias]

Yes, I sure do!

This was just to keep testing util it worked. :) I can now release it to the public (or at least in the beta channel)

Thanks for all the testing!!

On Fri, Apr 11, 2014 at 3:24 PM, technogeezer <spider...@gmail.com> wrote:

Yes, all appears to be well.  However, and not to ruin your day, but the fix does appear to require that last .apk that you posted above.  Do you intend to include that change in an actual release?

Thanks

[technogeezer]

No problem.  Yours is the kind of customer service I wish I could experience for all products I purchase.

I am overall very pleased with your apps.  In fact, I just ordered a Chromecast (via your web page) and purchased both AutoCast and AutoShare.

Keep up the good work!

Thanks

[João Dias]

Oh awesome! :D You're only the second person to do that, so I really appreciate it :) Thanks again!

[technogeezer]

You are going to think me crazy.  Remember that Federico said he still saw the problem.

After sitting for a couple of hours, I ran my 16 message test three times.  Each time, the fourth message was dropped.

I'm sorry to bring this bad news but I thought you'd like to know.

It does appear that the frequency of errors is proportional to the time span between uses.

Thanks

[João Dias]

Weird that it's always the 4th message.... Ok, thanks for the report!

[technogeezer]

Well now, here's a bit of good news.

Since the Tasker update, I have not seen a single failure.  At least, not yet.  :)

Thanks

[João Dias]

Oh, nice :) Let me know if it all works everytime now!

[technogeezer]

I have been running my 8 HTTP:GET messages test throughout the day all of a sudden, I get two failures in three tries.

I tried experimenting with setting different delay actions between message actions in the task.  I found that somewhere between 500ms and 1 second the failures go away.

For the above test I assume that actions within a task execute consecutively and that a wait action's time variables can be zero, i.e. %mswait = 500 and %swait = 0, or %mswait = 0 and %swait = 1.

Sorry.  This has got to be frustrating.

Thanks

[João Dias]

It is :/

Oh well...

[João Dias]

Can you please try using the AutoRemote Event instead of the AutoRemote state? Maybe that helps?

[technogeezer]

Sorry, no.  In fact, instead of skipping one or two messages, it skips three or four.

FYI, on my phone, Tasker can run *very* slowly sometimes.  Say I tap a Tasker task icon on my screen.  It can take up to five seconds before the tasks's screen appears.  My phone is a quad core running at 1.7GHz and I don't keep stuff running in the background.

Thanks

[João Dias]

I know it's a bit of work, but what if you disable all AutoRemote profiles except for the one that gives you this wrong behaviour? Does it work then?

Thanks

[technogeezer]

This is the *only* AR profile I run.

Thanks

[João Dias]

Oh really? :O Wow, that's worse than I thought...

On Fri, Apr 18, 2014 at 2:46 PM, technogeezer <spider...@gmail.com> wrote:

This is the *only* AR profile I run.

Thanks

[ajsra...@gmail.com]

I'm having this same problem and I wanted to thrown in my 2 cents.

My issues only started after I upgraded to KitKat. Now, Tasker will sometimes get the message correct, but usually registers the previous message. This is with very long times between messages (an hour or more apart). I've attempted uninstalling/reinstalling both Tasker and AutoRemote, and the other fixes suggested in the thread, but with no luck.

I get that this is an old thread, but wanted to check is anyone made any headway.

[João Dias]

Hi. Can you please try the AutoRemote beta people have been very positive about it solving this issue so far :)

[ajsra...@gmail.com]

Thank you for the suggestion. I'm using the beta now and it is working great so far. I'm cautiously optimistic that it solves my problems.

Thanks again.