I lost count of how many times I answered that question.
I thought, I could get away without saying something to this, but it is still the same as it was before with this totally useless changes and warning messagesā¦
If such changes are really needed (this and a few other threads let me doubt that, butā¦), why the **** is it not possible to set useful warnings? Is it that hard to show users where they have to look?
I have the same warnings like a few months ago (was some change with templates as well), where totally useless warnings are added, not once, nooooo, if it is a warning, it should show up at least five times, no wait I give you six, if you look right now sevenā¦ These error messages are like a mix between a gaming show and home shopping channelsā¦
Or does anybody expect me to get any informational value out of this:
2021-10-08 14:03:34 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'float' got invalid input 'None' when rendering template '{{value_json.currentZ|float}}' but no default was specified. Currently 'float' will return '0', however this template will fail to render in Home Assistant core 2021.12
No, why would I? So, up to the editor of choice it goes and searching for an exact string: value_json.currentZ
And now you can guess what the response isā¦right, nothingā¦ no match found beside the entries in the log.
Thanks to the developers, who obviously never use their own product.
No, rant is not over, because this is exactly, what others voice their critics over, but heyā¦letās do a launch party, so everybody can see, we do what we want, and we donāt care about the user basisā¦ We have more than 100000 installations, who cares about the few that donāt like itā¦ I hope they get their a**** burned in sunny California, where nobody cares, as long as you can be a cool Start-up in home automationā¦
4 Likes
Relax. Thatās a bug that needs to be issued against whatever youāre using to populate mqtt. Iām guessing thatās custom integration? Or custom addon like zigbee2mqtt or zwave2mqtt?
Or a discovery topic with a state template?
Very possibly. I was messing around with one of my zigbee locks tonight and managed to mangle the config for it and generated a few cryptic warnings like this.
It is a discovery topic, but itās not in his config. Therefore itās coming from a topic thatās generated outside HA. I.e. custom addon or custom integration or device configuration
Yeah, that was I meant, as a generality
this sounds very helpful thanks for that. Experiencing the odd spikes and drops, I started to change my value_templates on mqtt sensors from {{value|round(2)}} to:
value_template: >
{{min(value|round(2),2400)}}
just so I can be sure the sensor wont report 10000W or more given its max amperage set on the device its measuring.
adding the float(none) here would be done like
{{min(value|round(2),2400)|float(none)}}
? asking because I am not sure it the float(none) should not be on the value directly
this should be in the energy: documents! thanks
And how should one know that? You do know that, but I wouldnāt set your knowledge at a ānormal user levelāā¦ And thatās what Iām angry about. It looks to me, that no one takes the user serious. 
You know it best, you answered all threads that came up since yesterday. It is a mess, again, because communication isnāt what it should be. Why not write explicit warnings, with some background information where to find it and what itās about?
No, developer view seems to be enough and that canāt be it.
OK, now the rant is over, Iāll go back to the beautiful design Iām working on (not my design), so I can have fun with my HA installation over the weekend. And I wonāt react on any **** warning messages my installation gives me. I just ignore them. End of story until Monday. 
PS: Sorry, if I offended anyone! Sometimes I just canāt stand itā¦
2 Likes
Youāre complaining about something that canāt be fixed. Sorry but discovery topics are done using mqtt discovery. Even if the error message was explicit, you still wouldnāt know what to do if you donāt know the system. Because thereās nothing to do but wait until the integration, addon, or device has been updated to work with 2021.10 without warnings. Remember, custom anything is not managed by HA.
2 Likes
So what about template sensors? I pulled my hair out searching hours to find the error, because the persistant notification says āthe following platforms could not be set up (ā¦) see logs.ā - and logs are empty and config check says āokā.
Can you post the full error?
I can reproduce it, please wait a secondā¦
and what about these?
state: >
{{(states('sensor.teller_2')|float -
states('sensor.teller_2_daystart')|float)|round(2)}}
the sensors.teller_2** are again, mqtt sensors. Should I āguardā the individual sensors, (and what does that do with the template in total if either would be ānoneā)
state: >
{{(states('sensor.teller_2')|float(none) -
states('sensor.teller_2_daystart')|float(none))|round(2)}}
or āguardā the full template.
{{((states('sensor.teller_2')|float -
states('sensor.teller_2_daystart')|float)|round(2))|float(none)}}
BTW, rule of thumb for a casual HA user: Do not jump over an upgrade on day 1. Let it settle and give time to 3rd party developers to adapt.
I donāt upgrade my production environment on day 1, either, just my test environment. At the very least, I wait for the WE to have time to fix whatever has been broken
1 Like
Logs: empty.
Config Check: ok.
Solution: a careless mistake, using device_class: presence in a sensor.
Just be sure that sensor.teller_2 availability is properly configured.
This default thing is a non-event if the source availability is properly done, just because the template wonāt even be rendered. When you get to the point of guarding, itās already too late, because choosing a valid default is more than often just not possible.
yes, thanks. And I just realized the |float(none) is meaningless without the appropriate check for not is none, so not very useful in a value_templateā¦
value_template: >
{% set old = states(entity_id)|float %}
{% set new = (value|round(2))|float(none) %}
{% if new is not none %}
{% if states(entity_id) in ['unknown','unavailable'] %} {{new}}
{% else %}
{% if old == 0.0 and new < 2 %} {{new}}
{% elif new > old * 1.5 or
(new < old and new != 0) %}
{{old}}
{% else %} {{new}}
{% endif %}
{% endif %}
{% else %}
{% endif %}
So that will produce a proper error using config check via ssh. I donāt know why that isnāt extended to the errors in the ui config check. You can always make a feature request for that, but itās unrelated to these template changes.
Sorry, my English is not the best. Isnāt it core-related? Or are talking about the topic here? 