-
-
Notifications
You must be signed in to change notification settings - Fork 29.1k
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
Update Environment Canada platforms #24884
Conversation
|
||
MIN_TIME_BETWEEN_UPDATES = datetime.timedelta(minutes=10) | ||
|
||
SENSOR_TYPES = { | ||
'temperature': {'name': 'Temperature', | ||
'temperature': {'english': 'Temperature', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels counterproductive to me to put translations, hardcoded, in the backend.
A user can customize entities if he wants to, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, they can. In this case the source data is available in both English and French, and I'd like a user to be able to select one of the two languages and have both the labels and the underlying data match. I'm not sure that hardcoding two sets of labels is that different from hardcoding one.
Is there a way to leverage the user selection for the front end language to drive this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't merge this, as translations are not stored inside the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback. I've moved the labels out to the env_canada
library, which makes things cleaner. Please let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is just working around the original concern raised!?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unique ID != entity_id
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you saying that I should use something unique in the entity_id
, e.g. sensor.env_canada.temperature
? I used to have this and removed it based on a comment on the original PR for this platform: #21110 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unique_id
is a property on the entity that can be implemented to activate the entity registry for the entity.
https://developers.home-assistant.io/docs/en/entity_index.html#generic-properties
https://developers.home-assistant.io/docs/en/entity_registry_index.html#unique-id-requirements
https://developers.home-assistant.io/docs/en/entity_registry_index.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I should have given more context. Thanks Martin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarifying, I've switched this over.
c943bdf
to
4949354
Compare
This update to the |
I've updated the description to better describe the included changes. |
Should this be marked as a breaking change, since the |
vol.Required(CONF_MONITORED_CONDITIONS, default=list(SENSOR_TYPES)): | ||
vol.All(cv.ensure_list, [vol.In(SENSOR_TYPES)]), | ||
vol.Optional(CONF_NAME): cv.string, | ||
vol.Required(CONF_LANGUAGE, default='english'): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we ok with this config option? @balloob?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be happy to pull this value from the front end configuration, if that's possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On sensor, yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But yeah, we should add a core language config flag
Description:
External Library
env_canada
to 0.0.18numpy
for conditions)Sensor
monitored_conditions
from configuration, create sensors for all provided dataname
from configurationlanguage
to configuration (addresses Add Language parameter michaeldavie/env_canada#2)unique_id
for each sensor (addresses Documentation is wrong michaeldavie/env_canada#3)env_canada
instead (addresses Sensors titles are badly formatted in the UI michaeldavie/env_canada#5)Weather
Pull request with documentation for home-assistant.io (if applicable): home-assistant/home-assistant.io#9747
Example entry for
configuration.yaml
(if applicable):Checklist:
tox
. Your PR cannot be merged unless tests passIf user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
python3 -m script.hassfest
.requirements_all.txt
by runningpython3 -m script.gen_requirements_all
..coveragerc
.If the code does not interact with devices: