That is pretty much what the linked PR suggests. But the output name is an user configurable identifier.
Let me explain how I understand things: The HA requirements of unique ID aim to provide coherent behavior across services and devices. No matter if a “thing” is virtual or physical: The “thing” comes to live, the “thing” gets changed, the “thing” gets deleted. It all should behave seamlessly: The “thing” appears in HA, if changes are attributes visible in HA, they get transferred to HA, the “thing” gets deleted in HA.
For most physical things such unique ID appear naturally. For virtual things most often as well (usually a database primary key, or a UUID is used to identify a new record of a “thing”).
IoTaWatt outputs are also such a “thing”. The users creates with an intention (e.g. I want the sum of my 2nd floor power usage). So he clicks “add”, enter “Upper Floor”, enters the calculation. In Home Assistant he configures the output attributes such as Icons etc. Now he goes back, to IoTaWatt, presses “Edit”, changes the formula. That will work no matter what. Now he goes back and actually realizes he wants to name it “2nd Floor”. If we were to use the Name
as unique ID, that last operation discards all settings in HA, since the Output now has a new “unique id”. That clearly wasn’t the intention of the user. He pressed “Edit” of that output, and just changed its name…
A technical inclined user might understand that the name has been used as identifier, and that therefor the settings for that output got lost.
But I think most users these days expect things to work “more” seamless as in, a “thing” stays the same thing on both sides, is “connected”, no matter what properties I change.
I don’t want to go into politics, I just want to point out where the requirements in HA come from. They help to ensure a certain user experience.
I’ve looked at the POST requests when pressing save, and I see what you are saying. But in the end, this is how it works behind the scenes.
For me as an user, I just click on “Edit” of a particular output, and then change its properties…
Ok, but an id
field could easily be part of this configuration and not user changeable (on the web frontend). E.g. “Add” could just increment the highest id currently present, and store it along the other attributes. “Edit” would just not change the existing id
. Sure, that wouldn’t be a bullet prove method (as in, the user can fake POST
), but that is not the requirement for such an id
.
“config entries” in a HA semantics is a thing created by the user through the HA web interface (“Add integration”). The rule allows to use the HA internal identifier if it gets created by the user in HA itself and the thing has no external identifier. When the IoTaWatt (device) config entry gets created it provides an unique ID for that already. The outputs do not get created through the HA interface (“setup by a config entry”), so we can’t use that rule.