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
Yes. I was afraid of that. You are the first to answer directly to the matter. I thought so from the beginning and thought that maybe I just don't understand something. Thank you.
1 Like
With all due respect, everyone, including me, has been trying to answer your question, but, despite requests (e.g., @thebearmayās request above), you havenāt provided any details.
We canāt read your mind. My powers of telepathy have vanished now that I am well into my seventies.
3 Likes
What other platforms/devices are you using? Each will have a different level of compatibility with Hubitat.
While most users prefer devices that support local (no cloud) connections to Hubitat, there are some very good cloud integrations. Ecobee, for example. There is user-developed ecobee application/driver that allows me to access features of the device that are not available in Ecobee's own app.
And there are local integrations that use WiFi to communicate with the end device. Kasa plugs and others have already been mentioned, but there are more. Again, a thorough list of the systems/apps/platforms you're currently using will help direct you to the right resources for each.
And it may be useful to start with just one, get comfortable with apps, drivers, rules, etc. before diving in headfirst and getting overwhelmed.
I see the picture. Thanks everybody very much.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
