Again, do it once and.make a snapshot
That doesn’t really give you a clean development environment though.
It does if you snapshot a clean Dev environment
What about a programmatical way to remove entities? Would that help?
1 Like
If you remove a device, then what config of that integration are you wanting to keep? Your comment doesn’t quite make sense to me.
Any automations which relate to that device will still exist, they just won’t work until you add your new device to HA and give it the same entity_id, then it will work as before. Trust me, I’ve done it.
I don’t understand this. I have never had one fail. They do take some time to create though so I schedule it for midnight… if you make one and copy it off too soon it won’t be complete… is that maybe it?
I have, because I forgot the password 
Every other time they’ve worked as intended.
There isn’t always much feedback as to what is.happening in the background, (containers downloading etc.) So you need to just be patient and wait
That’s a conundrum. The integration configuration has the devices and entities. It seems you just want a way to clean the config_entries. That should be simple enough, just realize that devices may appear again if it’s discovered, which is most likely the case. Also realize that this will wipe out entities and the entity_id’s associated with the integration, meaning you’ll have to rename them again. Lastly, this would be slightly faster than deleting the integration and re-adding it. It’ll usually just save the time from checking a few boxes and adding a port/host name.
restart does this every time. Nothing really needs to be added here…
This is already built into the interface. You can disable an entity or device. You can also delete it if it wasn’t detected on the last HA restart.
And comments like this always lead to angry threads without any chance of progression. How about we stick to the topic: How can the this integration process be altered to fit @troykelly’s use cases?
2 Likes
What is everybody else doing for staging/test environments?
I clearly need to change what I am doing - but not sure what I am meant to be doing.
dev I start clean, but there are problems that I have come across with a “loaded” server that causes an integration to fail.
That’s where I used the legacy behaviour to be able to quickly stand up a staging / more realistic environment.
Thank you petro - is there a bulk option?
Not currently. The closest you have is to remove the integration and add it back in. The integrations you mentioned have minimal setup and auto discover. Should only take about a minute to set back up unless you have to rename entity_ids
I’m just unlucky I guess.
I’ve tried quite a few times to restore a snapshot, and it’s never been successful.
For the “production” boxes - I now take a vm snapshot, and also tar the /config folder and keep it.
Typically the database is corrupted in snapshots. Restore delete database and you’re good to go. If you separate the DB then you won’t ever run into that problem. That’s how I run and I’ve never had issues.
4 Likes
DB is kept seperate (mariadb).
Is this what you do for staging/testing as well?
Yep, Maria db on a separate device
Would making a git repository of your ./config folder be helpful?
That’s what I do. Whenever it’s at a stable place, I do a commit.
If I ever want to know what changed later, well, it’s git, so that’s easy.
1 Like
It would be good if there was an API into the configuration machinery that could be used to enumerate the current configuration and also be used to add/delete persistent state that lives in the .config/ directory. Right now, that directory contains various files which contain both persistent configuration state and, apparently, some ephemeral state isn’t necessarily part of the specification for the configuration of Home Assistant.
Ideally the GUI interface would also use the same API to ensure it’s complete and can be used to manipulate the private manifestation of the configuration.
In this way, one could extract the state, with some confidence that all the required information was present and then externally checkpoint, save and modify it; and then have tools to push it into Home Assistant. I was hoping that hass-cli could be used for this purpose, but I don’t believe that it can be.
This pattern is often used in, e.g, network elements like routers and switches built by vendors like Juniper, Cisco, Arista and others. Some of their customers own only a handful of boxes and hand-configure each one with some interactive interface. Others own an entire fleet with dozens or hundreds that are managed, and the idea of manually doing anything to them all is just incomprehensible. Too much opportunity for human error. And it flies in the face of how they manage the authoritative expression of their infrastructure configuration – it’s not in the network elements, it’s in a configuration database, and state gets pushed out to ensure consistent deployments. See “infrastructure as code” in the funny papers.
If someone (a VAR? Nabu Casa?) were to imagine operating hundreds or thousands of Home Assistant instances, you’d absolutely need something like this, so you can avoid scaling your headcount at the same rate as your customer base. I wrote a longer comment about this in the Future of YAML thread if anyone wants to relive that.
3 Likes
We deploy HA in commercial environments with 100s of devices and i can tell you removing the yaml config option is a serious kick in the nuts. There are fancy integrations with discovery but they are way less reliable than predefined yaml. (Like sometimes a device is down at discovery then it wont be added etc). We are currently evaluating how to tackle this challenge, the options are:
- Fork from (massive additional costs in maintenance, missing out on new features)
- Get dirty and create a custom component for given devices (mediocre effort)
- Just drop HA and switch to Domoticz, Open Hab or else.
I am honestly not happy about leaving the yaml, i see the goals but it kills the commercial growth potential and limits the platform a lot to personal usage.
5 Likes
@balloob @frenck @Bram_Kragten if there is a feature/epic in the roadmap to introduce programmatic configuration via an API that the GUI is also using I am willing to also contribute to that and add man power for the implementation.
Thanks in advance your kind reply.
1 Like
How would you see that working - most of the configurations are multiscreen/procedural. Or are you thinking of some sort of data file that could be imported to ingest configurations on a new deployment?