That’s odd, because executing device commands is definitely a POST.
Wow! This looks exciting.
What does the ‘Powersource’ show and does it change conditions when AC power is available and when it isn’t? If so, can the powersource condition be used as a trigger for Routines?
Update: I was able to get this Tasker profile working so it can change the vEdge Battery device, but the vEdge Battery device is broken trying to use the Power Source as an If condition in a Routine.
I did notice that Tasker does not have a native %POWERSOURCE variable, so to get this to work, I created two Tasker Profiles to set the %POWERSOURCE variable to either Mains or Battery depending on the AC power source before the HTTP Request.
I can’t save the Routine to test it at the moment but I thought I’d tested it previously.
Oops, I’d forgotten what I’d done. I use a single Profile based on the Power state being ‘Any’, with anonymous tasks to set the variable to
battery and send the HTTP request when it becomes active and inactive.
I find Tasker to be simultaneously brilliant and borderline unusable and the less I think about it the better.
After getting a good night’s sleep, I took another stab at this and immediately found my issue: I’m an idiot. I missed the “/commands” at the tail end of the URL
Thanks to everybody for your help, without it I would have given up.
Also, @joshua_lyon I still can’t get SharpTools to even show the virtual battery device in the “Authorize Things” screen. Not sure if that’s a feature or a bug, but it would probably make this easier for people like me who use SharpTools a ton.
I am following your instructions for Present Phone Battery Charge % To Be Used as Trigger to use on one of my task but I can not figure why the request will not toggle the light (Sengled z01-a19nae26 is using Edge Zigbee Switch)? I am have been informed the Edge Zigbee device must have toggle capabilities for the Tasker task to run. Any ideas or suggestions?
In order to implement a ‘toggle’, something, somewhere, is implementing the logic ‘if the switch is already on then turn it off, or if the switch is already off then turn it on’. There appears to be an undocumented Rule action for this which Routines are using, but otherwise the Routine would implement it with the basic conditions and actions. You either have to implement that logic in Tasker or shift the problem elsewhere.
My preference is not to attempt to use Tasker as an automation engine, but instead to use it in combination with virtual devices in SmartThings as part of the device integration. A DIY cloud connected device in effect. So in the case of battery level I would define a virtual battery in SmartThings and use Tasker to set it (which is what my earlier example shows). You then have a device in SmartThings you can use as you wish.
It is essentially the same idea as what you are already implementing with your virtual presence sensor.
Ok so I may need to explain what I am trying to accomplish… I am using Bubble Cloud Launcher for WEAR OS and it lets us use Tasker to send task from the Tasker task list (workaround due to new Smartthings Edge platform). From there we setup icons and when we press the icon it running the task to Smartthings (turn on, off, or toggle light). Bubble Cloud Launcher for WEAR OS must pull from the Tasker task list to preform command to Smartthings. I thought your post mentioned above would help me to accomplish what I am trying todo in the WearOS Cloud launcher with light toggling?
Ah I see. In that case I can see why you might find it more appealing to have Tasker send a ‘toggle’ directly. That is perfectly viable in Tasker, you just have to first use the SmartThings API to query the current state of the switch and then choose to send either on or off. I can’t suggest the details as I was never that fluent in Tasker and I have deleted it from all my devices.
I’d probably just execute a Rule myself but that’s me.
Could you just have Tasker turn on a virtual momentary switch? Then, have a SmartThings routine that toggles your desired light every time the virtual momentary switch turns on.
I tried @sdgood idea to us a virtual momentary switch as a middle man and it works.
I still used the switch “on” command in Tasker.
Just like @orangebucket advised, I use @TAustin virtual Battery device and have Tasker HTTP Response post the battery power level and power source of an Android Tablet to the Battery virtual device in SmartThings. Then I use the battery level as the trigger in SmartThings. Besides using the Battery level, I also use the Power Source of the virtual Battery device to know when power is out since I leave this Tablet plugged in all the time.
I can not get this battery level automation to work. Some questions:
Does indentation matter? Orangebucket shows and indentation pattern and DaWeave doesn’t show any indentation.
Am using the same token as I use for my other http requests in Tasker. All my other tasks use the,“switch” capability. Do I need a different token.
And what profile are you using to trigger this task?
Any other suggestions?
A few things come to mind:
- %POWERSOURCE is not a built in variable. You’ll need separate tasks and profiles to set that variable to either “Mains”, “DC”, or “Battery”.
- Break up the HTTP task into two tasks: one to set the battery level and one to set the power source. This should also help figure out if/where you have an issue. If one works and the other doesn’t, it could be a matter of scope for the PAT. I have mine set to update battery level every 15 minutes and update power source when plugged in or unplugged.
- Make sure it’s a space and not a return between " “capability”: " and " “partyvoice239…” "
- I just removed the indentation from mine and it posted fine.
Hope this helps!
Thanks. It is still not working.
I broke it up as you suggested so that battery level is separate task.
I have a space, not a return between " “capability”: " and " “partyvoice239…” "
The only other thing I can think of is to create a new PAT with all scopes authorized. If it works then you know your scope is the problem. If not, it’s something else. For the sake of security, don’t use this PAT day-to-day, just create it, run your tests, then delete it.
I created a new token with everything checked and it still does NOT work.
Thanks for looking.
Could you post a screenshot of your task without the PAT?
What exactly doesn’t work? Error in the request? Failure to update the ST device?
Another thing to try: remove the space between “Authorization:” and “Bearer…” in the Headers field
Failure to update virtual battery in ST