Virtual Device not supported by Google

🚧 Developers
1

I've created a simple driver to switch my Sonoff Mini on and off, all the device is, is a 'Switch' and that's the only Capability.

I can create a 'Virtual Device' and specify the type as 'Sonoff Standard' (the name of my driver).

This works perfectly within the Hubitat web page, I can switch my Sonoff device on/off by pressing the buttons, but when I try to add it to Google Home, the logs show an error of.

The following devices are not supported by Google Home and will be removed from your device list: (mysonoff)

What is it that's preventing this device from being controlled by Google, does it not like the fact that it's a Virtual device?

...Update...

The device is a local LAN/Wifi device, and it's called 'Sonoff Mini' SONOFF MINI - Two Way Wi-Fi Wireless Smart DIY Switch

2

I'm curious - why not use the built-in virtual switch driver?

1 Like
3

Mainly because I didn't know there was one specifically for this device, I couldn't find one, and every article I read seemed to be talking about complex instructions about flashing roms and soldering stuff.

I'm also just interested in learning groovy and understanding how these things fit together.

What driver are you referring to, and will this allow it to be controlled by google?

4

If you're interested in figuring out why your driver doesn't work, my guess is that all capability attributes (for capability "Switch", this would be just the switch attribute) were not initialized to a valid value. On the device page, you can tell from whether the "Current States" section shows anything for this attribute. The Google Home integration seems to reject devices that don't have a valid value for some or all attributes that are required by devices of capabilities that it supports.

Something like this works for me as-is, but you could also just manually run "On" or "Off" on your switch from the device page to populate the attribute with a valid value. I'm just setting this one to "off" on installation (by running that command, but sendEvent directly would also work):

/**
 * Basic Virtual Switch Driver
 */

metadata {
    definition (name: "Virtual Switch TEST", namespace: "Test", author: "Test") {
        capability "Switch"
    }   
}

void on() {
    sendEvent(name: "switch", value: "on")
}

void off() {
    sendEvent(name: "switch", value: "off")
}

void installed() {
    off()
}

void updated() {
}

But to second @aaiyar, Hubitat already has a built-in Virtual Switch driver that should do everything and more (it has auto-off built in, for example) compared to the above one. Like the above, it would work with Google Home. I don't see any mention of what real-world device you're talking about, but sometimes you can use virtual switches as workarounds for integrating devices that don't integrate directly (via another service like Alexa, GH, or IFTTT), so I assume that's what you're doing. No soldering required for virtual Hubitat devices, but maybe something for the real-world device? :smiley:

PS - I'm assuming this isn't the problem (and it might not even save as such), but capability "Switch" also has a lowercase "C" in "capability." It's generally most helpful to share the code you're working with if you are asking for help on it, but I'm guessing the problem is the above and not this.

2 Likes
5

Thanks for your response, I have edited the question to include a better description of the device I'm trying to integrate.

As I said above, the device is working fine within Hubitat, but it just isn't accepted by Google Home.

I didn't have installed / updated methods defined, but I've just tried, and it still comes back with the same error from Google. Within the on method, I'm just calling a simple http-post command, but as I said above, this is working fine when running within Hubitat.

Ahhh.. I've just tried again, I had added the 'sendEvent` method call (as you included it in your code above) and tested, and it didn't work, but I tried deleting the virtual device, then re-adding it, and now it is accepted by Google, I reversed the change (removed the sendEvent commands), just to confirm that this was the difference, and re-added it, but it continued to work, but once I deleted the device and re-created it, it then stopped (which is what I would have expected).

It is now working perfectly, and it seems that the issue was the lack of the sendEvent method call in the on/off methods.

Are these method calls always required?

thanks

6

If you want to update the switch attribute (or whatever name you're passing in sendEvent()), then yes. For real-world devices, you might wait to hear back from the device (doing so in the parse() method that would be called for Zigbee or Z-Wave reports back from the device, for example), but for virtual devices with no real-world device behind them, it's typical to just generate the event in the on() or off() command itself (as if it "worked"). For pseudo-virtual/LAN devices that actually do have real-world devices behind them, you might choose to still "optimistically" generate the event in this manner anyway unless you have a way of hearing back from the device, but if you can, the other way seems preferable to me since it's more accurate.

But either way, you'll need to create an event somehow. No event, no attribute ("current states" items on the device page). No attribute value and Google Home isn't happy. There is nothing built in to the platform that generates a "switch" event just by you (or a user) calling the on() or off() command, for example--the driver has to do it.

A related point: many Hubitat apps don't like it when standard attributes have missing (or null) values, so if you claim to implement a capability, it's good to make sure that all attributes get populated with a value (either requested from the device shortly after installation, or perhaps just initialized with sensible defaults if it's virtual). Google Home is a "popular" place where this issue seems to come up, but it's not unique.