Howto: Full control Android device with OH using Tasker

Dear community,

Recently joaomgcd of Tasker has released a beta version of Tasker that comes with an extra (and long waited) feature; The Tasker HTTP Request Event and HTTP Response Action functions.
According to joaomgcd on his reddit channel, this releases a range of new features. I agree!

With these new functions we are not only able to not only receive something from tasker but also send something to tasker. Let`s get busy :grinning:

In this example I will use this new feature to adjust the screen brightness of my tablet running HABpanel without the need of an external service (e.g. myopenhab) or another app (e.g. Fully Kiosk Browser). This is all local from client (OH) to server (tasker)

1) Download and install Tasker Beta
First we need to install the latest beta of Tasker that contains these functions.
The latest beta releases can be found here.
Please note that Tasker is a paid application for Android.

2) Setup Tasker

  • Variable:
    First we will create a Global Variable
    Go to VARS and add (+) a variable called %VarBrightness

  • Tasks:
    Go to Tasks and add (+)
    First task we name: “Request from OH”
    Add action → Variables > Variable Set
    Enter name %VarBrightness
    Enter To %request
    Second task we name “SetBrightnessDisplay”
    Add action → Display → Display Brightness
    Level → click on the two-arrow-icon on the right
    Add %VarBrightness

  • Profiles:
    Now we add two Profiles
    First profile we add (+) event → net → HTTP Request
    Configure this profile by
    adding to Method: GET
    adding to Path /command*
    Tasker wants to link this profile to a task, link it to “Request from OH”
    Add a second profile name “Event VarBrightness change”
    Variables → Variable Set
    Enter %VarBrightness as Variable
    Link this profile to “SetBrightnessDisplay”
    Make sure both profiles are enabled

3) Configure openHAB

Install the exec Binding

Create a script
p.s. I couldn`t get the script started in the script folder so I ended up putting it elsewhere. Depending on the platform you use for openHAB, make sure the script is whitelist and is accessible by OH

#!/bin/bash
# change the IP address to your tasker device
TASKER_URL="http://192.168.88.19:1821/command"
PAYLOAD="$1 $"

# Send the cURL request
curl -X GET "$TASKER_URL" --data "test=$PAYLOAD"

Then we make the script executable by OH

sudo chmod 755 /usr/local/bin/tasker_brightness.sh

Put the script in the whitelist by OH (full path)

/usr/local/bin/tasker_brightness.sh %2$s

Create a thing manually and place it in the things folder, e.g. execute.things

Thing exec:command:ToTasker "Tasker Command Brightness" [ 
    command="/usr/local/bin/tasker_brightness.sh %2$s", 
    interval=0,timeout=10, 
    autorun=true ]

please note that wherever you will put your script, it need to be full path as stated in the how-to by Rich

Create two items:

Dimmer TaskerBrightness "Display tablet Brightness "
String TaskerBrightnessOutput {channel="exec:command:ToTasker:input"}

Create a rule:


rule "Send Command Brightness to Tasker"
when
   Item TaskerBrightness changed
then
      val Number IntBrightness = (TaskerBrightness.state as DecimalType)
      
      //adapt 100% dimming to 8-bit representation
      val Number IntBrightnessNew = ((IntBrightness / 100) * 255).intValue()
      
      TaskerBrightnessOutput.sendCommand(IntBrightnessNew.toString())
end

Now whenever TaskerBrightness is changed, the request will be send over to Tasker and it will act accordingly. As Tasker is a very powerfull tool you could almost control the whole android device from openHAB, which makes it really awesome!

Troubleshooting:
As I am not an software engineer I spent a few evenings on this matter. The exec binding is quite old and this forum has alot of old topics regadering the binding. The full example on the exec binding creates a loginfo like such

 logInfo("Your command exec", "Raw result:" + yourcommand_Out.state )

This gives a lot of insight of what you are actually sending. Please read the docs for this.
I guess it could be done using the HTTP binding awell.

Now tasker is a bit of a strange duck when it comes to logic. If you run into any problems with Tasker, Joaomgcd created a http request example which you can import into tasker as a project. This could provide some insight in how Joaomgcd thinks and thus how Tasker works.

Goodluck!

Thanks for the tutorial. It’s good to see jaomgcd is continuing development of Tasker.

Some screen shots on step 2 I think would be very helpful, particularly to those who are not as familiar with Tasker.

Why not use the HTTP binding? That should be more straight forward.

One gotcha here is that most modern phones use mac address randomization. To ensure that your phone always gets the same IP address, you need to disable that on the phone under wifi settings (it’s configured on an SSID by SSID basis so it’s not turning it off for all networks, just your home network) and configure a reservation in your router so the phone always gets the same address.

Another alternative would be to have Tasker update an Item with the IP address when ever your phone joins the home network which can then be used to conbstruct the URL. If you used that approach, instead of the HTTP binding or Exec binding using sendHttpGetRequest from a rule would probable be the most straightforward approach.

To control your phone even when it’s not at home, you can use a VPN but then you need to keep track of whether the phone is connected locally or via the VPN and use the corresponding IP address.

Yes, I mention this in the last paragraph :slight_smile: I took this path and it worked but both are possible for sure.

Yes, thanks for this clarification. I assume the reader knows some basics of network topology.
They are not Home Assistant users :sweat_smile: , that counts for something right?

I will look into the screenshots. You are right that it would make it easier to set this up correctly!

Is there a way for openHAB to reach Tasker on an Android device that’s not on the same network (ergo, not home)?

No, not directly. You could use an openHAB notification and the Tasker AutoNotification plug-in maybe but that’s going to be quite a bit more complicated of a setup.

You might be able to set something up using AutoShare. It’s been a super long time since I messed with that but I think there is a way to share something using sendHttpXRequests from OH.

AutoRemote may be appropriate here as well. I’ve never used that one but the description seems like it might be relevant.

There is a third party MQTT plugin for Tasker (maybe more) so if you are using a publically available broker that could be an option.

The absolutely easiest thing to do though would be to set up Tailscale. You can create a Tasker profile to automatically connect/disconnect when you are not on your home WiFi. Then your Android devices will always have access to your LAN when away and you don’t have to do anything special in Tasker at all.

And of course, the subject of the original post above shows how to use Tasker to poll openHAB using HTP requests. You’ll have to go through myopenhab.org to do it though.

Okay, I’ll dive into those holes when time allows!

A bit off topic (or maybe not if such a connection is established): is there a way for Tasker to read the state of openHAB Items? The openHAB plugin in Tasker doesn’t seem to offer that feature?

Reverse SSH tunnel — works but fragile on Android (battery optimizer kills it, needs Termux + autostart hacks).

I would suggest Tailscale — easiest by far.

  • Install Tailscale on the openHAB host and on the Android device.
  • Both get a stable 100.x.x.x IP on your tailnet, regardless of network.
  • openHAB’s HTTP binding / sendHttp* actions just hit the Android’s Tailscale IP on the AutoRemote/Tasker HTTP port. No port
    forwarding, no DDNS, works on cellular.
  • Bonus: MagicDNS gives you a hostname like phone.tailnet-xyz.ts.net.

Doesn’t Tailscale get killed by battery optimizer and/or have a negative effect on power usage?

Yes

But you have not stated your purpose. If the android is a wearable/mobile it makes thing a different obviously. The whole reason I started this topic is power on/off the android device as it displayed the openHAB HABpanel.
Having a weareable/moble doing the same thing would not make sense to me, but i could be wrong.

That’s the whole point of this thread. To show how to set up a poling profile in Tasker to pull the state of an OH Item.

JuiceSSH works well and is less complicated than Termux. And you could automate monitoring and relaunch through Tasker (assuming JuiceSSH exposes the right intents or has a plug-in for Tasker. Since I switched to Tailscale I’ve abandonded SSH tunnels. But I published a tutorioal her on the forum a good while back concerning them.

You can exempt Tailscale from being killed by the optimizer.

But nothing comes free. You’ll have batery drain one way or the other. The reason the Android app doesn’t provide a profile trigger based on Item state is because it uses up to much battery.

But if you don’t exempt Tailscale from battery optimization, you can have Tasker monitor the connection and restart it if it does get killed and your device isn’t on the home WiFi.

Right… While trying to figure out this “when not connected to home network”, I lost track of the angle.

That makes sense… On the other hand, the openHAB Android app does provide push notifications. I would assume that’s more or less comparable?

Not comparable at all.

The notifications work by going through Google’s notification service through the OH cloud service. This is a service that is built in to the phone and optimized for batery usage. As I understand it, the Android app registers a callback to some service built into the OS which gets activated only when a notification becomes available. So the only think running loking for the notification is built into the OS and it’s runing anywayon behalf of al the apps on your phone.

Item updates come to the OH android app through a direct websocket. The next time you log in to your openHAB MainUI on a browser on a computer, open the developer sidebar, go to the second tab and click “stream events”. That represents the sheer flood of data that is pasing from OH to any OH UI client any time it’s open. The Android app rightly doesn’t listen and process all of those events all the time. It only does so when you have the app open and active.

So the only alternative the app has then is to poll for Item updates. That means it needs to be awake and not kiled by the battery optimizer. And then how timely does the detection of a change in an Item need to be? Commands are out entirely because those are ephemeral events. You can’t see those by polling.

When the Android apps implemented polling in the past, the battery drain was far too much and dropped it before it ever made it into the code baseline. I doubt that has changed.