Google Home - Actions (API) now available!

You want the highest level of security for your home network with your connected devices. Since installing openhab-cloud will require opening some ports, move your home network with your openhab server behind a second router.

You have to let openhab google assistant call backs go through openhab-cloud: some additions are needed to openhab-cloud routes. To make make your life easier with the code change, you deploy openhab google assistant under openhab-cloud directory. With this setup, do the following changes with the openhab-cloud:

file ./routes/index.js
add var googleassistant = require(’…/googleassistant/functions/index’);
add to function Routes.prototype.setupRoutes : this.setupGoogleAssistant(app);
add new function:
Routes.prototype.setupGoogleAssistant = function (app) {
// Google Assistant backend
app.all(’/openhabGoogleAssistant’, googleassistant.openhabGoogleAssistant);

file ./app.js
if (!req.path.match(’/rest*’) && !req.path.match(’/oauth2/token’) && !req.path.match(’/ifttt/’))
if (!req.path.match(’/openhabGoogleAssistant
’) && !req.path.match(’/rest*’) && !req.path.match(’/oauth2/token’) && !req.path.match(’/ifttt/*’))

Anyone interested in Thermostat functionality take a look at this PR and review. I would not add as it requires a few fixes. [NEW 1/31/2018] Also, works with CurrentTemperature only, but you need to add Temp Unit (e.g. Fahrenheit) in the item.

  • Celsius: Currently all my devices report in Fahrenheit so I have no basis for testing this (one function - isEventFahrenheit - was sending to utils folder with what looks like an Alexa skill function so I revised)
  • [FIXED 1/31/2018] Thermostat Group parsing: I did not have the coding ability to parse efficiently so it is currently set in order in the .items file:
  1. Thermostat Group
  2. Mode (String)
  3. Current Temp (Number, %.1f) - No more than 1 decimal!
  4. Setpoint Temp (Number, %.1f) - No more than 1 decimal!
  • Mode [FIXED 1/31/2018]: I only have hydronic baseboard heating, no central air so I only have one mode: Heat. I think I had some more user-side issues so I think a few of my changes to the mode section could be stepped back

Please take a look at the pull and feel free to comment, just looking to advance this as much as possible and contribute where I can!

[EDIT]: For troubleshooting your logs:

The SYNC Validator is invaluable, just paste your code in and it will check the JSON, then you can trace through your code.


1 Like

I think you might be missing the scope in mongodb, see @MARZIMA previous post on this

The fact that you are getting your OH-Cloud instance on the Home App means you are almost there…

I don’t think so. My line of thinking was, why not have a openhab-cloud with integrated google assistant back-end functionality? My personal rational was also that I didn’t have another pi lying around and that I was too lazy to setup another node.js environment for openhab google assistant.

Since I can’t post more than 3 posts, here are some additional info for the other members I cannot respond to:

  • After you have successfully installed openhab-cloud, encapsulated it with pm2 process manager. Since openhab google assistant is logging to the console, you will be able to debug using pm2 logs . This will also add the benefit of being able to automatically launch openhab-cloud when you reboot the server.

  • The account linking on Google Actions should look like this:

Authorization URL : https:// youropenhab-cloud/oauth2/authorize
Token URL : https:// youropenhab-cloud/oauth2/token

  • The action.json that you upload to Google should look like this, after you have enabled the openhabGoogleAssistant route in your openhab-cloud instance:

“actions”: [{
“name”: “actions.devices”,
“deviceControl”: {
“fulfillment”: {
“conversationName”: “automation”
“conversations”: {
“automation” :
“name”: “automation”,
“url”: “https:// youropenhab-cloud/openhabGoogleAssistant”

  • Finally, the file functions/config.js of your openhab google assistant (that you deployed under your openhab-cloud instance) should look like this:

module.exports = {
//userpass: ‘’,
host: ‘youropenhab-cloud’,
port: 443,
path: ‘/rest/items/’,

  • a few comments; since everything runs locally, a little bit more performance could be squeezed out by replacing https protocol with regular http between openhab, openhab-cloud and openhab google assistant.
  1. in openhab, the openhab-cloud binding can use a local address : http://192.168.x.x:3000/
    Note that we use http, not https; also openhab-cloud is listening on port 3000 with default installation.

  2. The openhab google assistant file functions/config.js becomes:

module.exports = {
//userpass: ‘’,
host: ‘localhost’,
port: 3000,
path: ‘/rest/items/’,

  1. in the openhab google assistant file functions/rest.js, replace all occurrences of the word https with http

A few more comments:

  • The Google Home app is buggy, so even if you got everything right, the initial synching may still not work. If this is happens:
  1. Authenticate a second time and click on ‘Allow’
  2. If the Google app forwards you a second time to the allow/deny page, do not click on ‘Allow’ a second time. Just close the window.
  3. If this still doesn’t work, try to delete the cache of the Google app and do the synch again
  • Google is still playing catch up with Amazon; you won’t be charged for testing… for know. When they change their policy, just switch to another ASR provider. Or even better, run your ASR locally, I have been playing with a few ones recently. Performance and user experience is still so-so… so sticking with Google ASR for now.

Sorry for the dupe post @atzat, I will just leave the below link which helps with OH Cloud setup below…

while you’re fixing your OAuth links don’t forget to setup your “google-assistant” scope, then make sure it’s in mongodb (look up through the posts if you don’t know what that means) :wink:

This is also a good resource if you get hung up on the https (I used the letsencrypt…its free…easy, etc.)

do you mean that google action is “not” part of cloud service?

the google action we uploaded won’t be charged when running?


Currently tearing my hair out. I got everything working, restarted my node server and suddenly Google home won’t authenticate properly. It even says “Accounts now linked” but the browser doesn’t close and no SYNC requests are sent. I have verified in the oauth2 playground that the authentication on my instance is working and I have tried restarting my raspberry, reinstalling the node server and using both Chrome and Firefox in the home app. I have also tried phone reboot and reinstalling Google home app. Please advise or confirm if you are having the same issues!

Aww man, this is exactly where I’m at on this. I’ve been following this thread for months and decided to give it a go tongiht. And now I’ve been fighting this for a couple hours.

I too get the “Accounts now linked.” but then it redirects me to the Oauth2 Allow/Deny page on my openhab-cloud instance again. If I click Allow again, unfortunately, I get this error and the “[test] my test app” in the Google Home app doesn’t show up under linked services.

0|app      | GET /oauth2/js-plugin/jquery-cookie/jquery.cookie.js?_=[numbers] 404 4.808 ms - 186
0|app      | POST /oauth2/authorize/decision 302 7.017 ms - 1516
0|app      | POST /oauth2/token 200 6.048 ms - -
0|app      | GET /oauth2/js-plugin/jquery-cookie/jquery.cookie.js?_=[numbers] 404 3.579 ms - 186
0|app      | POST /oauth2/authorize/decision 403 9.827 ms - 3034
0|app      | Error
0|app      |     at transactionLoader (/var/www/
0|app      |     at Layer.handle [as handle_request] (/var/www/
0|app      |     at next (/var/www/
0|app      |     at Routes.ensureAuthenticated (/var/www/
0|app      |     at Layer.handle [as handle_request] (/var/www/
0|app      |     at next (/var/www/
0|app      |     at Route.dispatch (/var/www/
0|app      |     at Layer.handle [as handle_request] (/var/www/
0|app      |     at /var/www/
0|app      |     at Function.process_params (/var/www/
0|app      |     at next (/var/www/
0|app      |     at serveStatic (/var/www/
0|app      |     at Layer.handle [as handle_request] (/var/www/
0|app      |     at trim_prefix (/var/www/
0|app      |     at /var/www/
0|app      |     at Function.process_params (/var/www/
0|app      |     at next (/var/www/
0|app      |     at /var/www/
0|app      |     at Layer.handle [as handle_request] (/var/www/
0|app      |     at trim_prefix (/var/www/
0|app      |     at /var/www/
0|app      |     at Function.process_params (/var/www/

I thought maybe there was something cookie related going on since there was a 404 error on jquery.cookie.js. So I created a symlink in the public folder to it and it was finally able to find the file. But I still had the same issue, so unfortunately, that wasn’t it.

I verified my oauth2 in the Oauth2 Playground, it seemed to work… But just doesn’t want to work with the Google Home app. Anyone have any ideas what would be causing this?


1 Like

Exactly where I’m as well … it used to work - but I had a (yet unidentified) problem with my items. So I decided to remove all my neatly arranged item files and start adding them one by one and reconnecting google home each time.

After I readded the third item file google home suddenly refused to work with the exact same behaviour as described above.

Google Home App either forwards my a second time to the allow/deny page or sometimes even pops up chrome with a random page I recently visited.

@blennster @gstrike I figured it out … it is a client side problem with the google home app. I just tried to add connect the smart home devices on my wifes smartphone and it worked like a charm (added my google account).

Now we have to figure out what exactly is stale - already tried to deinstall/reinstall google home app - without luck.

@Elmar Well that’s at least some good news! Since the Google Home app is launching Chrome to do the oauth2, I focused on that. I disabled Chrome and installed Firefox. With Firefox installed, it hangs at the “Accounts Now Linked”. I reinstalled Chrome. I cleared all browsing data in Chrome (for "All Time) with Chrome I get the same behavior.

So here’s a really strange piece… Just on a whim I decided to choose “Deny” when asked to authorize. The behavior was exactly the same, it even showed “Accounts Now Linked”. Sooo uhhh… yeah…


I am now at the exact same point just minutes after you @gstrike

One thing I did was that I added “timezone”: “Europe/” to the config.json which solved timezone.js errors before reaching this point with Accounts Now Linked but the app responds with “Couldn’t update settings. Configuration not changed” or something equivalent.

Holy sh*t!!!

Thank you so much @Lockzi! It was either this or the new oreo update on my OnePlus 5T that did it but it is working!

To anyone else reading this, add the “timezone”: “Europe/” to the config.json of you openhab-cloud instance and make sure the google cloud endpoint is returning response 200. It didn’t work the first try but it did the second so just keep at it.

Great! Glad I could help!

I am still not up and running though. I keep on getting the “Account Linking Failed” followed by “Couldn’t update the setting. Check your connection.”

Nothing being verbosed into the logs.

Nothing in the Google function logs? No response code? Just some pointers on the problems I had:

hostname should NOT have https:// and the path should be ‘/rest/items/’. Important that all of the ‘/’ are in the path otherwise the cloud function will return a 404.

Also make sure your openhab is accessible from your cloud instance. Try adding /rest/items to the url when you are logged in. There you can see the rest API and make sure everything that you want have the tag Lighting or Switchable.

Send me a message if you need anything else!

Hi all, just thought I would add this in here in case anyone is considering alternatives. I was hoping to avoid using any external cloud service (except google of course) like myopenhab, since I’m in Australia and latency is an issue, plus just simply avoiding relying on external services for my openhab system to work.

I found, through various posts, hints and my own experimenting, a fairly simple solution.I created an IFTTT account, created an applet to recognise commands from my home mini, and added a url with POST request as the action, directed at my openhab running on Pine64. On the Pine I installed apache and PHP and the IFTTT applet will execute the PHP script. The PHP script can do whatever you want… right now I just have it sending MQTT publishes which openhab responds to, but I intend to expand that. The whole thing took me about 3 hours to setup and get working.It takes about 3 seconds (remember I’m in Aus) from saying a google command to having the device respond; not bad I think.

Any thoughts? Any limitations? I also intend to add a reverse proxy to increase security.

Cool that you guys try it!

The Google app had a lot of bugs before. Make sure you dont search only errors on your setup. Delete app or reconnect accounts with OH cloud.

Let me know if I can support.

Thanks for that! Using ‘/rest/items/’ I seemed to get me a bit further! Once I changed it to that, it looked like it was going to work, and said something along the lines of linking… Then nothing happened and it didn’t show up as a linked account. Now, I can’t get it to do it again. It’s now behaving exactly like what it was before I updated it to ‘/rest/items/’.

@MARZIMA, you are correct. It appears that there are ALOT of bugs on Google’s side. I really want to believe it’s something I’m doing wrong. But I’ve been at this for days. :slight_smile: Very frustrating. Thanks for sticking with us though!

I’ll second this suggestion. I was having similar troubles to y’all, so I gave IFTTT a shot and it works fabulously–for me, better than a native Actions API would. For me, the chief benefit is that IFTTT can intercept any command natively. This way, I can capture any phrase and have it trigger arbitrary rules in openhab.

Similar to what @dontpanic does, I use webhooks in IFTTT to send out a POST request, however, I just go directly to the rest API in openhab (or rather, I use authenticate through an nginx reverse proxy, which hands the request off to the openhab rest api). Rather than have 45 different applets on IFTTT, I just have 5 different “master templates”, e.g. “Turn $”, “Open $”, “Close $”, “Dim $ to #”, and “Set $ to #”. These just pass to the same String Item in openhab, and I have a master rule that fires when that Item updates. This allows me to parse the phrase however I want, and all changes and additions are handled entirely within openhab.

I can supply additional info and examples of what I did, if anyone is interested. The result is rock solid and immediately responsive (at least here in the US). Note that I started off trying to use instead of my own openhab cloud instance to handle the IFTTT action (through the official openhab IFTTT action), but I found that was wildly unreliable–sometimes it would work great, sometimes I had minutes (or more) of latency. YMMV, but if you’ve got your own openhab cloud set up, I advise you to use that.