The “debacle” part was the decision to do it without notice and/or community feedback. Moreover, it’s not even in the traditional realm of home automation, but password hygiene, and it was automatically enabled.
Imagine discovering your favorite phone app has been doing something with your information that is a departure from its normal responsibilities. “No worries, your anonymity is ensured” doesn’t justify its unsolicited inclusion.
The way analytics was introduced was far superior; I appreciate the transparency and the fact you aren’t automatically subscribed.
The same is true of Firefox but the amount of complaint about the telemetry is surprisingly high. Then people who have switched it off complain they weren’t consulted about changes they don’t like!
I actually think the number of entities in HA is artificially inflated given the two design options to either make all values separate entities or have one entity with all values as attributes.
Perhaps it’s not the best value to put next to automations. I’d be curious to see how both compare to the amount of devices.
Given that devices are relatively new, and only integrations installed through config flow can create devices, it is best to count entities. Integrations installed in .yaml can only create entities, not devices.
Most changes to Home Assistant are made without notice (aside from release notes and to be fair to you I don’t recall this change being included in the release notes) and none are made with community feedback unless you count the community as the people reviewing GitHub PR’s and architecture issues (I’m going to hazard a guess that these aren’t the people you are referring to). There have been many security features introduced over the years without anyone batting an eye and without community discussion.
What you are pointing out is that you (and others) didn’t like a particular security feature, which is fine, hence the reversion. But calling it a debacle or trying to imply failure on the development team is wrong basically gaslighting (EDIT: as pointed out below, this was poor choice of words and in lieu of anything better I have attempted to soften the statement). Please stop that.
yeah that wasn’t the right word here. It’s late and couldn’t come up with a better one - looking for some sort of word for “boy who cried wolf”. Maybe I should have just gone with that. I started with disingenuous but that doesn’t really fit either
Probably because they didn’t cross the line of delivering personal/private information to a third party without consent. Do you recall which other ones did that?
BTW, there was the introduction of code finger-printing that employed a third-party but that didn’t share personal information (and few users were even aware of its existence unless they modified source-code).
While you’re searching for a word to dismiss my characterization of the incident, the community had no difficulty finding a word for it: mistake. To the development team’s credit they didn’t react by dismissing the community’s reaction as being “disingenuous” etc but simply fixed the mistake by making it opt-in.
Was my choice of the word ‘debacle’ too strong? In fairness to the development team and you, yes, because the mistake was rectified fairly quickly and with little pushback. It’s also dwarfed in comparison to when it was announced that Home Assistant Supervised would be deprecated. The community’s reaction was much stronger, there was far more pushback to reversing the decision, and it took longer to find a compromise.
Do you offer the analytics data in any kind of raw form? I’d like, as a core user, to cross correlate between type of installation and update in time. Do core, OS or other types of installation update more or less frequently?
Home Assistant founders estimate that less than around 20% of all users have enabled opt-in for analytics and if that is the case at 13% of the userbase there should only be around 50,000 Home Assistant installations with the ZHA integration installed, however based on the number of users on the community forum my guesstimate would be fewer users have opt-in for analytics and there and there are actually way more ZHA installations than so.
Btw, would be cool if analytics could get statistics about radio type users of ZHA integration are using.
ZHA integration today offer compatibility with ezsp, deconz, znp, zigate, or xbee as different radio type.
Data could then maybe be used as additional statistics to try to convince manufacturers to contribute.
I opted in for full telemetry for one simple reason; if the devs don’t know of issues, they can’t be quickly fixed. I don’t understand the reticence of those who opt out.
Yes and also remember that there are also alternative app stores and options to install them manually.
Hmm, again wonder why they estimate is that there are only ~5 times more installations who did not “opt in” when sounds like are more installations of Home Assistant companion apps on mobile devices?
Hmm, keep in mind that there might be more app installs than there are HA installations. I have the app on a wall mounted tablet, my phone, my wifes phone and my sons phone. That is 4 app installs for 1 HA installation. I am not saying that is going to be the case for all HA installations, but I would expect a reasonable amount of installations will have more than 1 app install associated with them.
