How can I convert my HASSIO instance to not use default_config in the config file?
I tried this on one installation and tanked it. I could no longer access it. Just need some guidance on proper steps as just removing default_config does not seem to be the proper steps.
Remove default_config: from your configuration.yaml file then add back all the listed entries here that you need:
But if I remove it wont I lose access to the frontend and have to edit another way?
I tried commenting it out before on another installation and could no longer access the frontend.
If you just remove default_config: without adding those things back manually, it will screw up your installation. There’s a bunch of important things in there like frontend: (required to show the frontend), config: (required to show the Configuration panel), updater: (for being notified of updates), and more.
In general it’s not a good idea to mess with that unless you know exactly what you’re doing.
@SeanM My problem is that default_config picked up some cast devices via auto discovery that I cannot remove. Looking around there doesnt seem to be a sound method to remove the individual devices.
I don’t need/want some of the services included in default_config so here’s how I’ve defined it in configuration.yaml. I’ve commented out cloud, history, logbook, map, ssdp, and zeroconf.
# Configure a default setup of Home Assistant (frontend, api, etc)
#default_config:
# Individual options represented by default_config
automation: !include automations.yaml
automation manual: !include_dir_merge_list automations
#cloud:
config:
frontend:
#history:
input_boolean:
input_datetime:
input_number:
input_select:
input_text:
#logbook:
#map:
mobile_app:
person:
script: !include scripts.yaml
#ssdp:
sun:
system_health:
updater:
#zeroconf:
zone:
Whatever you do, don’t exclude frontend (it will prevent the UI from being rendered) or config (it will cause problems if you use multiple dashboards).
FWIW, this part:
automation: !include automations.yaml
automation manual: !include_dir_merge_list automations
allows any automations created by Automation Editor to reside in automations.yaml and automations that I create with a text editor to reside in a sub-directory called automations.
Thanks @123
Do you know if I convert to this will it remove existing devices?
I have a separate cast.yaml defined so this should stay intact?
What is cast.yaml?
Cast integration uses zeroconf: to discover devices I believe, so you’d only need to comment out that one line (which is already done in @123’s code block).
But if you do this, you should be aware of the consequences. It will prevent the vast majority of devices from being discovered in the future, not just your Cast ones. It will also break functionality in numerous other places - for example when you install the official mobile apps it uses zeroconf: to scan your network during the onboarding steps, this would fail.
In some cases it might not fail completely, but you would have to perform “manual” setup of entering an IP address and port rather than it being detected automatically through zeroconf: … So basically it’d be less convenient. This might be OK with you, just wanted to point it out ahead of time.
I would suggest opening a bug report on the core repo saying that you can’t ignore a cast device. My understanding is that frenck updated all existing integrations to support this after ADR-011: Discovery requires Unique ID. If you can’t ignore the discoveries here, it might be either a bug or an oversight.
What Sean said; understand what you lose if you disable things.
After initially discovering all discoverable devices using zeroconf and ssdp (in my case it discovered various Homekit accessories, Google Cast devices, and printers) I installed the integrations I wanted, clicked Ignore for what I didn’t want, and then disabled zeroconf and ssdp (because I no longer need it to monitor my network for new devices).
All integrations I installed work perfectly but if I, for example, were to connect a new Homekit accessory to my network, Home Assistant is no longer aware of such additions so the new device would not be identified and reported to me. However, for my purposes, that’s OK; I can manually add the new device (like Sean said, there’s a decreased level of convenience if you disable zeroconf).
Thanks @123, did you click ignore for the integrations or the devices after discovery? I have devices discovered that I want to remove.
My other question. If using default_config will discovery: ignore: work. I tried and Invalid config for [discovery]: value is not allowed @ data[‘discovery’][‘ignore’][0]. Got ‘zeroconf’
The answer to both questions is yes.
Is there documentation on this? I wasn’t able to find anything in my searches. Does this work with other entries too? For example, script?
Sorry, I should have been more clear. I mean the automation manual part. I’ve not seen this before.
It’s described here in the section concerning the Automation Editor. The only difference is that the example uses a different word to differentiate between the files you edit manually and the file used by the Automation Editor.
I’m not seeing where the linked section refers to separating GUI and manually-coded !includes, is there any other documentation on this feature?
if you want to split your scripts up so that the script UI editor works and your files are split, look here or,
go into a terminal in HA and do this:
ln -f /config/scripts.yaml /config/#path_to_your_sub-folder/scripts.yaml
and in configuration.yaml do this:
script: !include_dir_merge_named /config/#path_to_your_sub-folder
Then put your split folders here for scripts. Add your other scripts in other xxx.yaml files into this folder and they will be used in the config as well.
This links a file placeholder in your sub-folder to contain the actual scripts.yaml data for the config process to use, and it allows the Home Assistant UI editor to parse, destroy, and re-create the /config/scripts.yaml file anytime it needs to for editing.
I didn’t care about the scripts UI editor until I started doing blueprints and needed the script UI editor to actually work.
(I haven’t tried, but I believe you can do the same trick with automations.yaml.)