-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
Add entity translation strings for ScreenLogic #130708
base: dev
Are you sure you want to change the base?
Changes from all commits
dc255c5
6752337
d44e556
5c4211e
e8c0439
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -55,7 +55,8 @@ def __init__( | |
self._data_path = (*self.entity_description.data_root, self._data_key) | ||
mac = self.mac | ||
self._attr_unique_id = f"{mac}_{generate_unique_id(*self._data_path)}" | ||
self._attr_name = self.entity_data[ATTR.NAME] | ||
if not entity_description.translation_key: | ||
self._attr_name = self.entity_data[ATTR.NAME] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's this name? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Currently all entities get their name from the api. The referenced change leaves that convention in place for entities that get their name from the device (user named circuits/features), which as it applies to the integration, are There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you add some examples with what you want to achieve where? With translations set, you usually don't need to use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The api lib screenlogicpy (which I maintain) originally provided the majority of data that HA uses, for each value intended to be supported in HA.
Since moving to EntityDescriptions though, the majority of that extra data is no longer used, except for the name. Prior to this PR adding entity translations, all entities were sill using the name provided by the api lib. That's where the Some of the entities this integration exposes (like the example above) are statically named, meaning the integration knows ahead of time what value it is exposing, but there are other entities that are created dynamically. Because the ScreenLogic gateway device supports various equipment configurations there can be different amounts of circuits, pumps, and heaters (along with other equipment either present or not). Additionally, the pool controller allows the user to custom name the individual circuits within the device. It is intended for entities that expose these circuits ( Therefore for the entities known ahead of time I've provided translations for them, but for the ones not known ahead of time (where I haven't provided a Sorry it's a bit long-winded, but I thought it might be helpful to have a little context as to how the code got to where it is now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay this explains it well. I'll check the code on how we can do this the best. How do the devices currently look in HA? Is every pump its own device? Or is everything thrown under 1 device? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Everything is currently under one device. There's a mix of conventions within the Pentair ScreenLogic system that made breaking out individual devices messy and in my opinion confusing. Some equipment is presented as a stand-alone device, some are only referenced through the central controller, and some are presented as multiple devices that are only active depending on what mode the central controller is in. Because the official app presents as one point of connection/device I elected to start there. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ideally we have one device per physical device. I don't think there's a big lack of user experience if we can't do that and just put it on the controller when that's not possible. How do you mean with the device being active? Using devices is quite a nice way to not use a lot of placeholders. We can use via_device to neatly connect them to the main controller. (Also, I don't see this as a must, if we can't do that and the user experience is worse, we shouldn't, I'm just exploring at this point :) ) |
||
assert mac is not None | ||
self._attr_device_info = DeviceInfo( | ||
connections={(dr.CONNECTION_NETWORK_MAC, mac)}, | ||
|
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.
What's ORP? Should we write it out? Does pH have different translations for other languages? Maybe it would make sense to keep them as part of the translation string
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.
ORP stands for Oxidation Reduction Potential. Neither appear to be translated for other languages. Looking at the Pentair Europe site and cycling through the available languages, neither ORP or pH are ever referred to by their full name, or translated.