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.
Exactly; it’s not a valid REST endpoint. You specified a file path but nothing at the destination will reply with the file’s contents.
As an experiment, add the following to configuration.yaml then restart Home Assistant.
homeassistant:
allowlist_external_dirs:
- "/config"
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:
homeassistant:
customize: !include customize.yaml
media_dirs:
music: /mnt/Music
customize_domain:
light:
assumed_state: false
allowlist_external_dirs:
- "/config"
But as I said, HA will not even start because /config does not exist. I would believe the correct answer is “/” but still that does not work.
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).
Couple of thoughts.
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 could symlink 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:
/home/homeassistant/.homeassistant
/.homeassistant
/
Cannot find anything/any path that allows access to that file.
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.
sensor:
- platform: command_line
name: Insteon modem aldb
command: "jq '.[0]' insteon_devices.json"
value_template: "{{ value_json[0].address }}"
json_attributes:
- aldb
Although I guess one note is make sure you have jq installed. Since you’re on a core install you’ll need to do that manually.
2 Likes
Thanks @CentralCommand, this looks like what could work with what I have. Just need to look into installing “jq”
What’s the OS? Raspbian/RaspberryPiOS, and most distros, should be as simple as installing from the native package manager.
It Linux Mint and I just checked with
sudo apt-get install jq
Already installed. So onto trying it out now!
1 Like
@CentralCommand solution is perfect.
- platform: command_line
name: Testing ALDB
command: "jq '.[0]' insteon_devices.json"
value_template: "{{ value_json[0].address }}"
json_attributes:
- aldb
1 Like
“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 EDIT I was wrong; command-line sensor executes in the container context, not the OS, so this will work (because jq). Not that it matters for you but for most users the Solution can’t be implemented.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.
3 Likes
Doh! I thought the command-line sensor executed in the context of the OS but I was wrong.
I’ve amended my previous post.
This seems to be the solution to my problems as well, @CentralCommand . However, I can’t get it to work (on HaOS).
In Terminal add-on, I get the following, indicating that the solution should work just fine.
[core-ssh ~]$ jq '.' /config/www/resurser/log.json
{
"Body": {
"I18N_COMMON_PV_DAYILY_ENERGY_GENERATION": "0.0",
"I18N_COMMON_PV_TOTAL_ENERGY_GENERATION": "316.8",
"I18N_COMMON_TOTAL_YIELD": "--",
"I18N_COMMON_DEVICE_STATUS": "Energy Dispatching Operation",
"I18N_COMMON_BUS_VOLTAGE": "634.0",
"I18N_COMMON_AIR_TEM_INSIDE_MACHINE": "24.1",
"I18N_COMMON_SQUARE_ARRAY_INSULATION_IMPEDANCE": "891",
"I18N_CONFIG_KEY_1001188": "100.0",
"I18N_COMMON_FEED_NETWORK_TOTAL_ACTIVE_POWER": "0.00",
"I18N_CONFIG_KEY_4060": "0.78",
"I18N_COMMON_DAILY_FEED_NETWORK_VOLUME": "0.0",
"I18N_COMMON_TOTAL_FEED_NETWORK_VOLUME": "192.8",
"I18N_COMMON_ENERGY_GET_FROM_GRID_DAILY": "63.7",
"I18N_COMMON_TOTAL_ELECTRIC_GRID_GET_POWER": "4713.0",
"I18N_COMMON_DAILY_FEED_NETWORK_PV": "0.0",
"I18N_COMMON_TOTAL_FEED_NETWORK_PV": "180.1",
"I18N_COMMON_LOAD_TOTAL_ACTIVE_POWER": "0.752",
"I18N_COMMON_DAILY_DIRECT_CONSUMPTION_ELECTRICITY_PV": "0.0",
"I18N_COMMON_TOTAL_DIRECT_POWER_CONSUMPTION_PV": "98.9",
"I18N_COMMON_TOTAL_DCPOWER": "0.00",
"I18N_COMMON_TOTAL_ACTIVE_POWER": "-0.02",
"I18N_COMMON_TOTAL_REACTIVE_POWER": "-0.01",
"I18N_COMMON_TOTAL_APPARENT_POWER": "0.02",
"I18N_COMMON_TOTAL_POWER_FACTOR": "0.937",
"I18N_COMMON_GRID_FREQUENCY": "50.02",
"I18N_COMMONUA": "235.3",
"I18N_COMMON_UB": "234.5",
"I18N_COMMON_UC": "233.1",
"I18N_COMMON_FRAGMENT_RUN_TYPE1": "0.4",
"I18N_COMMON_IB": "0.4",
"I18N_COMMON_IC": "0.4",
"I18N_COMMON_PHASE_A_BACKUP_CURRENT_QFKYGING": "0.1",
"I18N_COMMON_PHASE_B_BACKUP_CURRENT_ODXCTVMS": "0.1",
"I18N_COMMON_PHASE_C_BACKUP_CURRENT_PBSQLZIX": "0.4",
"I18N_COMMON_PHASE_A_BACKUP_VOLTAGE_PEIYFKXE": "--",
"I18N_COMMON_PHASE_B_BACKUP_VOLTAGE_MCDGYUJO": "--",
"I18N_COMMON_PHASE_C_BACKUP_VOLTAGE_SCJZFFCQ": "--",
"I18N_COMMON_BACKUP_FREQUENCY_MPPOWHDF": "--",
"I18N_COMMON_PHASE_A_BACKUP_POWER_BRBJDGVB": "0.000",
"I18N_COMMON_PHASE_B_BACKUP_POWER_OCDHLMZB": "0.000",
"I18N_COMMON_PHASE_C_BACKUP_POWER_HAMBBGNL": "0.000",
"I18N_COMMON_TOTAL_BACKUP_POWER_WLECIVPM": "0.000",
"I18N_COMMON_MAXIMUM_APPARENT_POWER_SIWHFGQY": "10.0",
"I18N_COMMON_METER_GRID_FREQ_AMMAKPKU": "50.02",
"I18N_COMMON_REACTIVE_POWER_UPLOADED_BY_ME_KISYMRKR":
"-221",
"I18N_CONFIG_KEY_3907": "0.000",
"I18N_CONFIG_KEY_3921": "0.000",
"I18N_COMMON_BATTERY_VOLTAGE": "328.6",
"I18N_COMMON_BATTERY_CURRENT": "0.0",
"I18N_COMMON_BATTERY_TEMPERATURE": "16.5",
"I18N_COMMON_BATTERY_SOC": "60.0",
"I18N_COMMON_BATTARY_HEALTH": "100",
"I18N_COMMON_MAX_CHARGE_CURRENT_BMS": "30",
"I18N_COMMON_MAX_DISCHARGE_CURRENT_BMS": "30",
"I18N_COMMON_DAILY_BATTERY_CHARGE_PV": "0.0",
"I18N_COMMON_TOTAL_BATTERY_CHARGE_PV": "37.8",
"I18N_COMMON_DAILY_BATTERY_DISCHARGE": "0.0",
"I18N_COMMON_TOTAL_BATTRY_DISCHARGE": "45.2",
"I18N_COMMON_DAILY_BATTERY_CHARGE": "0.2",
"I18N_COMMON_TOTAL_BATTERY_CHARGE": "73.5",
"MPPT1": "0.0",
"MPPT2": "0.0",
"I18N_COMMON_GROUP_BUNCH_TITLE_AND%@1": "0.00",
"I18N_COMMON_GROUP_BUNCH_TITLE_AND%@2": "0.00",
"I18N_COMMON_REMAIN_BATTERY_POWER": "62.0",
"I18N_COMMON_TOTAL_BATTERY_DISCHARGE_BMS": "67.1",
"I18N_COMMON_BATTERY_OPERATION_STATUS": "Run"
}
}
In configuration.yaml I have the following code, which for some reason does not produce a sensor.
sensor:
- platform: command_line
name: sgjson
scan_interval: 20
command: 'jq ''.'' /config/www/resurser/log.json'
value_template: "{{ value_json[0].Body }}"
json_attributes:
- I18N_COMMON_BATTERY_TEMPERATURE
Any ideas as to why the above does not work? I’ve tried inverting quotes: command: "jq '.' /config/www/resurser/log.json"
The following code solved the issue:
sensor:
- platform: command_line
name: sgjson
scan_interval: 20
command: 'jq ''.Body'' /config/www/resurser/log.json'
value_template: "OK"
json_attributes:
- I18N_COMMON_BATTERY_TEMPERATURE