Trying to debug a blueprint which broke during the summer, and have tracked it down to some kind of change in how the entity attributes object works.
It seems the dictionary keys for the attributes object are no longer plain strings, but something else? You can still access individual values as if the keys were strings, but serializing an attributes object (or an object derived from an attributes object) does not work. Passing it back from Jinja to HA, the keys are weird so HA can no longer re-interpret the returned string as a dictionary.
Why did this change and how do I work around it? Is there some way to convert all dictionary keys for an object into plain strings?!
Now I will admit to not reading the release notes religiously, I mostly just skim over the big new features and then check if any integration I use appear under backward-incompatible changes, but I really cannot remember anything about this ever being mentioned…
I think it has something to do with making it so the attributes can work with the purpose-specific components and the UI autocomplete… but the autocomplete only seems to work with dot notation, not bracket notation.
What you are seeing is that attribute keys can now be enum values instead if strings. As json doesn’t support that, the values are converted to string by to_json
This was changed in the 2026.7 release and I also had issues because of it with my template weather. I used to to_json work around myself. It was discussed in the beta channel on the HA Discord server.
@petro did create a PR to attempt to solve the issue, but it was decided not to proceed with it and work on another solution, however, I don’t know what the status of that is.
Thank you, that does explain and solve the problem!
Unless there are plans to make HA understand enums passed back in this way from Jinja, surely it would make sense to always render them out to plain strings in the end?
And while on the topic of enums, is there any way to look them up in templates? Once or twice I’ve been interested in checking whether say a media_player entity supports a feature, for example GROUPING. While I can make a bitwise comparison against its supported_features attribute, that requires me to already know and hardcode the value 524288. It’d be much easier if within the template I could look up media_player.MediaPlayerEntityFeature.GROUPING similar to working with selectors in a blueprint…
This is interesting. I wonder how much this will affect me after I eventually upgrade to 2026.7. I have a dev container running version 2026.7.0.dev0 and several trigger-based entities that make heavy use of attributes, as well as a lot of javascript code that uses them - but so far I haven’t noticed any issues.
It likely won’t as a PR just went through to ensure enums are not passed in template resolution data. Probably won’t make noteworthy changes in next release, but it’s slated for 2026.10
