Starting Over With Home Assistant

Configuration
1

After a few years of using Home Assistant I’ve learned so much and refined so much of what I did originally but I’ve also learned some good lessons on how I would do it better - plus there’s always old lingering “stuff” around that’s good to get rid of. The problem is that I built up Home Assistant to mimic how I set up Indigo so I created so many unnecessary things as a result (some were unnecessary at the time, others became unnecessary as new features became available in Home Assistant).

Like so many others I’ve over-engineered a lot of stuff that could be much simpler, less prone to problems and create less of a need for me to “lay hands” on HA on pretty much a daily basis.

I have a pretty good system for rebuilding Home Assistant gradually, rather than spending the next month in a state of flux. Since I run on a virtual machine, I can literally power down the “production” system, then power on the “beta” system and attach all my dongles with the click of a button. This is to say swapping back and forth should be fairly seamless.

My intention is that I’ll just clone my current virtual machine and then start surgically removing pretty much everything, stripping it down to the core devices and redoing all automation and scripts and so forth. Really starting with a pristine system, no HACS or anything because I think some of that is the source of so many errors I get. I’ve leaned too hard on extensions to fill gaps and have too much reliance on them.

What I’m not quite sure about, and am hoping for suggestions about this, is keeping a few items in sync with the production system:

  • Keeping the Z-Wave devices in sync (I’m going to try not to add new ones during this time but things happen)
  • Keeping the Zigbee devices in sync (same deal)
  • Keeping my history. This one is tricky because I’m on MariaDB and will be going back to SQLite so I know I have to do that migration and my question is if having my database “mirrored” on a system where all the automations and such are gone will be a negative thing. I don’t think so since my devices will remain the same (the entity ID’s will change, so I know I’ll lose data there but I’m ok with that). I don’t think I’ll migrate the database frequently but towards the end I likely will do it repeatedly to ensure I don’t lose things like my energy stats.

Any suggestions? Pitfalls I have not taken into consideration? Better approach than this one?

1 Like
2

It might be helpful, before you start, to document the parts of your current system you plan to replicate in the new. Not code-level documentation of the “how”, but the “what” such as devices you change when it gets dark, when you turn on security mode, etc. It will be simpler to refer to this listing as you rebuild, rather than needing to switch back and forth to the old environment. It will also help you recognize when you’re done! (This is based on my experience converting from Homeseer to HA a couple years ago.)

1 Like
3

That was the first thing I did! I’ll also have all of the files I use (as I currently use HA in a package based system) so I can easily re-use things that work well.

4

Awesome! Will the new system use HAOS or one of the other installation method?

5

100% HAOS, I have no interest in core or docker honestly. I know some folks find real benefit to it but for me HAOS has been a great platform and I have no compelling reason to change.

6

Excellent. Your Z-Wave should all transfer over nicely, since most of that info is stored in the stick itself.

Good luck, and let us know how it works out!

7

Well, everything will transfer over initially since it’s a clone, I’m more concerned with updating the clone from that point forward, I’m pretty sure all the definitions need to come from the .storage but don’t know if there are pitfalls to copying that. Same with Zigbee.

8

I just through this together, but the blueprint should sync lights and switches. It’s loosely based on these old automations i’ve been using

It’ll work with any number of lights/switches and keep them all in sync.

blueprint:
  name: Toggle Buddy
  description: Keep lights and switches in sync.
  author: Petro
  domain: automation
  homeassistant:
    min_version 2020.1.1
  input:
    entities:
      name: Entities
      description: The entities that will be in sync
      selector:
        entity:
          multiple: True
          filter:
            domain:
            - light
            - switch
            - input_boolean

trigger:
- platform: state
  entity_id: !input entities
variables:
  input_entities: !input entities
  entities: >
    {{ [input_entities] if input_entities is string else entities }}
  state_list:
  - 'on'
  - 'off'
  continue: >
    {{ trigger | default(none) is not none and trigger.to_state is defined and trigger.from_state is defined }}
  to_state: >
    {{ trigger.to_state.state | default(none) if continue else none }}
  targets: >
    {{ expand(entities) | rejectattr('entity_id', 'eq', trigger.entity_id) | rejectattr('state', 'eq', to_state) | map(attribute='entity_id') | list if continue else [] }}
condition:
- condition: template
  value_template: "{{ continue and to_state in state_list and targets | count > 0 }}"
action:
- service: switch.turn_{{ to_state }}
  target:
    entity_id: "{{ targets }}"
1 Like
9

As for starting over, I usually opt to fix sections instead of starting over. At this point, I’m maintaining a configuration I started in ~2015ish. I’ve rewritten main automations over probably 3 or 4 times from that point. I perform major plumbing once a year when I have time. This usually means spending time migrating from legacy systems to the new stuff in the UI. Or taking advantage of new features.

1 Like
10

As do I as a general rule, but my HA has been super iffy lately where I’m getting erroneous errors that I cannot track down (and have searched extensively on here, they are too generic to pinpoint to anything) and it’s now causing automations to execute halfway and then die. I generally prefer to just go do a major overhaul but at the very least if I strip it down to the bones I can see how it acts as I re-add components back to the mix.

It’s to the point I have to babysit and coddle HA every day and it’s getting super old. I don’t fault HA, it’s most likely either faulty functions/automations I’ve written or perhaps a goofy HACS plugin (of which I only have a dozen or so) but something is really knocking HA on its butt every day. Heck it could be one of my dongles is going south, but I need to strip down to see and safe mode only gives me so much.

Plus I implemented my package based very much on Frenck’s system example and it’s pretty slick but there things I would do differently now that I’ve used it for a couple of years (like not having integrations below entities in the folders, it gets confusing) and once I start messing with that too, then it’s a domino effect of my house of cards falling in on me :flushed:.

On the blueprint you provided above, is that more for actually synchronizing two systems or for migrating from source files? In my scenario only one system will be running and connecting to the dongles. I was more concerned with as I make changes to Z-Wave or Zigbee (i.e., new device or param change) that I reflect that into the new system so it stays the same.

11

This is timely. I have a month off this (Southern) summer and one aim is to move my supervised system on a nuc style PC to a hassos system on a new proxmox server (still awaiting a few parts).

My system has been around a while and is, frankly, cluttered with crap. It has some good stuff in it, but also a lot of cruft. Often while helping on this forum I install things just to check it out, and I am fascinated by new features, obscure add-ons and general hacking/playing.

I also have been a bit slack on refining my automations as new features come out. For example all my motion based lights have a separate on and off automation, instead of using trigger IDs.

TL;DR I am looking forward to rebuilding my messy setup.

1 Like
12

Yup!

No Doubt!

Constantly!

Same!

And this is why I’m doing this, lol!

13

Also, badly named entities, automations and very confused dashboards.

Sick of trying to work out how to control a garage door from a row of dashboards named test, test2, test A, another test etc etc. See you at the other end, and undoubtedly at various waypoints on the journey.

2 Likes
14

If you can, for the new portion - start from scratch. It is much easier to cut and paste (and then fix) YAML code. This way you can be confident you have a cokpletely clean installation and there are no leftover under the cover binary code that is invisible that may cause issues. ANd before you even do that - replace any older hardware, especially SSD’s etc. Just my two cents worth that you got for free! LOL

1 Like
15

I have not done a re-install from scratch from HA to HA, but when I switched to HA from Mozilla IoT (ugh, what an improvement!). I got a new RPi4 (and upgraded from Rpi3 with MIoT). Ran them both at the same time and gradually moved devices over one at a time. Doing the zigbee was a bit of a challenge. It was easier to just purchase a second zigbee adaptor for the new Rpi4 and reset the zigbee devices one by one (I only had about 15 back then). This is easier with HA 2 HA by far, as you can export and import the zigbee stick DB.