Corrected in latest version 0.9.3
Yes, This will cause odd things to happen. The updating routine searches the shadow dom for IDs associated with the specific items in the card. the IDs need to be unique to work correctly. If you have more than one instance of the card then the IDs won’t be unique and it will be indeterminate as to what happens during the update.
EDIT… In thinking about this more, I don’t think this should be an issue. Each instance of the card should have its own Shadow DOM so it really shouldn’t be an issue. I will do some further testing.
Not sure what to say for this. I don’t have this issue. I am able to navigate to and from the card without issue. Possibly something is wrong in HA. Does it continue to be an issue after restarting HA?
New version 0.9.3 here
# 0.9.3
- Corrected issue where an extra UOM would show on the forecast daily temps
1 Like
You rock! Thanks Mark!
yes is does, many reboots tried…
changing to my previous card immediately solves all issues… navigating is back, and swift. And all my icons show on loading the card. No wait what so ever, and rock solid.
Seems this LIT thing is rather a nuisance for the new soon to be default Lovelace interface…
id be happy to send you my adapted code to have you test it and see if anything pops up on your side. I don’t get any errors what so ever. Simply doesn’t work as expected.
Are you saying here that we can’t have 2 cards on 1 view using the new Lit technique? That would be most impractical…(understatement of the severest kind).
–Feature request–
please consider adding an icon arrow for wind bearing.
I am also using the card with a chart which uses that, and I think it is kind of neat and simple:
@Yevgeniy does it like this:
this.cardinalDirectionsIcon = [
'mdi:arrow-down', 'mdi:arrow-bottom-left', 'mdi:arrow-left',
'mdi:arrow-top-left', 'mdi:arrow-up', 'mdi:arrow-top-right',
'mdi:arrow-right', 'mdi:arrow-bottom-right', 'mdi:arrow-down'
];
and:
<ha-icon icon="hass:[[getWindDirIcon(windBearing)]]"></ha-icon> [[getWindDir(windBearing)]]<br>
using:
set hass(hass) {
this._hass = hass;
this.lang = this._hass.selectedLanguage || this._hass.language;
this.weatherObj = this.config.weather in hass.states ? hass.states[this.config.weather] : null;
this.sunObj = 'sun.sun' in hass.states ? hass.states['sun.sun'] : null;
this.tempObj = this.config.temp in hass.states ? hass.states[this.config.temp] : null;
this.forecast = this.weatherObj.attributes.forecast.slice(0,9);
this.windBearing = this.weatherObj.attributes.wind_bearing;
}
and
getWindDir(deg) {
if (locale[this.lang] === undefined)
return locale.en.cardinalDirections[parseInt((deg + 11.25) / 22.5)];
return locale[this.lang]['cardinalDirections'][parseInt((deg + 11.25) / 22.5)];
}
might be cool to have this added to the wind display in your card, or maybe even split up the current wind setting into 2?
would be a nice addition to the slots 
like this maybe?:
separate reply, with a solution…
turns out I had this in the Update values optional entities, which is incorrect…
if (this.config.entity_today) { root.getElementById("today-text").textContent = `${this._hass.states[this.config.entity_today].state}` }`
I had added that because I use this too:
var today = this.config.entity_today ? html`<span class="today" id="today-txt">${this._hass.states[this.config.entity_today].state}</span>` : ``;
not sure why, or why it is incorrect, but taking it out gives me back my navigation.
also, I had not seen the extra 2 entries for the icon path in the Update Values section…
which makes me want to repeat my earlier suggestion to have the icon_path as a config option. Having to edit the main js.file is getting more an more complex, so making a mistake is rather easy…
Has nothing to do with LIT. Has to do with card being able to update dynamically. The getElementById function requires the id you are looking up to be unique. If there is more than one with the same element it will return the 1st one it finds.
To have more than one instance of a card you would need to find a way to make the IDs unique across the card instances. That can easily be done for cards that are single element specific like a guage card or a individual sensor card. Because those cards are only for one entity, you can use the entitiy name as part of the id. That obviously won’t work for this card.
EDIT… (Edited original post as well)… In thinking about this further, I don’t think multiple copies of the card should cause an issue. Each instance should have it’s own Shadow DOM so as long as the IDs are unique within the card there shouldn’t be an issue I will test further…
Spelling mistake. Your getElementByID is looking for “today-text” but you have defined id as “today-txt”
1 Like
Not sure how practical this would be, If you don’t want to use the directory that the card requires, It would be much easier for you to just create a symlink for the directory that this card expects.
I use the icons, as do many other people, for other purposes too, cards, template sensors, etc. Would simply be easiest if we could set
icon_path: /config/weather/ (or whatever path one has set)
in the card config, and have the card take care it…and not have to adjust the path for each and every other card.
If that’s what you call a sym-link that would be fine. I don’t think 1 extra entry would be ‘impractical’ given the plethora of options that are already there?
duh…
thanks for spotting that.
a mistake with severe consequences though, not being able to navigate because of it…
A symlink is a linux concept that allows you to have a directory or file that appears in one place but is actually in another. Doing this will allow you to have your icons in a central place without breaking this card or anything else that might need them.
For example: You could have the directories
/my_icons/weather_icons/animated
/my_icons/weather_icons/static
where you keep all your icons.
The card needs those directories to be
/local/icons/weather_icons/animated
/local/icons/weather_icons/static
You could create a symlink called /local/icons/weather_icons that points to /my_icons/weather_icons. This will not create copies of the icons but will instead provide a link that appears to be a directory with the correct name the card needs.
to do so you would use the command
ln -s /my_icons/weather_icons /local/icons/weather_icons
the syntax is “ln -s source link” (the -s makes it a soft - symlink)
When I said it was not practical I was not referring to how many options the card has but rather to the complexity it would add to the source code of the card vs the ease of creating a symlink to handle it.
1 Like
ah, yes, I feed as much… thanks for this very clear explanation, Ill certainly store it.
But, tbh, I fear this is not what I would describe as user friendly, or ‘simple’. This is exactly what should be in the card, and not up to the end-user imho. Have a look at the lengths you’ve gone to create a variable for the top margin of some of the entities in your card… Much appreciated, don’t get me wrong. But I think adding icon_path: to the config options would be so much more user oriented than having to deal with unix/linux commands.
The key issue here is:
while it should be: where are the user icons located? tell the card and it takes care of the rest…
that all being said, my card is back up again, and, as far as I see now, never been more solid… so thanks for all the efforts you’ve put into this.
Thank you for a great card! The documentation is top notch.
Just updated to latest version and I can’t seem to find a way to show the 2nd separator line. I get the one at the top but not at the bottom. What am I missing?
Thanks
Please add feature requests to the github page as an issue. Its really hard to keep track of them in this thread and I am sure there have been many that have gone by that I have forgotten…
its not in the card, but I’ve added it manually…
this is what I use, <hr> being the main objective for your question:
</div>
<br>
<hr>
<span class="summary">Summary for: </span>${today}
${summaryToday}
<br><span class="summary">Rest of the week: </span>
${summary}
</ha-card>
`;
}
1 Like
There have been several feature requests in the past weeks and I have tried to respond to them all but it is difficult to keep track of them in this thread.
Going forward, please add add any feature requests to the github page for the card as an issue. This will allow them to be tracked and discussed individually. People can then vote Thumbs up or Thumbs down as to whether they feel the feature should be in the card. Once a feature request gets enough positive feedback I will consider adding it to the card.
1 Like
sure, consider it done feature request: add icons for wind bearing · Issue #9 · iammexx/home-assistant-config · GitHub
Is there a way to add the daily expected accumulation (sensor.dark_sky_precip_accumulation) under each day similar to how the chance of precip is listed?