Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set icons for sensors that are in units of degrees #213

Closed
wants to merge 1 commit into from

Conversation

sdague
Copy link
Contributor

@sdague sdague commented Feb 17, 2017

This also updates the icon rotation direction based on the degrees
direction, which means that something like a wind sensor will have an
icon which is in a representative direction.

This also updates the icon rotation direction based on the degrees
direction, which means that something like a wind sensor will have an
icon which is in a representative direction.
@mention-bot
Copy link

@sdague, thanks for your PR! By analyzing the history of the files in this pull request, we identified @balloob, @armills and @robbiet480 to be potential reviewers.

@sdague
Copy link
Contributor Author

sdague commented Feb 17, 2017

This is mostly a concept patch to figure out if going down this direction is something that's worth while. Please let me know what you think.

@emlove
Copy link
Contributor

emlove commented Feb 17, 2017

You can use device_class as the semantic selector for this behavior. (This is a new feature going out with 0.39.) The first step would be a PR to add device_class support to the sensor component to replace these icon exceptions. See home-assistant/core#5881 as an example. You could then maybe use navigation, or a new device class for the rotation.

@sdague
Copy link
Contributor Author

sdague commented Feb 17, 2017

@armills yeh, I could see putting device_class into the sensors infrastructure and selecting on that. Sensors are the things I'm most interested in right now, and I think that actually semantically calling things:

"temperature"
"humidity"
"wind:speed"
"wind:gust"
"wind:direction"
"barometer"
"light:brightness"
"light:uv"

possibly others. Honestly, if there was a good existing taxonomy would just want to reuse that. That could push a lot of the guessing based on units out of the JS and do this more semantic approach.

@emlove
Copy link
Contributor

emlove commented Feb 17, 2017

Yep, this is exactly what device_class is for. I don't think we currently have a well defined list of possible classes, but that's what device_class will add. The specific names used will have to be hashed out in the PR. We don't need to come up with a complete list all at once, but once we add a class we should expect it to never change.

@MartinHjelmare
Copy link
Member

MartinHjelmare commented Feb 18, 2017

I've been looking at refactoring the unit system in HA to be more coherent. Point is that a device type or attribute type should have the same unit all over HA. Another point with this is the possiblity to group entities and attributes by type and not by unit of measure. This is important eg when logging data into a db like influxdb. The device_class concept will work nicely in that plan. I think using the device_class to look up unit and icon for an entity is the way to go.

@balloob
Copy link
Member

balloob commented Feb 19, 2017

I like using the device_class.

@sdague
Copy link
Contributor Author

sdague commented Feb 19, 2017

Ok, how should I go about standardizing device_class? Issue tracking on the main home-assistant side, then start looking at the taxonomy there?

@balloob
Copy link
Member

balloob commented Feb 19, 2017

I think that we should do like we did for binary sensor - grow as we go:

  • Pick a platform, add device classes to it.
  • Add support for device class in frontend
  • Repeat.

@balloob
Copy link
Member

balloob commented May 5, 2017

Going to close this PR as it's gone stale. The idea is still good, let's hope someone starts on it.

@balloob balloob closed this May 5, 2017
@github-actions github-actions bot locked and limited conversation to collaborators Jul 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants