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.
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.
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.
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.
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.
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 )
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.
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.
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 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.
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.
)
