Starting from scratch...?

Installation
1

Hi All!

Firstly, I’m quite well versed with HA, Linux, Proxmox, Alexa, HomeKit etc.
I’m running the supervised install in a VM on Proxmox and it’s working brilliantly.

I’ve been putting it off for quite some time, however, now that supervisor install is being forcibly deprecated, it’s time to change.
I still want add-ons, so decision-made, it’s HAOS in a VM for me.

Now, I can back things up and restore to a brand new install but I’m wondering if I should start again as there have been quite a few ‘abominations’ over the years that are cluttering up the database and device names should really be better and more uniform. I can manually copy the automations/scripts back over etc as I use seperate YAML files for everything and reference them from the configuration file to keep things tidy.

I like to ask Alexa and Siri to turn things on/off. Open the office left window, open the spare room window, is the back door open etc etc

Currently it works, however, sometimes I have to name a sensor (eg Back Room Temperature) to Temperature and put it in the Back Room area to get it to work because it wants me to say “What is the back room temperature temperature?”

I normally use sensor.front_window, sensor.front_door, sensor, sensor.library_humidity etc
Also, I’ve written quite a few template sensor/rest sensor configs etc, so it’s quite a complex setup which utilises Node Reg, InfluxDB, Grafana etc

Should I be using areas and naming things more simply? Then that would lead to a load of devices with the same name (not ID) but different areas. I’m not sure if that’s a good way to do things.

Also, there are a lot of devices which have components that I don’t really need in home assistant, such as “Window/door is open in regular position” which take up another entity name that i don’t need for my application. Should I disable these extra sensors? Door/Window sensors have a lot of useless (to me) extra sensors. I just need open/closed/tamper/battery/last-seen etc

Second question, if I’m going to start from scratch and do things properly, should node-red, influxdb, grafana etc be addons or separate isolated installs/vm’/lxc’s?

I know there’s a load of tutorials and such out there but they seem to be for basic setups and there’s a lot of different opinions about which is the CORRECT way.

I’m laying out a plan to redo things and I’m leaning toward the “start again” thing and the only real downside is losing long-term data but I could always access the old InfluxDB database and get that if I needed to.

Any tips/recommendations would be appreciated.

2

Nice thing about VM’s are you can spin up as many as you want…
I would make certain you have good off-site backups and the key ready, spin one up, then once up restore the back-up.
If you don’t like what’s happening spin up a new copy, and try migrating stuff over.
You haven’t killed your supervised yet so just get your transition where you want it before you do.

1 Like
3

Yes, agreed. That’s why I like to use them. I’ve been spinning a couple up and playing. Any suggestions about naming-conventions?

4

Overengineering is the trap most people fall into, in production systems. There is a simple rule of thumb. Stick to the KISS principle.

The less dependencies you have going forward the more stable your system will be. So stick to the standard HAOS components for everything. Install an add-on or HACS module only if it will provide much needed functionality to your production system.

Automation is about not seeing things. A well designed system, ideally, has no user interface as things happen, well, automatically, but if it must have an interface ensure it is dead simple to use with one touch/voice command.

I see dashboards with a myriad of options that on face value look fantastic, but from a usability point of view they are a show stopper.

After all we are not designing for a fighter plane cockpit.

To satisfy your curiosity and appetite for learning/tinkering design a playground system which does not interfere with your production system.

Long term stability can only be achieved if you stick as close as possible to standard HAOS with as minimum as possible add-ons/HACS.

1 Like
5

Understood and I take your point. I’ve playpen’ed HA in many different instances over the years aside from my production server and only implemented things that I need in the main system.

I’m more interested in naming-conventions and if extras should be addons etc. I take from your reply that you recommend any extras be installed as their own creature and not an addon. Thank you.

6

For naming convention you need to design a dictionary first; for exmaple:

r = room
u = user
l = light
f = fan

Then you can create entries like R1F1 and so on.

For add-ons and HACS, you are spot on run what you can outside HAOS.

7

All good points, however, what is the benefit of a generic dictionary object over some more specificity like sensor.front_room_temperature ?

8

Some of the points below might not be applicable to your circumstances:

If you create a dictionary generic enough it is easy to create an abstraction layer between physical infrastructure and HA.

If, for example you changes location you can keep the naming conventions mostly intact, just change where your dictionary terms point to.

It is easy to scale. For example, adding another room is easy instead of having to think how to name things.

Changing an item’s physical position within the same location does not require renaming the resource.

OSs are built with abstraction layers. A dictionary allows you to build that abstraction layer that shields you from having to renaming resources frequently.

Lastly an additional benefit is less typing.

You could consider naming the physical resource using long descriptive names, but create a shortened version using helpers. Then all operations in HA can exclusively use the helper names. This is one way creating an abstraction layer in your infrastructure.

Apologies for the typos, damn autocorrect.

9

Thank for the reply. All good stuff to consider.

I’m used to reading around typos! Autocatrectal gets me too, sometimes! :slight_smile:

10

Well, I’ve sandboxed everything in VMs/CTs and so-far so-good. Only in staging at this point but I’m just making sure everything can talk to each other with no problems. I’m still working on naming-conventions and not 100% sure on the way I want to go.

Does anyone have any points on using Areas and names with less specificity or just go with what I think?