Solar system name will be based on what you set in the Tesla app (defaults to "My Home"). In some cases, when you haven't changed the solar system name in the Tesla app, it may not be present in the API data so the default name of "My Home" will be set.
Solar, load and grid power sensor naming will be based on the solar system name and sensor type. Same behavior when the solar system name hasn't been set, "My Home" will be used for the solar system name.
Details
When initializing Controller, calling a new method get_site_config and updating the energysite dictionary. This allows us to have the site_name available for use which is what you name your solar system in the Tesla app.
EnergySiteDevice retains the naming convention used for _uniq_name which combines the energy_site_id and type. The energy_site_id should be unique to each solar system, so even someone with two systems at a single home won't have issues. However, _name was updated to use the site_name combined with type.
Since _uniq_id hasn't changed, there are no breaking changes.
I did want to make sure @bassrock was in the loop as this reverts some of the changes he made in a previous pull request. The issue before was the _uniq_name was being set to the same thing when a site name wasn't specified which obviously causes issues for Home Assistant (two devices can't have the same UUID). The changes made in this pull request should not reintroduce that issue since I'm still using the energy_site_id as a part of the _uniq_name, which is no different than how it was before, just that it's explicitly being set in _uniq_name rather than using exactly the same value as _name.
There were a few other changes I did bring back, like adding the TESLA_DEFAULT_ENERGY_SITE_NAME constant. In the case where a site_name doesn't exist, I think it's better to just set the name to the default rather than use energy_site_id. This way it matches the Tesla app and you don't have a device name in Home Assistant that's just a bunch of numbers. This is just the displayed name and sensor name in Home Assistant, separate from the UUID which will always be unique.
Additionally, I reverted the self.__energysite_name dictionary back to using TESLA_DEFAULT_ENERGY_SITE_NAME for the scenario mentioned above. This is actually a dictionary that is defined by a key using the energy_site_id and value of the site_name, so even if you have two sites with the same name, they still have unique keys. It really doesn't matter though since I don't actually see self.__energysite_name being used anywhere in the code. When we set the name of the power sensors, we're just pulling from the energysite dictionary again.
To recap, the behavior in Home Assistant for a single site should be:
UUID (i.e. _uniq_name) will always be unique (e.g. 12345678_power_sensor)
Device name of the solar system will be site_name (e.g. My Home)
Sensors will be site_name + device_type (e.g. `sensor.my_home_power_sensor)
For two sites with the same site name:
UUID (i.e. _uniq_name) will always be unique (e.g. 12345678_power_sensor)
Device name should be the same with 2 appended (e.g. My Home 2) based on how Home Assistant handles devices/entities with the same name
Sensor names should be the same with _2 appended (e.g. sensor.my_home_power_sensor_2)
Fixes issue #338.
Changes
Details
When initializing
Controller
, calling a new methodget_site_config
and updating theenergysite
dictionary. This allows us to have thesite_name
available for use which is what you name your solar system in the Tesla app.EnergySiteDevice
retains the naming convention used for_uniq_name
which combines theenergy_site_id
andtype
. Theenergy_site_id
should be unique to each solar system, so even someone with two systems at a single home won't have issues. However,_name
was updated to use thesite_name
combined withtype
.Since
_uniq_id
hasn't changed, there are no breaking changes.I did want to make sure @bassrock was in the loop as this reverts some of the changes he made in a previous pull request. The issue before was the
_uniq_name
was being set to the same thing when a site name wasn't specified which obviously causes issues for Home Assistant (two devices can't have the same UUID). The changes made in this pull request should not reintroduce that issue since I'm still using theenergy_site_id
as a part of the_uniq_name
, which is no different than how it was before, just that it's explicitly being set in_uniq_name
rather than using exactly the same value as_name
.There were a few other changes I did bring back, like adding the
TESLA_DEFAULT_ENERGY_SITE_NAME
constant. In the case where asite_name
doesn't exist, I think it's better to just set the name to the default rather than useenergy_site_id
. This way it matches the Tesla app and you don't have a device name in Home Assistant that's just a bunch of numbers. This is just the displayed name and sensor name in Home Assistant, separate from the UUID which will always be unique.Additionally, I reverted the
self.__energysite_name
dictionary back to usingTESLA_DEFAULT_ENERGY_SITE_NAME
for the scenario mentioned above. This is actually a dictionary that is defined by a key using theenergy_site_id
and value of thesite_name
, so even if you have two sites with the same name, they still have unique keys. It really doesn't matter though since I don't actually seeself.__energysite_name
being used anywhere in the code. When we set the name of the power sensors, we're just pulling from theenergysite
dictionary again.To recap, the behavior in Home Assistant for a single site should be:
_uniq_name
) will always be unique (e.g.12345678_power_sensor
)site_name
(e.g.My Home
)site_name
+device_type
(e.g. `sensor.my_home_power_sensor)For two sites with the same site name:
_uniq_name
) will always be unique (e.g.12345678_power_sensor
)2
appended (e.g.My Home 2
) based on how Home Assistant handles devices/entities with the same name_2
appended (e.g.sensor.my_home_power_sensor_2
)