I completely understand that there are valid, important technical reasons for this change. I’m in favor of seeing Home Assistant make progress! This change makes a significant improvement “under the hood”, and we all benefit from it. No argument there.
I also want to acknowledge — and say thank you! — to the volunteers in this thread and elsewhere in these discussions who are helping folks who are having difficulties with the change. You guys are awesome! We are grateful that you’re here and helping. I hope you’ll understand and forgive when frustrations boil over a bit and someone (me!) gets snippy in our comments here. It’s the problem with our config, not the discussion. Again, thank you!
That said, I want to offer some (hopefully) constructive feedback. I hope this will be seen as friendly and useful, rather than a complaint.
First, in the commercial software world where I work, when we roll out a feature change and it generates a slew of unexpected customer complaints and cases, we look at that as signal. Our customers are telling us something; what is it?
- Sometimes the feature is a bad idea. (Not the case here!)
- Sometimes the feature is buggy.
- Sometimes the feature is poorly documented (my job), and customers can’t fix the problem themselves by reading it.
- Sometimes the feature is great, but the transition was problematic. We didn’t understand the impact or effort customers would have to go through to adopt the change.
- Sometimes the feature misses one or more important customer use cases.
- And so on.
I hope that the folks who manage this feature area will take the time to read through this whole thread, and think about what signal is being sent. What does it mean? What improvements can we make, either to this feature, or to our rollout process, or whatever?
Second, a couple thoughts about specific comments here:
My use case is that I want to use my local backyard temperature instead of the “local” current temperature provided by the integration. That’s it. One value, from one sensor, “pushed” into the weather data used by all the rest of my Home Assistant install. Scripts, dashboards, etc.
The Template Weather Provider seems (seemed) like the perfect way to handle this. It worked great for months. It was easy to understand, and straightforward to implement.
It was not, in my opinion, a “high level” use case or advanced configuration. Certainly, I think that taking your local weather forecast but using your backyard temperature in displays doesn’t seem like an uncommon thing for people to want to do. Temperature sensors are among the easiest and most common devices added to any smart home, and “what temperature is it outside right now?” is probably the second most important weather-related question that people regularly ask. (After, “will it rain today?”, and setting aside hazardous conditions like tornados and lightning.)
So, the signal I’m sending is that the new feature design makes an important use case harder to understand and harder to implement. (The weather template docs are also…not helping.)
I very much hope that there’s zero expectation that “normal users” will hang out in the developer forums and repos, trying to parse out useful information from technical conversations that make zero sense to them.
Maybe this discussion was great, and would address end user concerns with understanding the change and its impact. But, uh, yeah, we don’t hang out there. How would any non-HA dev ever have even come across this discussion? If a tree falls in a forest…
Final thoughts:
-
Regardless of the completeness, thoroughness, and best intentions of the folks who designed and implemented this feature change, this and other discussions suggest that the full impact of the change on end users was not fully understood. I think it would be worth ask, why not? How could we do better?
-
Regardless of the quality of the implementation, and the number of deprecation and repair notices, many end users didn’t understand the implications of this change. We upgraded, things that worked before broke, and fixing it was hard. That wasn’t a good experience. How can repair notifications be made more understandable?
-
There’s no doubt in my mind that the documentation wasn’t fully updated for this change. Some doc was updated, but not all of it, or without clear and complete explanations of the new feature design and how to use it. Why not? What process changes could be made to ensure all doc for an affected feature is updated and complete in the future?
If you made it this far, what signal do you think this discussion thread is sending? What signal do you want to send? (Be constructive, please!)
