I was just going to say this and saw you mentioned it already. The day of the AWS outage this week all my Alexa, ring, and blink cameras were offline. My locally connected zwave and zigbee devices, and home assistant automations for them all kept running fine.
In my situation, yes this was a pain. I eventually paired a smart switch with the smart light, decoupled the switch from relay and used it as a button. That relay stays on forever unless something goes wrong with the fixture 
Yes. I had a house sitter that went around and removed the sticky dots I put over each switch so they could not be operated manually. She just could not get her head around the need to not use light switches. It’s probably just a psychological need to be in control, as since being home (8 months) I have not needed to touch a light switch once, so the automation does actually work.
Though if you use an external editor like VSCode there are many extensions that assist in creating Home Assistant YAML (not just the HA helper extension, indent rainbow, bracket rainbow, spell check, etc…).
Also I would advise against using blueprints as much as possible so you have a deeper understanding of how your home automation works and are not reliant on others to sort out the bugs. This will minimise downtime.
Excellent advice. Getting this right from the start helps tremendously. Fix your entity_ids as soon as you add new devices and stick to your chosen convention.
Just to be clear, I’m not throwing away all my gear, just restarting HA config 
This is indeed excellent advice.
yes, although you can also use those in conjunction with the ui editor, correct? just edit automations.yaml with aforementioned editor (although you may want to use the GUI to initially create automations, I’m not sure.
I concur for things like a simple light turning on when a door opens, etc., but for handling input devices like this one, writing that automation and debugging it from scratch? No thanks! And definitely not three times over during the ozw to open zwave beta to zwave js debacle. 
Twice was enough!
edit: and case in point, I can see in that thread there was a zwave js breaking change that was fixed in that blueprint too, that I just had to re-import to fix as the author fixed it for everyone. 
2 Likes
I have another one:
- Minimize the number of add-ons and integrations you use.
I say this because HA (and the whole smart home market) is so dynamic. So many things change in each version. The more “stuff” you have, the more likely something will be broken by an update. Likewise, vendors make firmware and API changes which require some time for the HA integration to catch up.
You don’t want to be in a position where you cannot update HA over several versions, because that one integration you rely on introduced a bug that’s not fixed yet. Especially if, just as your first bug is fixed, a new version introduces a new bug in a different integration you also rely on. The more different integrations/add-ons/protocols you use, the more likely this is to go on over many versions.
It is still true that HA is great for integrating smart devices from many different vendors, using many different protocols. But you do expose yourself to more maintenance the more of these you use.
2 Likes
This is V3 of my HA config and the only thing I brought across from V2 was the Docker compose file that handles all the containers.
V1, everything was edited by hand in the various yaml files, V2 was mostly edited by hand with more being done in the GUI as I went along & the gui matured.
V3 will be as much GUI as possible, up until the point I need to go and edit me some YAML. I think some of the sensors I need to create will have to be manual, like a sensor to indicate when the house is empty because we’re all away.
1 Like
I’ve seen people try to minimize integrations by using mqtt whenever possible- ie zwavejs2mqtt and zigbee2mqtt. Their setups seem more resilient to breaking changes.
2 Likes
Keep it simple (KISS).
I started with a RB Pi 4 with with Docker, Portainer, non-HA stuff running in other containers, MQTT, etc. and a bunch of add-ons and integrations (including HACS stuff). I restarted from scratch with Home Assistant OS, as per recommended installation method, and tried to standardize and simplify as much as possible:
- trying to stick to one brand for a specific device class
- standard naming conventions (+1 to everyone who mentioned this)
- only using Node-Red for automations (no YAML)
- ensure everything still works if HA is down (switches can still be switched, sensors will still alarm locally, alarm system can still be armed/disarmed and phone me if there is a problem - yup, I still have a land line).
- One wireless protocol
- no more mqtt (to be clear, I love mqtt but the devices/integrations I use now don’t need it; therefore, one less thing to worry about).
I learned a lot with the first setup. I learned more with the second (simple is better). And I’m still learning and having fun.
As for my favorite automation… I like the presence detection automations: notifying us that the garage door is open after dark, prompting to arm the alarm system when everyone has left the house, disarming the alarm when we get home, turning lights on and off, etc. But the flood sensor has saved me twice!
2 Likes
I love the MQTT based integrations because you can trivially watch what’s going on from the outside by just subscribing to topics. All of my ad-hoc sorts of integrations are done using MQTT, which has very good “coverage” across all of the entity types in Home Assistant.
3 Likes
Another “out of the box” Raspberry Pi / HASS OS installer here, trying to follow the KISS principle.
Nothing against MQTT, and I get why so many people love it. I’d use it if I could justify installing and learning it. So far “native” HA has done everything I want.
I had to use YAML to configure things anyway (although less so these days) so using it for automations made more sense to me than learning Node Red. The UI automation editor just keeps getting better, to the point where I find I use that instead of editing the YAML more often than not. To be honest, I never really “learned” YAML, just followed the examples and got used to its quirks through trial and error.
When skimming through the breaking changes and new version blogs, it’s nice to be able to ignore all those problems with components I don’t use.
- [quote=“CaptTom, post:5, topic:365072”]
Naming conventions: There are so many different ways to name devices and entities, and to create icons for them. It gets confusing, figuring out what’s what and what’s configured where.
[/quote]
What he said. Pick something a stick with it. I personally do type of device followed by general location. So for a smart outlet in master bedroom on my side of bed, ill use
switch.outlet_master_bedroom_jims_side
-
Keep organized. I created an excel file with multiple sheets that I keep active notes on. Cause at the time, you think, “oh ill remember why I did this” or “ill remember HOW i need to pair these when the time comes again”. But then you inevitably forget, aside from remembering that you thought you would remember. lol
-
Dont buy an overpriced ‘Flic’. Buy $4 Xiamoi smart buttons. lol
99,9 % of my hardware is integrated using mqtt. Tasmota, Openmqttgateway, EspRfLink, Zigbee2MQTT, …
In the almost 3 years I have been running HA I have had maybe 3 breaking changes.
So true!! My “HA” reference folder has 61 sub-folders and 773 files, not counting the backups of the live HA system I keep there. 146 of those files are shortcuts (links) to various forum threads here and pages from GitHub, HA documentation, and third-party hardware and software documentation and instructions. 81 are text files, mostly notes I’ve written to myself about how I did something.
There’s just so much information out there that it’s hard to remember where I’ve seen it or exactly what words I should be searching for. Very often one task requires multiple different reference sources, but may not need to be done again for months or years. “How did I do that again?” is probably my most-asked question to myself about HA.
2 Likes
I started to go down the same documentation path with folders, spreadsheets, word files and realized an old software developer adage: everything should be self documenting (as much as possible). Comments in YAML, Node-Red, etc. to explain what, why, how, etc.
So when I simplified everything, I was able to delete most of the notes, instructions, and directories I was keeping to help me keep track of stuff.
I do have a “Home Automation” bookmark folder in Chrome that I reference a lot 
.
And these forums are priceless.
Plus I backup everything regularly and test to make sure I can recover from the backups (in case you’re wondering: how would you rebuild everything if it went up in smoke?).
May I ask, if and how the bracket rainbow extension is working for you, when editing HA yaml files? I tested several bracket pair highlighting extensions, but all of them seem to intentionally ignore brackets in literals (strings). And the only place in HA yaml files where I’d really benefit from bracket pair highlighting are jinja templates. But as these are handled as literals in yaml files, everything in a template is just the same color. No bracket highlighting at all…
Am I missing something here?
I have to admit, that I tried two other extensions yesterday which didn’t work (Subtle Brackets and Bracket Pair Colorizer 2). But I didn’t try Rainbow Brackets, because this extension doesn’t show up in the search results, when using the built in search function:
Maybe it’s too old…?
Downloading it manually and installing it from a vsix file failed as well with a “No servers” error. So I gave up on this extension.
But today I found out that the vsix installation from the local file system just doesn’t work with any extension in hassio’s vscode addon and I rather had to copy the vsix to a folder mounted in the addon’s container file system, i.e. the home assistant config folder. From there I could finally install it and it’s indeed working now. 
Although Z-Wave is expensive, avoid those cheap Chinese PIR sensors (Neo Coolcam). Buy quality devices.