The question is though - would the state be stored in a string that says “3.9123456789012346e+21” or “+3912345678901234567890” ?
The only way to know for sure is to create the entity and look in Developer Tools / States.
All templates are typed after resolution. Where are you trying to use this string and for what? There may be other ways to avoid the typing, but lets see what you’re trying to do first.
I see now that if the template editor had other things it gives a different output.
I just added the string somewhere in the template editor last time that is why I got it to work it seems.
However, if the string is formatted then it works.
Usually a phone number consists of country code, area code and phone number.
If you add a space in between these parts then it works as expected and generally a space dosn’t make a difference when using the number for calling.
The returned string is not recognized as phone number in international notation because, I suppose, it contains an embedded NUL character. This happens also if the string contain embedded spaces, parenthesis, dash, newlines and so on. Apparently the accepted pattern is something like \+?\d+.
I’m passing this string to the notify.sms service from huawei_lte integration (example in my post) and to another MQTT gateway sms service and both reject such strings.
Unfortunately a string with embedded spaces, newlines, dash, parenthesis is not recognized as phone number by subsequent services.
In the subsequent service remove the space with a template {{ states() | replace(" ", "") }}
this is a possible workaround, but the phone number I receive doens’t necessary have a withespace embedded
I don’t understand all these unnecessary restrictions. I don’t know of a single platform that cannot tell a phone number with dashes in it. Let alone one that requires it to always be just a number. Anyways, even if you just needed a number, you could simply just output a word then a space and the number. This would keep it a string and every platform would recognize it because it would be separated by a space. Unless there’s something you’re not telling us… which is why I asked this question that you glossed over:
{{ 'the number ' ~ '+89374982374983749827349827349872394872398479283479' }}
I already answered: huawei_lte integration, notify.sms service for example. Try by yourself, if you don’t believe me: input a phone with dash or space, try send an sms, and notice that nothing is sent! Not the only one btw, I tried also with a proprietary MQTT service to accomplish the same and I got the same failure.
Yes, but show your entire planned workflow. That tells us nothing. All we know is that you’re trying to get some sort of work around to get a number into a string when there very well could be another way. But you refuse to show what you’re trying to do from the HA side. Any notification platform uses message. If there’s a special field that requires just the number, please show that. Otherwise all these arbitrary requirements seem… arbitrary. I don’t use any of these integrations however I do know templates like the back of my hand. I also know the system very well. So instead of focusing on this one small hurdle, please explain the whole picture using automations, scripts, and services.
If it uses a normal notificiation service. I.e. notify.xyz then this will certianly work and have a usable number:
service: notify.sms_or_whatever
data:
message: >
{{ 'the number is ' ~ '+38094209343209402934830' }}
EDIT: Also if you just want the number, this may work aswell.
service: notify.sms_or_whatever
data: >
{{ {'message': '+38972834798237498237' } }}
If you check my original question there is an example of one situation where the number conversion of the template result cause a failure.
action:
- service: notify.sms
data_template:
target: "{{ states('input_text.phone_number') }}"
message: "{{ '1234FOFF' }}"
I think is self-explanatory: there is an in input_text where someone input a phone number, with or without + and international prefix, followed by sequence of digits, and at some point an automation call the notify.sms service from huawei_lte integration passing the phone number as target.
Of course, the phone number need to go in the target, not in message. Messagge accept anything.
This service call fails even if the phone number comply to the correct pattern expected by the notify.sms service.
Thanks, that’s what I was looking for. 
Could have avoided this whole back and forth expecting people to read minds.
- service: notify.sms
data: >
{{ { 'target': states('input_text.phone_number'), 'message': '1234FOFF' } }}
EDIT: I do see that you had this service in the original post. That’s my fault for missing it. Sorry.
Acceptable workaround for this specific situation.
Another I found in the meanwhile is to embed phone number string in a list. Apparently notify.sms and the other MQTT service accept a list as recipient.
Because everyone focused on providing a workaround, I suppose that there is no way to keep string as string when working with template results, wich was my first question.
Yes, that would work as well. Home assistant’s typing logic is not recursive. It only looks at the top level object and types that. So providing a dict {} or list will cause the contents to remain what they are when being pushed to whatever field they end up in. Templating the whole data field is rather new (~ circa 2021.08, 09, or 10). However many non-single item fields have always accepted lists. This will be hit or miss without you looking at the documentation.
Thanks for the {{ "{}\x00".format(x) }} reference. I have HA version sensor badges based on template sensors that would convert HA version format from 2021.12.9 to 12.9 worked great until version .10 came out and the trailing zero is lost.
Now I use {{ "{}\x00".format(states.sensor.latest_version.state[5:]) }} and it correctly reports 12.10 as the version in the badge.
1 Like
Is there a way to change the language on a string result ? I have Google Travel Time enabled and with a sensor attribute result it displays it as like 38 mins. I would love to remote “min” from results or maybe change it to my own language.
{{ states.sensor.google_ev_is.attributes.duration_in_traffic }}
Thnx, I just bumped into this problem as well when storing the audio format as an attribute value. “5.1” becomes a number and there seems nothing you can do about other than adding the string termination char.
Not sure if this char will bite me again when I start using this attribute with matching.
I understand is if nice that some parser in the background automatically determines types. But as always, there’s always an exception where this is undesirable.
Would have been nice if there was a keyword to bypass this auto parsing behavior.