Just the topic here
FWIW, as a general note of interest, the PR for is_numeric indicates the function was introduced as a companion for the process of converting a numeric string to a number. It includes an example showing its use with float (convert to float only if the value is numeric).
Just one more tool to guard against edge-cases.
Nope, I have to disagree here. There are numerous ways to fix that, better to avoid it in the first place.
- Donāt set a warning, if it doesnāt come from core
- If you need to set it, show where it is coming from, ideally explain it: āThis warning is set by the addOn/custom component/whatever XX.ā
- Set a realistic timetable and work with it. One or two months to update the addOns/CC without setting a warning. So all developers have time to adjust. After that two months of warnings (like it is). Keep the user in mind, not the developer! It scares people, if they get warnings.
All in all, I can sum it up again to communication. It is what Iām alway saying: hire someone that orders the communication and knows how to speak with the general public. What weāre doing here is talking on a high level, with code examples and things like that.
These changes affect users, most of them not very knowledgeable. An thatās the way poeple should be. They want to use a system, not look for a warning here and an error message there. As a normal user I couldnāt care less, if this is set by an addOn or the core. I donāt want it to happen at all! And if there is a warning, I want to know why and where. I donāt want to go to the forum and search in threads like this one to find a solution, that is not very user friendly and not very āsolutionyā. Or is wait and see if maybe an addOn is the reason, but it has to be updated, maybe, or not, orā¦ a good answer for a normal user?! I donāt think so!
And letās be honest, streaming a launch party isnāt the way to make good communication. You set roadmaps, where interested users can see what is going in the future. And where developers can check, if something isnāt right. What we see here is developers thinking of changes, make them, and let others (like the suporting people in a forum) care of the rest. Why even thinking about how things turn out? This is the approach of a developer guided company, and that shouldnāt even be a point of discussion. If you want to run a business, you have to look at your customers/users. And that brings us back to communication. But Iām starting to going in circles hereā¦ 
1 Like
You donāt know that information. Itās MQTT discovery. Sorry, but you donāt understand how this works, so this statement is not accurate. It would literally say āMQTTā and youād be back here with the same question. MQTT is a bridge between a component and HA, HA only knows about MQTT, it does not know what sets the MQTT topics.
MQTT Is a part of core. See previous response.
What your asking for is 100% not possible.
Roadmaps are set. These are on the roadmapsā¦ People donāt want to use the tools that the devs use, which is github. Again, all explained many times before. Just because itās not on these forums doesnāt mean itās non-existent.
Youāre going in circles because you, like many, are unwilling to use the tools that HA provides for information.
The release party is a new and been going on since January to get people outside developers involved in the changes for each release. Iām sorry that you donāt like that, but not everything in life is catered towards you. The release party seeās thousands of views and many many many people like it. So, youāre welcome to sulk, but itās not going to change anything.
You donāt understand my point. Iām not unhappy with the release party, Iām saying it should not be the way to communicate changes. Itās a nice bonus for communication, but choosing it as the one way to communicate isnāt the right way. That is what Iām saying.
And these are the most thruthful words Iāve read in this thread. Fuck off users, we donāt care, we do it the way we want, good or bad, dump or not, it is our thing and we do as we choose.
Congratulations to such an insightful and understanding statement regarding user input! You couldnāt have made it clearer, how you (and maybe the developing team as well) sees us idiots, pumping money, time and heart in a project, where they have no influence or otherwise noteable voices to hear!
@finity See, yesterday I said it to you, and now Iām exactly where you areā¦ Havenāt thought it escaleted that quicklyā¦ 
2 Likes
Same as above, you donāt get my point. It is exactly what Iām complaining about. One needs to know the information, if it isnāt there, it should be part of the general change to develop a solution where this information IS present when a warning message is set. Easy as that. If you donāt have the information, donāt set a warning!
Or in short, donāt do half the job. The communication, and therefor to inform a user, must be part of the change. As I said, easy as that!
Reading this, I just remember a joke:
A man is driving on the wrong side of a highway, there comes a message in the radio: āBe careful, there is a wrong-way driver on the highway!ā. āOne?ā he asks, āhundreds!āā¦
Maybe the thinking should go into another direction. If people are not using it, have we done this right? But it is always easier to pinpoint it to others than to yourself. I havenāt done anything wrong, the others are the idiots that canāt readā¦ Maybe itās just hidden that good?! But as I said numerous times, Iām going in circles, as the statement above stands: āā¦it will not change anything!ā
I would argue that part of being a user of HA is at least to know whatās going in your system.
If value_json.currentZ doesnāt ring a bell to you, you probably lost control, and thatās exactly what those new warnings are trying to address.
Pick your MQTT explorer, check the config topics and find out which device is sending you wrong values, likely since a long time.
New templating changes doesnāt make it easy to be true, but Iāll try and want to understand because Iāve couple of them.
How can I solve below template warning?
attribute_templates:
updated: >
{{ as_timestamp(states.energy_teller_consumption.last_updated) | timestamp_custom('%Y-%m-%d %H:%M', true) }}
Template warning: 'as_timestamp' got invalid input 'None' when rendering template '{{ as_timestamp(states.energy_teller_consumption.last_updated) | timestamp_custom('%Y-%m-%d %H:%M', true) }}' but no default was specified. Currently 'as_timestamp' will return 'None', however this template will fail to render in Home Assistant core 2021.12
Thank you! 
Let me see if I understand you correctlyā¦
So, as users we are supposed to read every bit of code in a custom integration (and apparently submit it to memory) or we have ālost controlā of our systems?
Really!?
What about HA core? is that our responsibility to dig into the code and understand everything in there as well?
we might as well all be developers if that is what you are implying.
And apologies if I misundertood something.
1 Like
The point is that the original warning message contain no information that the error is mqtt related.
Paddy has right to extent: messages stored in logs are one of weakest points of HA since I remember. Especially considering that HA is under constant development thus full of issues.
This problem is well known since multiple times discussed on that forum. Cannot say if this situation is improving but from time to time I can see questions from users about particular log record which indeed says nothing about the source. Only most experienced forum members are able to decode the log entry (probably because they experienced something similar so are able to connect those facts)
As for example from my log:
2021-10-08 17:20:41 WARNING (MainThread) [homeassistant.components.mqtt] JSON result was not a dictionary
At least I may suppose itās related to mqtt (so no template related making it OT, sorry for it, but it proves my point). But WTH there is no information about related entity? Is it really so hard to add such info?
Youāre at least supposed to check your MQTT messages to determine where it comes from, so that to know where to report the issue, yes, donāt you agree?
Thatās an easy one. If itās not in your code, the only way I can think of that a template is pushed to HA is MQTT.
I agree with you that it would be extremely easy to include the entity_id on that one (and others).
Itās your assumption (maybe true in case of HA). Regardless users skill this is not what can be confidently identified this way based on the warning message. Potentially there might be other components or even parts of single component communicate with each other causing such a message.
You are able to make a qualified guess. But most users are not. Which is the Paddyās point.
Ah yes, solve breaking changes with more breaking changes.
My man, 1000s of people use the current tools and enjoy them. Literally a small handful of people on these forums donāt use them and complain about them. You are in the minority here.
The blog post has all the breaking changes. The release party is an in depth breakdown of each change and how it affects HA. All the information in the release party and blog is scattered across issues, PRs, and discussions on GitHub. The team takes that information and consolidates it for you, the user. Iām sorry itās not up to your standard. Youāre welcome to volunteer and help get that information across to the users in a better fashion.
Provide a default value for as_timestamp.
You should know that the reason you got the warning message isnāt simply because you didnāt provide a default value. You got a warning because states.energy_teller_consumption.last_updated was None and as_timestamp cannot convert None to a timestamp.
Why is it None? Because states.energy_teller_consumption.last_updated is an invalid entity reference. If itās a sensor entity then it should be this:
states.sensor.energy_teller_consumption.last_updated
^
|
You overlooked to include this
The warning coming from the setup of mqtt discovery is a bit of a chicken-egg scenario. Home assistant is built in a way to have a fast startup. The more questions that home assistant setup asks, the slower the system is when it restarts. At that point during startup, the system does not know what itās creating because it hasnāt been created yet. At best, you could get a topic if a topic was supplied, however, it will be the config topic and not the topic the sensor itself uses. Again, pretty useless for the user. The only logical solution here is to wait for a fix to the custom integration, addon, or device.
Hypothetically, even if you had the sensor information thatās failing, what could you do? You canāt fix it because itās coming from the integration, addon, or device, you have to wait for an update.
EDIT: I also want to point out that, even if you had the entity information thatās being created, the developer whoās fixing the issue doesnāt need it. They just need the template thatās failing, which is already supplied in the warning.
I feel so stupid sometimes!
I really overlooked this one, as I do have 6 same kind of sensors which are ok, including the sensor part.
Iām mixing up things. Iāll come back later with a better, real example.
Create a new topic. This topic is for discussing the recent changes to several functions. General template debugging is best handled in a separate topic.