and on the point of US-centric device support: its to be expected, seeing as Hubitat is a US company, and the US is the(/one of?) the largest addressable automation markets on the planet.
my experience (as a non-yank) has been the Hubitat team are very open to adding device support.
the question could be more about what the community in a given country/region can do to enable them to do it. they can't automagically somehow know/prioritise what devices need doing, and go around buying random products in far away countries.
in my case, i have been proactive about identifying key products that I believe will impact the most users in the aust market, and investing time and $ to send over devices to the Hubitat guys, so they can do their thing (which helps us).
I would say this is one of the issues. With a small team, they are not going to be be doing extensive research into what API has recently opened up, or what new device has come onto the market. I think that some of this needs to be on the users to identify what devices have come into play, and put in a feature request in the forum (if not emailing support too) to bring things to their attention.
As to whether they feel it is a worthy thing to add, or if they have time to add it, that is a different issue. But they have been very good in most cases about adding new devices, as well as updating and improving existing items.
Well when you have 500 or more people doing things, it should speed up the process. But from what I experienced, that speed came at a huge price of instability, and the inability to support things. I got "read the f'n manual" more times over there than I care to remember. If something didn't work, it was on that person who wrote the integration to help you, or to rewrite things, and somehow get it into the update stream.
There is no real official support channel like there is here. And that doesn't even include the horrible setup and all the mucking about in YAML to put some stupid { or indent in the right place else you break the whole thing and have to wipe everything and start over again. So I don't think things are as rosy as people make Home Assistant out to be.
I don't think Hubitat is perfect, but it is a very good commercial product and it does what it is supposed to do.
Thanks folks, there's a lot of food for thought in these replies and I appreciate the time you've taken to write them.
I'd struggled with OpenHAB and HomeAssistant in the past, and Hubitat seemed to be the "holy grail" in my search for home automation perfection - not too expensive (Control4, I'm looking at you here!), support for a significant amount of devices, and the ability to expand via user-plugins where needed. I think much of my frustration has come from needing to rely on the user-plugins more than I rely on the in-built drivers/apps, and I'd be lost without Hubitat Package Manager!
I totally get the point that as a smaller team, releases are going to be more tightly focused and that (as I mentioned in another comment) my priorities are not the same as other people's priorities, and with that in mind I'm wondering if there's a public "roadmap" or similar available so that the community can see what's coming up in future releases? A simple web-page would be awesome, a trello board would be even better! Something like the Emma Roadmap perhaps?
The ability to feed into that roadmap in a clear manner would also be amazing if it doesn't already exist. DigitalOcean have an ideas site in which folks can add things they want and the community can vote on them to help the developers understand where the demands are. As far as I'm aware, the only way to raise ideas with the dev team is to post on the forums and hope they see it/respond to it, and given the amount of traffic on here it would be unfair to assume they read every message.
In my original post, I asked whether I should be running multiple systems and it looks like the answer is "yes", so that's what I'll do.
I also asked if I should even be writing this post, and I think the answer to that was "yes" as well - it's certainly provided some good responses for me and I hope others who experience the same frustrations in future will be able to learn from those responses too!
I am just picking on Velux here as a placeholder name, I have no inside info about any of this. So don't take this as picking on this particular thing. It could have been a Smartthings sensor or a Aeotec switch or whatever.
No there isn't a public roadmap, and I agree with not having one. So many times users have been pissed off when something is promised yet it never materializes. Wink did this to us, "Big changes coming by the Hollidays!" never materialized. I think it caused more ill will than anything. A companies priorities change over time, and devices/integrations come and go. If they said "yea, we want to integrate Velux" and it never happens (maybe not even the fault of Hubitat), what would you think or do?
I had a discussion about this with someone a while back. After much discussion, and some thought, I decided it is a bad idea just like the roadmap.
So you have 500 people voting for "Velux", and 5 voting for a Zwave switch, and the Zwave switch makes it into the firmware (because it is quicker/simpler/fits timelines/skills of staff, whatever) before "Velux", what will those 500 people think? Maybe they can't even do the "Velux" do you get pissed off and move on? Or there is a mob of 500 angry people in the forums and on the support line.
In both cases, there is no winner here. The everyday users lose, the feature voters lose, the Hubitat staff loses, and so on.
Yup, and this is what happened for the "proper" driver for the Aurora AONE's, which a random comment suggested was on the way and then it suddenly turned up in a release. I don't expect the devs to come back and comment on every forum post asking for new features, and the "ideas portal" or a clear roadmap would remove the need to do so whilst keeping the customer informed.
It depends how the ideas platform is used - if there's no response to a feature then yes, people are going to get upset and either rant or move on.
If the idea is moved onto a roadmap backlog, then at least people know it's been selected for consideration and can track the progress.
A lot of my day-job these days is supporting large enterprises in how they improve visibility into their software development cycle and how they can then use that to keep their customers happy.
A huge part of this is transparency - if people can see that something is on the backlog and working its way towards the top, or is in development, they're far less likely to get angry. If they ask for something on a forum and comments are made that appear to be a commitment without any further information given and no ability to find out for yourself without bugging the developers, that gets very frustrating very quickly for all involved (especially the developer who's being hounded by forum posts!)
To come back to your point - if there was a quick justification given for the decision to develop Zwave rather than Velux ("Sorry folks, we just don't have the capacity at the moment", "Sorry folks, we're talking to Velux to make sure we get this right, in the meantime we're going to focus on this Zwave device so we're not holding everyone up") then that would be miles better than just hoping that at some point someone might read a forum post and then a couple of months later publish a driver that meets the request.
I don't think any offence is meant in the fact US devices have more support than European. Most people who contribute a driver do so for a device they own and need one for. There are more people in America than there are in England so the probability of finding the driver you need for a US device is higher than for finding an English one. Just like living in some parts of the world you're more likely to go hungry and not get medical care than others, living in other parts of the world you're more likely to be frustrated for technology support than others.
Europe population is 2.3 times bigger than USA population. Ignoring or investing in the EU should be a business decision that a company should take.
I would love to see HE team pushing more towards the EU market. More users will join and more user development will take place. Currently it seems to me ST is controlling the EU and HE is way behind. I wish this would change.
ST presumably has an advantage in international markets since it’s owned by one of the world’s largest consumer appliance/electronics manufacturers. HE has a small team based entirely in the US (AFAIK).
You've been a Community member for 2 years now and that makes me think you saw a big push for UK devices last year during one of the Hubitat Live sessions. Mike had gotten a box of engineering samples from a vendor and got to work on them. I read a LOT of the posts here on the forum and can't think of a missing device.. not because there are none, quite the opposite, I think the process of identifying needed/popular devices and getting them physically from far flung places is more difficult.
I've been here a mere year longer, but I have seen the quantity of supported devices climb very rapidly... a lot based on what devices land in Mike's lap. (Probably Brian's lap now days too.) If I needed something, I know I'd be starting a topic with "I contacted Bob at Blue Acorns and I'll PM Mike and staff with his contact info. He said if Hubitat contacts him, he'll be happy to send out engineering samples and discuss the .... " and so on. (Blue Acorns is imaginary, just as Bob is. )
My point is.. someone around here has better access to the UK vendors, if only from a TZ (and Language ) standpoint and can travel a small distance down those Company's Pre-Sales path for info that can be handed off to Staff.
The question really isn't which country has the highest population but really has the highest adoption rates for Home Automation. Just because the population is higher ( EU population is 115,096,856 higher than the US currently) does not mean the Adoption rate is. There are other considerations. Is there a standard across all of the EU, or do memeber countries have local standards? If it's the latter that population advantage vanishes. Just because there is higher population, does not mean the adoption rate is higher.
I do not know those answers, however I suspect because generally there are more devices developed for the US market, the adoption in the US may be higher than the EU.
From a purely "company centered" point of view, designing and programming an interface to another company's API is fraught with issues:
-is this a worthwhile investment of precious company time?
-will that company be there in 2,3,4 years from now?
-how many customers do they have now, and in the future? And, how many of them are Hubitat customers?
-if we do build an interface, how stable will it be? Will the company change it's API specs in a year or two?
Obviously, there are many factors to be considered. Hubitat has built some interfaces, with the Lutron one being probably the most important. It obviously can be done. In the past, I personally have recommended that the company build an interface where the other product had a very significant market presence. That way, you can always say in your marketing pitch "Works with ..."
It's a difficult decision - where and when to build an external interface. It's also a decision that I'm sure is not taken lightly.
Also don't forget to add the population of Canada (37.5 million) when considering the American market. For all purposes concerning home automation the American and Canadian market are the same.
And Mexico (130 million). While I don't know the size of the HA market in Canada and Mexico, there are several community members from both countries; although clearly more from Canada.
My current setup is simply a combination of hibitat as the central control system that leans on node-red and then a Smartthings hubless configuration as a cloud aggregator.
My setup does currently use a few cloud based API's and one thing that is clear from the few i have worked with is the cloud systems tend to just suck. The lack of standards and overall consistency with the flow of actions creates quirks. A zwave bulb will have pretty much the same functions no matter who makes it. Between two wifi devices there is no telling if a function is present and sometimes the API doesn't have all of the functions. On top of that cloud integration that don't talk back to the hub immediately and depend on pooling which adds to how cpu intensive they are to the hub.
Just compare the runtime stats for network connected devices vs local zwave/zigbee devices. The difference is nuts.
Anything that has to pool a cloud service isn't really a good choice for home automation.
Well. that's partly self evident given the paths involved but it doesn't always have to be. Manufacturers like cloud API's because it keeps them in control of the customer and allegiance to their products if done correctly. It's a handcuff situation. But cloud API's can be adequately fast too. I accept some local conditions will present Internet performance issues. My biggest issue is they go if the company ceases or are just discontinued by the manufacturer.
This also is self evidently true and polling is really awful but there are cloud based push alternatives. Polling is really a lack of implementation attention. For some devices a cloud API is the only way particularly if there is associated data that the manufacturer uses like TV listings or other live information or even passthrough transparent interaction with other cloud service like IFTTT and for these polling might be appropriate. IFTTT does a good conversion to push though.
I happen to love and prefer IP interfaces for devices. I find them so much more reliable and easy to observe than radio based alternatives. I have a difficult home for RF and the vagaries of Zigbee and ZWave routings cause unpredictable availability. WiFi works dependably for me. Yes battery powered devices are still few on WiFi but available and the emerging standards here seems to deliver. 6LoWPAN, maybe Thread, LoRaWan etc.
I use quite a few cloud services when local is not practical and in general all seem pretty good TBH. In my setup missing 'cloud' device status is not typically a problem to the operation of my system, nor does it stall the operation like awaiting information that never arrives.
Do I prefer and opt for local wherever possible? Of course... even using limited 'local' and fuller 'cloud' is often a great solution. Did I mention 'polling' is to be avoided wherever possible especially in cloud services
PS Just as an adjunct please do think about speed of response. You ask a device to turn on or you receive a message that it has. Does it really matter if the confirmation arrives in 20ms, 200mS or even 2s - typically not. Yes I agree tripping a motion sensor or pressing a button and the light turns on instantly is very desirable (and mostly achievable locally) but for most other aspects, like a room calling for heat, the doorbell or the sunrise scheduling it really doesn't matter.
Something like 
