@DavidFW1960 I am going through cleaning up my config. I am trying to avoid templates as much as possible as they just add another level of complexity to the config. Just wondering what the point of the bom_current_text template is? It seems to just potentially truncate the actual text if it has a dot in the middle of the input text (such as ‘Mostly sunny. Possible storm.’).
Also in your template.md it has bom_forecast_0 to 6, but I can’t see anywhere they are referenced. Is this just something left over from the previous bom integration?
Yes essentially that’s the point. If that text is too long it gets ugly. Like I say in the docs these are examples of what I use but you can modify them to use whatever you like.
Ok, so I will just use the actual sensor text. Missing out on the ‘possible storm’ that sometimes gets tacked on the end sounds bad to me. Pretty sure that with the new API they are keeping the summary as short as possible since it needs to work on small screens for the mobile app.
Ok, so I don’t need the bom_forecast_x templates
I now just have templates for fire_danger and uv_text. It would be nice if I could get rid of these as well. All the fire danger one does is prepend a constant string.
thanks @DavidFW1960 ok can see adding HA integ back in its asking way more now for settings - observations/forecasts… So much change now… for the cards , and platform templates
sensor naming (for area) seems to be also handled differently.
yes that’s right. It uses that for the text in the displayed summary - it wouldn’t make sense without that. It could be included in the card however remember this card is used by people not using the BOM component from all over the world… In any case, you can do whatever you want.
Regarding the current conditions, It’s maybe a hang over from before when icon descriptions weren’t there. Can’t remember. It works for me like this otherwise it’s too long a lot of the time as you will see…
(Remember too the possible storm etc tacked on is in the summary at the bottom anyway)
When you use the value ‘pop’ for a a slot the data it uses seems very odd. If returns the forecast percentage of the actual amount of rain recorded so far today. I think it should really be returning the forecast percentage of the forecast range for the day.
In the future day forecasts it does this, but not for the slot field.
Yes. So at present for me it is returning 30 % - 0mm. The actual forecast is 30 % - 0-0.2 mm. If it actually rains it would change to 30 % - 15mm, that is mixing up forecast info and observations.
The actual rainfall should be displayed in its own field maybe with a slot name of ‘rainfall’.
Yes you can. You just need to pick some coordinates close to the weather station you want and then don’t tick the forecast box (to avoid lots of unnecessary sensors).
It doesn’t use the current predicted rainfall for today at all… only actual recorded rainfall. With the old integration, BOM helpfully removed the current days forecast here for my config (like it blanks the min/max as well) This behaviour has changed regarding the timing it zeros it out.
I think I did change this because there was no forecast available for today when I made my original changes to the card. I could add some additional slots as options but it would be a PITA changing this for default etc now and would no doubt piss off a lot of people.
So you are saying that pop (Possibility of Precipitation) shows actual recorded rainfall? That really is quite bizarre. Surely pop is a forecast field not an observations field.
Brendan’s integration now returns data for all the rain ranges. This looks like what you are using for future day forecasts. A lot of the time it will be just 0 mm (the bom often just leave it blank when the percentage is really low, but it looks like Brendan has filled it with 0 when that happens). POP really should be using the forecast amount, with a separate field for actual recorded rainfall.
Pretty sure you can define that for a slot now by itself if you want it. I can look at combining it with the percentage as an option instead of the actual rainfall but I’m not going to break existing implementation to do it.
I can’t see how you can create a custom slot. The code has hardcoded formats defined for those. Also you have already defined ‘possible_today’ which is using the value that should be getting inserted after the percentage. Really both pop and possible_today are the same thing and both should probably give ‘% of range’ type results. For best flexibility though considering slot values are not user customizable there should probably be a few more and the current ones properly named. My initial thoughts are there should be at least 4 options to do with rain:
rainfall - the actual recorded rainfall amount
possible_today - the range that might occur (ie. 0 - 0.2 mm)
percentage_today - the percentage chance of rain (ie. 30%)
pop - the percentage and range predicted (ie. 30% of 0 - 0.2 mm)
You can define a slot to show possible_today and so far as I know without looking again at the code that will display what you parse for entity_possible_today in my case sensor.kariong_rain_amount_range_0 (your option 2) Percentage and recorded rainfall (options 3 and 1) are similarly parsed through already
However I currently combine 4, pop with percentage and actual instead of range.
Like I said I am not going to break a bunch on installations by changing this. What I can examine is defining another slot to display the information in option 4. I will need to take a look and see what I can do.
The slot values are customisable it’s just this one slot that combines 2 entities that isn’t.
The way it is now is a result of that being the best solution given available data previously. Now we have better data. This card is used by people around the world who don’t use BOM too and it’s not a trivial thing to break their installations just cos it suits you/me. Give me a couple of days to see how to best do this.
