As discussed in your post here 
You can still improve on your configuration file.
By using the "packages:!include_dir_named integrations "
Then make a dir named integrations
And store yaml files according to what you want to add to your config file.
Then you make a file : binary_sensor.yaml ( example)
Then you write all the stuff from binary sensors in that file
I also include the link in the file from the Homeassistant website explaining what binary sensors do or how you van adjust it.
That way in the future you just open the file and have the link ready to read up about it 
And this way you have all your configuration items nicely ordered in your haos
You’re mixing two things here, this is exactly what packages are not for. 
If you want to include device or integration specific files, you don’t need to use packages. These can be included via splitting up the configuration > advanced.
It doesn’t hurt to do it that way, but the real advantages in packages is to not need to put all sensors or input_xy or ?? into one file each. In packages you mix all the different things in one file which allows for a more logical approach to sort and devide like rooms or areas or whatever.
There are two ways to handle the outsourcing of things out of configuration.yaml. One is the way you partly described, where you put every integration like sensor, input_boolean, input_datetime and so on into one file for each integration and let them load via the one command for each in configuration.yaml.
Like this:
# configuration.yaml
sensor: !include sensor.yaml
# or for directories with different files
sensor: !include_dir_list sensors
This would work for a setup, where you have either a file sensor.yaml in the same directory where configuration.yaml lives, or you have a folder in that same directory where you have different files like sensor_1.yaml, sensor_2.yaml or whatever_name_you_want.yaml.
# directory structure
|--- sensors/
| |--- sensor_1.yaml
| |--- sensor_2.yaml
| |--- whatever_name_you_want.yaml
|--- configuration.yaml
|--- sensor.yaml #only one is allowed, either file or directory
In every file you now can only list sensors:
#sensor:
- ...
If you want that, this is your way to go.
Now the second method to get things out of configuration.yaml is packages. As stated above, they allow for another direction to go to, where you put all things together, that belong together in the logic you invent. An example would be, you want to have all your things belonging to your front door in one file, no matter the type.
Like this:
# configuration.yaml
homeassistant:
packages: !include_dir_named packages
# directory_structure
|--- packages/
| |--- frontdoor_package.yaml
| |--- backdoor_package.yaml
|--- configuration.yaml
And in your file frontdoor_package.yaml, you work like this:
input_boolean:
- ...
automation:
- id: whenever my door opens
...
- id: whenever my door closes
...
template:
binary_sensor:
frontdoor_is_open
alert:
- ...
As you can see, everything is in this one file. From automations to sensors and whatever your heart wants. 
I personally find that very appealing, it is way more of a logical order in my eyes. If i have to look for something, I finally find it on a first glance. That might have to do with my age, but I don’t want to remember how I named the one specific sensor on my front door. I just look into one file and find it. 
Please don’t misunderstand me, there is no right or wrong with this, it is just a flavour question. What is the logic, you want to put behind all this? And not to forget, you can mix and match as you want. Like you did in your post above, there is surely no harm in including the package folder and use it with domains (like sensor or ìnput_boolean). It just doesn’t make use of the most important feature of packages - the possibility to include every domain without naming it in configuration.yaml.
5 Likes
And you can make it even easier to find stuff if you have a naming convention that allows you to know which package it’s in.
Example:
Almost all of my lighting automation system (include datetimes, booleans, scripts, automations, etc) are in my lighting_package.yaml file. but there are a couple that aren’t because they don’t necessarily logically fit in that package.
all of the entity_ids for things in the lighting package all start with “lc_” (for “lighting controls”). The others that aren’t in that package start with a different prefix and clue me in to which package they are included with.
1 Like
Very good thread and some great things to consider.
My Home Assistant does not run on bare metal. Virtualization is the way to go. Rasberry Pi boards are slow and expensive and very limited in performance. Proxmox running on a small micro computer system will far out perform a Pi board, in addition to opening up the world to further visualize other components of a secure network.
People make the mistake of running network services as a HA plugin, for example, reverse proxy, DNS/AD Blockers, etc. I separate these to keep my HA instance clear of non-automation tasks. Those micro services run just fine virtualized on the same Proxmox box.
For backups, I will never EVER send my backup data to Google. Afterall, its another cloud provider that snoops data. Storage is cheap, keep it local. The so called “off site” backup is over rated and not necessary for home applications. If your home burns down, you have bigger problems than a google backup. If off site is required, there are other options that offer encrypted storage.
Working with HA for the past couple years has exposed me to a lot more technology that just HA itself. Its truly amazing what open source software can do, if there is a reason to do it.
Thank you for this wonderful write-up @kameo4242.
I noticed that in #6 above the link to "securing your network…’ does not work. When I click it, it says: “Oops! That page doesn’t exist or is private.”
Has it moved or is it posted elsewhere? Thank you.
The title of that thread was changed, so the link isn’t valid anymore…
Here you go, but take your time, this is a seriously written post, and it is long! The length is needed, but it is not a “five-minute-job”.
@kameo4242 Sorry for tagging you, but could you please change the link to your tutorial? Thanks!
What sort of helper would you recommend as a proxy variable for a smartphone device tracker please?
Great idea!
Use the old style groups in your config.yaml
Hi @FriedCheese just did that, created old style groups for my smartphone (one for gps and one for wifi). Those groups do what they are supposed to do, they show me as home or not_home based on the underlaying entity state (wifi or gps on my smartphone).
However, the groups are not selectable in the person entity. How to go about this please? Can one set the device type of a group to device_tracker for example?
Entity ID 'group.fred_smartphone_gps' does not belong to domain 'device_tracker' for dictionary value @ data['device_trackers']. Got ['group.fred_smartphone_gps']
I’d you’re putting them in the person entity it is itself a group. (you don’t need it)
You would add the device trackers tonthe person then the person’s aggregate state is home or not_home. So you don’t need a group inside a person. Object.
(read: You’re already abstracting the group membership and don’t gain any benefit)
Use old style groups for grouping trackers when you’re NOT using them with a person
1 Like
Ah ok. I thought the point of proxy entities is needing less changes. Such as when you replace your smartphone.
E.g., how could proxy entities be set up for using in-app (HASS) notifications?
For those you need a notify group.
For my system I put my phone in my person object (its the base object for presence detection in my system). (use zone counts to determine home presence. The Home zone will be a count of persons in zone)
Then I also put the phone in one or more notify groups:
Family Member Notify
Family Member Notify Verbose
Guest
Admin
All automation targets one of those notify groups or person object. So when I get a new phone next year I just edit 5 groups.
2 Likes
Excellent list, thanks.
I would also add to spend some time on the various automation solutions and realistically decide on which to use vs. the number of automation vs the expected dynamism (how often you will change them) vs the time you have.
I started with HA some 5 years ago and initially went for the UI-based automation.
I then felt that they are very limiting and moved to AppDaemon (I am an amateur developer)
I briefly decided to replace it with my own code
I then felt that this is too disconnected from the core HA and moved to YAML for automation
Then I discovered pyscript and moved everything there
And today I am back to UI-based automation 
Why? Because I realized that I have a fairly stable set of similar automation (I need to have a look at blueprints BTW) that I need to switch on and off on a regular basis.
I also need from time to time to change them from my bed, on my phone.
This means that I have a long web page with automations and writing them is a bit cumbersome. My developer’s heart feels pain as well. But this si probably the most optimal solution for me (and that’s why one should spend some time on testing the above to avoid constant moving between solutions)
1 Like
Indeed, that works. For those who prefer a notification group instead of an individual device (so you only need to change the group instead of all automations where the device is called), a few pointers.
This solved it: Sending notifications to a group - #6 by agios
Working example (e.g., you’ll get notify.phone_fred and notify.phone_x).
notify:
#NOTIFICATION GROUP:
# https://companion.home-assistant.io/docs/notifications/notifications-basic/#sending-notifications-to-multiple-devices
# https://www.home-assistant.io/integrations/group#notify-groups
# https://www.home-assistant.io/integrations/notify/#test-if-it-works
- name: "Phone Fred"
platform: group
services:
- service: mobile_app_freds_phone
- name: "Phone Partner"
platform: group
services:
- service: mobile_app_x_iphone
1 Like
So true, like Tuya, asking for a lot of $$$ after 3 months of use on their wifi products because it is cloud dependent. Buy Tuya if you want, but Zigbee not Wifi. You’ll even save a few bucks on consumption.
And don’t tell me that you can ask for an additional 6 months easely! Yes, but for how long? Are you aware of Tuya’s plans for the future?
3 Likes
Thanks for these tips.
To add to your point 16 “Don’t under-estimate groups”, these tips also apply to the new style of groups.
For example, when you define a group in the new style:
binary_sensor:
- platform: group
name: "pirs"
device_class: motion
entities:
- binary_sensor.pir1
- binary_sensor.pir2
You can enumerate group members like so:
{% for sensor in expand(state_attr('switch.always_on_group', 'entity_id')) -%}
– Ingrid
4 Likes
So… wow… this is great! Having just installed HA yesterday what I now realize is… I think I know just enough to really grind myself into the dirt.
When I started I thought it had something to do with self-hosting and privacy. NOPE!
Where are the discussions on privacy? Should I give someone access to my github and go to sketchville to D/L files to crack my NSpanel ?. I did. I have a NABU subscription, I use duckduck for my searches. should I put a Google ai device in my home server? Feels like I am turning my chicken coup into a B&B for foxes.
Well I think a self hosted solution like HA is a good starting point.
Also, as highlighted in the post, use cyphered protocols, focus on FOSS, no Cloud dependencies as much as possible, no Alexa and other connected mics. Secure your remote accesses, segregate your networks. etc.
But there is indeed more to write on that front.