But this is a procedure which require repeating manual operations over and over again, unlike installing openhab (software/OS/whatever) which is a one time operation.
The procedure itself of making an image of the sd card is easy. But the repeating manual operation is, in my opinion, the reason why many users wont get it done, in time.
So, we know at least one good and easy way to do backup. Now turn the focus into handling the challenging with the “repeating manual operation” part of it, and making it an easy, simple and automatic operation.
I´m not saying it´s a easy challenge. But it should be the way to think, when you are developing something in a data and computer environment. Just as well as it should be a feature users are focusin on.
See me reply to pacive.
I do not agree with taking down the system is a draw back. The challenge is, the repeating manual operation.
But its depending on how big the system is and how long the backup procedure will take, ofcouse. A huge system with several TB of data will require fare to much down time to do such a backup. A small system, like Openhabian (OpenHab) should be possible to backup in just a few minutes.
Any other procedure is going to require you to set up a place to back up to since you must backup everything on the drive to catch everything. And that is the hard part of setting up Amanda. Once set up, Amanda takes a single command to run or can be set up to run automatically.
In short, automatic backups so not really get any simpler than Amanda because they all will require you to configure a place to back up to.
We’ll, Amanda is difficult for some but not impossible.
But I will argue that any backup system that:
works across operating systems
supports restore (in which case there is no point in backing up)
Openhab/openhabian itself require something.
It´s not the requirements itself which is the major hassle. If the Rpi had a second SD card reader, it would be obvious. Rpi doesn´t, then move on to next step. USB disk, NAS, network path etc…
When moving on to possible requirements, make sure the procedure to include these requirement is as easy and simple as installing the software (openhabian/openhab). Meaning, I should not have to study linux for decades to include these requirement, to be able to do a simple, easy and effective backup prodcedure. It breaks the idea of beeing hasslefree.
This leads to your next sentence.
Exactly…
So if we can agree setting up Amanda (or Amanda´s requirements) is the hardest part, then developing Amanda should focus on making that part easier. I´m not asking for procedure a monkey can deal with it. But some where in between.
This leads me back to my frst suggestions, PaperUi (or infact something simular Ui system like openhabian-config, or perhaps an amanda-config) for setting up and running Amanda and it´s requirements. In PaperUi there could be an option to make this an automatic crone job by rules or whatever, perhaps even setting up Amanda as well.
I know this sound simple. But I fail to understand why this would be close to impossible, no matter what enviroments we´re speaking of. Ofcouse the user has to get the necessary hardware requirements, (backup storage/cloud service/whatever). Connect it to the Rpi (or whatever hardware beeing used) and then configure Amanda. Anything else, it´s in controle of the developer to make possible.
Amanda (the backup procedure) will end op creating an image backup file, which the user can start over with using the same procedure as the first starting point, writing the image file to an SD card, insert the SD card into the Rpi. And the system is up running from the date the image bakup file was created.
(This is a shot story. I know there will be more questions to answer going through the setup. But I hope you get the point).
Now, where is the problem?
I know the above procedure will not deal with everyone of us. Some have even less knowlegde. But in a principal, it´s a matter of making this most hasslefree as possible, despite of the users knowledgement.
And OH would have to support backup to ANY of those options. And most work differently and have lots of options in how they can work. Just setting up and maintaining an automated system to work with all of these potential external devices is a project almost as big as OH itself.
So let’s assume we leave that up to the user to provide a path to a folder that represents some external drive or network shared drive. Now we are back in Amanda territory that apparently you “have to study linux for decades” to figure out how to mount a USB or network file system. We’ve solved exactly nothing.
I’m honestly not sure what could be done to make the setup of backup and restore on openHABian any easier. Assuming a USB drive for backup:
run openhabian-config
Choose 50 Backup and Restore
Choose install and configure
Answer the questions asked (password for backups, etc)
Say OK to back up to Locally attached or NAS storage
Provide the path to the external drive. Apparently the hard step
Answer the rest of the questions
If your main complaint is that it is hard to ssh in to the RPi to do the initial setup then perhaps you should be running on Windows or something more familiar. If the main complaint is step 6, well ALL backup systems will require this of you. If projects that are nearly as big as the OH project do not automate this for you what chance is there that OH would have the people with the skills and willingness to implement it?
From an OH perspective the problem is that Amanda only runs on certain Linux distros and Windows. That leaves out Mac and the NAS systems (QNAP, Synology) which means adding it to PaperUI would make at least that part of OH incompatible with those platforms. Based on the standards of contributing to the project as I understand them, that means it would be not allowed. A solution that works across them all would have to be provided.
So now the problem has become bigger and we can no longer rely on Amanda. In fact, I know of no backup system that supports all the platforms that OH is supported on so we have to figure out multiple backup and restore solutions. Then we have to somehow automate all the dozens of different ways that someone may choose to mount an external file system to backup to on each of those platforms.
Then we have the problem that some of the platforms like Windows don’t allow complete backup of the system without making very deep hooks into the OS to prevent certain things from being written to while the system is running. Now we have a huge amount of code to write that is specific to only one platform. Oh, and that code can’t be written in Java so we have to either have a subsystem that exists outside of OH for Windows backup or we need to rewrite all of OH in another programming language.
Because of this line of reasoning.
No changes will be allowed to the OH UIs that are platform specific
Your home automation system consists of more than OH
OH cannot know exactly what other services you are using in your home automation system
Therefore to backup your full home automation you must backup the full drive that OH is running off of, operating system and all (NOTE: this still won’t catch everything as many if not most OH users run other services on other hardware separate from the OH server).
Every platform works differently so almost every platform will require it’s own backup system. At a minimum Linux (Amanda), Mac, and Windows (Amanda won’t backup the full drive, just selected files).
Certain platforms like Windows will require code written in some other programming language, I’ve no idea what would work for something like QNAP or Synology though perhaps those won’t matter since they should be running on RAID anyway.
Once you get to 5 we are looking at at least three different subsystems , at least one of which will be as large as OH itself in terms of the amount of code required, to solve a problem for which there are already third party software, both FOSS and commercial, to solve.
Cool, that is mostly how Amanda on openHABian works. But what about OH on a Mac, Windows, etc? There is no SD card to copy. The drive is likely to be too large to fit on an SD card to back up. What about those who have a NAS and want to backup to that?
This solves the problem nice and easy for your specific configuration and deployment. Your’s is not the only way to configure and deploy OH.
Guys, just some quick input on this.
It’s obviously out of scope for openHAB(ian) and therefore not mentioned in the openHABian Amanda Readme, but you can run Amanda on MacOS and almost any UNIX (including Synology and QNAP NAS).
And there’s even a Windows client available, too, so as long as you have a UNIX backup host to run Amanda on you can even use this to backup your Windows openHAB or even Windows based gateway or desktop PC.
@rlkoshak : any Amanda setup can backup (and restore) both, directories as well as complete raw devices (such as SD cards or HDDs). It’s even the openHABian default to do both in parallel, and the Readme recommends to use this to create a SD clone as your first action after you ran your first backup.
@Kim_Andersen, I honestly don’t understand what you feel to be difficult about setting up openHABian Amanda. Rich quoted the steps. It’s as simple as it can get given the range of HW and functionality we want it to cover.
Yes you need to read a single somewhat lengthy doc but doing so does not seem to be a problem given the time you already kept spending on this thread alone. Yes it’s easier for UNIX people but there’s quite a number of Windows people who successfully made it and I’ve spent quite some effort to incorporate their findings into the Readme.
If you have questions or problems, put them up in this Amanda thread and I’ll try to give an answer.
If you feel the Readme is missing anything essential or it’s incomprehensive at any point, let me know where exactly and why.
As far as I can read from others, this IS the hardest step. And I guess for most, they would say this is where things mostly goes wrong.
Now - focus on that one… Try think of somekind of easier procedure for this specific matter. It seems to me you´re says 1 - 5 and step 7, is easy. Then it doesn´t matter step 6 is a hard one.
It doesn´t make any sence, as step 6 is probably the most important part.
Openhabian (Linux) PaperUi is used to add/remove things/items/devices. Then tell me, how is a USB device different from anything else, wether or not it´s a z-wave dongle, USB storage device etc??
I know Linux has to know the USB device ofcouse to be able to spot. This is the only requirement the user should be dealing with. And it´s the sam eon all platforms and all devices.
But if I plug an USB storage device into my Rpi, I do not have the option to configure this device, just as well as all others devices I configure in OpenHab…
Why not?
Whenever you have the USB storage device configured, you´re free to use it as you please, wether or not it´s for backup or anything else.
This is where configuration of Amanda or any other backup procedure comes in, and you now have made the hard step 6 easier. Agree? You could even have several kinds of backup procedures to choose form, within Openhab (PaperUi etc) just as well as you have bindings/connections to every other stuff.
My main compaint is not, wether I find it hard to use ssh.
It´s a principial matter, to me. why there is a need to do ssh at all, when you´re setting up a system, which is suppose to be hasslefree an have it´s own kinda configuration itself.
As said, I could live with beeing inside the openhabian-config panel, though I still don´t think it´s the best option. But´s it´s an acceptable alternative, for me.
Either there is a language barrier or you simply misunderstand.
Amanda is included as an option within the hasslefree setup op Openhab from inside openhabia-config, right? It leaves out every other platforms for this matter. It doesnt matter if Amanda don´t not run on any other platform. It´s there, in Openhab. Why bother about the other platforms then?
Amanda for other platforms either have to support it (somehow) or leave it. I can´t see how setting up the requirements has anything to do with this. Mac´s, Windows etc. can use USB storage devices or even mapping to a network device. So where is the catch?
Lets twist this from another point of view.
I assume you know Windows.
Imaging setting up connection to an external storage device would require you to go through a Dos promt (command promt), even though you have the Windows Explorer? My bet is, if this happens today lots of people would think this is a wrong way to do things, and even more people would not be able to deal with it.
My mother which is 72 yeas old is able to connect an external USB storage device to hers windows box and make use of it wether or not it´s for backup or anything else.
Remeber, you said it yourself - step 6 “Provide the path to the external drive.” is the hard step.
Keep focusing on this one. And tell me, where is the catch doing the same with Openhab (openhabian) ?
Difficult or Unnecessary, from a user perspective?
Remember, you as the knowledged, will always believe its easy. You may even find it easy to read the docs, due to your experiences and understanding of the system itself. Not all have the same knowledge and experiences as you (or me).
I dont mind reading stuff. I have been in this “game” for decades now. But my situation is not really the best way to target on this matter due to my experience. I started off in 1986 with Dos, moved to OS´s with graphical interfaces (Atari Tos) and Windows.
Now I find myself beeing send back in time, over and over again ssh´íng to the OS to do stuff from a command line, I have been doing alot easier in the last couple of decades. And I simply fail to understand why it has to be this way, specially if we can agree upon:
Providing the required path and making it avaible to Amanda is the hardest part.
I have a feeling this is due to, “thats the way it has always been in Linux/Unix”. And like you said yourself in a quote from the Amanda thread. “You can´t teach everyone”. And, “this require some Linux knowledge”.
I understand you see this as two different task´s.
First - connecting and setting up path of where to store the backup.
Second - the backup procedure itself, (Amanda)
The first task is the one which you believe is not part of Amanda. And you wont teach people about this.
I accept your opinion, and I partly agree, In an ideal world, it should not be part of Amanda.
But in real life it is, cause nowehere else in the hasslefree setup of Openhab (openhabian) is this part available, (as far as I know). But it´s a need requirement for Amanda to be working. Agree?
So infact my opinion is not really just about Amanda itself. It´s about the structure of the whole enviroment.
If the system itself provided an easy procedure to connect an external device, setting up the required path. Most people would probably work through the rest of Amanda setup without much hassle. (ie blindfolded).
I´ll rest my case on this matter. I have provided my opninion about this. Hopefully some day someone will understand this from my perspective. Untill then, ssh´ing and using commandlines is what it takes = Not hasslefree unless you have linux experience.
Like I said above, if mounting a file system on a Linux system is too hard, then run on a platform you are more familiar with like Windows.
openHABian does a lot to make installing and configuring OH on a Linux system easier but it does not eliminate the need for you the user to possess or be willing to learn the basics of navigating and working on Linux. That is why we also support running on Windows and Mac and more.
Perhaps someday someone will sell a turnkey black box OH or ESH based hub, but I agree with Markus, that is outside the boundary of what the OH project can or should be responsible for.
Because a USB zwave dongle appears as a serial device so OH can talk directly to it (once you give the openhab user permission to do so). The file /dev/ttyUSB0 means that you are performing raw reads and writes directly to that device. So it is a pretty simple matter to supply the path to the device to the binding and the binding can just start reading and writing.
Drives are different. Not only do you have the device location you also have the file system. A program like OH doesn’t communicate directly to the drive, they have to go through a part of the operating system called the file system. NOTE: there are over a dozen different types of file systems. In order for that to happen one must tell the operating system what type of file system it is and where you want to mount that files system.
These are all operating system operations pretty much always outside the boundaries of what a typical program like OH would implement. Also, these are operations that require root to perform and from a security perspective you never want to run something like OH as root.
And this just focuses on one potential way to back up: USB thumb drives. What about those who have a NAS and want to back up to that?
But most of the time on a Linux platform all you have to do is plug in the USB drive and it will automatically be mounted and will appear under /media.
So your step 6 would be:
plug in the USB drive
configure Amanda to use /media/nameofthumbdrive for the backup, or if you are on Windows use d:\ (only you don’t know ahead of time what drive letter the thumb drive will be assigned).
Because that isn’t OH’s job. It is the operating system’s job.
I think the major point that I’m trying to get across and failing is that yes, OH could potentially implement something like this assuming the problem space were drastically reduced (i.e. “we only support backup to USB drives” which would be unacceptable) but:
that isn’t OH’s job
the procedure would either have to be so limitied as to only be useful to a tiny fraction of OH users or would have to be as complex as doing it through the operating system in the first place
openHABian IS NOT openHAB. PaperUI is not openHABian.
openHABian is a set of scripts that automate the installation and configuration of openHAB and related services on a apt based Linux Distro.
If you want to make the Amanda configuration in openHABian easier I’m all for it. You have just about everything you need right there already:
constrained to one type of Linux distro so you can eliminate whole swaths of possible configurations
runs as root so you don’t have to worry about permission problems doing things that require root to perform
But again, openHABian IS NOT openHAB. It is a support mechanism to openHAB. You don’t have the ability to install and configure Mosquitto from PaperUI. You don’t have the ability to install and configure InfluxDB, MariaDB, MySQL, etc through PaperUI. You don’t have the ability to install and configure SAMBA through PaperUI. And those features should not be there because they are not openHAB’s job.
Now if you want to argue that openHABian should implement some sort of web-based user interface that is something else entirely. I could see openHABian growing in that direction at some point. That would eliminate the need to ssh into the RPi some.
But right now, openHABian is not intended to replace the user’s need to ever access their RPi except through a web interface. It is a convenience that helps perform a common set of setup and configuration tasks for you.
What you are asking for is a turn-key system that never requires the user to get dirty on the command line. That is NEVER going to be implemented by OH itself. Something like openHABian can maybe grow into that because it has a much smaller set of parameters it needs to deal with. And that would be kind of cool. But that is beyond what I think was ever envisioned for openHABian.
No. We haven’t made anything harder. Step 6 is as easy or as hard as it ever was with or without OH.
No one ever claimed that openHABian was hassle free. No one claimed it was a turn-key system. No one ever claimed that you do not and never need to have some basic Linux skills to use openHABian to setup, configure, and maintain a system to run openHAB. You don’t have to be a “Linux enthusiast” but that doesn’t mean you can remain completely ignorant of all things Linux. You still have to know some basics.
Because you want to make this openHAB’s job through PaperUI.
openHAB != openHABian
Because you want to have this set up so the user can set up this USB storage or network mapping without any knowledge of how these operating systems work and how to do it. Mapping a network drive for you is simple enough because you know how to do it. But you want openHAB to do that for you.
Or, if you want parity then you need to expect the same of Linux users as you expect from Windows users: i.e. figure out how to map a network drive through the OS. Then tell the backup software where to save the backups.
I’m equally comfortable on most OSs including Windows, Mac, most Linux, BSDs, AIX, and Solaris.
Then don’t run on Linux. You have other choices. But at the end of the day:
dealing with mounting file systems is the job of the operating system not a program like openHAB
this could be something that openHABian could help more with, that that is outside of openHAB. openHAB != openHABian
openHAB, even with openHABian, is a LOOOOOONG way away from being something your 72 year-old mother would be able to handle, unless they were technically and computer inclined. We’d like to get there someday, but I’m skeptical it can ever happen without neutering or excluding whole swaths of supported technologies.
I would argue that OH is not yet ready for use by someone who is unable or unwilling to read the docs and examples to configure and make a system out of OH. A much more limited system like SmartThings, Wink, or Vera would be a more appropriate platform for such a user.
The reason I say this is because:
the number of technologies OH supports is overwhelming
there is a whole lot of variability in the comprehensiveness and quality of each of the 300+ APIs and technologies that are supported
major portions of OH config still require text-based configuration
OH will ALWAYS require at least a little bit of ability to think like a coder (if this then do that type thinking)
Lots of work is being done to make all of this better but we still have a very long way to go. And I’m personally not convinced that rules will ever be simple enough.
But the key points are:
openHABian is not openHAB. This is NOT an openHAB job.
it is something that openHABian can do better but it will require someone to build and contribute a web-based front end to openHABian
if using ssh and other standard ways to interact with openHAB, there are plenty of other platforms upon which openHAB will run. Your main complaint seems to be you don’t like how Linux does things (at least the stripped down version of Linux openHABian sets up and configures. If you use a desktop version of Linux then it is as easy to deal with USB drives and network mounts as it is in Windows). It is not openHAB’s job to fix Linux. It could be the job of openHABian, though I think that is beyond the vision of what openHABian was intended.
Nah that’s plain wrong. Amanda is not part of openHAB. Never has been, never will be.
Amanda is part of openHABian, as are other tools and software useful for running a smarthome service such as mosquitto, SSH, postgres, FIND and (Raspbian) Linux.
But all of them are complementary to openHAB and not part of it. And they’re dependent on each other, so you cannot run any of them on every HW and SW that openHAB alone might be running on (such as e.g. Windows on x86).
You’re showing some fundamental misunderstanding of what’s openHAB vs. openHABian vs. Operating System vs. ‘environment’ a.k.a. ‘eco system’. Rich answered on that already.
My point is, in order to provide a very flexible, highly complex system and to support a large variety of HW and still provide this as a system-in-a-box, you have to make compromises if you still want to keep offering all the possibilities, and I expect a user to understand and accept that.
Sigh… yes filesystems and backups are complex topics and UNIX usage is a wellknown hurdle to Windozers, but I haven’t seen anyone be that unwilling so far. They all made it there, sooner or later.
And there’s certainly enough ressources available on the net explaining this in more or less great detail.
Btw, ever heard of Google?
You find it too difficult to mount a directory ? It’s difficult to the power of three to develop a system that on the one hand side still offers all the flexibility OH is appreciated for and on the other sides is working reliably in all of those gazillion enviroments and combinations people bring and want to use AND is still (almost) one-click to deploy.
Yes, we cannot start explaining at ground zero and teach everyone the basics - so you have to bring some fundamental computer knowledge and willingness to learn at least the basics on your own such as first steps on UNIX, how to use SSH, to name a few.
If you are unwilling or unable to acquire this knowledge - ok. But then at least stick with what’s accessible to you without that knowledge and don’t demand others to fill the gap. I’m really close to getting a bit angry when I have to keep reading I would need to yet put more work into development/docs just because you are unwilling to invest some time to familiarize yourself with some UNIX basics in this case.
Not to mention that we all do this for free, in our spare time …
Rich… You´re twisting my point and avoiding the fact, that this is a complicated task, wether or not it has be done through the OS or an application. It hasn´t anything to do with openhabian, openhab or Amanda. It´s the task, the linux structure itself, which make it complicated, specially for people not beeing Linux enthusiast.
When you´r answer is to change platform, I see no reason to continue arguing. The answer itself makes no changes. It may solve MY problem on this specific matter. But it will not change the complicated task on Linux to become less complicated, which is what I was trying to argue about.
Making complicated task become less complicated should be something everybody wants.
I believe I was wrong in this matter.
Markus, I´m sorry you get angry from this, it wasn´t my intention.
I´m not unwilling. I´m struggling. And while I´m struggling, I see others are as well. It tells me, this IS a complicated task to manage, where most non-linux enthusiast will be failing, or even avoid trying.
I was mainly suggesting this specific task get some more focus, to make it become less complicated.
I understand, this is not going to happen. Therefore, no need to continue this arguing.
I’ve said it twice and I’ll say it again. THEN DON"T USE LINUX. No one is forcing you to use Linux of openHABian. If learning a few of the basics of Linus is too hard or cumbersome then don’t run on Linux. OH runs quite well on Windows and Mac if you are more comfortable there.
But it is unreasonable to expect to run any program as complex as OH on ANY OS and eliminate the need for the user to have any knowledge of that OS. If you want that then buy a commercial hub which is more limited given you fewer options but trades that for a simpler user experiance.
It is not openHAB’s job nor is it openHABian’s job to “fix” Linux. It is outside the scope of what openHAB has power over. openHABian can reduce the amount of Linux you have to know to get started, but it is never going to eliminate the need to know at least something about the OS.
And so we set the boundaries pretty much in the same place that EVERY OTHER PROJECT out there does for backups. You provide the path and it is up to you to make sure that path is to a mounted file system from a USB drive or a network share.
This is certainly a pet peeve of mine. It DOES solve your problem. Your problem is Linux is too difficult to learn and perform some of the basic steps necessary to preform offline backups. Fine, that is a legetimate problem. But switching to an OS that you are more familiar with IS a solution to your problem. It lets you run OH on a platform where you already have the knowledge and skills to do everything you need.
You are unwilling to accept that the (intentional) flexibility in HW and SW is already a big challenge to developers and that to automate deployments is even a lot harder. But to automate AND still keep/cover everything we want to maintain is impossible.
You are unwilling to accept that backup in general and specifically the “hard” step to mount a directory is neither a openHAB nor openHABian job. Not caused by OH, cannot be compensated for by OH (except maybe in very specific setups, but even you agreed that’s not what we want).
You are unwilling to bring yourself up to the basic knowledge that is required for the level of usage you want.
If a couple of people out of thousands to run openHABian (and even more to run openHAB without it, latest count I heard about was around 20k) are struggling this means there’s thousands that DO have managed it, and it’s certainly not because they’re all “Linux enthusiasts”.
So it’s a problem that only applies to a minority of people and by no means is too complicated to solve and clearly a manageable task. And - unlike all those things that can only be done inside OH - there’s many ressources available outside of openHAB to help you solve this.
Still, you are unwilling to invest your time to google to find out yourself just as does everyone else while at the same time you keep telling me you expect me to invest more of mine.
Pretty much everything is there (openHABian, Amanda) because there has been a focus on already. The only remaining task (of providing a storage dir) cannot “become less complicated” because it is just as complex as it is.
No, this was no “suggestion”. You were asking us to do your job - work that to invest everyone else accepted to be his own duty. Us, right those people to spend their spare time to make people like you a little happier. And you didn’t even offer anything in return.
And you continued telling us even after we told you we don’t want to do it because it cannot be done.
Yes now you got me angry.
I wonder if we could make a good backup by developing a Binding that does it?
Just brainstorming here…maybe it’s unnecessary; what would running inside the OpenHAB instance matter? It would take advantage of the rules and events bus:
It would monitor event bus to determine when config changes for other bindings and therefor what config needs to be backed up.
It would know from the OpenHAB config what modules are installed and pull config from them, as well as during Restore know what modules to re-install.
Backup would not have to include binaries or jars as long as it has enough bundle/module config to restore them from a binary repo…perhaps using SHAs to determine whats already backed up.
It would trigger events and rules when backups occured which might be useful.
It could encrypt and backup to cloud or dropbox, etc.
config entries could list extra file patterns to include in backups
Sigh. Seems you didn’t read the previous posts.
There’s no point in having openHAB do the backup for various reasons, one of them being that for your smarthome to work you need to backup way more than just openHAB config.
For openHAB config-only backup/restore, there’s the openhab-cli builtin script. Trigger it whenever you’ve done a substantial amount of config changes.
For anything else there’s Amanda. It runs once a day per default.
Oh, and please open a new thread if you want to continue discussing backup.
I did. Including the part of you getting angry. I wasn’t implying you or core developers of OpenHAB need or should do it. I am very capable of writing code (already started binding dev) and I wasn’t trying to put this on your shoulders, just looking for feedback. This is obviously a heated topic so there is desire on at least one side to have something simpler to setup than Amanda. I’ve done kernel driver development and been on Linux for >20yrs so I dont even need any of this…but I do think newbies do and I like a lower barrier to entry.
This is the “Inter-mess of Things”. I’m very disappointed in all these companies’ “must use our or our partners ecosystem/protocol/hub/etc” hubris and nothing really works together which was the main premise of IoT/HA I though…perhaps I’m misguided. OpenHAB has finally bridged the gaps in my HA and I’m happy. I would like to see it more widely available to a bigger audience…so you’re a sustaining member, what is your opinion? same or would you like to keep it l33t? (and FYI I am being genuine, I won’t judge anyone for wanting to keep things l33t.)
)
