Offer both ULO and TOU rates as separate entities?

[nwf]

In the interest of doing some long-term retrospective analysis of our power bill, would it be possible for the integration to offer, as two different entities, both the ULO and not-ULO rates simultaneously? Having to pick just one is kind of a bummer.

Thanks!

[jrfernandes]

You can add more than one provider. Once you add one, customize the name of the added entity before adding a new one.

[nwf]

I must be doing something wrong. I have deleted all devices from the integration; added the non-ULO device; then renamed the device, the entity, and the entity unique name... and yet I am still told "Device is already configured" when I try to add the ULO one. :(

[BJamin99]

I have the same issue. I've changed the name and the entity id, but still comes back that it is already configured when trying to add a second one.

[BJamin99]

I think I found the reason. Config_flow.py sets unique_id to the energy company name. Unique id is static and therefore two entities for the same energy company cannot be added to do this.

await self.async_set_unique_id(energy_company) self._abort_if_unique_id_configured()

[BJamin99]

I've never developed an integration, so I feel like I might break something if I try to fix this. Anyway, I've started to do it and wanted to record a few notes on this so hopefully someone can fix my errors!

The main issue is in config_flow.py where the unique_id is set to the energy company. While I understand it may be helpful in the majority of cases to block duplicate integrations, I'm not sure it is as big of a deal to accidentally have duplicate entities than to outright block the addition of a second entity. To that end, I've removed the setting of the unique_id (my assumption is that a guaranteed unique random value will be assigned if one isn't specified by the integration itself).

The second issue is that in coordinator.py there was a use of the unique_id to grab the energy company. As the unique_id no longer contains the energy company, this would break the integration. As the energy company is set in configuration data, I've replaced that assignment to use the energy company recorded in the config data.

There is a third spot where unique_id is used. That is in sensor.py. This one I'm not sure what the impact on the system is for changing it, and I'm not sure how necessary it is. What I see there is that the OntarioEnergyBoardSensor object is being initialised with the unique_id, which is stored in an attribute of the instance (_attr_unique_id). But other than that, I don't see _attr_unique_id being used by the integration itself. What I'm unsure of is if there is code in HASS that uses that attribute. But I'm thinking that even if HASS does use it, it doesn't matter if that value isn't the energy company any more. The other thing that I was thinking is that there may not be a need to have the entity_unique_id in the ObtarioEnergyBoardSensor constructor, or to set _attr_unique_id to the entity_unique_id. But as this goes beyond what I know, and it probably doesn't matter for this change, I've left it.

I've opened PR #53 to start this change.