Thank you. But the “customize:” mechanism written up here, if I understand it correctly, basically lets YAML accomplish existing configuration that HA uses, such as the icon of an entity. What I am suggesting is along the lines of what michaelblight wrote above, something that will only have meaning to my scripts and automations. Probably a single dictionary associated with each entity that is just “dumb storage” would suffice.
Am I misunderstanding the documentation? Or is there an unintended effect of customize: that will “create” attributes that HA doesn’t use, so that my own scripts and automations can use them? If that’s an intended use of “customize:” it doesn’t really come across in this documentation (and it would seem like a somewhat arbitrary place to be discussing that mechanism, surrounded by discussion of HA configuration). If it’s the latter, it’s possibly useful, but also makes me nervous that it’s a behavior that might break or change in future releases.
You can absolutely add an attribute that way, and many people have.
Thanks for this piece of info. I’ll do some experimenting to get a better sense for how it works.
I suppose another way this problem could be solved is by an integration that simply keeps track of a giant dictionary and provides some basic service calls to set/get from the dictionary. I have never tried to write an integration but seems theoretically possible.
I think the only bit that is missing here, is to be able to change the attribute value from an automation/script, taken from a template, for instance.
Bdraco spent the first half of this year massively improving HA DB performance. The primary way he was able to do this was by reducing or eliminating attributes that change frequently and then de-duping the ones that remained in storage.
Your suggestion here seems like it would pretty much roll all this back. Now every entity can have a massive dictionary of mutable attribute data that is completely unpredictable and therefore can’t be indexed or optimized really. It would also be quite difficult to use since attributes themselves are difficult to use and actively being discouraged.
Perhaps I’m wrong but I think for performance HA would strongly prefer user-mutable state is isolated to helpers. You’d probably have better luck pushing for variables.
Unless what you’re asking to attach arbitrary but constant metadata to entities. Attaching constant metadata to entities via customization is fine and already possible (as has been mentioned earlier). The mentioned optimizations work well with that already since that’s what the de-duping was about. But if it can change then stuffing it in attributes isn’t ideal.
This is interesting insight. I was definitely not looking at how something like this would affect performance. If performance costs scale reasonably with the amount of state and/or how frequently it changes, could still consider offering it on a “caveat emptor” basis, just to avoid the maintenance of having to perform separate configuration to add helpers each time new entities are added to the system. But if the issue is that offering enough mutability to support this feature requires a baseline performance toll, even if the feature is then used to store exactly one attribute for one entity, I guess that’s an entire different story. Though since performance is just fine with helpers, it makes me think we’d be looking at something in the former category.
(And definitely give a lot of merit to the “if it isn’t going to scale right, it shouldn’t be a feature, since people are going to abuse it and blame the product rather than their own incompetence” – which might in and of itself be enough to defeat the caveat-emptor point.)
this attributes should be restored on reboot, because if they are set and lost on reboot they would be unusable.
Sorry but how do you use customize to add a user attributes exactly? Couldn’t find that configuration variable on Customizing entities - Home Assistant
Look at the “Manual Customization” section at the bottom of that document. My understanding, which I haven’t yet tested, is that you can add dictionary keys there that will then become accessible along with other elements of an entity’s state. I am not sure if you can do this via the UI; the section of the documentation is focused on YAML.
You can’t. There used to be a customization section in settings in the UI but it was removed. I can’t remember what release, it was a while ago. Although if memory serves it only allowed you to create attributes with string values, if you wanted to put a dictionary in an attribute you always had to do it in YAML.
This is about as user friendly as chewing on glass.
Adding extra information (call it whatever you want) to an entity or device should be through available through the UI.
The provided link and explanation points to documentation that explicitly narrows the customization down to “look and feel of your front page”. If there are more possibilities is is not clearly documented (if at all).
I would love to add a flag to an entity that is accessible through the system, for example identify devices that are wall powered versus battery powered, or define that a device is using a CR2032 or 3xAAA batteries. At time of discovery, the option can be presented to add user entities, or extra info to an entity.
You could open a WTH about it, assuming there’s not one already.
I logged in here to make the same suggestion. My thinking is that every entity in HA could have a “userData” property that we could set ourselves. Because it would all be stored under that property, there wouldn’t be any conflicts with other properties in the entity. I envision assigning an object created using JSON to that property.
My current use case: I have sensors and other items that have batteries. I have created an automation to send me a notification when a battery needs to be replaced. I would like to store info as to what type of battery I need to buy. This way my automation can include that info in the notification that I receive on my phone and I won’t have to go find out what type I need to buy.
I’d rather store it as part of the entity itself instead of in helper entities just because that would create a maintenance nightmare. In the meantime, helper entities will have to do.
Just add an attribute via customize.yaml. The likelyhood of this being built is low because the tools already exist to do this.
Hello
I am trying to add a custom attributes to a climate entity using a value of a select sensor yet it is not working as expected is that not possible currenty?
customize:
climate.ph_office_mqtt:
mode_auto: "{{states('select.penthouse_office_auto_level_2')}}"No, it’s not.
Thanks for the reply. I have been in the rabbit hole for 2-3 hours on this great to know it is currently not supported instead of me doing something wrong 
What are you trying to accomplish? Maybe there is a different way to do it.