Replacing IFTTT (Google Assistant -> WebHook) with OpenHAB

OpenHAB newbie here.

So, I’ve currently got IFTTT set up with a number of Applets that will trigger off a Google Assistant command to do an HTTP GET to a local server that will execute a command. Something like:

http://ip:port/command/?cmd=

All of the commands are basically stateless executions.

For example

If I say “Hey google, play morning playlist”, it will GET "http:/X.X.X.X:55555/command/?cmd=morning-playlist, which cause the playlist to play on my speaker group.

I have other commands connected to a Raspberry Pi with an IR emitter, so I also can say:

“Stereo on”
“Stereo off”
“TV on”
“TV on”

The IR codes for the above are non-toggles, and there is no state information available from my old A/V equipment. So if I say “Stereo on” and it’s on, it will stay on even after the IR command is sent.

I’d like to drop IFTTT (for reasons I won’t get into here for now), and it seems like OpenHAB (along with myopenHAB) might be capable to do the same thing for me. However, I’m a bit overwhelmed as I’ve been surveying it, so I’m coming here for advice.

I’m trying to work out the basic “model” I need to set up. It seems like OpenHAB is geared towards “stateful” things, but what I think I really want to model is a virtual remote control, where I have a bunch of “buttons” that do tasks.

Q1: Is this possible with OpenHAB?

Q2: Can I do this all in the Web UI? Or do I need to go to manual config files?

Q3: I’ve been playing with the “HTTP URL Thing”. Is the right approach to create a Channel for each command I want to execute? Is it correct that I want to set the “Command URL Extension” for each channel to something like “?cmd=morning-playlist” (where I have a URL like: “http:/X.X.X.X:55555/command/”)?

Q4: If “HTTP URL Thing” is the right way to go, how do I properly create a link to the channel for a “stateless” button?

Q5: I haven’t yet experimented with this yet, but I see some docs that say to expose the items to Google Assistant, I need to create bindings. It’s not clear how I should do that. Do I want to make my virtual remote control system look like a “Scene” device to Google? Or is there a better choice?

Maybe I’m not even approaching this in the right way, and need a course correction.

Thanks for any guidance you all might have!

yes

possible with just UI config, no manual config files

openHAB has a bit of a learning curve, read the docs, start with the concepts section then load it up on whatever you’ve got and start having a play, when you get stuck, come back here and ask questions

Thanks Andrew! I’ve done as you suggested already, which brought me to questions 3 and 4. I’ve been overwhelmed by what I’ve seen, and just want to make sure I’m on the right track. Do you think using “HTTP URL Thing” is the right approach for implementing stateless triggers in my situation?

yes, you need HTTP binding, hence concepts section, bindings are add-ons for each different type of technology

I have something similar to what you’re asking, which is an IR fan that I control with a Logitech Harmony Hub. But before we go there, I agree with Andrew that you should get comfortable with the basics. I always recommend figuring out how to turn a light switch or smart plug on and off before wrapping your head around more advanced concepts. It’s a lot easier to grasp how the system works, because it removes a lot of complexity.

And to directly answer your question, I don’t use stateless triggers. I use items, which enable openHAB to know the current state of the device that’s being controlled via IR.

@rpwong Thanks. Yes, I did manage to get a one of my Wifi Kasa switches working pretty easily. The problem with the IR driven devices is that there is no way to know the state of them. So if the Pi-driven controller turns it on, and another hand controlled remote turns it off, any manufactured state can easily become incorrect.

Yep, that’s pretty much it. This is a common problem with trying to automate IR devices. I use Logitech Harmony Hubs to control my TVs, and they also get confused if you keep using the original TV and cable remotes. The difference is that the Harmony Hub comes with a remote, so there’s no need for the originals.

Google Assistant requires that you have openHAB items with metadata, which enables them to be found and controlled. You can see all the different types of devices here (including TV).

If you want to treat them as stateless, fire-and-forget triggers (so that you can use other remotes), make a switch item for each command you want to send, and then expose the switches to GA.

Then you can tell GA to turn the items ON, and each item will trigger a rule that:

1. Sends the appropriate HTTP command
2. Resets the item to OFF (so that GA will respond to it in the future)

EDIT: Per Rich’s comment, the rule isn’t necessary. I got confused between the core HTTP actions (which can be invoked in rules) and the HTTP binding (which you can use to create things and items).

The downside to this is that all of those items will show up in the Google Home app as individual switches. That doesn’t matter if you don’t use the app regularly, but it might otherwise be annoying.

I haven’t used the TV functionality in Google Assistant, so I can’t help you much with that. You can experiment to see if it can replicate a dumb remote control, but I have a feeling that it relies on knowing when the TV is ON.

The half-and-half solution would be to retrain yourself to only power on/off the TV and stereo using Google Assistant, enabling you to use remotes for everything else. That way, you could have a single item for each device, and openHAB would always know the states. Personally, this is what I’d do. After you get used to turning your TV on and off with voice, it becomes second nature.

Yes. Just because a Switch Item holds a state doesn’t mean you have to pay attention to it’s state. Sending an ON command to a Switch that is already ON will still cause that command to be sent on to the device (in this case the HTTP Thing).

You can also apply Expire to the Item to automatically flip it back to OFF (or ON) after a given amount of time so the state of the Switch acts like a momentary button push. But that’s not strictly necessary except in cases where the Item is linked to a Binding that cares.

There is also the concept of trigger Channels but those depend on a binding implementing them which isn’t going to be the case here with the GA integration. GA only can send commands to Items so you are stuck with working with Items. And all Items have a state. But you can choose to ignore that state.

You can do this all through the Web UI.

I don’t use HTTP binding myself but your description seems reasonable. Typically one would create a separate Thing per device. If your only device is an AV system then I’d expect there to be just the one Thing.

Just link it to a regular old Switch Item. The fact that it keeps a state can be ignored. It doesn’t have any practical effect in this case.

You do need to install the openHAB Cloud Connector binding and create and configure myopenhab.org account. Then you need to apply Item metadata to each Item you want to be able to control from Google Assistant.

Doesn’t the HTTP binding support calling a URL when an Item receives a command? I would have figured that would be a basic capability. I admit the docs do not make it clear one way or the other. If not then yes, a rule with sendHttpGetRequest would be required.

In some cases it makes sense to create Routines in Google Assistant. For example, I’ve a Switch Item that represents my Garage Door Opener. It’s awkward to say “Turn on the large garage door opener”. So I’ve routines that map “Open the large garage door” and “Close the large garage door” to “turn on the large garage door opener”. Whether or not the Switch Item is already ON or not doesn’t matter because the ON command will still result in the MQTT message (in this case) being sent to trigger the opener.

It never occurred to me to try, as I only use it in rules that have other things going on already. :wink:

Ah, I didn’t think Google Assistant would send an ON command if it knows that the device is already on. If that doesn’t matter, then yeah, the expire/reset isn’t necessary. It’ll just always appear to be on in Google Home.

Looking at the docs, it could be clearer by noting that the thing can be used in an item, but I just got confused. I installed the HTTP binding intending to look at this, but ended up just using HTTP actions in my rules (since I didn’t need items). I struck out that text in my previous comment to avoid further confusion.

@rlkoshak @rpwong Thanks for the tips, guys. I’ll dig into this more this weekend when I have time, and report back with what I come up with for my setup.