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…
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:
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.
Definitely agree with CaptTom at message #5. My biggest lesson was to stick to one learning curve at a time. Too many tutorials/blogs are undated and can send you down paths of maximum frustration. Give up, calm down, and try again (picking a different instructions) when your hair has grown back.
fyi: my naming convention
Initially I tried to use self-documenting device ids; but after my first year, gradually adding devices, I have a large naming headache … so now I’ll start HA again but with a device naming convention But my naming convention is different.
My major influences are (a) I am semi-retired with low income, and (b) I am renting, which means:
none of my devices are fixed into the building. I recently bought more compact smart power switches and moved the old one named “charger” so it is now monitoring electricity used by my washing machine. I’m thinking to buy a zigbee solar powered blind motor - and so my current living room unit will be relocated to the study. I also expect some attrition just after warranty period.
Since my devices all are portable and interchangable, it does not make sense for me to use location or purpose as part of device_id name. YMMV
because I don’t expect a large number of devices, wi-fi is acceptable. It also improves availability of lower-cost devices.
Other considerations:
I saw suggestion to append last byte of IP address to IDs, especially when I have several of the same model.
I am also wanting to keep device and entity IDs fairly short to make them easy to read and write, and I don’t mind using model numbers.
I have started a spreadsheet to keep track of all the device details - including the location and purpose for each item.
often the device_ID is prefixed by the domain, hence switch.pc191ha_switch seems a little redundant
display names are used in Lovelace cards.
As an example, I have several Arlec PC191HA power switches, so the one with IP address 192.168.1.105 is switch.pc191ha-105 and has an entity number.pc191ha-105_countdown.
At least, that is my current thinking. Now to burn HA to a new SD card and setup everything from scratch again, hopefully avoiding the configuration errors I made previously.
I like this one! I’m forever going back to my router to find out which one is which!
I agree that WiFi devices are cheaper and work fine. I use a number of them. The one thing I’d be careful of is that so many of them require connection back to the manufacturer’s cloud.
There are several problems with this. Obviously performance and reliability suffer if every command has to travel (and be translated) from HA, over the internet to the manufacturer’s server, then come back the same path before the device responds.
But the most insidious part is relying on a third party to keep everything working. Manufacturers can and do go out of business or start charging for a previously free service. Even if you have a fully local integration, the manufacturer can send an OTA update which breaks that integration and forces you back to using their cloud. I’ve had it happen to devices I’ve owned.
Fully local WiFi devices, flashed with Tasmota or ESPHome, obviously don’t have these problems.
It’s easy to choose wisely though. Not one of my 105 Wifi devices are cloud connected. All local control.
This is a pretty neat idea. I have a spreadsheet I reference once a month or so, it would be easier just to look at the entity id. 105 devices though, most with multiple entities. And so many automations and scripts that use them. I wonder if it is worth the time retroactively renaming them for me now?
I’ve always been afraid to look at charts like that. I’m that guy who will spend days creating something which will save me seconds. This odd behavior had some benefits in the corporate IT world though. I think some things I set up to make my job easier over a decade ago are still in use by thousands of users.
If it saves you 5 seconds a day and you do it 5 times a day you can spend 12 hours on getting it right. It will only take you 5 years to recoup the time
.
But my naming convention is different.
