Yes, that is what I have tried to do, it is just laborious having to do it manually. What was the reasons for fixing this thing that did not appear to have broken?
The “reason” was in the release notes for v105.
Apparently one person asked to make more things change color based on state and that triggered a discussion that eventually led to the decision to just remove all state color changes by default…except for lights… I guess that made sense to someone who thought it would be less confusing to new people who wouldn’t understand why some things changed colors but not others. So they made more things not change colors but not everything. I fail to see how that is now less confusing. All it did was aggravate a whole lot of existing users for the request of one person.
All of these merry-go-round conversations about this state_color issue just remind me of a buddy of mine back in college.
We used to go this bar called CJs all. of. the. time. His girlfriend would HATE that we’d always be up there and that he wasn’t spending time with her. When she finally, for the 28th time confronted him - he said, “I like CJs. Live with it, or dump me”.
That’s pretty much the situation with some of these changes. For better or worse or indifferent. “Live with them or dump HA”.
Your choice. Otherwise, after a thread is closed or a dev hears the same thing for the 28th time, it’s not changing opinions / decisions - it just is what it is.
The change wasn’t 100% ok with me, but instead of ranting here on and on - I simply spent that same time (about 2 minutes) updating my config and moved on w/ my life. They changed the climate states and such back in .96 or so, I didn’t b!tch, I changed my config and moved on.
If you want to use HA, then either figure out how to code/aid in the development, figure out how/where to contribute BEFORE/WHILE these changes are being discussed, or go somewhere else. These are the same options we all have. If I was a dev and working on this and kept hearing people complain (an infinitum) about the FREE PRODUCT they’re using, it would irk me too.
Anyhow, end of my rant - just hoping people can take the AWESOME community and environment and keep it positive / constructive / beneficial for the LONG TERM development / betterment of (what I’ve found to be) the best home automation platform currently available.
3 Likes
Of course Markus is right.
Still, there’s another issue here. I’ve been involved in enough development projects to know that when the developers start feeling like the project would be so much better if it weren’t for all those pesky users, things go off the rails fast.
Ideally, we develop for the users, not to prove our own coding prowess. The job isn’t finished until users find it useful and convenient.
HA is a great product, with a committed and talented development team. Sliding into a negative attitude toward beginners and non-technical users is probably the largest risk to its success.
You simply don’t yank out a key feature that people depend on, and which users don’t understand how to fix, then say “tough luck,” if you want to grow your user base.
3 Likes
Oh, Ok so then if you are a user of some other app, free or not, then you don’t think you have the right to let the developers know that you disagree with a decision that they made that affects your use of that app?
Do you think that Harmony or some of the other ig name platforms would have backed off of their decisions that affected all of their users if there were a couple of people who “complained” (I call it voicing an opinion instead but that’s just me) and everybody else just “sucked it up and moved on with their lives”? I know exactly what would have happened - nothing.
So how many people does it take to “complain” about something before it’s too much? you said 28 as a number. Is it less than that or is that the official HA complaint limit before the developers stop listening?
I think it’s interesting that if people strongly voice their opinions about anything having to do with HA are chastised because “if your not a dev then you don’t have the right to complain about it” but I was listening to the HA podcast the other day and the guest was “ranting” (his words not mine) about a product and the hosts said something along the lines of “it’s OK to voice your opinions about something you don’t like because it just shows that you are a passionate user of the app and just want to try to make it better, if you didn’t like it then you would just move on to something else and not say a word…”.
Exactly.
It’s always said that “we are all beta testers”. So if we are the testers then what’s the point of us testing things if we can’t give our feedback on the changes and the way things are heading - good or bad?
exactly…
You understand that you’re bitching to the community and not to the developers right? That’s why I’m always a dick to people who complain. Dev’s don’t cruise the forums, they don’t have the time. Create an issue on github and move on. Discuss it in the issue.
3 Likes
My point is that this specific issue has been discussed for the last 3 weeks, in 12 different threads and, to be honest, the horse is dead, let’s all stop kicking it.
That doesn’t mean I can’t also agree w/ @CaptTom as well, - as I am certainly not blindly siding w/ the developers. I admitted that I did not ‘like’ this change, and would have preferred more discourse before it was unilaterally decided upon. I think I even commented in this thread (or another [can’t recall, there are too many on this issue alone…]).
The other thread was all about putting a product / project manager in between the devs and the users - to monitors these forums, get proactive (before the change[s]) feedback and such - but that takes time and $$s and dedicated person, etc…
Someone also posted this link (https://github.com/home-assistant/home-assistant/pulls?q=is%3Apr+is%3Aopen+label%3A"breaking+change") which is open discussions about breaking changes - feel free to visit early/often and comment on where/how you want things to be.
1 Like
But it’s not an issue. It’s a feature.
the issue won’t get discussed. It will just get shutdown because the devs have already decided and they don’t have the time (as you say) to keep re-hashing the same decisions.
I know there are a few developers who pop in on things here and there and maybe if one or two sees enough of a groundswell of complaints then they might decide to look into it.
If one user writes an issue and nobody else comments then we’re right back to you being the only one who doesn’t like it because everybody else “just moved on”.
And even if no one of any import is listening it’s still a bit cathartic to yell into the void on things. 
Actually the funny thing is that even tho it’s been discussed for three weeks in 12 threads adrusa asked why the decision was made and I was just simply explaining to them what they missed. Of course with a tone that showed my displeasure. Apparently they didn’t see those other 12 threads… 
I wasn’t just “bitching about it” again for no reason.
What a stupid change. It should have been put in the UI like the “Show header toggle” instead of hidden like this before turning it off for everyone.
Could this - and possibly other similar challenges - be partially solved by tweaking the way !include works, to allow you to set some global values in a global yaml-file, and simply include that in every other yaml-file?
At least for people not using the GUI-editor.
That way, we could simply create a “common.yaml” with something like
card_anchor:
<<: &entity_card
type: entities
state_color: true
(...whateveer other stuff you "always" set for your entities-cards)
And replace the card configs with
cards:
- <<: *entity_card
(...settings and values for this specific card)
Currently, all anchors are local to the file they are defined in, so you would need to add all the anchors to every file, which makes them a lot less useful…
no tweaking necessary.
anchors:
state_color: &state_color
state_color: true
cards:
- type: entities
<<: *state_color
entity: sensor.xxx
etc: ..
But you cant put the anchors in a separate file and !include it.
My lovelace config currently consists of 25 yaml-files, and it would be really helpful to be able to set all “default” values in one file and include that in all the others. Especially for cards with lots of options and long configs.
But also for cases like the one discussed here.
You should move to lovelace_gen, you wont have these issues.