In praise of configuration files - having choices is good

I’ve been an openHAB user for about 4 years now, all sorts of domestic stuff plus monitoring of some servers.

After 4 years using the very cute little Raspberry PI, I have come to the conclusion that I now have a massive amount of “stuff” being controlled by a plastic box powered via a USB port. No offence, but’s a school science project in a lunch box. Scary when away from it…

So, I decided to move it to something more reliable… My choice was based on work machines I happen to have… Windows. Specifically a Windows 10 Enterprise N LTSC (2021) virtual PC built on a Windows Server 2022 Server (under HyperV). This places the system in a much more safe environment - firewalled to hell and running UPS’d Dual PSUs and RAID 6 disks, plus, because it’s a VM, it can be run up on another machine, checkpointed etc. I now longer live in fear of SD card failure (which I’ve experienced). For those now growling at the hardware list, the same could be achieved with a laptop (built in UPS!) running Win10.

The point to this post - A while back I ditched the GUI configurator and returned to files as this allowed me much greater control… plus a more confident backup.

Today, I spent a few hours building the new environment. Mosquitto was a poorly documented bitch to setup on Windows, but openHAB (3.2) went in with great ease… Out of interest, to see how much I’d ned to fix, I dragged across my config file directory… Well blow me, EVERYTHING worked…

So I just change platform with great ease…

Thank you config files for moving 96 “things” and 561 “items”, sitemaps, rules etc etc etc with ease… and I haven’t had to reprogram any of the devices as I placed the new widows machine and MQTT server at the same IP address as the science project was…

That has nailed me to openHAB for the foreseeable future…

Thank you Rik, thank you developers…


Glad you got your new system working. FYI, if you had used sudo openhab-cli backup, you’d get a zip file with both your databases and text config files, which could then be restored to your new server with similar ease. It works quite well.

I’m not taking issue with you preferring to configure things via text files, but don’t want other readers to get the impression that things/items/rules/etc. in the GUI are difficult to transfer between systems. That’s not the case.

It’s weird to me when people say, “no offence” and then follow it with an insult to someone/something. I always feel like it translates as “I could choose to not be insulting, but I feel like being insulting.” :wink:

Personally, I agree that the RPi is focused on education, and hobbyists who struggle with its limitations should understand that we aren’t the target audience. I’ve seen university engineering students build fantastic things thanks to the RPi, so I’m grateful for what it is. If you’re not comfortable with it, it makes good sense that you’d find another platform.

Whatever the case, I’ve been running OH for three years, and only had one early SD failure before I got a UPS (and with an already-old SD card). So, I don’t worry about it and just keep regular backups.

Glad you got it all working the way you want it!

1 Like

No offense :wink: but really… Windows???

I’m using GNU/Linux as a base for my virtualized systems since almost 15 years and never had any crash. Running both GNU/Linux and Windows Machines, just because there is some Software which doesn’t exist for GNU/Linux. My PBS is FreeBSD based and (guess what) also virtualized. I don’t need additional licenses for additional Windows machines.
Firewall, ZFS with redundancy and automatic snapshots, autoreplication to another small machine (with pull replication, so no way to infect the backup machine from my server. Not to mention, to login, you need a private key. And yes, there is also an UPS…

Most Webservers in the internet are running on GNU/Linux, because of the stability. Uptime of a year is not unusual, even if the system is patched frequently.

The Raspberry as an SBC is a small yet adequate solution in question of energy consumption, and although there are some issues with the hardware, there are also cheap solutions for these problems, may it be a SSD instead of a Micro-SD-Card, may it be a HAT UPS for about 40 €.

1 Like

I’d actually like to see more people run openHAB on Windows/Mac so that there would be more support available for new users. When I started, I had an RPi3 that I had bought to play around with, so it made sense to go in that direction. However, I didn’t know anything about Linux, and it was a steep learning curve that caused at least one false start. Even now, I’m in there so infrequently that I never remember how to do things without looking up basic Linux commands.

If I didn’t have an RPi3 already, I would have wanted to use my old Windows laptop. I suspect that would have not gone well, and I might have abandoned the idea before I even got started.

There are a lot of old Windows/Mac PCs out there that could be repurposed, enabling new users to start from a comfort zone. But since the vast majority of us are using Linux, we’re not in a position to help those Windows/Mac users (and understandably say so when replying to them). So if we had more active users helping out, I imagine that we’d reduce barriers to entry and potentially increase adoption. That would also make it easier for those new users to eventually switch to Linux in the future.

Of course, the challenge with supporting multiple OSes is that it would sometimes be hard to troubleshoot problems that may or may not be OS-related. But right now, we’re basically saying that if you don’t use Linux, you’re on your own.


Yep, and whilst I fully respect the Unix choice, I’m not a Unix guru… Originally I started with windows and OH2, but because of a lack of Windows love in the OH community, I gave up and went the RPi way. - I just don’t have the Unix expertise to run a mission critical box on Unix of any flavour - my webserver is on Ubuntu, as a VM on top of Windows… but that doesn’t control things which actually exist. the 3.2 install on Windows was actually very easy(ish) and it appears that through Java it’s a very similar code base… I’m impressed - There is no need for normal people to learn Unix… I also use a bunch of RPi’s as music players (PiCoreplayer), so the old hardware will find a non-critical home now…

If I was a Unix guru, I’d have gone that path… The Unix tech is fully capable… I’m not… (I’m really an AS/400 guy :slight_smile: ) I just don’t have the knowledge to create all the stuff required… I do on Windows, as many, many do and I’m please to see it working so much better on that platform.

Hi Russ.

I think I was originally put off by bad experiences with the GUI in OH2 - I had a couple of occasions where I had to flatten everything and rebuild. I also like the ability to cookie cutter the addition of e.g. another 10 switches quickly using cut and paste. I also like being able to look at the nuts and bolts when something doesn’t play… Of course, it might work better if I let the GUI build it :slight_smile:

I can totally see why many would prefer the GUI interface, and if it’s reliable in OH3.2 (I never tried it in 3.2) that’s great. I think a good GUI interface and a reliable easy platform is the way to long term take-up.

The RPi SD failure caused me pain as on two occasions the failure caused it to error and open my garage doors at 3am… complete with alarms etc… I was not popular…

I do love PI’s - I have a few… but I just can’t use them for something mission critical anymore… I’m surrounded by Windows hardware, and I lack Unix expertise

Yeah, OH2’s PaperUI was incomplete, and the general recommendation was to not use it for items. OH3’s MainUI is better in every way, but still has room for improvement.

I’m actually somewhere in between with my system. I moved over my OH2 config files when I set up OH3, and then moved most of my items into MainUI. I was already using GUI for most things except MQTT, and kept it that way.

I think that if new users come in and start with the GUI, they’ll mostly find it’s all they ever need. And since that’s their paradigm, it’s no big deal. It’s harder for those of us who have “grown up” with text files to make the shift. Once someone figures out a solution they like, they’ll reject other approaches that may actually be more convenient, purely out of comfort and familiarity. You see that a lot with people manually typing formulas into Excel instead of using the built-in functions (I’m sometimes guilty of that).

It would be really helpful if you wrote a tutorial to help people get started in Windows. I’d just suggest that you make it about Windows, and not about avoiding UNIX. That’ll just start an unnecessary culture war. :wink:

Indeed… I should write a few notes up… especially around the Mosquitto part - Their configuration is counter intuitive…

Any particular reasons you stayed away from openHABian?
It’s built right for people like you that aren’t and don’t want to become Un*x lovers.
Going with the mainstream might be a lame move but rewards you with saving a lot of time on installing (and documenting!) and also in the future when you’re in need of help: there’s hardly any Windows users around that will be able to help you as the mass of people and all experts run Linux.
openHABian will also install Mosquitto for you. Like any software, you can expect that to run better in its native environment.
Most important: openHABian provides a number of data safety features such as the capability to have the SD card mirrored. Peace of mind, shrink-wrapped.
As others noted openHAB config is OS independent so you can export on Windows and import on Linux or vice versa at any time.

1 Like

Amen! May the text configuration + rules remain supported forever! I can’t imagine dealing with GUI trying to create, maintain, or making changes and tweaks to 100+ Tasmota mqtt things + items. At the end of the day it’d probably involve writing a script to manipulate the JSON database, which is basically back to text configuration anyway.

With text configuration, it’s a matter of seconds if I want to change my Things / Items definition and propagate the changes to 100+ items.

1 Like

I used to think that. But the battery on a laptop that is left always plugged in will almost certainly die at some point soon (if it’s an older laptop) without you’re ever knowing there’s a problem until your first power outage. Happened to me twice before giving up on trying to use a laptop this way.

An alternative approach is to build your home automation so there is no missing critical box. If OH goes down, it might be slightly inconvenient but that doesn’t mean I have to drop everything and get it back working. If you have a single point of failure, no matter how robust you make it, it’s going to fail at some point and you’re going to have a bad day.

My advice is always to push the “smarts” to the edge where possible and maintain fall backs for when OH is offline. That way when OH is offline your home is still usable and controllable. Like the Mitch Hedberg joke, “You should never see an escalator out of service sign. Escalator temporarily stairs. Sorry for the convenience.” Build escalators, not elevators.

Not similar. The exact same code base.There is only one code base for OH used on all supported operating systems. There might be some minor differences in certain bindings in libraries used to interact with hardware (e.g. BT binding) but for core, it’s all the same code everywhere.

Do not judge MainUI based on your experiences with PaperUI. PaperUI was frankly never completed and only barely usable for most purposes. MainUI is a completely rewritten UI and it is quite usable. I’m not trying to have you change over, but just want to make sure you don’t paint them both with the same brush.


I was the same before, but dared the step towards MainUI - and I never regretted it. The most convenient thing for me is, to be able to change most of the config directly on my cell phone. Smaller things I only change there.

And the automatic discovery of things, which works flawlessly. PaperUI was a pain in the …. - but MainUI is really enlightening!

Just my 2 cents…

There is a HABApp function which will create your items based on your existing things. You can use wildcards and thing fields to populate items fields. So if you think about a script you can always look there first. It’s quite powerful. You basically create rules how your things should relate to items and HABApp will do the rest.

I for myself am a huge fan of textual configuration, too. It helps me tremendously in how I structure my installation and to quickly find defined items.

However I acknowledge that (especially for new users) textual configuration can be overwhelming and error prone so it’s good openHAB offers a choice and I really hope it stays that way.

just to add my 2 cents here: I also love being able to use textual configuration - BUT I left that path after I really, really let me use the OH3-UI and it saves me a ton of work. Because in text files you really have to be conscious in how you name them and if you just leave a stupid typo here and there again - sometimes something doesn’t work and only after hours you find the reason for that.
And for backups: you can either use regularly the “openhab-cli backup” or the builtin Amanda from openHABian. Importing the “backup” is as easy (or even less work as it is just a import of a zip!) as putting all items, rules, things, … into the respective folders.

Yes - I had that problem once, too. It drives you crazy and openhab really could emit better error messages when reading files and validate them better.

However even with all difficulties textual files still save me a ton work. I often need to apply changes to many items and with fully featured text editors I am so much faster. Also I am supervising multiple openhab instances and text files allow me to either share whole files across instances or quickly merge parts together.

As I said:
it’s good to heave a choice so we can both be happy!

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.