Lack of IFTTT / GE Washer

I am working through various aspects of my SmartThings / Webcore system figuring out how to support them in OpenHab (I’m determined to dump SmartThings asap) … seems I found one sticking area …

I use IFTTT for several things:

  1. OhmConnect sends me an email during OhmHour events which I use to trigger my house to go into power saving mode. IFTTT gets the email and then uses a webhook to call my SmartThings WebCore Piston

  2. My GE Washer and Dryer send an event when they are complete … IFTTT catches this and does a Webhook to have the system inform me.

I see from this post, that there is no GE Binding, so IFTTT would be the only way?

Also, it seems IFTTT is not supported anymore (not sure of the history but apparently it was being abused) …

So what are others doing for these kinds of things?

“Misunderstood” would be a better description than “abused”. People were exposing many (if not all) of their items in to myopenhab, particularly to use them with Google Assistant and Alexa. In reality, items only needed to be exposed for IFTTT. As a result, myopenhab kept crashing under the strain of updating exposed items, so it was turned off. In the end, IFTTT wasn’t actually being used by a lot of people, and even less so now that it’s restricted to three applets in the free tier.

As you already know, IFTTT can receive webhooks. So if you want to send commands to it from OH, that’s easy to do. However, getting commands from IFTTT requires pieces in between. For example, if you have a spare Android device, you can have IFTTT trigger notifications on that device, which in turn trigger Tasker routines, which in turn sends commands to the OH app. It works, but it’s annoying.

This would actually work in Android/Tasker without IFTTT. You could have Tasker monitor for notifications about OhmConnect. There’s probably a more direct pathway, but I haven’t tried using emails as triggers.

A quick search led me to an email-to-MQTT bridge if you wanted to give that a shot.

Does GE not have an app that can inform you directly? If they do, you could again use the Tasker solution…but I would think you could just have the app installed on your phone. I’m not sure how openHAB fits in here.

It’s also possible that someone has built a GE-to-MQTT bridge, so you might want to look for that.

1 Like

Thanks Russ, very helpful. It’s a bit depressing as I had high hopes to start converting my existing ST/WC setup. I am not an Android user but I’m aware of Tasker and perhaps that would be the best approach. I envision that I could buy a cheap Android phone that is on Wifi only, set it up in the house somewhere and it becomes the bridge to the outside using Tasker. Perhaps I could:

  1. Run the GE Washer App on the Android and use Tasker to forward those alerts? (I have no idea if Tasker can do that)
  2. Give the Android an email address and again use Tasker (or perhaps there is a direct link to email from OpenHab.
  3. Other use cases I have that use IFTTT: I construct Google Home queries that trigger IFTTT to inform me to do something and then report back on the Google Home system. Perhaps again Android/Tasker could be used. (A concrete example is that I can say to my Google Home “I’m cooking” which then prevents the light from turning off for the next hour - perhaps there is another OpenHab solution for this case, I’ve got a lot to learn still)

Regarding the Washer / Dryer comment:

I’m not sure how openHAB fits in here.

It’s simple. I take the W/D notifications about its status (almost done, Done, sitting for too long, etc) and have them spoken on any Google Home that has had nearby movement in x minutes.

So, the exciting thing is: I may need to get an Android phone and learn a while new application (Tasker) which will further eliminate my dependance on a Cloud solution like IFTTT (which incidentally I pay for to be Pro) but …
The depressing thing is I can’t just use OpenHab and have to learn a whole new App and add another device to the house.

My reading starts here:

I Found something like this

This could be a starting point for someone who wants to commit to this

I don’t have any GE appliances myself.

1 Like

You could connect your SmartThings hub to OH and maintain it just for that specific functionality. I don’t know how well that works, but it seems like it would be less hassle. I’d probably feel differently if you had an Android phone laying around.

I believe that Google Assistant can send actions to Node Red, but I haven’t tried that.

In this specific case, you just need a virtual switch item in openHAB that you’ll use as a check condition. You would have that item show up in Google Home, and then when you’re cooking you would ask Google to turn it on. That would then be the first IF statement in your rule.

Mind you, that feels like a lot of work for one very specific interaction. If you have a lot of scenarios where you’re trying to prevent an automation from running, you might want to reconsider them. If you’re intervening often, then you might want to remove the automation and instead just tell Google when to turn off the lights when you want them off. Or keep the automation, but disallow it during the time frame when you’re typically cooking. Or add motion sensors. Basically, automate whatever the most consistent behaviour is, so that you don’t have to spare it any thought.

Of course, I’m saying this based on one example. It might be that you don’t have to intervene very often, in which case you’re already on the right track. I’m just a strong believer that things should only be automated when you want them to happen 90% of the time.

1 Like

Well, I’d rather not be dependent on ST once I transition … I’m looking at buying a used Android phone …

In this specific case, you just need a virtual switch item in openHAB that you’ll use as a check condition. You would have that item show up in Google Home, and then when you’re cooking you would ask Google to turn it on. That would then be the first IF statement in your rule.

Yes of course … but it isn’t as natural as saying “Hey Google, I’m Cooking” … perhaps better motion sensing will solve this, Im hoping I will have more control over things with OH. In ST/WC I didn’t find a good way to to have enough granular control over the Motion events. I do have logic keep it on during normal cooking hours but there are things like darker cloudy days, spontaneous cooking, etc that prevent from predicting when the light should go off after 3 minutes of inactivity or 30 minutes.

That’s what routines are for. When I say, “I’m leaving”, Google turns on Away Mode.

Yeah, that’s why I don’t automate having lights turn off. It’s so unpredictable that I’d rather do it myself. For example, my lights turned on this morning due to it being dark and cloudy, and now it’s gotten sunny. I’ve thought about pointing a lux sensor out the window, but it doesn’t bother me enough to put in the effort.

I think the only light I have on a timer is my laundry room, which goes off after five minutes. Everything else requires me giving an order to Google or tripping a motion sensor.

I find the hard part with motion isn’t OH, but the individual behaviours of different sensors. I have an AC-powered motion sensor that resets within a few seconds. It’s great for acting like a tripwire, since it will spam reports to OH all day long. My other two sensors have longer reset periods to preserve battery, so I can only use them effectively for occupancy. And as you’ve likely learned, the challenge then is that occupancy detection only works when you keep moving in front of the sensor.

1 Like

This is openHAB. There is almost never “the only way.” There are always multiple ways.

The API is at least somewhat public, it’s not clear if that SDK comes from GE or it’s a reverse engineered effort. You could figure out how to use that external SDK (or the Python one Michiel posted) to interact with GE’s cloud services. From there you can send and receive messages with OH through the REST API or MQTT.

You could go a little deeper into the API and implement it as OH rules using the HTTP binding and/or sendHttpXRequest Actions. Usually the hardest part is if the API uses OAuth2 but I’ve shown how to do that with rules at OAuth2 using just OH Rules and I’ve been experimenting off and on trying to get the Honeywell Home API working in this way but I can’t get past the request for the auth token even when using CURL, which is frustrating.

You could put a smart plug on the washer that reports power usage and Washing Machine State Machine to determine when the load is done.

You could use other indirect sensing methods such as vibration, noise, temperature of the hot water pipe leading into the washer, etc.

Don’t get too focused on how you think the problem needs to be solved (i.e. get the notification from the phone app into openHAB) to the exclusion of a whole host of other approaches that solve the actual problem just as well or better and perhaps with less work.

They used to have a Maker channel (though I think it was renamed) that would make outgoing webhook calls. Do they not any more? I deleted my account a long time ago.

Unless there is a plugin I don’t know about, which is always a possibility, there is no way to directly trigger Tasker via an email. Obviously, the notification from the email app can be used though. And there is at least one MQTT add-on so that email-mqtt could be used. I think the Android app has/is getting support to trigger a profile based on commands to Items maybe so openHAB itself could command Tasker to do something based on an email.

It is probably worth your while to spend that effort exploring the two API implementations already linked to here and writing a script that lives on your OH server to bridge between the two. Using a spare phone and Tasker in this way seems like just as much work but the end result will be flakier and brittle.

You don’t need IFTTT nor Tasker for that. Set up GA integration with OH and your “I’m cooking” routine can send a command to an OH Item and do it’s thing from there in a rule.

Honestly, this is how it goes for all technologies and APIs that OH supports. To be successful you must be familiar with the underlying technology. Sometimes that means a lot of research and learning and experimentation, sometimes not so much. But it’s rarely pressing the big read easy button and it all works.

Well I raised an entire family that doesn’t know how to turn off a light (including myself now LOL) … so it’s pretty much the way it is. Every light in the house goes off after non-use after some period of time (or when told its night or when it detects we’ve left etc etc) … But I dont disagree that it cant be annoying, its always a balance.

1 Like

Yes, but you also said it was better not to provide too many ways to do things :wink:

You could put a smart plug on the washer that reports power usage and Washing Machine State Machine to determine when the load is done.

Well I’ve already have two smart Washers and Dryers :slight_smile:

But it’s rarely pressing the big read easy button and it all works.

That’s for sure, i’ve spent the last 30 years doing automation.

For the sake of completeness, I’m reposting this link from the other thread here.

It would be really interesting if we could set up dedicated email accounts for openHAB. I’ve never thought about that before.

1 Like

In APIs. We are not talking about OH’s API here.

1 Like

In APIs. We are not talking about OH’s API here.

Couldn’t resist :slight_smile:

But on a serious note, I take it from your messages that in fact the REST API is the best (and perhaps only fully supported way) to have external devices send information to OH. Correct? I’ve been playing around with the API (got my Auth issues solved) and can imagine it will meet my needs. I say this only to confirm that I haven’t overlooked something else that might be useful (in regards to the API)

Very good point … and a much better way to do it!

Most people use MQTT, which is why I mentioned it earlier. There are a number of advantages it provides which make it particularly well suited for this use case. But if you don’t want any external dependencies/extra add-ons, then yes the REST API is the only supported way to push data to OH.

I have my own little Python script that I use to integrate some of my Raspberry Pi DIY devices into OH. It supports both OH’s REST API (not updated for OH 3 yet so it doesn’t handle auth) and MQTT. I pretty much exclusively use MQTT.

With MQTT you get:

  • Last Will and Testament messages to detect/determine the online status of end devices
  • retained messages so a client doesn’t have to be online when a message was sent in order to receive it
  • control over how the messages are delivered
  • ability to monitor the messages with a third party tool like MQTTExplorer
  • if the end device supports the Homie or Home Assistant standards, openHAB will automatically discover and create the Things
  • very robust support for transformation including chaining transformations (for example, you could publish a single JSON message and have that message parsed and separate values delivered to separate Items from that one message
  • supported by almost all home automation hubs so you are not necessarily tied to openHAB forever
  • much lighter weight than HTTP calls
1 Like

Thanks Michiel … it looks like it’s active and they just moved it to here:

I posted a comment about wanting to port it to OH … thanks for the pointer!

1 Like