[PROJECT] [ANDROID] Mobile Controller - Get Your Mobile Device Status and Control Them

There is a thread around here with eg st code ported for hubitat. I also believe someone made a newer project for eg as well.

1 Like

Yep, I use it. Let me take a look...

This is the one I use to send commands for my mousemat lighting and to poll my ups

1 Like

Yes, I already do some of these myself. But I'm interested to see if my mobile can be more integrated into HE. Almost like a Hub Mesh for mobile devices

2 Likes

Things are starting to progress for this project. I have setup a new Git repository with the beginnings of a Mobile Device driver, effectively a copy of my Virtual Battery Sensor with the name changed. I've also added it to my HPM existing repository setup. So nothing functionally new from what is already available at this stage... but I've made a start.

I've also started to explore options for being able to share projects in Tasker, looking at how best to setup variables and what get's exported, etc. Looks like the global Vars I previously setup need to be Project Vars to make this work more seamlessly. Still some more to explore in this space.
I'll also flesh out a list of "issues" in the Git Repository to map out some sort of roadmap.

1 Like

Anyone ever re-imported a previously exported project? Seems a bit hard to find any notes on this, apart from people talking about renaming or removing the old project / profile, which seems both complicated and not a smooth experience... Hoping this can be done more easily. No-one, well at least me, get's things right the first time, so want to be able to release updated Tasker setups when needed.

I don't know if its related but I had difficulty moving all of my Tasker projects from an old phone to new the 1st time. I backed up the old phone but it never worked to import the backup file into new phone until I first created a backup on new phone of the blank Tasker install.

Hmmm... Does seem like it's only setup for a one off import.... which seems a shame... Will keep investigating.... I might have to join Reddit.... But will search a little longer first....

I reluctantly took the plunge.... Feel free to vote up or comment if you are a member...

Here's a bit of what I have been thinking about.... (these will most likely be developed from the bottom up in the screenshot). Actionable notifications may also slip into the list at some point as well... Feel free to take a look on the Git Repo and feel free to add comments or suggestions.

1 Like

This is an awesome idea. I was a tasker user back in the day. 10 years ago maybe but probably 100+ years in the world of tech.
Tasker is great but I find it's quite challenging just like node red and RM. I am getting older and lazier :rofl:

1 Like

Tagging this as something I would like to tackle early in the new year....

2 Likes

Any news on this project? It's likely overkill for what I need to do, which is to simply communicate HE mode changes to Tasker.

Unfortunately not. Been bugging me that I said I would look at it during my holidays around Christmas and haven't got back to it yet. I honestly don't know when I will get to it, it could be this weekend or in the next couple of months... Sorry... But my time on so many of my projects is very sporadic.

3 Likes

Spent some time on this today, mostly playing in Tasker at this stage, looking at the sticking point for me being how best to roll out changes to a Tasker Project. Not ideal, but I think it will be workable,,, Also got some of the commands working within Tasker for things like brightness adjustment, Do Not Disturb, media mute and unmute. Still very much a work in progress and work to be done on the HE side with an app and driver to be built / expanded.

But to your point re:

Heavily summarising the steps involved... (I got this working earlier today, triggered from the AutoRemote Chrome extension installed on my laptop), and assuming you already have Tasker installed and a basic knowledge of setting up profiles....:

  • Install and configure AutoRemote (I did this some time ago now, so my memory may be a little sketchy, be prepared for some trial and error and unclear instructions....)
  • Add a new variable under the VAR tab in the Tasker App, call it what you want, but I will assume you have called it he_mode for these instructions
  • (Optional) Setup a new Project for your new profile(s)
  • Setup a new Tasker profile that looks for an Event from the plugin AutoRemote
    • Set the Message Filter to the same name as the variable you created above, e.g. he_mode. Technically it doesn't have to be the same, just easier, I think.
    • Under the Advanced section click on the Command option and type the same variable name in the Command dialog that is displayed
  • Back in the main Tasker screen, create a new Task to Set Variable, selecting the variable you created earlier as the variable to set. For the value reference the AutoRemote variable you entered in the Command dialog above, e.g. he_mode, but with Auto Remote at the front to indicate it is a variable from the output of the Auto Remote event based on the use of the Command option.
  • Click the tick in Tasker to save the changes you made

In HE:

  • Choose your own adventure here, but my preference would be to setup an RM rule on a mode change, your choice... In the RM rule you need to include an HTTP GET action like the one below, replacing screen_on or screen_off with he_mode=:=< mode >. Note the port used, that is important also....

Then setup profiles in Tasker to respond to changes in the variable for he_mode.

Simple.... :wink:

You can see why it makes sense to build an HE app and Tasker Project to handle a lot of this... Perhaps my proposed app will not be entirely overkill, if only for the instructions I will need to cobble together for setting up Tasker and AutoRemote to allow this to all happen....

1 Like

If only to make sure this doesn't get closed...

This has been bouncing around in my head for a while now... The most recent nagging thought around cancelling notifications I send to my devices, i.e. send a "washing is done" notification, but when the smart plug starts using > X power again, then I've obviously started another washing cycle, so cancel the notifications on the various devices I sent the notification to. Similarly for other notifications which typically have some trigger to indicate the notification is no longer relevant.

Like anything I have developed, no promises.... only that it may come soon... Feel free to throw some weight behind my own thoughts on this.

1 Like

The most recent nagging thought around cancelling notifications I send to my devices, i.e. send a "washing is done" notification, but when the smart plug starts using > X power again, then I've obviously started another washing cycle, so cancel the notifications on the various devices I sent the notification to. Similarly for other notifications which typically have some trigger to indicate the notification is no longer relevant.

I have to say that notifications would probably be very low on my list regarding a Hubitat / Tasker integration, just because there are already a million ways to send notifications to my phone.

I'm currently using Tasker together with Hubitat to switch my phone into sleep mode when the house goes into sleep mode, and vice versa - i.e. for solutions that require things to actually happen on the phone. Essentially what you said earlier: things like brightness adjustment, Do Not Disturb, media mute and unmute, etc.

Yeah, that makes sense, there is more value in some of those other things that I have on my list.

Just with the notifications, I wasn't looking to using Tasker to receive notifications, those I still intend (for me) to send via the HE App. It is the cancelling of notifications that are showing on the device once some other event occurs that I want to handle using Tasker. So I send a notification using HE to tell me the washing is done, then the power on the smart plug for the washing machine goes above X watts and I send a AutoRemote command to cancel the notification if I haven't done so already. I know this isn't the biggest thing in the world, but just a nice option to have, and shouldn't be too hard to do.

Ooooh. You would like Tasker to kill the notification you might have previously sent to the HE app if conditions change?

I guess that in that case, I would just roll the entire notification system through Tasker - i.e. issue the notification via Tasker, and kill it or update it in Tasker if the notification content changes or the notification no longer applies.

That gives you the advantage of having updateable notifications. And you don't have to keep state somewhere of which notifications you've issued via HE and killed via Tasker, which sounds like it might quickly get out of hand once you're trying to update the notification status of a device more than one or two times.

It may need a bit more thought and testing, but I was hoping to be able to identify a simple notification and cancel it. I have already been able to intercept a notification sent via HE and re-display it differently, I was hoping the cancelling of the notification could be an extension of that. At least in my use-case I wasn't thinking I would need to maintain state information, but I guess we will see...

I get that for some use-cases it could become a little problematic, so it would likely be something to assess before using it in anger.

1 Like

Looks like Tasker is getting it's own HTTP server, allowing HTTP Requests to be sent to a device, like your phone or tablet, without the need to have AutoRemote (or Join) installed and running the Wi-Fi-based HTTP server. I think I will head down the path of using this to keep the setup much more lean and simple.

https://www.reddit.com/r/tasker/comments/13i9p3l/dev_tasker_62_beta_were_back_in_business_i_can/

I joined the beta program and tested this out on version 6.2-rc, I was able to receive a HTTP request on my phone and flash the word "hello". Simple enough to do, so am pleased the recent discussion here lead me to look at AutoRemote alternatives.

Here's a bit of what I have been playing with lately....

In Tasker I have setup various profiles under a single Project.

Profiles prefixed with MC Configuration are there to receive settings from HE via HTTP messages. So an app / device on HE would send multiple HTTP messages to the device to capture the configuration within Tasker for use in later communications from Tasker back to HE, such as the IP address of the HE hub, the virtual device id in HE and app-related settings used in HTTP comm's, like those needed in Maker API calls. E.g. reporting back the battery percentage uses Tasker Project Variables being set in the configuration profiles to call back to Maker API:

The Report profiles are those reporting details back to HE from the mobile device, such as battery level and the current Wi-Fi network SSID. There is also a heartbeat in there to be able to assess in HE if the device is still able to communicate with HE.

The Command profiles receive HTTP messages from HE relating to various commands that can be performed on the device, such as changes in Do Not Disturb settings, screen brightness, volume, etc. HE would send these commands to the mobile device running Tasker and Tasker would adjust these settings on the device.

The intention is that any of these Report and Command profiles can be turned on or off inside Tasker to allow users to control how much information and control is made available.

Here's taste of the HE device screen, though there is still much to do here to catch up with some things I have learnt via more recent work inside Tasker, such as the multi-faceted nature of device volume.

In terms of the attributes, there is:

  • The battery percentage and status, taken from my virtual battery sensor I developed, reported via the battery percentage reporting profile in Tasker
  • Current screen brightness reported by the device
  • The heartbeat recorded as a timestamp of when the heartbeat report was last received in HE
  • Last updated is just a record of activity, I may do away with it, not sure...
  • Motion may or may not stay in the mix
  • Wifi network is the current SSID. More work to do here, both in terms of handling dropping off the network and how I want to record it, e.g. provide options for recording a masked version like "home", "other" and "none" versus actual SSIS name (and no, I don't have a network called None :slight_smile: )

I'd like to try and finalise some of what I have done before trying to setup too much more in the way of new features than the one's shown above. Not sure when, but am at least targeting a release rather than new work, if that's of any encouragement about timing.

1 Like