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.
3 Likes
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.
3 Likes
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.
6 Likes
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.
3 Likes
Yes - the UK Hubitat distributor - Vesternet - who is desperately trying to show their 'added value'
1 Like
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.
I'm surprised you received that response. I'm curious to know more about the context of the replies.
If you're willing to indulge my curiosity, what was the account name you had used in the Home Assistant Community forum? I checked neonturbo but it couldn't have been that account because it only created a single post (and it didn't get a rude reply).
I'm thinking about taking your approach just to get the best of all worlds. Do you have any recommendations for documentation/resources to achieve this set up? I know next to nothing Home Assistant/Node Red.
My primary focus is to set up some killer looking dashboards that I plan to mount in my house. It looks like Home Assistant dashboards look the best, and I can integrate certain device cards that don't play nice with Hubitat.
I prefer to centralize my rules on Node-RED but I have the technical expertise to handle the install and deal with any issues that might arise. You will be accepting more responsibility not less..
Here's a quick post I did with some links..
There are others that are more in depth as well.. check out the main NR thread and this other one about common palette choices..
The headline for this aging thread is a little provocative - I see no reason why we shouldn't be able to use the Hubitat in this manner. It's a testament to the power of HE and not a negative thing - after all we still bought and use HE right?
For the record I have 3 active hubs and a few more still shrink wrapped.
I suggest you open an account in the Home Assistant Community forum where all of your Home Assistant questions can be answered.
I highly recommend you review Home Assistant's current Installation instructions. Your first step is to decide what you will use to host it (I run one instance on an 11-year-old laptop and the other is on an Raspberry Pi 3B+).
Node-Red is available as an Add-On for Home Assistant. Add-Ons are applications from other open-source software projects (Node-Red, Mosquitto MQTT broker, Samba, AdGuard, InfluxDB, Grafana, WireGuard, AirCast, Portainer, etc). However, they are more than just the stock versions and have been pre-configured to work better with Home Assistant. Installation is also simplified; you install them from Home Assistant's UI.
Home Assistant provides two integrations that make it easy to use HomeKit accessories (in lieu of using a separate Homebridge).
- HomeKit integration makes entities within Home Assistant appear as HomeKit accessories.
- HomeKit Controller makes Home Assistant appear as a HomeKit hub (i.e. HomeKit accessories can register with it).
Lastly, you will want to use the community built and supported Hubitat integration (also known as a "custom component" or "custom integration" where the word "custom" indicates it is community-supported as opposed to supported and maintained by the core development team). It's a fairly mature custom integration, first released in January 2020 (see its GitHub repo).
