Our plan and design criteria is that it will work with any current config. It will also continue to work with YAML but has a GUI config as well. The GUI config will make certain assumptions regarding dy numbers so you only configure the first day. There will also be a lot of new features, more slots, the ability to have 7 days forecasts, a vertical layout if you don’t like horizontal for the forecasts and summare data for those days as well in vertical mode.
2 Likes
The development version of the card is here https://github.com/Makin-Things/makin-things-weather-card
You can add that as a custom repo in HACS too so you will get updates.
1 Like
@pocket The summaries and info from @DavidFW1960 and @tom_l is accurate. I wanted to add some new features to the existing card, but parts of it weren’t particularly well written and to add the graphical config it really needed to be converted from javascript to typescript. So after some discussion I decided to start a rewrite utilising the knowledge of the existing card, mostly contributed by David.
If you do install the card from the repo David posted feel free to create issues. There are generic templates there, but at the moment I don’t care if you skip those. Issue #1 is a summary of things that I know we need to do before the card is considered ready. We also have a group chat that we can add people to that just want to discuss requirements, features etc. It would be good to have some non-aussies providing a different perspective.
I’ve only had HA for a week and installed the BOM integration today going straight for this updated version of the card.
I have a question. Is this designed to work only with Bureau of Meteorology integration sensor or be more flexible and pull the data from anywhere?
If it’s the former why not just have a setting to set the base sensor name and then set all the other entities based on that?
How do you set the entity names for the forecast days? Or (after reading issue #1) are they what you call “slots”?
EDIT: Never mind I’ve found ‘entity_forecast_icon_1’, ‘entity_summary_1’, ‘entity_forecast_low_temp_1’, ‘entity_forecast_high_temp_1’, ‘entity_pop_1’, ‘entity_pos_1’ in weather-card.ts… although I don’t know what pop and pos entries are for.
Cheers
ps. if you need help with this I am probably able to assist
Some of the other entities use templates and this card is designed to work with any weather provider that can provide the sensors
Firecast sensors are not slots. They have a whole GUI configuration section (the bottom one)
I recommend loads ng it and trying it and it should be pretty clear. The templates we use are in ny repo linked in the original post.
I’d be happy to contribute what I can. If your group chat is at a reasonable time of day on my end (New York time zone), I’d like to attend. Please PM the details.
I could also write up some things regarding how the NWS presents its data sets, which seem to be not as rich as the BOM sets. They require shifting the input assignments to the BOM card three times each 24 hours. All forecast temperatures are either daily high or nightly lows, and all changes happen when data arrive from the integration as fresh entities. Also, the forecasts get more verbose as they get more current, so I’m hoping you’ve considered a way to bust the 255-character limit for the forecast detail entities.
Unfortunately, the US uses different API endpoints for certain data such as fire risk and UV data, so there would need to be another integration to handle those (out of scope for this effort). In the meantime, it’d be nice to gracefully handle their absence. There are other quirks and details that are artifacts of the API service, and I could explain those as well, if only to make sure the card behaves in a benign way.
BTW, the end product looks very nice. Kudos for the implementation. I’ll create a new dashboard and take a test drive.
1 Like
these are optional in the card anyway… If you don’t want them use a different slot configuration. Also the card doesn’t care one whit where the data comes from or what the source is. You are ultimately passing the entity to the card so as long as it’s an entity in Home Assistant it can be displayed. We are not doing any API calls ourselves. In the case of BOM we are using an integration that grabs data from BOM but this card is not BOM specific… In fact it was originally forked from the original which used Dark Sky.
1 Like
@pocket, I have sent you an invite to join the chat. It’s just a thread that has people that are interested in having some input and helping with testing.
I am happy to try it out and give some feedback, but the first chance I’ll have to look at it will probably be Wednesday. I am in the US and using Climacell as my weather provider.
Hi @theRat,
I’ve a question that’s related but also somewhat off topic. Forgive me.
In a nut shell, what do you get out of using TypeScript?
Before yesterday I’d never heard of it; I’ve a background in CS. However according to (lame) w3schools I am now an expert in it having done their online “course”.
I’ve been looking at the weather-card code on github where it’s about 1500 sloc, and then comparing it to the 11000+ lines of code it compiles to on HAOS using the file editor. That’s /some/ bloat.
The need to compile the TS to JS also means you can’t just easily edit the code running on HAOS and refresh (I assume you can actually do this with just vanilla JS). Instead you have to compile any changes remotely and then apply the changes in HA.
So, what do you actually get out using TS? I mean apart from type safety?
Cheers
The frontend of HA is written in typescript and various helper functions plus the card boilerplate. Basically the HA devs prefer people use it.
At the moment the compilation has a lot of optimisations disabled to make debugging easier, as well as having chunking disabled. So yes at the moment it is considerably larger than it will eventually be.
OK thanks.
(though tbqh I remain unconvinced as to the overall benefits of anyone using TS even though I would 100% agree that JS being loosely typed is it’s biggest problem. From my POV the cons of using TS seem to outweigh any advantage of using it)
I set up a test dashboard and used the UI to install the new version of the card. Have a bug in the slots section, and have some questions/comments about options. Where is the appropriate place to discuss?
The best thing is to open an issue on the github repo for the card. That way it gets on a list of things to do and nothing gets missed.
1 Like
Is anyone else having this issue for the past few weeks at least?
type: custom:bom-weather-card
title: BOM Weather
entity_current_conditions: sensor.newy_icon_descriptor_0
entity_temperature: sensor.nobbys_temp
entity_forecast_high_temp_1: sensor.newy_temp_max_1
entity_forecast_high_temp_2: sensor.newy_temp_max_2
entity_forecast_high_temp_3: sensor.newy_temp_max_3
entity_forecast_high_temp_4: sensor.newy_temp_max_4
entity_forecast_high_temp_5: sensor.newy_temp_max_5
entity_forecast_icon_1: sensor.newy_icon_descriptor_1
entity_forecast_icon_2: sensor.newy_icon_descriptor_2
entity_forecast_icon_3: sensor.newy_icon_descriptor_3
entity_forecast_icon_4: sensor.newy_icon_descriptor_4
entity_forecast_icon_5: sensor.newy_icon_descriptor_5
entity_forecast_low_temp_1: sensor.newy_temp_min_1
entity_forecast_low_temp_2: sensor.newy_temp_min_2
entity_forecast_low_temp_3: sensor.newy_temp_min_3
entity_forecast_low_temp_4: sensor.newy_temp_min_4
entity_forecast_low_temp_5: sensor.newy_temp_min_5
It works for a short while after refreshing the page, then pretty quickly becomes the undefined state error.
1 Like
I believe this got broken in the 2022.05 release, I had a look but couldn’t understand why. For me it doesn’t seem to actually affect the card working, just annoying errors in the browser log.
The hugely updated (rewritten from scratch) does not suffer from this.
Are there any users of the current card based in Europe that would be interested in joining a chat about the updates coming. We are trying really hard to accommodate people that are using weather integrations other than the BoM on that us in Australia use. At present we have 3 people from Aus and 2 from the USA in a chat, but more diversity would be good. I have already made a bunch of changes to help people using the NWS lives a little easier, which could potentially help others.
Basically if your not in Aus or USA I am really keen to get your input. If you are in Aus or USA try the new version and provide feedback via github issues.
2 Likes
@theRat Simon this has happened in the past when the refresh subroutine in the card was different to the original fetch
1 Like
I’m currently trying out the new Alpha release and liking it so far - especially the GUI config. Any chance of making the card actionable like other Lovelace cards ? My idea was to have a ‘summary’ card showing some weather details but either going to a pop-up or navigating to another view with more detailed information when the card is tapped, double-tapped, or tapped and held.
1 Like