Using openHAB for commercial

I’m new to IoT and I have been asked to study how to build a solution for a cloud services provider.
The idea is to have part of the services, an IoT and home automation for clients that’s brand dependent. So we thought about having a single board computer and various connections such as Zigbee, Bluetooth, wifi and zwave.
The cloud service will be providing not only IoT but with more services like CMS and others. There will be a smartphone app as well.

So, can we use openHAB as a kickoff solution and is it possible to completely customize and rebrand it to have the name of the solution provider, at least in the dashboards? Maybe colors and UI changes also.
Can we also do the same for the cloud and mobile apps, copy the repository and modify it ourselves and adding our own customization?

Not with the openHAB name. It is owned by @Kai and has this been discussed here many times previously.

Thanks, but what do you mean by not with the name? So it’s ok if we copy the sources, modify it and change the name?

Perhaps see what this user is doing.

I think the EPL 2.0 license permits forking the code, but it must still be freely available.

Thanks a lot I will contact him.
There might not be modifications actually maybe new UI that integrates with parts of the main system because this is going to be fixed with some brands due to the complexity of the setup for end users. Not all of the features of openHAB will be exposed initially to ensure scalability and compatibility.

AFAIK, you can use openHAB but you must not change the name. You should refer to something like „powered by openHAB“.

You might want to read through Starting a company that provide smart home automation solutions based on openHAB software, which was a fairly similar question.
In general, I’d suggest to also get some legal assistance when starting such a business. The key points were mentioned here: The EPLv2 license defines in detail what is allowed to do with the code and what obligations you might have. Furthermore, the openHAB name is a registered trademark, so it (= the name) must not be used in commercial solutions, while references to openHAB (like “based on openHAB”) are in general ok.

3 Likes

Hello,
I have the similar questions and for me the thread Commercial support for openHAB from ConnectorIO did not answer what I needed to know.
I was asked by a local electrician to provide a openhab solution to one of his customer as he has seen what openHAB can do. His customer was not happy with the functionalities of his commercial KNX server because heating control & air ventilation system couldn’t be integrated.
So I thought why not offering a openHAB integration service based on KNX.

  • Is it allowed to explain on a website what openHAB can do and the advantages of openHAB? The final installation will not be modified or rebranded so I will ship a “normal” openHAB installation.
  • To list on a website that openHAB programming services are offered
  • A link to openHAB’s website

I didn’t contribute except answering a few questions on the forum. This is due to the technology and programming languages openHAB is built on which is not my expertise.
So contributing money is what I think of. So a monthly contribution and a project based contribution is what I consider. Is this possible?
@Kai: I don’t want to involve a lawyer (legal assistance) but keep my costs down. I am trying to do this part-time and I don’t know if there is market around were I live. So it is basically an extended hobby first.

You referenced @splatch thread and I am sure he can provide experiences.

Hey @marco_hoefle,
Most of things we do at connectorio is related this way or another with openhab. We do provide both - programming/consultancy services and complete product which is compatible at APi level with openHAB (so called ConnectorIO Gateway+ConnectorIO Cloud). Currently we limit supported bindings to just few.

What you refer to is first case - selling services. Nobody can forbid you from making money on open source as long as you are inline with source code license and trademark usage. What you do is commercial service which has nothing to do with project contributions (it would probably help you with marketing). This is pretty much same around multiple projects I know.
What you can’t and should not say is that you sell openHAB. Such statement would create false perception on client/end customer side.

Because trademark guides are still not defined (at least not that I am aware of) and trademark belongs to an individual (not foundation) there is still some grey area which might need further clarifications.

I can just welcome you to list of people who try to move this market ahead. :slight_smile:

2 Likes

Trademark is personally owned by @Kai I believe. I think the logo is owned by the Foundation.

Thanks Bruce and splatch,
@spatch: Thanks for your offer regarding marketing.
I will come back to you regarding your solution anyway. What I see is that the maintenance of an openhab installation can be time consuming. If it is your hobby that’s ok and from time to time fun.
If you have to upgrade 100 unique and different installations that can be a problem.

You are using the Logo here:
https://connectorio.com/smart-buildings-resources/openhab-industrial-integrations/
I want to - if I am not violating anything - do something similar.

What I would appreciate is having an online meeting among people who use openhab in a professional way were we cover the following topics:

  • What would be the way to contribute to openhab (from maintainers perspective). I don’t want to “take only”
  • How to advertise lets say a OpenHAB programming service
  • Support options (if something is broken, for me a killer would be for example an unstable KNX plugin)

Indeed this is a struggle everyone have, especially if you have solution creating an “moving target”. On other hand if you stick with stable protocols such as KNX it might be close to “fire and forget”.
You can ask @george.erhan or refer to his presentation from Eclipse SmartHome Day 2018/2019. If installation is done properly all you need to do is database maintenance from time to time. Some of his projects might be still on OH 1.x cause it is so stable, and there is no reason to change it.

If you want to do things at large scale you either stick with repeatable setup (ie. the same HVAC controller in the same configuration), stick with very few protocols or use on-site help from installer/system integrator.

I hope we do not violate it too! :wink: So far we haven’t been contacted by anyone with trademark issue (also big corps mentioned on the same page). Either we do things properly or we are too small to be noticed.
Our use is similar to for example smartbms.pl which lists all manufacturer logos they could possibly get!

You are going on an already well known path. Long story short:

  1. never ever upgrade a working solution, especially when dealing with building automation (no 2 buildings are alike).
  2. Sandbox all the setups either through virtualization, or other networking security solutions. If you know what you are doing, openHAB is the way to go. I still have working setups running openHAB 1.8.

After dealing with a few protocols, I can definitely say that the transmitting environment is the first essential key to reliable solutions: wired solutions are way more reliable than any RF solution. 2.4 GHz solutions (WiFi, Bluetooth) are becoming increasingly less reliable due to channel frequency congestion.
In terms of protocols, any RS485 based protocol, or TCP/IP based, is a rock solid reliable protocol.

@chris has commercial users using his libraries on Zigbee and, perhaps Z-Wave Wireless can be stable.
Wi-Fi (proper trademark spelling) was not designed primarily for battery powered devices nor for the smart home. It has high network throughput and power overhead. 5GHz or the newer 6GHz Wi-Fi. if properly deployed might be more reliable but there are no smart home devices produced for them.

While I might agree that wired will normally be more reliable - if you have a reliable system, then it doesn’t really need to be “more reliable” :slight_smile: and I think it’s not really right to blame the technology when (as is normally the case) it’s often us humans who are to blame…

Just like wired solutions, wireless solutions need some planning to understand the network. With a wired system, this happens - it has to or you don’t have any connectivity. With a wireless system, this often doesn’t happen - people tend to plug things in without really thinking, and then complain when it doesn’t work well and either blame the software, or the technology.

I worked on the Hilton Hotels ConnectedRoom system. In the hotels we were testing in, there were hundreds of rooms - all served with 2.4GHz WiFi, BLE door locks, and ZigBee for lights and thermostats. This worked very well (ie reliably), and I think it would be difficult to think of a more congested place (RF wise).

If you’re building a new house - wire it with CAT-6 and be done with it - it has to be best for sure. However, wireless will just as work well if some thought is put into it, and you understand what you’re doing and how RF propagates etc. and it’s usually easier to install into existing buildings than a wired system.

What I would say though is doing “half and half” is often not good. Wireless systems tend to work best when you add more devices, and I sometimes see people say things like “I’m going to wire my house for lighting etc, and then put ZigBee battery sensors in” - this won’t work as the mains powered wireless devices provide the network for battery devices - no mains devices = a very poor network.

2 Likes

I 100% agree!

I never said, nor will I ever say that RF systems can not reliably work. I am only pointing out some drawbacks, one of them being the white noise (e.g. busy channels with no BSSID) that 2.4GHz systems may encounter (it happened to me several times). Of course, one can argue that even wired solutions may have EM interference, and that is true, but the likeliness of RF systems being interfered is way bigger.

True. What I fail to understand is why people building new houses refuse to wire and still rely on RF. I consider RF systems the perfect solution for existing buildings with little to no method of rewiring.

At least in North America, most new home buyers are offered limited customization options when buying a new house in a subdivision. Very few have their own custom designed & built house. I assume even fewer are tech savvy enough to want it wired for network.

True story. When we bought this old house a few years ago, we got a free home inspection. The inspector thought the TV antenna twin-lead screw terminal wall panel was a 2 prong electrical outlet??

2 Likes

I broadly agree with this question/statement… However, I’ll try with an explanation - although it is a kind of repeat of above…

I’m currently moving house (and country!) - we might buy, or we might build a new house. If we build, then my immediate thought is of a wired solution - exactly as you have questioned. It makes sense - put in point to point wiring, CAT-6 everywhere, all wired back to a central panel and you’re done - perfect solution.

But for one issue… You then consider that you might want to add some wireless sensors - maybe a door sensor, or some extra thermostats. You could wire these, but wired door sensors tend to be messy - especially when you spend a lot of money on fancy door systems. Or, you might find you want to have a motion sensor somewhere that you forgot to wire when you built to provide better coverage, or to meet some new use case. Now you’re into the grey area I spoke of above - for a wireless system to work well, it needs a lot of mains devices to provide the routing infrastructure.

There are other solutions - I could put a bunch of access points for the wired system (eg ZWave controllers or ZigBee coordinators) wired back to the main controller and have a number of different networks - that would work, but it’s a whole different kind of mess.

So, I think we’re largely in agreement here :slight_smile: but I’m not sure if there’s really a perfect solution (yet)…

4 Likes