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.
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).
)
