Currently trying to display on a dashboard card a specific attribute value of an entity. Want to be able to do this by using the native visual editor. Can’t seem to do that. Would like it to have that feature.
In this specific case, I have the Launch Library integration installed. Want a card on the dashboard to show the next launch time information. Right now just see “Tomorrow” listed:
But the visual editor doesn’t expose internal attributes of an entity to be displayed (or at least not that I can tell). Would be great if the visual editor could do that.
You should raise a feature request with that integration’s developer. I saw this post from one of the core developers the other day that made some recommendations on what should not be an attribute:
Would someone extract it using a template into an other (binary) sensor → Not an attribute
It is essential to automation on? Can it be standalone as its own entity? → Not an attribute
It is static, e.g., from configuration; doesn’t belong in the state machine → Not an attribute
Do we want to track long term stats of the value? → Not an attribute
It could be argued that the attributes of that integration fail the first two points.
Edit: As it is a core integration the FR belongs here.
I’m confused. This integration does list attributes. Are you saying they aren’t really attributes? Or that they shouldn’t be attributes? Maybe I’m just not clear on what an attribute is insofar as Home Assistant is concerned. If they aren’t attributes, what should they be?
So, based on what I’m trying to achieve, how would I go about it then? The integration has useful information that is only being exposed as what it thinks are “attributes” and apparently I can’t get hold of them using the visual editor. Maybe with YAML, but this is getting into Paul Hibbert frustration territory.
Super-excited to find an integration with this kind of information that is automatically up-to-date, but having a difficult time making use of them. Thought putting all the data into a card would be easy (and some of it was), but getting the specific launch time, not so much. And really want to get that info into an automation, one where I can fire off an action based on the launch time minus some offset in order to tell us of an impending launch, particularly (and specifically) if the launch location is at Cape Canaveral (yes, that data is also in this integration as well). Am amazed nobody seems to be using this integration, when all the home automation enthusiasts are likely to be space flight nerds as well.
Putting aside whether this should be an attribute it state [after all you are stuck with the implementation you have], you can get an attribute in that card, it’s in the docs
Thanks. If those should be sensors… any idea how I can contact the developer of that integration? My searching leads me to believe Launch Library is an integration of the core Home Assistant project:
I’m not seeing who is/are the person/people I could lobby to get those attributes to be sensors, as you have suggested.
The FR still stands, though would like to get the squared away. Granted, this is a non-critical issue (getting Launch Library attributes promoted to be sensors), but I suppose I can ask.
In that directory you are in on GitHub, look at the file manifest.json, the code owners are listed there.
Having said that. Please don’t badger them.
Particularly as you can get the same result without changing the integration. An attribute can be made into a sensor with a template. Or displayed in the ui by writing less in your yaml code than has already been typed in 1% of this thread.
Thanks. As someone who supports IT for several decades, I usually don’t find it helpful for users who have an issue to just sit on it and not mention it. Suffering silently doesn’t help me know that there is something amiss. Certainly don’t want them to badger me, but that isn’t the same as just making them aware. And in this case, according to the moderator (tom_i), those attributes should be sensors, not attributes. His words, not mine. That isn’t a bug, just an error in implementation, if I’m reading that right.
As far as how text-written-vs-YAML,… maybe… though much more of a learning curve to get this worked out in YAML, and that doesn’t help the next guy down the line. If the issue gets solved for one, it is solved for everyone.
