This is (currently) only happending, if last digit is 0, compare to this
Any ideas on this, as it is working in developer tools, other cards, etc. but the card author says, that it is not a problem of the card, because is rendered via the HA backend and that the template is getting sent to the backend and the result is displayed.
Can you first confirm your locale format for numbers with decimal digits?
The above screenshot show a number with decimals. zeros at the end of the decimals would normally be truncated, just as leading zeros before the number would be truncated, e.g. 0100 becomes 100.
Similarly, should your value be 1.000, you’d end up with 1
This is standard practice.
That being said, if you wanted to force your number to look like 1.230, I think there’s a bug which may require an issue to be created:
the data returned is automatically converted to a number if it thinks it’s one:
Sometimes the unit messes it all up, because then HA sees it as a number and the remove lead zeros and trailing decimal zeros.
Try removing the unit line and see if that change it.
If it does, then try to add the unit to the value_template line instead.
You are both right. Thanks for bringing me in this direction.
However this don’t make any sense for me, that
HA ignores, that I put it as |string as in lolouk44’s first example, what I can confirm as well.
HA convert to a number, independently from the local number formats. Here in Germany . is thousend and , is decimals. Here in this example it sees the . as , and the string as number and removes the 0. Makes no sense. Same if I use {{ "{0:_.0f}".format(1230).replace("_",",") }} then it returns 1230 instead of formated 1,230
Now I know, what HA is doing (whyever), but don’t have a solution for this special problem in this card, becaus neither I don’t want to put another string after the string only that HA uses it as string, nor want to put % as string and not as unit, because then the formatting from the picture is of course gone.
I have had a little success before with html tags, so if you add </font> after the number, then it will often write it as you want, since the </font> tag is invisible when rendered.
This didn’t work, but that brought me to search for invisible and non-spacing characters and used Method 1 from https://emptycharacter.com Method 2 added another space, so if you still want it centered, you should use it in front and after the template. But method2 really added an invisible non-spacing character, and now HA is accepting that a string is a string.
You cannot even see it in the editor, but only in the html result afterwards, so it is still somehow risky in terms of maintenance, because you cannot see it after pasting it.
But I would still prefer that HA is taking strings as strings and not trying to do unwanted magic, which results in 1230 instead of 1,230 or 1.23 instead of 1.230
The “unwanted magic” you are referring to is Home Assistant’s support for native types. The template result’s appearance determines its type.
In other words, if the template produces a result that looks like a number, its type will be number (that’s why your numeric string is converted to a number and numbers don’t have trailing zeros in their decimal portion).
But how to avoid this in the situation above? Or what would be a proposal for a work-around in the given situation (without adding invisible unspacing character)?
Even if |sting is ignored? Or as it is ignored, that the frontend number format is set to German, where . is not (!) a decimal portion, but , is?
To be clear: I like such features, but in this cases, there has to be always an option/switch/whatever to overstear this.
You’re misunderstanding how native typing works. It doesn’t matter want kind of filters you use within the template. It’s the template’s final result that is interpreted. If the template’s result looks like a list, it’s handled as a list. If it looks like a number, it’s handled as a number.
Shortly after native typing was first introduced, there was a request to provide a manual override but it was rejected.
O.k. But then there is another solution for the problem? Or in such cases where a string of a wanted, formated number, you are lost without any solution?
You already discovered the workaround; make the string contain a character (visible or non-visible) that prevents native typing from interpreting the string as a number.
Not that important, but for me more a dirty hack for a missing real useful solution for such cases. And if it would only such a solution, that I can place whatever documented escape marks around these cases. But of course, if not available, I have to live with this design gap.
