[COMPLETE] Webhooks without IFTTT

#1

As IFTTT moves towards a subscription model, could we get support for proper webhooks so that we may move away from IFTTT?

Currently I have a IFTTT webhook triggering a light in Home Assistant, but since Home Assistant can support a webhook itself (e.g. Nabu Casa), generic webhooks would be greatly appreciated.

Add support for home assistant
#2

Currently we supporit generic http requests through Tasker. This is extremely versatile and sports an inexpensive one-time licence fee so our stance was always that implementing our own custom http request builder would be duplicating the effort.
Would that work for you?

1 Like
#3

I second this request.

I love Tasker and used to be an avid user several years ago. However, I no longer run Tasker on my phone and would prefer to not require it.

It would be excellent if you had a Webhook option that performed the same exact tasks as your IFTTT integration but let us define our own webhook endpoint instead of IFTTT.

I too use Home Assistant (not through Nabu Casa) and would love to send these webhook requests to my Home Assistant. For my purposes, it doesn’t have to be all that customizable. So a lot of the same code for your IFTTT integration can probably be adapted.

3 Likes
#4

I third this request.

I also used Tasker ~8 years ago but I have no other use for it right now. This is not about shelling a few bucks to that app since I’ve done that already, it’s about not wanting to have another app installed to do just one more thing. Like Royal2000H and Midnitte, I use Home Assistant, and I would like everything to work as local as possible. IFTTT breaks sometimes, and if I lose my internet connection during night for whatever reason, I don’t have my morning coffee ready when I get up :smiling_imp:

#5

Hi, I’ve just commited the code for this feature so it should be available in the next beta version of Sleep as Android.
Documentation is already available at https://docs.sleep.urbandroid.org/services/custom_webhooks.html

6 Likes
#6

You guys are awesome!

#7

Hello everyone, in the latest BETA we have created a kind of Automation dashboard where you can choose a subset of the events, see all available events (there are 26 different events now) and you can choose if you want to send them to custom webhooks, IFTTT, MQTT, Tasker or just use Androdi Intents directly…

device-2020-11-14-103911
device-2020-11-14-1039111080Ă—2280 121 KB

device-2020-11-14-103847
device-2020-11-14-1038471080Ă—2280 70.3 KB

Many tanks for your feedback!

3 Likes
#8

Whoa this is absolutely amazing! Thank you for the work! This is a great replacement for IFTTT

#9

I also use this to integrate with Home Assistant. But we are 3 persons in the house hold, and there is no way to know who has called the web hook. This I solved by creating different endpoints.

But I am missing one future that would really help when writing automation. And that is the label of the alarm. It would be great if all events could send a value of the alarm that caused the event to fire.

In the docs it says that “alarm_alert_start”-event should have this value, but it doesn’t. But I would also like to have this information for all the others, especially for the events starting with “alarm_”

This way I can have different automation in Home Assistant for different alarms in Sleep as Android.

#10

Thanks for pointing this out. There’s a discrepancy between documentation and the app’s behavior. The app is sending only the label, as “value0” (in the json). I’m fixing that so that it adheres to the documentation - the fix will be available in the next beta.
I’m also updating the docs so all of the alarm_ events are correctly described with their event values.

Big thanks!

#11

Just got some spare time to do some more tests.

I am still not getting any values on “alarm_alert_start” (neither timestamp or label), only the event name. It is the same for webhook and MQTT.
But I am getting them both on “alarm_alert_dismiss” (timestamp and label) for MQTT, but only timestamp and not label when using webhook.

The topic setting for MQTT works great. So now there is a possibility to separate different users in the household on both MQTT (change topic) and webhook (different endpoints).

So to be able to build different automation for different alarms and different users in the same household I am still missing the following:

  • “alarm_alert_start” needs a value for the label of the alarm (both webhook and MQTT)
  • “alarm_alert_dismiss” needs av value for the label of the alarm (webhook)
  • “smart_period” needs a value for the label of the alarm, and preferably a timestamp of the alarm start time (both webhook and MQTT)
  • “alarm_skip_next” needs a value for the label of the alarm, and preferably a timestamp of the alarm start time (both webhook and MQTT)
  • And finally there is a need for sending an event when turning of the alarm in the app it self before it has started. Now we get an “alarm_skip_next” if we turn of the alarm from the notification, but not if it is turned of in the app.

(I am using version 20210106 (22243) Premium BETA)

#12

Thanks for the tests @strixx!
I’ve tried to reproduce the issues with missing values but all came through correctly (I’ve been testing webhooks using https://webhook.site/ which correctly shown both the timestamp and label for alarm_alert_start and alarm_alert_dismiss. I was testing on the same code that is in the latest beta.
Especially confusing are the differences that you see between MQTT and Webhooks since those two services get passed exactly the same JSON as body. Could you please give it a try somewhere else than on your usual setup, or monitor the raw requests incoming to the mqtt/webhook server you are using?

Regarding the bucket list:

  1. We’ll sort this out
  2. Dtto
  3. Will do
  4. Will do
  5. This needs a little more thought - as it stands now it would be directly mapped to a button press in the app so possibly could generate a lot of “false” requests when setting up alarms the evening before. Could you please describe the use case so we can better understand what is this needed for and maybe come up with an alternative solution than just wiring it up benevolently?

Thanks a lot
Jiri

#13

Okay points 3 and 4 are tested and will be there in the next beta.

#14

Thanks for the quick reply.

I noticed one big misstake i did. I had my phone set up useing MQTT and my tablet useing webhooks. But the alarm on my tablet had no label… :roll_eyes:
So the “alarm_alert_dismiss” is working as it should. The same object is passed in both MQTT and webhook.

But I still don’t get any values for “alarm_alert_start”. I am doing all the testing in Node-RED. But i tried the page you linked to, and the results are the same:

start

Regarding number five in my list.

The goal with this is to let Home Assistant know when I want to wake up, and when I am awake. So that I can start dimming up some lights before the alarm goes of. And if I do wake up before the alarm starts I want the light automation to stop. But only if I am at home and it is an “morning alarm”. I also want to be able to start different automation depending on if it’s my alarm or my wife’s. And a separate set of automation if it is my sons alarm.

If I can get the label in the “smart_period” we can create a special alarm in SleepAsAndroid with a smart period of 15 minutes, and then Home Assistant will know 1 hour before some alarm is about to fire. So this will be solved.
I guess if it is hard to send events when you switch on or off an alarm in the app, I would have to use the notification to dismiss the alarm, and never do it in the app. But then I need to know the label in the “alarm_skip_next”. And since you wrote 3 and 4 will be in the next beta I think I will be able to do what I want.

So I will be looking forward to the next BETA… Thanks!!!