I have HA Core installed and the root directory is:
Path to configuration.yaml: /home/homeassistant/.homeassistant
In that root directory is a file that is created and modified by the Insteon integration. It is insteon_devices.json.
Now, I would like to create some template sensors, etc. that are based on this file. In order to do that, I really need to use REST because I need to be able to process the (huge) data using json_attributes_path. I say this because other sensors do not support json_attributes_path from what I see (like the command_line sensor which can read the file).
Is there anyway to read a file that is at that path (the root of the configuration)? I have tried many ways and it appears that it cannot be read. As a workaround, I have copied the file to something like:
But in reality, I would not want to access the copy. I would much rather access the actual file. I cannot find any address that allows this file to be grabbed via resource … like:
http://192.168.2.245:8123/insteon_devices.json
That yields a 404, File not Found. So is there a web address that corresponds to the root where configuration.yaml exists?
And by copying … yes I can create a command_line sensor that just copies the file I believe but that seems so wrong.
The resource option expects a REST endpoint (basically a web server able to reply to REST requests). You specified a file and that’s not a valid endpoint.
That is a file located at .homeassistant/www/insteon_devices/insteon_devices.json.
Translation – the web service that is /local on HA root is configured to serve files.
What I believe you are saying is that Home Assistant is not configured to serve files from that root configuration directory.
By the way, I can think of very good reasons why it doesn;t expose this directory, like someone could go after secrets.yaml. The issue that I have here is that the Insteon integration manages this file (like a cache) and I cannot change where it is. Perhaps the real solution is that this file in the integration should maybe be moved to somewhere else.
Alternatively I guess I could create another web service that allows access to that file or modify the existing web server in HA Core to provide access, but again that seems like hacks. Or maybe so pyscript which is the way I believe I may go that actually uses XSLT to read that JSON and modifies it, writing the result to another file that in turn is then read into a bunch of sensors.
Your config file may already have a homeassistant key so just add the suggested information under it (i.e. don’t create duplicate homeassistant keys).
I tried that before. To be clear.
The .homeassistant directory does not have a /config directory.
If I add
allowlist_external_dirs:
- "/config"
HA will not run because there is no /config
If I instead use:
allowlist_external_dirs:
- "/"
HA starts but I cannot access the files. Possibly the question is … if I do allow “/”, what is the web service endpoint named? I did try adding it as in:
Have you tried /home/homeassistant/.homeassistant in allowlist_external_dirs? I believe the /config value commonly shown is for those running Home Assistant OS / Docker which mounts that into /config in the core container (and add-on containers).
First and foremost - Putting the whole config directory up as web-accessible (even if only locally) is a TERRIBLE idea. Don’t do it under any circumstance. Don’t pursue this path. Just don’t do it. Seriously!
Now, you couldsymlink the file in the config directory to appear in www. I don’t know what all is in insteon_devices.json, but there’s a good chance you still wouldn’t want to expose it via a web address.
A better idea would be to use use a command line tool like jq or python’s json parser with command_line sensors. Either solution will take some extra work, but ultimately will be a secure way to access this info.
Doesn;t work either. Thanks for the efforts. I think it would be better to just do some pyscript to copy and process the file. I tried many things like:
Totally agree. As I said before I can see the exact reason no one would want to do this.
I think I will kill a few birds with that one stone … and do some script/json parser to process and write out files into my own directory. This will actually make it much easier to write out “good” and “targeted” JSON for my sensors.
I think something like this would work. No reason to copy it somewhere and try and go over REST, just parse it with jq. It’s better then json_attributes_path anyway.
“config”, like “local”, isn’t the literal name of an existing directory. It refers to the Home Assistant’s root directory whose actual location depends on which installation method was used.
Exactly. I understand that … really … I was trying to see if there is one that references the root or there is a way to reference it. But as stated (even by me) that would be a huge no-no. The “jq” solution as a command line sensor works perfect and I have already integrated it in 10 secs.
True but only because you’re using Home Assistant Supervised (on an unsupported distro of Linux but that’s another discussion or maybe you’re using Home Assistant Container or Core). The majority of users use Home Assistant OS which doesn’t permit installing additional applications (like jq). Not that it matters for you but for most users the Solution can’t be implemented.EDIT I was wrong; command-line sensor executes in the container context, not the OS, so this will work (because jq is preinstalled in the homeassistant container). See CentralCommand’s post below.
Which is exactly why I use Core. Not that should be a matter of discussion in this thread but the title clearly states “Core”. Given that I have a big-ass server in my home closet with many things like Kodi and many other things, the need for a dedicated little box for me is not important.
Like 5TB storage
50,000 songs
Other apps that run in Linux for the house …
Actually at first I omitted this, it was only once I realized they were on core that I had to add it:
jq comes preinstalled in any Home Assistant container. So on any other installation method that sensor just works, there’s no additional configuration required.