I don't see it that way. Obviously that list is in reference to hubitat officially supported devices. It's not officially supported if it's a community development.
And they're not going to, nor should they, add devices to an official hubitat list that they haven't tested and directly support.
The name of the page is actually supported devices, although the content inside uses the phrase compatible devices, perhaps that could be one change they could make (supported instead of compatible). There is quite a lengthy explanation at the top of the page, though
There's a very slight difference between officially supported devices and officially integrated devices. But there's barely any daylight between two terms. So I don't see Hubitat going there either.
I do find @djgutheinz's other point compelling - his Kasa integration is a great example of a community integration that makes devices compatible with Hubitat. And, he's correct - there's plenty of WiFi devices on that list - even cloud-integrated devices like ecobee thermostats.
Agree, this was not my point. It is the terminology used in the list of "compatible" when there are other compatible devices. The term supported is more accurate.
I still think we're completely splitting hairs here. The company can only comment on compatibility with devices they have tested. They shouldn't list community supported devices as compatible.
But whatever. Everyone's entitled to their own opinion of course. The page literally says that there are other devices supported with community drivers... 
I can understand your indignation when people berate the "Wi-Fi" devices. It is, in part, for lack of understanding that not all Wi-Fi devices require cloud. Generally when people think of Wi-Fi, they automatically link the device to a cloud server somewhere in the world. Our engineers have tested plenty of local network devices that communicate with the router via Wi-Fi, then connect to the hub via local network (Lifx, Hue, and more, just to name a few).
I am sorry you feel that the title of the list of devices that our engineers confirmed to have worked as expected, is injust. We greatly appreciate the efforts that our community is making to enhance users' experience, and we so highlight that fact, by stating that the list of "Compatible Devices" is not all inclusive. The last paragraph even says:
"While this list includes devices known by Hubitat to work, there are countless other devices users have been running on their hubs. Visit our Community Devices Page to see other devices users have running on their hubs. Some of these devices use custom drivers, for which support comes from the custom driver author, not from Hubitat."
Supported has other connotations. So it isn't a good choice from a Hubitat Support perspective.
Compatible really is a good word for that list of items. Perhaps the distinction could be:
Built-in compatible devices
vs
Community-created compatible devices
The more I read through this thread and the documentation page, I feel like the paragraph @bobbyD quoted goes a long way to clarifying the distinction between the two lists of devices.
This is what makes it an “official” compatibility list.
Hubitat staff have confirmed the device works, with built-in drivers. Nothing wrong with community integrations, but they’d open a big can of worms by including community developed code in the same designation.
I agree.
But who decides which devices get included in that list?
Concur. As I said, it was a very short soap-box.
As has been brought up many times before, if someone wants to make a list of all devices and their compatibility with hubitat, feel free to do so.
Thus far no one's wanted to create it and maintain it long-term though, so having a note that there are other community drivers/integrations and to check the forum is probably as good as it's going to get.
It feels like the stepping up may have more to do with the views expressed at different times amongst the Community, perhaps more than the phrasing or documentation from Hubitat?
Threads like this will hopefully serve to re-inforce for others in the Community the views held by developers, as well as educate people along the way.
As an aside, I agree with your sentiment. There are many locally controllable/non-cloud Wi-Fi devices that can be very reliable in a home automation setup. I use quite a few myself - some sonoff, some kasa, some Arduino, some lifx, etc.
FWIW, I have encountered the same 'anti-wifi' sentiment across threads and I tried not to let it get to me. I came to HE with a smart home that was 75% grounded in wifi and I've had nothing but a stellar experience with the 150+ devices I'm running on wifi. My wifi experience on ST was rocky but for other reasons (cloud depemdencies).
Since joining this forum, I'd say I'm MUCH more cognizant of device types/longevity and I definitely steer away from WiFi when possible. Had I not already came with so many wifi devices, the persistent messaging of 'wifi is bad' probably would've stopped me from pursuing any wifi devices whatsoever.
Just being real, I legit had the same thought at the OP in the shower the other day and I said to myself "why are people so against wifi?"
I understand the challenges for some people but I can honestly say running 150+ wifi devices locally through HE with intermediate/complex automations with another 75+ zigbee/zwave devices has offered a very reliable solution for me.
Having a top tier internet routing solution is non-negotiable for this many wifi devices but barring that I'd say that one could have a very good experience with wifi devices (including timely responsiveness).
I think it's more in general like this from the communi
Wi-Fi device using cloud integration = It can work but we're not recommending it s
Wi-Fi device using 100% local access -= full steam ahead!
From Hubitat's stand point there are a couple of cloud based integrations (Google, eco bee) that's there and works for the moment. It's not really touted because they're focus is on local automation. They leave it to the community to figure out any cloud integrations but it's also up to the community to support cause they sure aren't. Local Wi-Fi stuff like Shelley and Lifx can be officially supported because they're local and in cases like Shelley, they worked directly with the company.
It's a mix of this and
This.
The issue is most people coming into home automation don't have anything more than a standard ISP router and don't know that their devices are locally controlled or not. They just want to be able to make them work together.
So this can lead to problems as they expand as if they are using WiFi devices, why wouldn't they not continue to buy them.
Hence why the device as a whole is use them but sparingly and ask question on why.
Battery devices are a no no aswell unless you happy to change batterys for a living, the cost of batterys will cover the additional cost for the proper designed for home automation product.
Correct me if I am wrong here (I generally avoid Wifi stuff).
But don't you have to:
From there, wouldn't you need to block a wifi devices access to the internet and delete that app and your account? Otherwise aren't you still (albeit maybe in a roundabout way) still sending your private information all over the internet?
With Zwave and Zigbee they talk to the hub, and that is it. No need to block devices, no extra accounts on servers of questionable origin, and so on.
So to me, there is more to it than "wifi can run local".
The discuss was not the process nor convenience of using wifi; but, that wifi works well with Hubitat. The advantage of the phone app is redundant control if your Hubitat goes off-line.
Security actions and concerns should be risk-based and the risk here is extremely low. The risk is greater from your phone, tablet, tv streaming device, and other cloud devices in your home. Until the house is completey locked down (no cell phone, pc, tablet, streaming device), a wifi appliance device provides very little comparative risk.
Of course, not using wifi devices for the garage door, locks, and other security-related activities may be a good idea. But even then, a lot of people use the MyQ garage opener.
You can also control information. Create a second e-mail address. When creating an account for the device, use this bogus address as well as bogus name, physical address, and phone number. (I think this would work - never felt compelled to try it.)
PS. I do understand the concerns. The Kasa Integration supports unbinding the devices from the Kasa cloud. Then there is no data shared with the cloud by the device even when using the phone app. (I also disable the phone app until I need it for some maintenance activity. But you could delete it and then re-add when you need it again.)
Not necessarily, I think. I believe Shelly devices, for example, have a web server that can be used to configure them directly.
And it is feasible with Kasa devices. Just more code to write an I like the second path for user troubleshooting (e.g, I can't control my switch. Resp: Check it works in the Kasa Phone App.) Hubitat (Smart Things, everything) has problems identifying device failures. The Phone App provides a second path that verifies operational status independently.
PS - I have had Kasa devices for 5 years. Never a failure. Several lamp switches turned off by cleaning lady.
Download the Hubitat app
