Tasker Profile intermittently not triggering

SharpTools.io (web) Legacy Tasker/Widgets
1

Hello,
I’ve noticed that at random times all my profile triggers stop working.
When I check, the events are triggered in both SmartThings & SharpTools (main app), but the trigger doesn’t come through in Tasker (I set up a profile that catches all changes from SharpTools and responds with a toast).
Just as randomly as it stops working, it starts working again.
For the record, this is running on an Amazon Fire Tablet with the persistent notification.
Are there any tests I can do/logs I can provide to help resolve this issue?
Thanks,
Ryan

2

This could be a key contributor. The Tasker Event triggers in the SharpTools Tasker Plugins rely on Google’s Firebase Cloud Messaging for events to be delivered. Since Google Services don’t come with a Fire Tablet, I’m guessing that it has been side-loaded onto your tablet?

You could try the steps in the following article to improve the reliability of event receiving by making sure both Tasker and SharpTools are deoptimized with any battery saving features, but the issue could fundamentally just be related to Google Play Services not playing well on the Fire tablet.

Edit: I’m not sure exactly how this would apply on a Fire tablet. I just took a look and the Fire tablet I checked doesn’t seem to have the same options (the newest Fire Tablets that have a newer OS might have this setting though)… the device I checked does have some similar options around battery saving and Smart Suspend that you might want to disable for troubleshooting

An alternative approach you could try would be to use Pushbullet or Pushover to get the events to Tasker. Each of those apps has an integration with SmartThings and Hubitat and also has a Tasker integration. They’re both 100% focused on push events, so they might have some tricks up their sleeves to more reliably deliver events to the devices. Though they both still fundamentally rely on Google’s push event service as all, so they might be subject to the same issues.

3

Thank you for your quick reply.
I believe I already disabled Smart Suspend, but will double check.
When the main app is open, changes seem to be reported there consistently, even when Tasker doesn’t see them. I have the app set to refresh every 5 seconds when opened; is there a way to force polling every few seconds within Tasker?

4

The main app polls SmartThings for updates. The original version of the main UI didn’t actually display any data as it was primarily just a stopping point for setting things up before using it in Tasker… over time people asked for a basic UI to be added, so I added the interface you see now, but kept it simple with basic polling as it wasn’t expected to be used as the primary interface for interacting with SmartThings.

The event integrations with Tasker use events that are pushed down to the device.

–

What are you trying to setup in Tasker? Perhaps there’s an alternative approach that would work for you.

5

I have a simulated switch that I use to trigger a tasker task which sends a particular UDP command…

6

Have you tried Pushbullet or Pushover?

7

Will give them a try and see if they give more consistent results…

1 Like
8

I tried out Pushbullet, but unfortunately due to it also relying on Google Services the results are much the same.
I made a work-around which so far seems to be doing well:
I have a separate task that runs periodically to check the current status of the “thing”, and compares it to a User Variable; it then executes the correct UDP comand if the two variables do not match.

1 Like
10

Generally, I would try to avoid frequent polling if you can.

If you want to go event driven, you could consider using something like the AutoRemote Tasker plugin which can spin up it’s own local HTTP server on your LAN and your hub can communicate directly with it.

I did something similar in Hubitat with the following driver:

It could easily be modified to work in SmartThings - I think it just needs the tile definitions so you can use it in the SmartThings mobile app.

11

Thanks for the suggestion.
Do you mean:
When SmartThings Device is on, send command to AutoRemote to trigger task?
Doesn’t that also rely on Google Services, so the same issue would be present?

12

This particular implementation acts like a switch, so you can turn it on from any normal SmartThings SmartApp or automation and it sends the event to your device running Tasker using AutoRemote. So yeah, basically sending a command to AutoRemote to trigger the task.

This integration communicates over HTTP directly on your LAN. It communicates straight from your Hub to the Android device running AutoRemote… and straight from the Android device to your Hub.

13

That sounds perfect; will look into it and report the result here.
Thanks Josh!

14

It’s been a while since I originally set this up, but here are some tips from what I remember:

  • Install the device handler code, then manually create a device using this DTH
    • After creating the device, edit the preferences and set the Device IP address and Default Command accordingly
    • The Device IP address should be the IP address of your Android device running AutoRemote - make sure to reserve a static IP address for it
    • The Command can be whatever you want and is what is used in the AutoApps command filter below - for example, I used whitenoise since I was turning on the whitenoise on my son’s tablet
  • Setup a Tasker Profile triggered by Device Boot which runs the Plugin > AutoRemote > Wifi
    • Check the box next to Wifi Service and the box next to Persistent Notification
  • Setup a Tasker Profile triggered by Event > Plugin > AutoRemote > AutoRemote
    • Set the Message Filter to match the ‘command’ that was configured in the device instance above
    • The resulting on or off command will get stored to %arcomm by default
      • You can optionally edit Advanced > Command to rename this variable
  • If you’re not using any of the remote push features of AutoRemote, you can uncheck the box for ‘Active’ in the AutoRemote app settings.
    • This turns off the normal AutoRemote cloud communication features which aren’t necessary since we’re just using the built in LAN stuff.
15

I tried this on SmartThings and realized the code needed to be updated a bit to work with SmartThings.

Here’s a tweaked version of the device handler for SmartThings:

1 Like
16

It seems to work perfectly! Thanks for your help, Josh.

1 Like