If you turn on the GHC logging (inside the app) and look at the Hubitat logs, you should be able to see that. On a "heh google sync devices" you will get the dump of sync packets. When you try to access the device, the same coming back from Google.
I believe if it's an oAUTH issue, you should get error messages in the Hubitat logs.
I'm seeing an oAUTH issue over in the Google Actions dashboard but all my credentials and tokens seem correct, per the instructions. I'm not an expert enough to understand if oauth is really my problem.
When it comes to GHC logs I can see some debug output that seems perfectly reasonable:
app:502021-05-20 14:50:07.328 debug{"requestId":"17596934120528609864","payload":{"devices":[{"id":"28","type":"action.devices.types.CURTAIN","traits":["action.devices.traits.OpenClose"],"name":{"defaultNames":["ZemiSmart Zigbee Blind"],"name":"Living Room Bookcase Shade"},"willReportState":false,"attributes":{"discreteOnlyOpenClose":false,"queryOnlyOpenClose":false},"roomHint":null},{"id":"30","type":"action.devices.types.CURTAIN","traits":["action.devices.traits.OpenClose"],"name":{"defaultNames":["ZemiSmart Zigbee Blind"],"name":"Dining Room Shade"},"willReportState":false,"attributes":{"discreteOnlyOpenClose":false,"queryOnlyOpenClose":false},"roomHint":null},{"id":"hubitat_mode_Day","type":"action.devices.types.SCENE","traits":["action.devices.traits.Scene"],"name":{"defaultNames":["Day"],"name":"Day Mode"},"willReportState":false,"attributes":{"sceneReversible":false},"roomHint":null},{"id":"hubitat_mode_Sleeping","type":"action.devices.types.SCENE","traits":["action.devices.traits.Scene"],"name":{"defaultNames":["Sleeping"],"name":"Sleeping Mode"},"willReportState":false,"attributes":{"sceneReversible":false},"roomHint":null}]}}
That log message means you don't have an OAuth problem. If Google gets as far as syncing devices then it's successfully authenticated. What do you see in the Hubitat logs when you try to open or close your shades?
That icon is really more of a "Google doesn't have an icon for that type of device". In this case, Google doesn't have an icon for curtains. There's an icon for blinds, if you really want an icon, but those aren't controllable via the phone app either, so you won't actually get any more functionality.
I have a dashboard setting and can manually control these just find. Here's a bit of example log while they're closing:
dev:282021-05-20 16:45:25.988 debugupdatePosition: position=18
dev:282021-05-20 16:45:25.971 debugupdateWindowShadeMoving: position=18, lastPosition=20
dev:282021-05-20 16:45:25.967 debugparse: moving to position 18
dev:282021-05-20 16:45:24.050 debugupdatePosition: position=19
dev:282021-05-20 16:45:24.046 debugupdateWindowShadeMoving: position=19, lastPosition=20
dev:282021-05-20 16:45:24.039 debugparse: moving to position 19
dev:282021-05-20 16:45:23.003 debugupdatePosition: position=20
dev:282021-05-20 16:45:22.997 debugupdateWindowShadeMoving: position=20, lastPosition=22
dev:282021-05-20 16:45:22.994 debugparse: moving to position 20
dev:282021-05-20 16:45:22.011 debugupdatePosition: position=21
dev:282021-05-20 16:45:22.008 debugupdateWindowShadeMoving: position=21, lastPosition=22
dev:282021-05-20 16:45:22.000 debugparse: moving to position 21
dev:282021-05-20 16:45:21.002 debugupdatePosition: position=22
dev:282021-05-20 16:45:20.998 debugupdateWindowShadeMoving: position=22, lastPosition=24
dev:282021-05-20 16:45:20.993 debugparse: moving to position 22
dev:282021-05-20 16:45:20.024 debugupdatePosition: position=23
dev:282021-05-20 16:45:20.020 debugupdateWindowShadeMoving: position=23, lastPosi
Is that fixable by adding other skills that Google knows how to interpret, or something like that?
I mean what gets logged when you try to control them via the Google Assistant.
Sort of. Google documents which device types and traits have touch controls in their various interfaces on this page. The Google Home app does not have controls for any shade/blinds/curtain device types or the Open/Close trait. You could call your shade a switch and add both the Open/Close and the On/Off traits. That way you could retain the "Hey Google, open the blinds" voice command and maybe get a button in the app.
I’m try again to be sure but I’m pretty confident the answer is “nothing, I get an error in Google Assistant”
ok, so not an explicit error. My Google Assistant actually understands and responds "sure I'm closing the shade" but nothing actually happens to the motor. Here's the log from HE:
dev:282021-05-20 18:37:05.471 debugupdatePosition: position=0
dev:282021-05-20 18:37:05.468 debugupdateWindowShadeMoving: position=0, lastPosition=0
dev:282021-05-20 18:37:05.465 debugparse: moving to position 0
app:502021-05-20 18:37:05.084 debug{"requestId":"5594568545503351924","payload":{"commands":[{"status":"PENDING","ids":["28"],"states":{"online":true,"openPercent":0}}]}}
app:502021-05-20 18:37:05.081 debugDevice Living Room Bookcase Shade not ready, moving to PENDING
app:502021-05-20 18:37:04.979 debugZemiSmart Zigbee Blind: Expected value test returned false for attribute windowShade with value opening
app:502021-05-20 18:37:04.876 debugZemiSmart Zigbee Blind: Expected value test returned false for attribute windowShade with value opening
app:502021-05-20 18:37:04.773 debugZemiSmart Zigbee Blind: Expected value test returned false for attribute windowShade with value opening
app:502021-05-20 18:37:04.671 debugZemiSmart Zigbee Blind: Expected value test returned false for attribute windowShade with value opening
app:502021-05-20 18:37:04.568 debugZemiSmart Zigbee Blind: Expected value test returned false for attribute windowShade with value opening
app:502021-05-20 18:37:04.466 debugZemiSmart Zigbee Blind: Expected value test returned false for attribute windowShade with value opening
dev:282021-05-20 18:37:04.453 debugupdatePosition: position=0
dev:282021-05-20 18:37:04.450 debugupdateWindowShadeMoving: position=0, lastPosition=0
dev:282021-05-20 18:37:04.447 debugparse: moving to position 0
app:502021-05-20 18:37:04.363 debugZemiSmart Zigbee Blind: Expected value test returned false for attribute windowShade with value opening
app:502021-05-20 18:37:04.260 debugZemiSmart Zigbee Blind: Expected value test returned false for attribute windowShade with value opening
app:502021-05-20 18:37:04.157 debugZemiSmart Zigbee Blind: Expected value test returned false for attribute windowShade with value opening
app:502021-05-20 18:37:04.056 debugZemiSmart Zigbee Blind: Expected value test returned false for attribute windowShade with value opening
app:502021-05-20 18:37:04.052 debugPolling device attributes for 1000 ms
dev:282021-05-20 18:37:04.041 debugsetPosition: position=0
app:502021-05-20 18:37:04.033 debugChecking MFA for Set Position command
app:502021-05-20 18:37:04.024 debug{"inputs":[{"context":{"locale_country":"US","locale_language":"en"},"intent":"action.devices.EXECUTE","payload":{"commands":[{"devices":[{"id":"28"}],"execution":[{"command":"action.devices.commands.OpenClose","params":{"followUpToken":"[redacted]","openPercent":0}}]}]}}],"requestId":"5594568545503351924"}Ah, it looks like your device considers position 0 to be fully open (aka 0% closed), while Google uses position 0 to mean fully closed (aka 0% open). To confirm this, you could try asking the Assistant to open the shade 75%. If my guess is correct, it will extend the shade to cover 75% of the window, while 75% open should only cover 25% of the window. I actually have an old issue to add a "reverse direction" toggle to the Open/Close trait for this situation that I never implemented because the specific driver that prompted it got updated. Since there's another example of a backwards driver I'll try to get that implemented.
As a workaround, you can set the "Discrete Only" toggle in the Open/Close trait and use the open and close commands instead of setPosition. That won't let you open the shade partially though.
Oh yeah using the reverse of the expected commands is working. I’ll play with the discrete idea for now. Awesome!
Update 0.31.6: Add a Reverse Direction toggle to the Open/Close trait
Some devices (primarily window shades) use position 0 to indicate "fully open" and position 100 to indicate "fully closed". This is the reverse of what Google uses, so this update adds a toggle to support those devices. @mexpsdw this should resolve your issue.
So far so good. The toggle shows and I have analog percentage available! For the record your temporary solution worked fine for me, too (in case anyone wants discrete only for some reason!).
I have two follow-ups and it's fair if neither of these are GHC:
Sounds like something timed out. GHC got the request from Google, but took to long to respond. My guess would be a driver that blocks until its action is complete. Drivers' command handlers should generally send their commands asynchronously, but some will block and wait for the command to finish and cause the app to time out.
Or it could be something else entirely. ¯\_(ツ)_/¯
That seems like something the device or device driver should handle to me.
I hope this is the right place to ask. I am setting up my first device and new to hubitat. I have one LED white controller that works on the hubitat itself. (well, that's another story because I can't get the dimmer tile, etc. to work in the dashboard. I can only turn it on and off)
My main issue is that I set up a google mini home speaker and added hubitat to the google home app on my iphone. I was able to tell google to turn it on and off, but then started to try to get the dimmer to work and everything stopped working. So, I deleted the hubitat from google home app and now I cannot re-add it. I get "the parameter "state" must be set in the query string". I have already tried several of the ideas out there but cannot get it to work.
Yup. It turns out the fundamental problem is that I was traveling between the UP and MID points without realizing it so the open-to-percentage commands were doing weird things.
Has anyone managed to get this app to expose a fan with speed control to google home?
I have setup speed control in GHC but GH just shows an On and Off button for a fan. No speed control.
Traits appear to be setup. What am I doing wrong here?
The Google Home mobile app does not have UI to control discrete fan speeds. You can control fan speeds via voice commands.
You can also select the fan speed on Nest Smart Displays, but unfortunately not on the GHome app.
I think I know the answer here, but GHC is exclusively getting SensorState from the Google cloud API, right (as opposed to the local Nest detector device)? I'm asking to that I can understand how things will behave (1) if Google's Cloud does down, is slow, etc and (2) if my environment gets fully airgapped -> will HE local execution ever get inputs about smoke such that it can do anything? (probably not)
Correct, all communication is done via the cloud right now. Google does have a local exec API, but it's not currently used by GHC.
GHC also never "pushes" any data to Google; it only responds when Google asks for something. That means that for something like a smoke detector it won't be able to push alerts to you. Again, Google has an API for that, but it's not implemented due to Hubitat platform limitations. @bhamiltoncx created a feature request for what we would need, and the Hubitat devs didn't seem to be against it, but there's not been a concrete answer yet.
Gotcha. Just out of curiosity do you have any existing plans to do anything with the local API? Obviously my use case is specifically about push alerts and that's a whole different problem (thank you for mentioning that relevant detail!), so ignore that example and think more about thermostats or some other device you might wish to control locally.
I'm not asking for any features, I'm just curious what may or may not already be in your plans. I don't think my ideas here are sufficient to justify that level of effort.
Download the Hubitat app
