But how can you be sure the cats are alive.... 
Sorry.... not helping....
1 Like
They are both alive and dead until @brianwilson's camect integration detects a cat and reports to HE that the cats are alive.
3 Likes
SchrĂśdinger's cats????
EDIT: Thank you to The BIg Bang Theory TV show for the education on what SchrĂśdinger's cat is.
2 Likes
If you want to be explicit.... 
Easy for me to extend the humorous tangent I started, but we should probably get back to @user4785 's original questions about cloud-hosted devices....
@thebearmay 's most recent questions about the kinds of devices is the most revelant questions at the moment I expect.
2 Likes
@user4785 Ok here is the thing. SOME wifi devices are directly supported by Hubitat because they have a local API. Shelley, Nanoleaf, Lifx to name a few. Other wifi devices that are cloud based (Like Tuya) have community supported integrations but they will remain cloud based because that is what their API exposes. But of course not all wifi devices have an API that their manufacturer allows.
The best way to keep things local is to use z-wave/zigbee/clear connect devices (the last requires the Lutron Pro 2 hub but is fantastic).
Now for controlling anything from your phone, it will be local when you are on the same network. It will switch to using Hubitat's cloud servers for control. (Or you can use a VPN to bypass them)
And lastly for myself, I prefer automation over remote control myself. I have one dashboard just to monitor a couple of things.
3 Likes
Feel bad for leaving Dan out of the list of people to refer to.... He seems to have come up with a popular set of steps for migrating a HE hub...
2 Likes
What forces from the dark-side have you exposed him to.... Does this mean I should uninstall my Harmony integration.... Will it start directing me to more and more commercial television... (Moving even more away from @user4785 's question's now... )
2 Likes
Just for clarity âlocalâ can mean via a hub. For example Philips Hue lights can operate in all three roles I believe.
You often use a Philips Hue Hub that sits in your home and the bulbs attach directly to this. So does the HE integration and so the control is implemented over your local WiFi or wired Ethernet via the local hub and a separated Philips only ZigBee network to attach to the bulbs
OR you can pair each bulb individually directly to the HE hub
OR the Philips hub actually connects to Philips and their cloud. This allows an app to be installed on your phone (or even HE) that talks to the hub allowing remote control of your Hue setup
And/or you can expose any HE device inc. Hue remotely via the HE Dashboard
OR you can integrate via Appleâs HomeKit using HE and both internally and externally. HomeKit was essentially a cloud based system but recent updates are offering local operation too.
Lots of approaches and different for each device but you can unify the presentation to say one dashboard. There are devices that require cloud and those that are always local and some that offer both.
Thereâs homework to do here for each of the devices you have, as mentioned above. In some cases even the local transport is selectable e.g. whether to use WiFi or a radio network like ZigBee, ZWave or newer things like Matter.
3 Likes
Well yes but my interpretation of local means just that, local with no internet access needed.
1 Like
People have differing views of Ethernet/WiFi transport and radio protocols like ZigBee, ZWave and soon to be Matter.
The most usual one for Ethernet/WiFi is speed, reliability, bandwidth and long distance bridging but these devices are rarely battery powered.
The Z networks typically support battery operation and quick retrofit but can be less predictable.
I use wired for my lighting and security and IP where possible elsewhere or bridging is required, dropping to Z radio devices where retrofit is difficult or battery operation required.
That suits me really well and works brilliantly. For those with stable Z networks they will have very different views. Horses for courses.
2 Likes
Thatâs mine too.. weâre saying the same thing, just because it uses a hub doesnât mean itâs cloud based. Cloud required for control/status is to be avoided wherever possible.
One of the other aspects to consider though is firmware updates if you donât have manufacturer cloud access.
The OPâs path is going to be primarily mandated by HE local support / drivers..
3 Likes
Friends, everything that was said and emphasized about the advantages of the local network is fine, but it really does not answer the first problem I raised. If my items all work with cloud wifi and a server and let's say they all have the HE driver and I connect them to Hubitat, then what has changed? They still use WiFi in the cloud and on the server. The Hubitat can only be used here to execute scenarios and run on the dashboard. Isn't that so?
If you stick to devices that can ONLY be integrated through their cloud app, then true. However, some community members have created integrations for some devices that actually makes them local (generally by sniffing the packets and reverse engineering them), and there are some native WiFi integrations that are local.
I would be happy to hear how to do it. However, does this mean that for example, the items that are activated on Wi-Fi in the smart life application will communicate with the Hubitat directly? Are the scenarios saved in the Hubitat's memory?
Well, you also have the device abstraction that allows Hubitatâs Rule Machine to âexecute scenariosâ (your language) on collections of very dissimilar devices. Most WiFi-implemented mobile apps only work with devices from that appâs manufacturer.
Rule Machine (or, I guess, webCoRE, which I donât use) is one of Hubitatâs greatest strengths over other platforms. Home automation is just that, not Dashboard control (which I donât use).
1 Like
Your answer is very general and does not answer my question at all. Either I'm not explaining correctly or you didn't understand me completely. My question is completely specific and the answer should be an execution process. My house includes Wi-Fi items in the smart life application through the cloud and a web server. I want to integrate Hubitat c8, what should be changed / done and how it will work. How it will make the network from external to local. that's it.
If your devices are WIFI and Cloud based, they will likely still be cloud based if you integrate them into hubitat. And that is IF you can integrate them into hubitat. For instance, you would have to use @kkosev's Tuya cloud integration to bring your Tuya wifi devices in and they would still remain cloud based as there is no local integration API for them and likely never will be. Ewelink has the potential to be local since I believe it's zigbee but will require a custom driver. Marcus's may work. But as I said, if anything you have at the moment is cloud based and IF it can be integrated into Hubitat it will still be cloud based. The recommendation from everyone here will be to get new devices in zigbee/z-wave/clear connect
LAN devices, including WiFi devices, lie in two categories:
- Those that strictly communicate with a cloud server. So any integration is dependent on the manufacturer of that device providing an API for a Hubitat developer to write an integration. When this happens, that integration woud still be a cloud integration.
- Those that communicate with a cloud server but also provide a defined local API. Hubitat developers can write an integration to control these devices locally using that local API.
An example of the first category would be MyQ garage door openers. Examples of the second category would be LiFX bulbs, Yeelights, TP-Link Kasa devices, the Philips Hue bridge, the Lutron Caseta Pro and RA2 bridges, and Shelly devices.
@adamkempenich has described a proof-of-concept approach to control SmartLife devices locally. You may wish to pursue your question further in the thread linked below:
1 Like
