the Decluttering Card i have install over hacs frontend.
in the cosole I see:
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading '6')
at eval (eval at <anonymous> (flex-table-card.js?hacstag=156292058072:348:42), <anonymous>:1:8)
at flex-table-card.js?hacstag=156292058072:348:42
at Array.map (<anonymous>)
at DataRow.render_data (flex-table-card.js?hacstag=156292058072:345:35)
at flex-table-card.js?hacstag=156292058072:100:47
at Array.map (<anonymous>)
at DataTable.add (flex-table-card.js?hacstag=156292058072:100:32)
at flex-table-card.js?hacstag=156292058072:537:26
at Array.forEach (<anonymous>)
at set hass [as hass] (flex-table-card.js?hacstag=156292058072:535:18)
OK, let me finish this code and update and repost the Dashboard to use all names. It looks to me that some other index ‘6’ is off. Mine is in flux as I was also adding Playoff Seed this am and I noted the change.
Will do. I just finished doing the code for NHL. It now uses this to select the fields in the table:
- name: GP
data: entries
modify: x.stats.find(y=>y.abbreviation == 'GP').displayValue
So now, as long as ESPN does NOT change the abbreviations, they can do whatever they like with the positional layout of them. I have updated the dashboard YAML in GITHUB. Can you grab only that and replace your dashboard and test for me it would be great. I will continue on doing a similar update for NFL, MLB and NBA.
OK, let me post a new thread and we’ll move issues over to that. We should not take away from @vasqued2 and his thread here that deals with Teamtracker. Give me a few hours and we can start to post there.
I have now posted a new “Share Your Projects” that deals with the STandings component.
I suggest moving discussions dealing with Standings to there.
@compoundbow83 and others, please use that to post questions on the Standings portion. I already know I have to modify the NFL, NBA and MLB stats to the new lookup method implemented for NHL.
Pretty sure it’s unpkg, where the Lit/LitElement imports are pulled from, causing the issue. Every custom card I have that uses unpkg is currently broken. @vasqued2, would it be possible to include the imports and switch to a local import? Awesome card integration and card btw!
Sorry. I’m out of town this week and next and don’t have the access I need to make or test changes.
If anyone has a fix and wants to submit a pull request, please do so. Same if there is a link with more info on how others have fixed it in other cards. I might be able to pull it in to a beta release this weekend if it’s a simple fix.
It’s still working for me in the Apple app. Is there a specific front end that is causing the problem or is it just working for me because it’s cached?
Just did some digging and it appears unpkg did indeed have issues earlier that impacted some regions and they’ve been resolved now. Maybe that’s why I’m not seeing issues now?
Could the “days until” value be modified to represent the actual number of days instead of the remaining time divided by 24 hours?
Currently, it displays “2 days” at 9 PM on Thursday, but it should say “3 days” until midnight and then switch to “2 days” afterward. Is it possible to make this change? Couldnt find anthing regarding this…
After some limited testing the following appears to work and allow for removing the dependency on unpkg:
const LitElement = customElements.get("hui-masonry-view")
? Object.getPrototypeOf(customElements.get("hui-masonry-view"))
: Object.getPrototypeOf(customElements.get("hui-view"));
const html = LitElement.prototype.html;
//import { html, LitElement } from "https://unpkg.com/lit?module";
I found similar code chunks across quite a few of my custom lovelace cards. I don’t know the full extent of advantages/disadvantages of the above code(reliability, future-proofing, compatibility, etc.) but in my brief testing I’ve had no issues. Would love a clarification or more explanation from someone more versed in JS!
Essentially there are some of us that want the entire team set for particular sports so that we can look at all things going on, but also would like a view that contains only our favorite teams. I think it would be great to add an additional attribute to a teamtracker team … “favorite”. This additional attribute would only carry the fact that a team is one of my favorites (defaults to “false” but could be “true”).
Then all-sports dashboards can be viewed as all teams or just “favorites”. Or better, a view of all my “favorities” independent of sport. Yes, I know I can just do this in some view by changing the YAML for the card to add that team, but auto-entities and templates would reduce that to a few lines of code and when I add a new team, mark it as a favorite in the sensor creation, it would just be there.
I use the humanize() function that is part of the arrow library (https://github.com/arrow-py/arrow) to calculate, translate, and localize the “days until”.
Unless I am missing something, it seems like you could get the same functionality by just using a standard naming convention and then using a template filter to only pull in the sensors you want.
For example, all my sensors are named something like tt_{league}_{team_abbr} or tt_test_{league}_{team_abbr} so I can filter out the test or prod sensors only. See my example below.
It seems like if you use a naming convention like tt_{league}_{team_abbr} and tt_{league}_fav_{team_abbr} you could pull in all of the sensors or only the fav depending on whether you included fav or not in the filter.
The reason I like driving it off of the sensor name is because it gives a lot more flexibility. For example, someone could filter based on conference or division if the wanted to. You couldn’t do that with a simple binary flag.
If I’m missing something, let me know.
template: |
{%- for team in integration_entities("teamtracker") -%}
{%- if "sensor.tt_nba_" in team -%}
{{{"type": "custom:teamtracker-card",
"show_league": true,
"debug": true,
"outline": true,
"outline_color": "lightgray",
"entity": team }}},
{%- endif -%}
{%- endfor -%}
You are not missing anything. You could use that as a naming convention and I think not break anything (I have done). But personally to me naming a team as you suggested is cheating. Maybe we are cheating too … because we want some team treated different that others. It was only pointed out in my blog and I thought I would present it here.
I think your people use teamtracker (which is top notch by the way) to follow their teams. My people use it by Sport and not by Team.
We can do what you want without even a naming convention, just a simple JSON file that contains your favorites. I will do that for folks then.
The difference you suggest is minimal.
Do I do?
- platform: teamtracker
league_id: NFL
team_id: DET
name: Detroit Lions
favorite: true
or
- platform: teamtracker
league_id: NFL
team_id: DET
name: Detroit Lions Favorite
You control the integration, but from an experienced software person … one of these is the better answer.
You young’uns is so cute. The best solution is the one that provides the most flexibility w/ the least amount of coding changes. Actually, scratch that. The best solution is one that already works. Someday you’ll have enough experience to realize the wisdom of those words.
Let’s look at what would be needed for your proposal for a second.
Change the sensor setup. Change the UI config setup. Add an options flow handler for the flag. Update the localization files for the UI changes including languages I don’t speak. Force a config schema upgrade on the entire install base. Reestablish and regenerate a regression baseline. With most changes occurring in the portion of the code base w/ the least amount of test coverage.
Then about two weeks after release, someone would ask to add another boolean flag to tag the sensors that are their roomate’s favorites. Or to hide the scores for teams they want to watch later and not be spoiled. Or. Or. Or.
It’s almost as if an “experienced software person” were going to implement something like you requested if they would recognize the limitations of a boolean and implement it as a tag to give more flexibility.
But I’m not going to do that either.
Because name is essentially a sensor tag already. And the best solution is one that already works.
