Has anyone been able to confirm/determine what file format the archive is for the backup - the extension is .LZF which isn't anything I can figure out... looks to be compressed but not sure in what.
G
Maybe this?
Reading about the ning/compress library mentions the H2 database, and the Hubitat LZF archive has a H2 file marker in the first few bytes, so I'm now thinking it is an H2 database backup output, so running the H2 library restore over the file would probably expose the database that was taken as copy. Interesting!
Anyway, chime in if you know more... just interested in seeing what's inside and if that's something that could be useful for making offline/bulk updates to things in a safe (yet probably unsupported) way.... 
1 Like
Definitely unsupported 
. Personally I wouldn’t alter my hub backups at all; I don’t see any upside and plenty of downsides.
2 Likes
I don't feel comfortable with having all my eggs in the Hubitat basket with zero ability to export configuration and/or settings - the closed minded nature of the platform isn't ideal for users and having some exposure to what is going on helps manage the impact of commercial changes to Hubitat's future. We've already seen ST take a different direction and everyone either had to jump or accept it... who's to say that Hubitat won't also be impacted by some future change that isn't compatible with what its users would prefer??
So at this point, just trying to open up the backup file to see what's stored and what can be recovered independently of the closed approach to "backup and restore"
3 Likes
I seem to be stumped as I don't have the filePassword or UserPassword of the encrypted H2 database... I'm guessing nobody from Hubitat will help either... not cool... not cool
2 Likes
I don't intend this to be offensive; if you're that concerned about Hubitat's future or survival, perhaps you should have migrated to a platform that is fully open (OpenHAB, Home Assistant, zigbee2mqtt, zwave2mqtt etc). Which would also save you the angst of butting heads with a password-protected database.
8 Likes
That's not offensive and is a good point. Finding the balance between 100% open vs 100% closed is always a struggle. Each have their benefits. Obviously with Hubitat fitting somewhere between the two (ie the developer focus around community drivers, apps etc isn't 100% closed).
It would just be nice to have some access to the system configuration beyond static APIs that limit / control the nature and way you can input and update running configuration. If it can't be done then I'll move on, but so far, I've been able to see that it is dumping a H2 database that is encrypted... with the right passwords it would then be more extensible and potentially useful for the community to have other ways to import/export configuration
2 Likes
Definitely sounds like a fully open source HA project would meet your expectations better.
1 Like
This won't be disclosed, and would be a terribly bad idea from the perspective of user security. You're pretty much stuck with the way we've decided to engineer this product if you choose to use it. It works very well for the vast majority of our customers. If you need something more open, there are options out there. We don't have any plan to meet your needs in this regard.
But, seriously, you're kidding yourself if you think the database is something you need access to. Ah, it's got your device names, and settings, and your app settings and state. All of that information is readily available to you. After all, you set all of it up.
5 Likes
True. Only actually keen to have a better way to configure the device beyond just the UI - ie a bulk import/export would be useful rather than just having a fixed UI that isn't easy to make multiple changes etc.
1 Like
Posting replies that encourage users to migrate to another competing platform is a fair bit less constructive than me complaining about the limitations of the closed elements of this platform. Surely you can see that having parts of the platform open (ie Drivers/Apps) actually gain a benefit from open source projects - ie standing on the shoulders of ST giants maybe?
4 Likes
Probably worth disclosing if the passwords used are secured with individual passwords (that I've set as part of the device setup) or if they are Hubitat Corp private passwords that means any/all backup files are readable by Hubitat Corp and staff ??
1 Like
User databases are readable by Hubitat engineers, and that is done from time to time to assist users, including for support purposes, or to diagnose customers' problems. And you can send your lzf backup file to another customer, and they could load it on a hub. Of course, they'd need your password to gain access to it. I've had times that users had some app crash that was quite problematic for them, and had them send me their lzf file so I could find and hopefully fix their problem.
So yeah, we can do that if need be.
3 Likes
…then a far more constructive question would be a feature request. You are probably one of about five users who would want to make mass edits/loads more than once.
Do you prefer to make bulk changes to your desktop OS via editing the backup instead of using the UI? That is tantamount to the same use case.
Create a script that manipulates the UI provided by HE. You can definitely do bulk loads that way. It’s even in vogue today. It’s called Robotic Process Automation. 
HA is pretty much a hobby. Many of the people here tweak their hubs daily, changing things, adding things, improving things, just dinking with things. Some people's taste in challenges run to more obscure items. Such as, a user a few days ago who wanted to use the backup from a rule app JSON file in an editor to make bulk changes. It's just another form of tinkering. I'm constantly creating rules to show people how to do something -- that's my tinkering. So @gslender seems to want to tinker with the db, and no doubt if he could, he would. I'm not against tinkering at all. But, we have a very large number of customers to support and all of them opening their databases and tinkering would blow up in their faces, and ours. So there are some conscious decisions made as to what is open for tinkering and what is not. Plus, at this point, we are way too busy doing things that benefit masses of customers to spend any time re-engineering designs committed years ago for those five users.
I find all of this amusing. I have a large system, with over 200 devices and around 100 automations. Mass edits? Please, give me a break. That's just lacking in seriousness.
5 Likes
I guess the same could be said for many of the Apps and Drivers written by the community, that on the surface seemed lacking purpose and was it seriously needed.
End of the day it’s your product and platform.
How you support and encourage adoption is up to you… this wouldn’t be my way, and nor has this attitude and approach worked successfully elsewhere, but who knows… it might work here 
2 Likes
I’m not against tinkering. I do my fair share. It just seems really peculiar when people go looking for something in between a completely proprietary system and a complete open source system then complain because it isn’t one of the extremes.
I really appreciate what you and the rest of the HE team have built. It is a great system. It is amazingly extensible.
Keep up the great work @bravenel and company!!!
2 Likes
That’s not secure in my book. My data is readable by a third party who won’t and doesn’t disclose any details of how they maintain security in their organisation. Are you audited by an independent 3rd security consultant?
2 Likes
Well, you bought the hub, didn't you? Not sure what you mean by "this attitude and approach". Closed vs open source system? Hmm, I can think of several very successful companies with that approach. Being frank with you about my opinion and our reasons for things? Yeah, most companies just put out bs pr drivel. Not catering to your personal sets of priorities? Hmmm.... How many hubs are you looking to deploy?
6 Likes
