Hubitat Devices with Voice Command Enabled fail to discover in Google Home

[wposner]

I've tested this numerous times. Whenever I enable any hubitat device (switch or dimmer) via the mcsHubitat plugin, and then run the rediscovery in GH, I get the "something went wrong error". If I disable the voice command for the Hubitat device and then only enable voice command for any other HS device, GH rediscovery works no problem.

Has anyone else run in to this issue?

Thanks!
Wayne

[Michael McSharry]

Did not notice this until now. I do not use Google Home, but in the mcsMQTT forum there is a recent discussion on getting GH to recognize a thermostat. It appears the DeviceAPI needs to set and the control use set to match what HST has defined for their Zwave devices. I changed it in mcsMQTT plugin. There are no provisions in Hubitat plugin, but willing to work with you for the specific devices you are using from Hubitat.

[fresnoboy]

Did not notice this until now. I do not use Google Home, but in the mcsMQTT forum there is a recent discussion on getting GH to recognize a thermostat. It appears the DeviceAPI needs to set and the control use set to match what HST has defined for their Zwave devices. I changed it in mcsMQTT plugin. There are no provisions in Hubitat plugin, but willing to work with you for the specific devices you are using from Hubitat.

There are many types of distinct devices and traits supported by the GH API. See here: https://developers.google.com/assist...arthome/guides To have the voice control work with the highest quality interactions, you need to do the right device mapping so Google has the right context, otherwise the device mapping could throw an error. The HS folks probably would see these types of errors in their logs, so maybe they can help debug this.

[Michael McSharry]

I agree that Google has done a good job of making available an API for the GH integration. I have not seen an equivalent for the HS Skill integration for Echo, GH, etc.

The experience has been that one needs to reverse engineer what HST has done for their ZWave implementation to know how to setup the HS DeviceAPI and ControlUse so it will work with the HST GH skill. In my case I do not use Zwave or GH so I do not have a good environment to perform this activity. As you indicated there are many GH devices. There are only a handful of DeviceAPI types in HS and these seems to exist based upon equipment sold in the HS store. Similarly there are many Hubitat device capabilities. Unfortunately there is not a common definition in Hubitat. Each author of a device driver makes up whatever they want.

The Hubitat-HS integration plugin model that is being used is based upon what a user has installed on Hubitat and then I will work with the user to add it to HS. The GH wrinkle just adds to the integration complexity. It would be nice to have HST involved, but there is a backlog of HS4 issues in GitHub so my expectations are low for HST being involved.

[fresnoboy]

Are you sure mappings for HST ZWave devices only are supported? There are a LOT of other types of devices out there…

[Michael McSharry]

I really do not know what specific GH support is or is not provided. I expect HST to only do testing using devices that are supported by their other plugins and devices that they have in their inventory. This means it will be primarily Zwave since this is their primary technology. Other plugin authors may have figured out what HST is expecting for their plugin devices such as was done in mcsMQTT for thermostat.