The video does a great job explaining what can be done in response to the HTTP Request but nothing to explain how to setup the HTTP Request server portion. Is that explained somewhere?
He does kind of brush over that... But there is effectively no setup required... Which is great. All you do is create a new profile using a HTTP Request as the trigger (to use HE terminology), and in my experience as long as you include a port and a path, everything is good. Give me a minute a while and I'll show you what I mean.
When setting up a new Profile you can now select a HTTP Request from the Event option:
As long as you set the port and path in the HTTP Request trigger:
Then you can then send a HTTP request with those in the URL and the actions will occur on the device. Weirdly this produced a 503 error on my laptop, but still triggered the actions on Tasker...?
I'll take it as a win for now...
1 Like
Am I correct assuming that you are using your phones IP address so this only works when you're on your home network?
I expect so as well... I haven't read the many comments around the Beta testing, so not sure about impacts of potentially using VPN's and alike. My intention would be, in terms of what I am trying to achieve with my project here, would be to revert to one of Tasker's alternatives, like Join / AutoRemote, but can't say I have investigated that enough to be sure what option I may choose, including others that may be available.
Also, this was part of the reason for considering the heartbeat in combination with network ssid, to try and detect if the device is on the local network in order to determine how best to communicate from HE to the mobile device. In my travels today through posts and pages about Join and other Tasker related Apps, I have seen there have been efforts in this space natively in order for the Apps to know whether to communicate between devices over the LAN, so I may be able to leverage this in some way, but it will need more investigation.
I'm definitely intrigued. I wonder if it would be possible for phone to send its IP address as a variable when it changes to the device that sends the HTTP request somehow.
If that IP address changes at a much later time, that would definitely be possible. You're obviously not going to receive a message from HE if HE is expecting IP address X and tries to send a HTTP request to X but the phone is operating on address Y, but when the address changes from X -> Y, I would expect we could send a message to HE to tell it the IP had changed.
That said, I don't expect this could extend to the HE app, and I would still encourage fixed IP addresses on the local LAN.
I definitely have fixed IP address at home. I am more interested in a way to do this even when not home and I don't have a fixed IP address on phone. I will just wait until this leaves beta; until then I will stick with Join.
The options I introduce are less likely to rely on the options available in Tasker, more likely o revert to notifications via the HE mobile devices or comm's HE -< mobile, mobile -> HE, I need to think about some more....
Awesome that you are working on this. Ive often wondered why tasker is not leveraged a little more amongst this community where we love to automate anything and everything that we may find slightly useful.
We caryy these powerful computing devices with us all the time. It seems like a natural fit with home automation.
A little more on topic. Have you looked autoweb? I believe its designed to work with things like maker api i believe. It may be useful in what youre trying to do here. Then again mqybe not. Just thought ibwould put it out there.
2 Likes
Thanks @cwwilson08 . I took a quick look at the description of AutoWeb and you are right it is referring the kind of thing we are trying to do now, though I am unsure whether Maker API exposes an API definition like AutoWeb requires. Regardless, I can probably get by without needing to use AutoWeb, and I am also conscious of not wanting to add extra tools into the mix if I don't need to.
But I will still look at AutoWeb in more detail in case there is something I have missed. Thanks for pointing this out.
Just so people don't think I have forgotten about this... 
I am still working on it, focusing on the Tasker end, I need to get back to the HE driver and potentially an App to manage it all... I plan to offer both communication using the new (beta) HTTP Request feature in Tasker as well as AutoRemote.
2 Likes
Thought this was a better place to capture new features I want to include or need to complete before a final release. Some are partially complete, e.g. setup in Tasker but no the MC driver or App, others are just thoughts at this stage... See here for the "release" topic.
Media
- Play/Pause and Stop
- Next and Previous Track
- These are already setup in my local Tasker project, I just need to setup the links in the device driver....
Local Battery Notifications
- Produce local notifications on the device when the battery reaches a high and low points, e.g. 20% and 80%
- Been using these for a while now...
- Useful for alerting of battery levels are low/high while outside Wi-Fi range of HE, prompting you to charge the device or take it off the charger
Launch App
- Option to nominate Apps that can be launched from HE
Bluetooth Monitoring
- Detect / Report connecting to nominated devices
- Useful to detect when connecting to devices that signify something useful from an automation perspective, such as a car
- Setup local option in Tasker to launch and App on connection to a Bluetooth device
Call and Text Monitoring
- Incoming Calls - Any, from specific contacts, etc
- Missed Calls
- Unread Messages
- Mostly working for me locally in Tasker, just need to transfer to MC
Notification Option
- Adjust Notification setting between Sound, Vibrate, or Mute
- Setup in my local Tasker setup, just need to include into MC
AutoRemote Cloud
- Look into options for issuing commands from HE to mobile device using AutoRemote cloud URL's
- More investigation will be required for this one....
