Thanks for the replies. … and apologies for the rant below…
tldr; I don’t like complex, generic, adaptable, jack of all trade, highly extensible systems. I don’t like big companies controlling me and spying on me.
It’s interesting, but I keep coming into design ethos conflicts with systems like OpenHAB (and many others) these days. It’s not really a matter of me saying I do not agree with OpenHAB (or others) approaches, but it is a matter of “design for purpose”.
I am in a unique position. I can design and develop what I need. So I can’t fairly attack these kind of systems which are used by people who can’t. But, in the context of what I want to achieve I feel like I will attack them. Attack in terms of frowning and grimacing at the complexity and bloat they suffer from. I will say this having not, yet, browsed the OpenHAB code, so it’s possibly unfair to point that finger at OpenHab.
If you want to create a system that works for every kind of device and works for every persons requirements and home, a system that is easy to use, idiot proof, pretty, well documented, support umpteen languages and locales, then yes it will be complex, yes it will bloat, yes it will be large, expensive and slow.
I don’t need any of that. The comment about Z-Wave being a complex mesh network that works with hundreds of different devices is an example. I don’t want nor need a mesh network. I don’t need nor want to work with hundreds of different devices. Why would I need a protocol that can work with a WhizzyDuffer2.0 when I don’t have, nor will ever have a WhizzyDuffer2.0? Why would I want to burden my system protocols with the intricacies and complexities of controlling a WhizzyDuffer2.0 when I don’t need to?
When you remove all these superfluous requirements you would be absolutely amazed at how simple these things actually become.
Extending this out to my day job (Senior Java Engineer in Big Data for Capital Markets and investment banking), I am currently tasked with removing and replacing a complicated system that someone decided to create as an all bells and whistles, can do everything and anything related to ETL (Extract Transform Load) of data, which turned into a massively over-engineered, highly abstract, generic, completely infuriating to work with monster that nobody wanted to develop in. It was slow, resource intensive and basically failed to deliver performance on non-commodity blade hardware with 100s of cores and 100s of GB of RAM. It’s being binned. The system being put in place is designed to handle the requirements bestowed upon it and ONLY the requirements bestowed upon it. Anyone in a design meeting who says, “But what if we have a different type of a thing later”, gets told to justify that in context of the CURRENT requirements or is silenced. Anyone who creates an abstract class gets asked to remove it unless they can absolutely justify it for the requirements as they stand NOW, not some fantasy prediction of future reality. In software, predicting requirements and creating highly extensible applications does NOT work anymore. Software life cycles in enterprise and much shorter today with systems being replaced in 5-10 years, not 20-30 years. Requirements change far too fast, you will never predict them all and when that one requirement you didn’t predict turns your framework upside down you have a much larger mess to fix, usually resulting in more layers or complexity and more angry developers, over budget, over time, unsatisfied clients.
In context of home automation each and every company is seemingly trying to create their own bespoke system. They are typically be-all-to-all systems, jack of all trades, master of none, which is understandable though infuriating. However they suffer badly from corporate spite and greed, boxing in, refusing to be compatible with their competitors. Standard procedure in the domestic computing market and not just the domestic. I have hopes that as “smart” home stuff becomes more and more popular that interopable frameworks and protocols will gain more and more traction, things like MQTT are a start. Things like IFTTT are NOT. However with Google, Amazon and Apple hitting it hard it is also likely that traction for open protocols will wane and those big three will become the defacto standards.
I realise there are developer APIs for those big three and that would open up the eco-system of either accessing those devices via Google/Amazon offering or making my devices support their protocols, but Google/Amazon come with the privacy policy issues. I use facebook, I use GMail, I use Amazon prime, but I am not oblivious to what I am providing them with and it’s risks to my privacy. Using Alexa or home assistant however is one step too close into my home life and many bits of data about me too far for me to have these in my home. That could change in the future, but for now, it’s a no. I urge the users of said devices to read the small print and really think about the data they provide, not just in how it is used today and by whom, but how that data could be used by someone you DONT want to have that data and for what? We already have the police, local councils, employers, insurance companies all demanding access to peoples Facebook and Amazon Alexa and Google devices and not just current access, but historical access. Something you did or said in your own home 2 years ago could come back to bite you later because “Google Knows”.
There is light glimpsing through the tunnel with MQTT. But MQTT does not define the payload and it’s highly likely when devices supporting MQTT for use with Google/Amazon start to be more common the payload will be locked down to ensure it can ONLY be used via Google/Amazon and enforce remote cloud based MQTT brokers, just like IFTTT forces cloud services.
It’s not just the privacy issue, it’s the control and ownership issue. These third-party protocols are subject to change, end-user-license agreements and each and EVERY one of them pretty much says, “The license issuer reserves the right to change, remove, disable or block any and all uses of the service, including disabling devices.” You DO NOT own any of the system, you are just licensed to use it at Amazon/Google’s whim. What this means is that in 5 years time the feature of Amazon Alexa you were using to run half your home can be simply switched off. In fact, Amazon/Google reserve the right to permanently brick your devices without asking permission first. This has happened already many times, devices and services switched off or deleted remotely without your consent, because you consent is not required. Nor does it matter how much you paid for the device or use of the services you have to read the small print!
I’m probably preaching to the choir here on this, but I think where I could come in conflict with OpenHAB will be it’s complexity in it’s attempt to support all devices in all homes for all people. I only want to support my devices in my home for me. You can call that selfish, but I will happily provide people with code and help to do the same. It’s more about ownership and control of my home and it’s technology, because I am in a position to do so.
Obviously I have conflicting issues here. I want full control, but devices out there that I might want to use do not want me to have control over them without using their services. OpenHab has the ability in some cases to circumvent that control back to me. So it has appeal, just not yet sure if I’m willing to accept the burden of that.
Maybe I should take some time this weekend and download OpenHAB and see what it can do for me and browser the code to see if (a) I can borrow code and (b) provide code in return. (I do get how OpenSource works).
If you read this far, thanks for for your attention and appolgies if I upset or offended you. Please don’t flame me too hard.
Paul
) then you have nowhere to go. Investing in a system that has the option of thousands of devices means you are more likely to find a device that meets your needs…