Unfortunately, I’ve been through all the threads and this is just driving me nuts.
I’ve begun working on a custom UI for my HASS install (Unraid -> Docker -> hass v0.103.2). I thought I’d start with a simply weather card (https://github.com/bramkragten/weather-card). I cleaned out all the card from my UI so I could work from scratch. No matter what I do, repath file locations, change url sources, switch between manual yaml and storage UI, etc seems to make this work. I cannot get past the “Entity not available: weather.yourweatherentity” error.
resources:
- type: module
url: /community_plugin/weather-card/weather-card.js
title: Home
views:
- cards:
- entity: weather.yourweatherentity
icons: /community_plugin/weather-card/icons/
type: 'custom:weather-card'
path: default_view
theme: Google - Light
title: Home
This is the text from the plugin page:
"When installed, this will be located in ‘/config/www/community/weather-card’, you still need to add it to your lovelace configuration (‘ui-lovelace.yaml’ or the raw UI config editor).
`When you add this to your lovelace configuration use this: "
No, the only map that exists in is config/www -> local/.
I think you’re over thinking this and the config/www -> local/ is messing with your head. It’s a simple map, that’s it. All other folders under the map are required.
Your card install location is most likely config/www.
So browse to that folder. Then browse all the way to weather-card.js. Note the full path. It will most likely be: config/www/community_plugin/weather-card/weather-card.js or possibly config/www/community/weather-card/weather-card.js.
Then knowing that config/www maps to local/… place the mapped path in your config.
This is what my full path looks like because things install to the config/www/community folder:
When you download plugins from HACS they do, in fact, get placed in the config/www/community folder. But when you place them in your resources section you reference them using /community_plugin/the_correct_folder.
The instructions for using the card in HACS even says as much.
Here is an example using the “aftership-card” that is installed on my system:
So, there actually is one more mapping that is being done in addition to the config/www/ → /local/.
I believe that the reason is that the mapping allows for some caching control where the www folder doesn’t.
Of course, your way will work using /local/community because that is where the folder is actually located but I’m not sure if you would get the same caching benefits that using the community_plugin/ reference would. I would say likely not, tho.
I actually ended up not using HACS for plugins. I use it to look up possibilities, then just visit the repository and do it manually. I saw enough wrong information in the first couple setups that I’d rather do it myself.
And yes, the folder path did need to be changed for targeting.
What did you end up using for the path in your “resources:”?
As far as using HACS I would prefer using that over the manual method any day (and do). I’ve never had any real issues using it and it cuts way down on making mistakes doing things manually.
I’ve used it pretty much since it was introduced with almost no issues.
I ended up moving my resources into /www/custom-lovelace/XXXXXX/ and referencing /local/custom-lovelace/XXXXXX/.
When HACS was in use, I ended up using /local/community/, because that was the actual path on the server. No idea why the mismatch is in the docs (3 of 3 that I checked). I can only imagine something updated somewhere recently and it hasn’t been updated.
