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
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.
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.
@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.
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?
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?
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.
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.
This is an early warning for anyone that is currently trying out the new version of the weather card that I have been working on. I have chosen a new name for the card to make it easily distinguishable from other cards. It will now be known as the ‘Platinum Weather Card’.
The next update that I make (about lunchtime tomorrow Australian time) is going to be a breaking change. This change will update the name internally in the card as well as renaming the repository to match. When it breaks you will need to do 2 things:
Delete the old custom repository and add the new one (I am going to get it added to the default HACS soon as well)
Update the card type in the yaml to type: custom:platinum-weather-card
Sorry for the inconvenience, but it is better to do it now before it is more widely used.
The new card has now been updated. The custom repo is now at https://github.com/Makin-Things/platinum-weather-card
Follow the instructions in the previous post to switch over. Let me know if you have any problems and I will assist.