Works with Alex et al

Many devices are sold as working with Alex, Google, and the other main players. I haven't looked enough to the provisioning of such devices. Is it generic enough for Hubitat to use the same interfaces or does it require working with each device manufacturer one by one by one by ...??

Who's Alex? :wink:

2 Likes

Alex is the politically correct companion of Alexa :stuck_out_tongue_winking_eye:

“Works with Alexa,” on its own, is too generic a statement to infer anything.

It depends which wireless protocols the device in question supports.

If it’s a ZHA 1.2 device that works with an echo plus, which has a zigbee coordinator in it, then there’s a pretty good chance it will work directly with Hubitat as well.

Or if it’s a z-wave device that pairs with a z-wave controller, it could still work with Alexa if the hub has an Alexa skill. Like Hubitat or SmartThings.

If it’s a WiFi device that can connect to Alexa through the cloud with an Alexa skill, then it’s less likely to work with Hubitat. But that would depend on the device. Lutron and Hue connect to Alexa via the cloud, for example, but both have direct connections to hubitat via a LAN.

Amazon product pages do tend to make these distinctions, to some extent. For example, it’ll say a hub is required to work with Alexa (i.e. it’s a z-wave or zigbee device). But to be certain you’d have to look in the details or check the product manufacturer’s website directly if the product page isn’t clear.

I don’t use google assistant devices so I can’t really comment on that. Which other main players are you referring to?

1 Like

As far as "Works with Google Assistant" all devices integrate through the cloud since no google home device has a zigbee or zwave radio in it yet. So, works with google doesn't mean works with hubitat at all.

1 Like

In general, I'd ignore the "Works with Alexa" and "Works with Google Home," etc. marketing claims if you're looking for something that works with Hubitat. The Echo Plus and 2nd gen Show do have a built-in Zigbee hub, and those devices should be able to work with Hubitat, as stated above. However, in general, what it means is that the device has some sort of cloud connection that Google or Alexa can access--and that's of little help with Hubitat. (It's not necessarily a no-go: many devices market themselves as "compatible with Alexa" and similar if used with a compatible hub, often mentioning SmartThings or similar; these devices are promising. Some also provide another interface, like Hue with a Hue Bridge that provides Alexa integration, HomeKit support, and a local LAN interface for Hubitat and others.)

If you're looking for something that works with Hubitat, your best bet is to search for Z-Wave or Zigbee devices in your desired product category. The List of Supported Devices is your official companion, but many that are not on there can be made to work with generic drivers if it's similar enough to other devices. (There are some LAN and cloud integrations, too, so check the list, but for most device classes, you'll probably want Z-Wave and Zigbee.)

Still, if you have something that only works with Alexa (or similar), say a proprietary cloud device, you can usually still manage to integrate it with Hubitat. This can be done using a Routine in Alexa and a virtual device in Hubitat that is also exposed to Alexa. For example, if you have a random Wi-Fi switch that only works with Alexa, you could tie them together with a virtual switch from Hubitat exposed to Alexa, then a rule in Hubitat that syncs the real and virtual states and a Routine in Alexa that turns on and off the virtual switch according to the state of the real switch. You'll likely experience a bit of delay with this, and reliability is dependent on both your Internet and all the third-party "clouds" you're going through. I think you can do something similar with Google Home, but I've never tried. IFTTT is another option that you could make to work in a similar manner. None is fun or as little work as something that just works with Hubitat natively, however.

I understand that.

I'm making a different very geeky point. Services like Alex, Google, IFTTT each have an interface and authentication protocol. I haven't looked into it deeply enough but I wondered if one can provide a similar service that, in effect, spoofs one of those services. It may not be the case -- each might be very special. Perhaps IFTTT is a likely starting point since it has less market clout so is more likely to use a more generic approach.

If one could leverage those closed systems than the universe of available options is immediately expanded.

It is surprising not to see more "works with Samsung" ... hmm

To clarify - I'm not trying to make one case work but hoping for a generic solution that I could use with Hubitat. And one that doesn't require getting into that far away cloud.

It may just be that I don’t have the technical background to understand what you’re looking for.

But the devices that work locally with hubitat are mostly zigbee and z-wave devices. There are some that can also communicate with the hub over the LAN.

How would the devices/services that integrate with Alexa (or Google, etc.) through the cloud be made to work directly/locally with hubitat?

And there are many devices that “work with (Samsung) SmartThings.”

I see now. I don't think anyone has done what you suggest, but I guess with enough work and reverse-engineering, it sounds like would be possible as long as Amazon doesn't change anything. You'd have to pretend to be the Alexa iOS/Android/mobile app or possibly an Alexa device (I assume you do mean Alexa). However, it seems like a lot of work for little reward. Most people are looking for integrations that go in the other direction (mostly already possible), plus...

I don't think that's likely to happen. As far as I know, almost everything you do through the Alexa app or devices requires an Internet connection, with most of the logic/processing happening in the cloud, though they did recently announce support for limited amounts of local voice control. However, it's not clear to me what extent that is currently implemented, or what types of devices this support encompasses--it should be able to accomodate any Zigbee device, but it can never help with devices that themselves need the cloud (many Wi-Fi "IoT" devices do, even ones that theoretically cloud work locally over Wi-Fi; they just don't, and the communication is cloud-to-cloud).

The reward for this is probably even less when existing intergrations pretty much allow you to do this with a bit of effort and virtual devices. :slight_smile:

1 Like

Fortunately there are an increasing number of open devices and IP-based ones. But if it's feasible it would be nice to be able to take advantages of the many devices that have tied themselves to that ecosystem.

Those ecosystems are pretty tied to the cloud.

While I appreciate hubitat’s integrations with other services that are unavoidably cloud-dependent, and the ability to remotely access things without always using a vpn, they are pretty focused on local automation. And that’s a big reason why many people here favor it over SmartThings.

I understand the cloud problem -- https://rmf.vc/IEEEContext. But I still want to use some of those devices despite the problems while accepting the risk.

Then to try to answer your original question. Yes, that is probably what it requires.

At some point I want to drill down on the particular protocols and workarounds. I can accept that the the support might require a shim on AWS or some other services. I'd use them with full awareness of the risks and exposures.

Of course I strongly favor local-first and the ability to use a simple API (like the MakerAPI) but also want access to the larger world of devices so, at very least, I can learn and experiment.

Each device manufacturer that advertises "works with . . . " will have a different API/method of communicating with the cloud platform. You would need to figure out how each of them work. It is likely none of them will be the same so things learned from one device/manufacturer will not transfer to another. You would need to craft many dozens of alternate intercepts to trick these devices into thinking they were talking to an Amazon or Google server. While your desire is admirable, your quest is likely to end in frustration and little gain. You sound determined so I wish you good luck.

1 Like