I want to switch on/off a power plug via Homey, which can only be managed via Google Home. I used to do this by installating a powerplug that I don’t even have, but that syncs to Google Home anyway. Like a virtual device, but simulated with a ‘fake real one’ 
That worked. Now I saw the new ‘Virtual Devices’ in Homey Pro, wanted to replace my fake devices by virtual ones, but Google Home Automation can’t start a routine based on a Virtual Device action (it’s simply not listed along the ‘real’ ones). Even devices created by the community ‘Virtual Devices’ app have the same problem. Strange that this problem is limited to virtual devices… How does Google Home even know that they’re virtual? Anybody any idea how to bypass, or do I have to keep using fake real devices?
Or, you can use device class ‘Kettle’ (no joke) to get a on/off switch in Google automations
I could use the Device Capability App, thank you for the suggestion. For what I need, this app seem a bit overkill, but it’s probably a cleaner solution than a fake 433Mhz device. Still, having to use the kettle class in this app suggests that Google Automation can be picky for a reason that is not known to most app developers. So I sent an incident ticket to Homey developers because I’d expect the built-in virtual devices to have the same capabilities as similar ‘real’ devices installed on Homey Pro.
It did work at some point with simple VD’s. Not sure why Google restricted it / changed it
This (for some reason) solved it for me! I tried using virtual device types for “vacuum”, “light”, “plug” etc. with no success. Some showed up in google home but would not trigger automations when activated from Homey, other simply failed to show up in google home at all.
Vritual device type “kettle” both shows up in google home, and allows me to trigger google home household automations successfully.
Thank you!
Thanks!
Still it’s ridiculous those more common device types aren’t valid anymore.
Makes no sense.
Thanks for the ‘kettle’ suggestion. I think that Google Automation only want do include devices that it can access/read-out directly and not via synchronisation. The problem is not restricted to virtual devices: e.g. Zigbee Innr plugs or lamps are not shown in Automation either. If this is true, the ‘kettle’ device may be accidentally escaping the exclusion. I’m hesitant to start building flows that rely on a bug in Google Automation
Well, in 3 years nothing works exactly as it did today anymore (IT law), just build it I’d say 
Oh, and ‘lock’ and ‘vacuumcleaner’ also (still) work in automations.
But maybe you should look for a solution without needing Homey > Ghome route.
Agree. And would if I could. I am trying to start my Roborock vacuum from Homey - and no working app/integration exists for Homey, whereas its natively added to Google Home.
The “kettle route” appears to be somewhat sketchy; its only working properly (triggering on-satte in GH when activated in Homey) one time out of five, and I havent really figured out what causes it to work/not work.
I am knee deep in trying to reverse engineer the Roborock API (or rather the implementation of the API usage for HA), to create a local web service that can be triggered via a logic REST action from Homey flows. The things you do for home automation… 
Is your model not supported by one of these apps?
Yes and no; those apps rely on the bot being paired with an older Xiaomi Mi app, not the newer and more feature complete Roborock app. They rely on the token created in the Mi app, and loans it for triggering actions from Homey.
The HA implementation uses the Roborock app apis instead. And I have managed to get what I need right now, so I can start/stop the vacuum using REST calls, while still being paired with the Roborock app 
