How are you getting
sensor.jvacaspers_intel_core_2_quad_q9650_temperatures_cpu_core_1?
I’ve never had any issues with commas in my temp sensors
This is a failure:
Value cannot be processed as a number: <state sensor.jvacaspers_intel_core_2_quad_q9650_temperatures_cpu_core_1=43,0; level_0=JVACASPERS, level_1=Intel Core 2 Quad Q9650, level_2=Temperatures, name=CPU Core #1, minimal_value=42,0, maximum_value=54,0, unit_of_measurement=°C, friendly_name=JVACASPERS Intel Core 2 Quad Q9650 Temperatures CPU Core #1 @ 2019-03-31T23:22:52.031088+02:00> (Offending entity: 43,0)
Whereas returning a 0 is just the float filter’s way of handling non-convertible strings.
You’ve mistakenly directed your question to me. I’m not the individual experiencing the problem, it’s @curryhoden.
That’s what I’d expect if the system is running properly.
If you can, at the Linux system prompt, type locale and confirm it is set correctly (de_DE.UTF-8).
Sorry Im back. It was night in germany.
@123 was right. In germany we use a comma as decimal seperator .
The output of locale is:
LANG=de_DE.UTF-8
I think the problem is the openhardwaremonitor tool running on my windows computer.
The openhardware component (running on my ha) is getting its information from the openhardwaremonitor-webserver (built-in) at my windows pc.
The ha component is reading a json file, which includes the temperature as
“43,0” -> comma as seperator.
The ha object/entity represents the json attribute, so the problem is NOT at home assistant.
BTW: i downloaded the newest version of openhardwaremonitor.
Windows 10 locale is germany
openhardwaremonitor is running in english (no language settings found)
Did you get “real” float values (43.0) in another countries?
Later i can try to set windows locale to united states.
Maybe there is the mistake.
@Codec303
I am running the openhardwaremonitor tool on my personal computer.
The tool has a built in webserver.
In ha, you can add the openhardwaremonitor component and reading the values of your personal computer at its webserver.
You will get states for each value in openhardwaremonitor
Yes, this works correctly for me:
{% set x = "43.0" %}
{{x | float}}
It gets converted to a numeric value: 43.0
Can you post a sample of the data from the JSON file? I’d like to know how the temperature is represented (as string or number).
String:
{"temperature": "46,0"}
Number:
{"temperature": 46,0}
@123 you misunderstood me.
I mean, did you get comma seperated values from openhardwaremonitor?
The value is a string.
In your conversion your are using a float value. That is working here, too.
But that is not the value we got from the webserver.
I see. I don’t use openhardwaremonitor so I can’t comment on that.
Is there any way to make openhardwaremonitor report it as a number?
My example is converting a numeric string to a float using the decimal separator native to my locale (a period). In theory it should be equally successful in converting a numeric string ("46,0") using the decimal separator for your locale (a comma). However, as you’ve reported earlier, it doesn’t. You have to replace it with a period to make it work and that suggests the Jinja2 interpreter is not using your locale (de_DE.UTF-8).
Yeah, the system locale is configured right.
And there is no way to change the output of openhardwaremonitor.
There a just a handfull settings like logging into a textfile or something else.
oops my bad, I must admit I’m not a huge fan of this forum layout
Thanks for clarifying, I’ve not heard of commas as decimal points before, but the jinja2 method to swap the , for the . may not be ideal but it’s better than nothing
Many countries do: Countries using Arabic numerals with decimal comma
That’s why I’m surprised the Jinja2 interpreter (specifically the float filter) is having trouble handling "46,0". It’s not like it’s an uncommon standard.
The computer running Home Assistant has its locale set correctly for Germany (de_DE.UTF-8) which happens to be a country that uses a comma for the decimal separator. Theoretically, Jinja2 should be handling this without a problem. Nevertheless, it’s behaving like the locale is a country where a period serves as the separator.
1 Like
Well, they say you learn a new thing everyday, I thought it was a German only thing until now. 
Quite interesting what wikipedia has to say:
Influence of calculators and computers
In countries with a decimal comma, the decimal point is also common as the “international” notation because of the influence of devices, such as electronic calculators, which use the decimal point. Most computer operating systems allow selection of the decimal separator and programs that have been carefully internationalized will follow this, but some programs ignore it and a few may even fail to operate if the setting has been changed.
Maybe there should some sort of option in the config file would allow people to select their regionial decimal point? I guess the part with your lat/long location and timezone would make the most sense.
I think the person who replied to you on GitHub missed the point about locale and focused on what float returns as a default value when it can’t convert the string.
… and then closed the Issue. 
You can set locale in python … but I have no idea how that would be done in Home Assistant nor if it influences the Jinja2 template processor.
1 Like
These are handled by custom filters in jinja, so even if localization was working w/ python in home assistant (it isn’t), you’d still need a filter for jinja. Not to mention the ramifications for yaml if you start putting commas everywhere. Everything would be a list. I think this is a no win situation for that PR. I understand why they closed it.
Wow! So that means for all countries that use a comma decimal separator, you can’t simply use float or int to convert a numeric string (and have to first replace the comma with a period).
Well that’s lame. 
Well the code was not written with that localization… You act like this is simply flipping a switch. This would be a huge scary change with many unforeseen issues alone related to lists vs numbers. I get you’re upset but honestly, is this that big of an issue? Would you rather have a better interface or the ability to use a comma as a decimal place? Also, something like that shouldn’t be a PR/Issue anyways. It should go in #feature-requests like all other enhancements.
Upset? Nah. I’m simply surprised that locale is not already supported.
It’s a non-issue for me because my locale uses a period. Lucky me. For all others, a custom filter, that can be defined for global use, would be a handy thing.
As for the PR/Issue, I didn’t post it but I feel the response missed the mark (and then the issue was summarily closed). It might’ve been more helpful had they responded the way you did, namely:
- it doesn’t work like that now
- there are implications to make it work that way
- if you really want it, post a feature request
- in the interim, make a custom filter
1 Like
I think the largest challenge will be the configuration aspect. If we (as in HA) ever get to a point where the configuration is handled 100% in the UI, this change will be much more feasible. The fact that there isn’t a layer between the backend and our configuration makes this pretty difficult. Then again, it could be much simpler than I’m making it out to be. 