take screenshot of
{{ states.sensor.unifi_gateway_firmware_upgradable.attributes }}
in template editor.
and
{{ states.sensor.unifi_gateway_firmware_upgradable.attributes['USG-PRO-4'] }}
{{ state_attr('sensor.unifi_gateway_firmware_upgradable', 'USG-PRO-4') }}
The only explanation is that USG-PRO-4 has hidden characters in it. What integration is creating this entity?
This one.
Write an issue against it. The attribute should be usable. For the time being try this:
{% set key, value = states.sensor.unifi_gateway_firmware_upgradable.attributes.items() | list | first %}
{{ state_attr('sensor.unifi_gateway_firmware_upgradable', key) }}
Thank you, I will do that.
Is it possible that one of the letters in USG-PRO-4 is not simple ASCII? I encountered a problem where the value the user had posted contained a C except it wasn’t ASCII Code 67 but a Cyrillic character with different encoding.
In this thread, the OP has been posting screenshots, whereas we have been posting text. If the OP copies our text (all ASCII) to perform the tests, then it won’t match the attribute’s value if it contains a non-ASCII coded character.
Yeah, it’s a long-shot because that string certainly doesn’t look like it contains some special Norwegian character but it might be worth eliminating this edge-case. If the OP copy-pastes the text from the Template Editor’s results pane to a post, we could inspect it (assuming no conversion takes place during copy-paste).
It’s either that or hidden characters like 0x00. Either way, you and I won’t be able to see it.
Maybe not a null (not transferred in copy-paste) but it’s possible to detect non-ASCII characters by examining their hex values. That’s how I spotted the Cyrillic c in this thread.
I would, but there’s nothing to copy…
In your post you displayed a screenshot of the Template Editor whose results included a listing of all attributes.
Ah!
{
"USG‑PRO‑4": true,
"friendly_name": "UniFi Gateway Firmware Upgradable",
"icon": "mdi:database-plus"
}
yep… odd characters for sure. Here’s the ascii rep "USG‑PRO‑4"
with that being said, this should work (You have to copy this, do not type it out):
{{ state_attr('sensor.unifi_gateway_firmware_upgradable', "USG‑PRO‑4") }}
That worked, thanks!
How did you convert it to a working format? Pretty soon that sensor will populate with other attributes as FW releases on my other devices so I’d like to possibly do it myself to not take up your time 
I didn’t convert it. I just copied what you pasted ;). I changed the encoding to ascii to see what it looks like without utf-8 encoding.
As I suspected, the attribute contains non-ASCII characters. The hyphen isn’t ASCII Code 45 but a multi-byte encoded character.
The problem has been that we have been posting examples for you using standard ASCII characters and you have been using them to match your attribute. The match has always failed because your attribute contains non-ASCII characters (specifically those two hyphens).
The only way to confirm the hypothesis, that your attribute contained non-ASCII characters, was for you to post the attribute’s text. You were always posting screenshots so we couldn’t inspect the attribute’s text.
For future reference, all you need to do is copy the attribute’s text from Developer tools > States in the Attributes column. If you use that in a template, you are certain to use the correct combination of characters.
NOTE
If you’re curious to see the difference between the two kinds of hyphen, an ASCII hyphen is coded as hex 2D (that’s 45 in decimal) whereas what you have is encoded using hex E2 80 91.
Here is a sample file where the first line uses ASCII hyphens and the second line uses your hyphens. It’s impossible to tell the difference between the two like this:
However, when the characters are shown as their hexadecimal encodings, it’s clear there’s a difference in the encoding.
1 Like
Thanks a lot guys! 
1 Like