Tasker http post + new auth

Configuration
1

I use http post via Tasker to automatic set my homeassistant alarm clock, the same as my phone alarm clock. But with the new auth system, this no longer work. Does anyone know how to use http post from tasker with the new auth system?

2

Startet working suddenly, so no problem anymore :slight_smile:

3

Hi @Zepixir,

I am trying to setup tasker to communicate with HA via HTTP Post too.

I am wondering how do you set this up? Mind to share your settings in Tasker?

Thanks in advance.

1 Like
4

Check out this post: Tasker & Long Lived Access Tokens
Then you don’t get an error message everytime you use tasker to control things too😊

1 Like
5

Thanks. It works.

However, other than Tasker, I have been playing around with IFTTT as well, specifically the webhook service.

Then it hit me both are actually using the same thing. So I applied the same concept I used for IFTTT on the built-in tasker HTTP Post task, and it works!

This is what works for me…

In Tasker HTTP Post Task:

Server:Port = https://[HA URL]
Path = /api/webhook/XXXXXXXXXXXXXXXXX (replace with your own URL)
Data / File = { “action”: “call_service”, “service”: “light.turn_on”, “entity_id”: “light.living_room” }
Content Type: application/json

In HA automation:

automation:
  trigger:
    platform: event
    event_type: ifttt_webhook_received
    event_data:
      action: call_service
  action:
    service_template: '{{ trigger.event.data.service }}'
    data_template:
      entity_id: '{{ trigger.event.data.entity_id }}'

I prefer this method because it doesn’t rely on third party plugin.

1 Like
6

OK. I dig deeper and I found this; 0.80: Lovelace updates, webhooks, TRÅDFRI switches - #21 by danielperna84

It is even simpler. Doesn’t need to enable the IFTTT integration.

In Tasker HTTP Post Task:

Server:Port = https://[HA URL]
Path = /api/webhook/call_service
Data / File = { “service”: “light.turn_on”, “entity_id”: “light.living_room” }
Content Type: application/json

In HA automation:

- alias: 'Webhook Call Service'
  initial_state: 'on'
  trigger:
    platform: webhook
    webhook_id: call_service
  action:
    service_template: '{{ trigger.json.service }}'
    data_template:
      entity_id: '{{ trigger.json.entity_id }}'
7 Likes
7

Thank you so much! The RESTask was very unreliable, so will change to webhooks definitely! :grinning:

1 Like
8

Hello. I’m surprised how much changed within the last 9 months on HA.

I tried to resetup my old automations, that included some Tasker http posts with the Post Service component. It can connect to HA and actually turns the lights off, what shows me at least it still can connect.

What’s not working anymore ist the data with the entity. It switches all my lights off instead of only the one i intend to. Has that something to do with the uptades and is the only workaround with a HA automation?

9

Hard to say anything without your config files…

The example above in my opinion is quite easy to read?

If you don’t want to use webhooks you should use bearer tokens. The “old” way with api password in uri I believe is going to be removed at some point.
I used restasker plugin for bearer token, but it seemed to be quite unreliable plugin. Don’t know if it has been improved recently.

10

Thanks I could actually get it working. Tried to use the same technique in an IFTTT Webhook post but wasn’t able to make it work. Is there something different if i want to use a http post via IFTTT?

11

thank you so much, this helped me solve a problem I have been having for a while. Was missing the

Content Type: application/json

from my tasker config

12

Please don’t call your webhook ID “call_service”. It’s meant to be something long and un-guessable, since the URL will basically have no security on it. Home assistant’s default is to have two GUIDs concatenated together. Something like this:

b97516e5ef904babbf092f5d112447f4f7fbb40c0819401295c6b09980184598

I use an online GUID generator for this.

13

What I ask me all the time.
Wouldnt a dep packet inspection just reveal this url then anyway?

14

Probably true, but URLs are encrypted for https, are they not? Mostly it just protects against guessing the url. Just don’t call a webhook “unlock_doors” or something like that. Even if somebody does guess a webhook ID, they’ll have no idea what it does.