Being in IT for decades only has proven one thing: Resistance is futile, things are moving very fast.
So the ideal world where everything you built will run forever after you are gone is a fairy tale and it might be worth to let go of things you built over the years before nobody (even you) is able to handle it anymore.
In the end it might be a question of how you setup your stuff so it can easily be dismantled later.
Nevertheless I might be proven wrong by time, so I tend to document things whenever I implement them.
What I will leave behind for the family when it comes to technology (or the one buying the house as downsizing might become appropriate before crossing the bridge):
Everything we do is a process and every process might be important or not. To understand a system it is highly critical that you know the reasons why things have been done and how they relate to each other.
So this is where I start to give an introduction for the less technical reader giving an overview.
A prioritised list of processes that run automated or support you.
- Name
- Purpose
- Criticality (1 = “Must run” … 5 = “Can be dropped it without any impact”)
- Dependencies (Other process)
Then things will get more technical.
Graphical system landscape from a box / network perspective.
- annotating devices with location, model, technology (e.g. network protocol), an indicator how “critical” or “close” it is to the core functionality of the whole house.
- Annotating connections with technology used (knx, zigbee, zwave, modbus …)
A list of all the devices shown in the graphical overview with detailed information about how they are configured
- Network addresses, NodeIDs or or similar stuff and names to identify it
- Where it that piece located?
- Details on hardware, vendor and configuration (e.g. parameters set)
- Credentials / How to access
- Backups, e.g. a replacement SD card or USB stick when it comes to my Raspberries.
A list of external service dependencies (e.g. Cloud services)
- How to access (Keys, credentials, URLs)
- …
A dependency list, showing which process requires which resources (which devices, network, services…).
And do not forget to give access to your mail account and/or use a specific mail account that is only used for automation purposes . Can everybody remember all the accounts you created to get certain integrations running ? In case a password reset is required this is crucial.
Providing a password safe and the corresponding password manager might be a good idea as well.
Always good: Label your physical items. Ever looked into the central cabinet of your house and wondered what all this stuff is for and (the easy part) which fuse is for what? Now think about somebody having to figure out for things you put into ceilings or walls. Guess you get it. (One more point for knx,you can arrange the project similar to the building and / or topological structure and assign the devices so you can easily identify them.)
In the end I hope this will allow someone to decide where to look into and strip it down to the very basic functionality required.
As I’m running the house on a knx backbone shutting down OH or anything else might lead to minor inconveniences like
- Some (not all) tablet access no longer being available,
- zigBee lights (I have them for non critical stuff only)
- ZWave thermostats not working (Simply replace them by a standard one and things are fine)
- Monitoring data only I am interested in is gone
But the core functionality to live in the house is completely available in the ETS project ( and a PDF export, just in case). That is something every skilled electrician can work with and as such future proof.
What I see extremely critical is mixing multiple (maybe exotic) devices and technologies without a strong backbone. To keep this alive is already a challenge when being mentally at the top.
When it come to openHAB honestly I’m a bit scared about the documentation topic, especially when it comes to coding - there are so many places you are able and required to code things.
My tendency is that I will split up my OH installation into 2-3 instances, split criterium will be the criticality of the processes running on them. Idea is to document “instance 1” with the important core stuff well, “instance 2” (well nice, but we can live without it) a bit and leave out “Instance 3” ( The stuff only I did care about like metering or fancy party lights). Only “Instance 1” will required a closer look, everything else can simply be shut down.
This will make it easier to maintain and drop complexity. Time will tell if this will be feasible, but to me it sounds like a plan I want to evaluate.
Start early is key when it comes to build your digital heritage.
Not only the “final” situation should be considered - the problems arise earlier than you expect them.
Getting older makes your eyes weak, your fingers start to shiver and things you did without any hesitation begin to challenge your brain. Do we all still remember the reasons why and how we implemented all our stuff after it was running fine for x years? Guess not, at least I don’t.
So maybe a controlled strip down over the years might be an option to consider strongly. Makes live (and death) easier for everybody.