Thank you - Raised
and also avoid things like
which in turn supports this
and I understand and agree
especially if they spent plenty of time making their UI useable and consistent and now it looks weird again because someone did something ‘logical’ from their point of view (as it was decision of 3-5 people as far as I understand). so we’re all reaping the results.
Well… as previously said the very same changes could be done better, much better using different approach.
2 Likes
Can we get a solution to set all state color to true?
I used it on all my devices before and it helped a lot to just get a visual confirmation.
I loved the update for the thermostat, when it activates the heater now it turns orange:)
Now it just need a color when it miss behaive
- The temperature is out of range lower or higher then set temp.
- heater/fan is “unavailable” or if it is not turned on, when it supposed to.
- temperature sensor is “unavailable”
Hello all,
First off, just want to highlight that changes to the project are not done in the shadows and feedback is always welcome. There was a lot of discussion on this PR that led to the final decisions: https://github.com/home-assistant/home-assistant-polymer/pull/4510.
I see quite a few people asking for things to be cross-posted here in the forums for more feedback/visibility and frankly, I just don’t see that being viable. Lots of PRs are from one-off contributors. We’re already hurting for contributors as it is and to make them post over here as well before we merge something is an obstacle that most won’t want to go through.
I’m a fairly regular contributor, but even that is a big ask for me. I do this in my free time; I’ve got 3 kids, a wife and trying to work on my own HA setup. And like I said before, all our PRs are open to the public, our Discord channel as well.
That all being said, I can feel your pain. I too had to go through my large configuration and added state_color to my cards as that is my preference for entities card. If you have a large config that you need to update, my best suggestion right now would be to copy your config to an IDE like Visual Studio Code (release 1.38 or higher), and do a find replace on
type: entities
and replace with
type: entities
state_color: true
Watch for indentation issues.
I really hope you don’t truly think contributors, myself and core devs included, are out to hurt you. I honestly thought this would be a great improvement to the UI and still do. Like I said, I too use this on a daily basis.
Lastly, I do plan to add the state_color option to button and glance cards as well as the state-icon element for those of you that want to turn off such indications. Feel free to provide feedback on the PRs when I submit them. You can subscribe to the frontend repo to get notifications if you wish. I’d recommend turning off email notifications though and just check them periodically if you want to keep your inbox at a sane level 
~Ian
11 Likes
Thanks Ian for your hard work and for the answer.
I think many of us understand you very well.
However, as it was your PR and after its merge there were many omissions showing that the merge was a bit rushed and it could benefit from a brief consultation with the community I just want to ask to think about the situation calmly and maybe try gathering more feedback before implementing such dramatic changes next time.
Of course, ideally it should apply to all of us.
And I’m not teaching, just voicing my opinion as a member of the community and a user of this great system.
Thanks again!
Thank you for such a detailed response. And thank you for continuing to work and improve HA! I think this change makes HA much better, people are just complaining that they want more control over it.
Any plans to add an option so you can globally set this variable or even change color in a config? Similar to how custom UI does it? There was a feature request about this, but I didn’t think it was actively being worked on.
Again thank you so much for your contribution!
No, I don’t think so. At the very least it is not something I will not work on as it is really just a stop-gap to avoid adding this to your cards. Which I can understand can be tedious for updating an existing large config, but should really not be a big issue going forward, in my opinion.
1 Like
It was in the beta for a week and no complaints were raised during that time. A PR open for a week and a week in beta is, in my opinion, far from being rushed 
I also can’t keep my ear to all the feedback on the forums. There is a LOT going on here 
I focus mostly on what is happening on GitHub.
Gotcha, so no plans for color state options? It would make it sooo easy to set up how state colors behaves for different entities. For example, using Custom UI (which is buggy as hell but somehow still works) my global config looks like this:
"switch.*":
templates:
icon_color: if (state === 'on') return '#fdd22f';
"binary_sensor.*occupancy*":
icon: mdi:home
templates:
icon_color: if (state === 'on') return '#FF1C8C';
"binary_sensor.*window":
device_class: window
templates:
icon_color: if (state === 'on') return '#5a5a5a';
This is easy as I can just name my entities a certain way and they will be colored accordingly.
Not by me I’m just one dev though and a selfish one who usually makes thing that I want 
I could see an icon_color option being added to cards, but I doubt it would be done the custom UI way, i.e. globally. But if icon_color becomes a thing, a custom solution to set those by templates becomes much easier.
I actually proposed icon_color previously, but don’t recall why I closed it…https://github.com/home-assistant/home-assistant-polymer/pull/3956
Ian, (I presume) that’s because most of the beta users are the very same people who propose changes or make PRs. I personally only update when .2 comes out as I cannot afford disrupting my setup. (I also open issues and sometimes make PRs, but not as great as yours 
)
And still, I think now you have at least 2 FRs on your hands related to the lack of functionality in various types of cards making them difficult to use after the change. We can call it whatever we want but it could have been less stressful, and it’s not only about time - more importantly, it’s taking into account users’ opinion.
If you meant that 2 weeks was enough for everyone to get familiar with that PR… I don’t know who reads all these PRs before they become part of HA. I got a link to it from the release blog when we discusses “why could it happen at all?”
but did you try to gather it? like a poll or something? if no, then yes, you can’t
I believe you and that’s great, really!
However,
it’s ok but do you really think that your discussion with @SeanM and @balloob could for sure take into account needs and use cases of say, 50% of HA users registered on this forum alone (50% of roughly 50k If I remember it right). Or 10%?
I’m happy either way as I can see HA progressing. But its progress ultimately relies upon its user base, which in turn is directly influenced by relationship between users and developers, by the way developers respond to their needs and issues - just because users are here if the product satisfies their needs.
Beta users will stay for sure as that’s their hobby, what about the majority? Everyone (both developers and users) should understand that.
1 Like
I can understand frustrations on all of that, but at the end of the day, I’m just a guy who likes poking around in a project in his free time. I don’t really want to be more than that.
I mean, we try not to break things, we try to make informed choices, we try to make things better. But asking me or anyone really to talk to 50k users, to do case studies and user polls and filter through all that to make a change to icon coloring…that’s not something I’m going to do. But I’m not a core dev, I’m just a guy, trying to have some fun and make cool things
3 Likes
Got it, thanks
2 All: is everything clear now?
I’m not entirely convinced that “no news is good news” during testing. No complaints may also be a result of:
- superficial testing
- exclusively focusing on pass/fail
In contrast, within a day of the feature’s release, members of this (large) community forum were reporting on its impact (reported in this thread and others and in GitHub).
I feel the community is a resource that ought to be leveraged earlier in the development process.
1 Like
Except that he is creating code, not just consuming it and, therefore, his point is also very important.
This sounds reasonable at first, but it ends up just opening a can of worms. All communities would (rightfully) want equal treatment. This forum has 55k users but the Home Assistant Reddit community is even larger. So it’d make sense to discuss it there as well, right?
Now you’re already up to 3 different locations, why not make it 4 or 5 and poll Facebook and Twitter too? Where do you make a cutoff that doesn’t make certain sub-communities feel left out? And now if you only participate in the forums (as several people here have indicated), you’d only be seeing a small fraction of the entire discussion. It quickly spirals out of hand, and places a very large burden on the contributor too.
GitHub is specialized for this exact purpose, the frontend repo has a feature request template and a bug report template. Things can be labeled and organized into roadmaps, easily cross-referenced and searched, etc. It’s far more efficient for all involved if the pre-release discussion happened there.
And this thread already has a good example of the current system working fine, @TazUk raised a valid issue using the proper avenue and @iantrich is adding support for it. Ian also improved the icon coloring for alarm control panel yesterday as well (here) based on feedback. Feedback is always welcome, just try to raise these issues in the proper spot for them.
2 Likes
Fair enough. I’ll monitor future frontend developments on GitHub (and chime in if I feel I have something worthwhile to add).
I wish the backend repo also had a Feature Request template. The current template explicitly states that Issues are for bug reporting, not feature requests.
This forum has a Feature Requests sub-section but, as everyone knows, that’s where ideas go to die (i.e. very few are ever implemented).
FWIW, I’ve commented on some PRs in the backend repo but, typically, only if the PR affects me directly. Overall I would say most developers are open to suggestions.
2 Likes
I agree, that’s a very accurate description of the Feature Request forum.
Most of those ideas (ie new integration support) require the purchase of expensive hardware, learning or reverse engineering an API, hours and hours of coding, etc… So it’s somewhat understandable that very few of those requests ever get implemented. I assume that’s the main reason feature requests aren’t allowed on the backend repo, they’d be just as dead/ignored over there too, with the additional downside of making it harder to find bug reports etc.
But feature requests are very much encouraged on the Frontend repo. A big focus right now is on making Home Assistant easier to use, and there’s now a full-time employee (Bram) focused on the frontend, so it’s been getting a lot of attention lately. Any ideas, critiques, feedback of any kind is appreciated there
My point was “he’s not the one who gives green lights” and he clearly is not in the position to address this completely non-developer issue.
I never underestimated his opinion.
I’d discuss that. Is this forum a part of HA ecosystem? I mean, it looks like part of https://www.home-assistant.io and people can access it from the main page of HA website.
There is no links to Reddit group there, is it? And I think we don’t need it - I believe it’s clear that if you want to know about something about a product/have an issue with it/want to be heard you head to the website and do it there. So I’d call this forum “an official HA forum”. Does anyone need more than one? I’d say no. There can be numerous “unofficial” ones but there is no need for more than one.
And on this premise your reasoning is not correct. HA authorities have the right channel and plenty of opportunities to gather user’s feedback. Here.
How about the majority, mere users. They are often far from programming at all and not that proficient in finding ways to that “holy Graal”, let alone the fact there is no clear link from HA’s front webpage to its Github repository.
Yeah, it is possible to break a leg and then heal it (but it won’t be as new anymore). We’re suggesting here some measures how to prevent breakages because it’s less painful (if it’s your leg, of course).
I believe there are different types of feedback and HA needs both. You’re talking about reporting issues. We’re asking for a feedback about upcoming breaking/serious changes as it can easily eliminate a lot of after-break issues. You just cannot say it’s the same, can you?
I know it can slow down the development process a bit but it depends on how it’s organised.
It seems like it’s down to @balloob/HA management (as there should be some), not to contributors. They need to integrate this bit into the development process and make sure the good balance is achieved.
I hope they can and will do it.
FR graveyard, very grim place.
I don’t think the majority of them are for new integrations support. I have a feeling it’s core enhancements (like ability to use variables in templates) so I have to disagree here.
Way to nowhere, honestly. FRs should be collected and regularly and carefully considered/re-evaluated (as HA evolves) by a panel and then prioritised. Some of them will be rejected, but not all.
That’s great. But in the last few days I saw at least two issues related to this state_color change closed swiftly with a short “it’s by design” comment. No further explanation given. So what do we have out of that feedback? Nothing. Would the person who opened such an issue do it again? Probably not as it’s not the greatest experience.
I know people are different and there are rude users and kind devs but it’s wrong to threat all users as an unnecessary annoyance when they bring you a new issue and ask for help. (I’m not talking about you @SeanM, you’re great!)