Using notifications as IFTTT triggers

[Don H]

I understand that notifications, currently, do not show up in the event log. The event log is what is used to trigger IFTTT functions.

For me this really limits functionality since I wish to control humidity by opening and closing a valve that supplies a misting system in my greenhouse.

My "rainmachine" valve controller only allows the user to open the valve from between 1-60 minutes in the IFTTT environment (probably  a safety feature to help against flooding). 

Many applets only allow for specific time durations until they turn off. The problem is that if they turn off before a condition is met  (I.E. humidity is normal) the applet is not re-triggered since there is no "new" event telling IFTTT that humidity is still to low (even tho' I continue to get notifications that my humidity is too low).

Support at wireless tag informs me that they will implement the function I want by tomorrow but warned me that if customers complain that the event log gets too cluttered they may remove it (I suggested they make it a user toggle to have all notifications become events or not but I have not heard back from them on that idea). I really do not like the threat of removing a function hanging over my head so I am wondering if anyone may have a workaround (I.E. found a way to have notifications become triggers in IFTTT or something else)?

[Don H]

Quick update: wirelesstag implemented my request that all notifications show up in the event log (WOW! they did it in a couple hours) but I don't see anything that allows the user to turn that function on/off so I am still interested in workarounds in the event too many folks complain about the event log getting to large and wirelesstag decides to remove it. 

BTW the function is awesome in that it continues to trigger applets that are constrained to run a chosen time duration before the applet stops.

[T Jakab]

You can trigger IFTTT with webhooks and webhooks can be called from KumoApps:

https://ifttt.com/maker_webhooks

[Don H]

I am not familiar with how webhooks works I have some learning to do ; ).  I did  a quick peek, and registered, but I am not sure how webhooks can be used as a threshold trigger (at first blush it appears webhooks just creates a trigger based on whether or not a notification was sent regardless of the information the message contains). I need the trigger to be based on whether or not the humidity is in range and I get all kinds notifications from WT many that do not have anything to do with my humidity being too high or too low. If you could expand on how this could work I would appreciate it.

[T Jakab]

Unfortunately IFTTT hasn't got conditions so webhooks can only be used like triggers in other services.

Depending on what you want to control Zapier might be a better choice because it has not only filters but zaps (actions) can be chained too.

However, in this case the threshold would be in the Kumo app, there's no point in calling IFTTT or any other external service if you don't want it to do something.

In fact you don't even need a Kumo app, URL calling should be good as well. There are already events for humidity high/low/returned to normal, just copy in the corresponding IFTTT URL you have created.

I.e. https://maker.ifttt.com/trigger/humidity_high/with/key/<your key goes here> for humidity too high.

[Don H]

I still am not sure how this would be different than using "events" from WT before they implemented the feature request to have all notifications be events. 

 Before WT made all notifications events here is what I ran into.

1) I set up WT so I get notifications every 30 minutes (time chosen by user)

2) I get notification that humidity is too low and since this is the first notification about humidity it becomes an event (all is good IFTTT now has trigger to turn on my sprinklers)

3) The sprinkler app (rainmachine) only allows you to turn on the sprinklers for a finite time then they turn off unless triggered again

4) After the sprinklers turn off, because of the time interval, I get another notification from WT that humidity is too low but since there really is no change in "state" from prior notification it does not become an event (new trigger)

I am not seeing how URL calling will work since I need to retrigger the applet but the "state" had not changed. I.E. after the sprinklers run for say 30 minutes and turn off if the humidity does not reach normal then I don't see how IFTTT gets a new trigger to turn the sprinklers back on since the "state" had not changed (it still just says humidity too dry but since it is the same "state" as before a new trigger is not created).

[Zhiheng Cao]

We changed server behavior so now if you set the option to "repeatedly notify" until back to normal, your IFTTT applet will repeatedly run. This applies only to temperature, humidity (or soil moisture), and brightness events. IFTTT behavior of other events like motion, out of range, etc, are not changed.

--
You received this message because you are subscribed to the Google Groups "Wireless Sensor Tags" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-...@googlegroups.com.
To post to this group, send email to wireless-s...@googlegroups.com.
Visit this group at https://groups.google.com/group/wireless-sensor-tags.
For more options, visit https://groups.google.com/d/optout.

[Don H]

Sounds great! Where is the "repeatedly notify" option located? I looked for it but have not found it yet.

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-tags+unsub...@googlegroups.com.

[Don H]

Just to make sure we are on the same page. Notifications are not used as triggers. Events are used as triggers.

How would "repeatedly notify" help here if the new function I requested is removed. As a reminder the new function is that every notification becomes an event.

 

The function to choose between notify once or every (user chooses time duration) was already there.

Now that wirelesstag has changed the behavior so that every notification becomes an event it works as I hoped.

The issue that is of concern now is that I was told that if enough customers complain that the event log gets too busy, now that every notification is an event, that wireless tag may decide to remove the function.

My suggestion was to have the user be able to choose if every notification becomes an event or if they want to have the old behavior of only "state" changes are events.