It would be so, so nice if user-assigned state could be easily associated with entities. Right now, a helper is needed, and while that is a viable way to keep track of user-assigned state, it is a maintenance hazard that requires configuring a helper for each new entity that needs user-assigned state.
I am not sure about the implementation, but it should be fairly easy to just add and/or remove dictionary entries to a special user-assigned state attribute of an entity. It would streamline advanced automations so much.
If I’m hitting a paradigm clash here where HA has a preferred way to do this that doesn’t require maintaining helpers separate of entities such as lights and sensors, or this suggestion reduces to an absurdity when considered in view of how it would actually work, I am happy to be defeated on this suggestion.
You cant change the state of an entity permanently (it gets updated on the next scan interval to the true value) you can actually set an attribute of the entity and it will be maintained until you change it.
It’s done using the “customize:” option for entities.
Thank you for this reply. I just did a quick Google search and didn’t locate this (but, “customize” is kind of a hard term to use with Home Assistant docs for any specificity–for good reason…) Could you share a link to the docs, if you are aware of one? This could help me out quite a bit and I wasn’t aware of it.
This is an oldie but a goodie. People have been asking for user-defined state for a long time - and I assume the OP does not mean the usual “state”; just the ability to store your own “stuff” (ie. other state).
It would be nice if entities had “attributes” as well as “user_attributes” and the latter only ever got changed by user code. I have used “customize:” before, but it’s very clunky for dynamic user attributes.
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.
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.
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.)
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.
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.