I am confused by your answer.
e.g. hacs alias is /hacsfiles/<path...to...js...file>
Instead use the local alias /local/community/<path...to...js...file>
In the past all the directions said to use /local/community/… Now it seems many of the cards call out - url: /hacsfiles/ some call out /local/custom-lovelace/
It is not very consistent. Should we use the directions for each of the cards or integrations installed or should all be changed to Local?
My responses are to only fix @molly200’s issue where the cards aren’t loading when they don’t have internet.
The general rule of thumb is: If you’re using hacs and you have internet, let hacs manage it for you.
As for the inconsistency, all you have to understand is that this is calling out a file on your computer. That’s it. There’s no voodoo here. It’s literally a path to the file. HACS makes it easier for users by making an alias that will point to all HACS installed custom resources. The local mapping to the www folder is an industry standard for web applications. As for all other custom cards in different locations, that’s on the developer to make it standard.
All you’re doing as a user is pointing to the file. You have multiple options to do that. If you want access from OUTSIDE your network, you have to use the local alias or the hacsfiles alias. In the end, they both do the same thing.
TLDR:
These paths all lead to the same place:
config\www\community\
local\community\
hacsfiles\
local is an alias that maps to config\www
hacsfiles is an alias that maps to config\www\community
“The general rule of thumb is: If you’re using hacs and you have internet, let hacs manage it for you.”
With all due respect I must disagree with your response and point to the fact that this is just one man’s opinion.
Here is the main Home assistant promoting statement:
“Awaken your home
Open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server”
One will question the support of an integration built in Home Assistant which is incompatible with the above statement.
Here is the boot log of my HA installation:
“2022-10-18 06:52:58.008 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant”
In my opinion there is a degree of hypocrisy behind Home Assistant. This might be due to the fact that the financing of this project is mostly supported by “Nabu Casa” online service. Understandably, there will be a loss of income for the developers and therefore progress of the project, if every user would run HA offline.
In the end, it’s the user’s choice to decide. However, the average user needs upfront disclosure statements, in order to reasonably and intelligently make an appropriate decisions, if considering Home Assistant in the context of it’s statements. Disclosing potential problems burred in log file that not everyone reads, is not good enough.
Over the years, and as a user, I share a lots of time loss, and frustration with home assistant. On the other hand, I’ve learn new things and realized that it’s the best there is in home automation, thus far.
It’s a good rule of thumb and it wasn’t directed at you. I was responding to @bschatzow who was asking a question about the aliases. You still can run HA with hacs without internet if you follow my directions above.
HACS is custom. It’s not built in. That’s why you’re getting this message.
You signed up for requiring internet by using HACS, a custom integration, not provided by Nabu Casa.
aarghhh
after todays ESPHome update, the misery of the renamed/rediscovered and because of that no longer functional BT proxies has returned…
Even deleting them to be rediscovered under their new name now doesnt work anymore…
Logger: homeassistant.components.esphome
Source: components/esphome/__init__.py:263
Integration: ESPHome (documentation, issues)
First occurred: 10:02:55 (9 occurrences)
Last logged: 10:08:04
Name of device bluetooth-proxy-centraal-277564 changed to bluetooth-proxy-centraal, potentially due to IP reassignment
2 listings for proxy-centraal…
and no there’s no IP re-assignment, I just renamed it via the ESPHome integration panel, all in the UI
This has never worked for me since released in beta. The found devices increases and I have no idea what they are. For me, as is, I do not see any use for it.
Yeah well, it s pretty annoying and so frustratingly unintuitive. Hope the devs would at least check up on the issues on the matter (or even better would respond)
After some serious manual editing the esphome files in the config And the .storage, I am back to a working setup and tbh, I am not sure which order of edits and deletes/rediscovers finally did it ….:
Note 2 devices are POE Olimex boards, and 1 is a WiFi M5stack
This is how esphome works. You change the name of something in the esphome addon and then flash it, it will show up as a new device.
Sure, but then it should no longer show as discovered with some old name…
It’s going round in circles
Moreover, this happened after the Esphome update, they were fine before that.
Must be some hidden registry that brought back the old name
Home assistant doesn’t know that old named device is what you renamed, it assumes I the device is alive, just unreachable. Like every other device in HA. This is nothing new. Delete it or disable it.
I think you have a miss-understanding on how esphome works with home assistant. Home assistant and Esphome do not talk to each other. Esphome only talks to the devices it manages. Home assistant only searches your network for esphome devices. You don’t even need the esphome addon for home assistant to work with your devices that have esphome flashed on them.
If you make changes in Esphome to your device, home assistant core is unaware of that change because it’s only looking for your devices.
that seems abundantly clear… Still a noob in that department.
as I faintly start to understand that, my name changes we’re done in the ESPhome dashboard, and while I did that, the new name was accepted, but at the same time, the old or maybe original named device was discovered. All still inside the Dashboard.
these devices in the esphome integration, so HA core indeed, have been around for some time now, and weren’t changed:
however, it was not after deleting one of these, and have it re-discovered in the integration during restart, the devices in the Esphome Dashboard were as posted above, 3 online devices, no more old name device discovered.
So it seems HA isnt completely agnostic to Esphome, or vice versa…
well, tbh, this I don’t understand. I would expect any (name) change made in the HA UI, to be propagated throughout the full HA system. Being all Core.
I dont have any other Add-on with devices to compare this with, but as an end-user this is utmost confusing.
And, I repeat, its only inside the ESPHome the issue arises, not in HA Integrations, these were all still fine and reflecting the correct states
Will there be a 2022.10.5 with the time zone fix for Tibber which was merged to dev some days ago?
The PR isn’t tagged with 10.5, so it’s likely in the next release.
Ohh. That is probably a misstake, the bug is rendering the implementation more or less useless for automating based on current price as it’s 2h off due to a time zone issue.
Is there a way to add that tag?
That’s up to whoever manages the builds. No clue who does that. Sorry.
Just a quick reminder that between 10.2 and 10.4 - someone broke the ‘health check’ ( [‘HomeAssistantCore.update’ blocked from execution, system is not healthy]) to mark the system as unhealthy when Portainer is installed alongside HA in docker.
A really bad misstep by whomever radically changed the health check to care about other docker containers running alongside HA, and break the update functionality.
A kludge to get around the dev who did this is to stop Portainer and do updates from now on:
docker stop portainer
Alternatively, some have noted that simply renaming the docker container avoid this very poorly designed health check:
docker tag portainer/portainer-ce:latest p0rtainer
I only detailed this because these HA nuisance traps, and documentation are getting worse.
This is by design. You can disable the health check if you like. Portainer is not something that the HA team wants people running on supervised systems.