Bridging OpenHab and Home Assistant

There are multiple views and concepts and each person would say their way is right.

Do you…

Create a massive UI with all your controls on it, VS create rules and automations that mean you don’t need to reach for a control.

Create all rules in 1 engine where you know the language inside out, VS distributing the smarts around the devices so ‘all your eggs are not in the one basket’. If you drop the basket holding all your eggs then all the eggs all smash leaving you with none.

Tasmota has the ability to place timeouts internally so if you turn on the plug/socket it will turn off all by itself. I see these working fine in both projects at the same time.

Uugh, well - no.
You have to centralize in order to be able to automate cross-device/cross IoT platform.
But yes when doing so, you have to take caution about how local devices (or systems) work and integrate their way to work into your central code.
Any proper automation faces the problem to coordinate inputs from multiple instances.
Let’s take a simple example like a light switch. Say you want to switch off light after 5 minutes.
You can easily automate that in OH but what if someone uses the app to switch it on or off meanwhile ? Prolongue those 5 mins ? Hand further control over to the app ? For how long ?
Same problem when someone hits the physical switch button.
Bottom line is, you have to coordinate all of these input “dimensions”.
Pure remote control is simple because it’s essentially stateless.
Home automation is hard.

2 Likes

Well, I think you and I are talking about slightly different aspects. Please correct if my understanding is off, as I’m relatively new to Home Automation (HA). You’re absolutely correct that HA is hard … and there is no unique way to achieve any given task.

  1. My initial thoughts (few weeks back) were to put everything smart I have on OH, and control everything from a ‘master remote’, including the various lights dimmers, the garage opener, or even the smart vacuum.

  2. Now however, I’m leaning to use OH only where necessary. If an automation across devices is needed, then for sure OH is the answer. In other situations, it is sufficient to use the dedicated App for specific tasks, and there is no need to clutter OH.

The above point #2 is in essence what I meant by ‘de-centralize’. For example, there are devices that in specific situations can be used as ‘sensors’ only, like most cameras i.e., they report a status to OH, but OH does not need to tell those cameras what to do, as they are recording continuously. In the end, the hardest part with HA (besides being a computer-wiz) is really deciding what to do, with all that’s available.

Cheers

Well everyone is free to decide for himself but you’re writing this in a forum which is on home automation not remote control.
And automation will not work if you decentralize. Believe me and others or walk down the route into a dead end. If you never arrive at automating things, fine. But I’d guess that even if you today do not think of automating you likely will tomorrow but if you continue your approach then by then you will have already put substantial work into an unsuitable architecture and need to change a lot more.

1 Like

You’re correct and not here to pick an argument. You are obviously at a higher/deeper level than many new comers (including me). When I started with Home Automation, my initial thinking was that I needed to put all my 70+ smart devices on OH, and also some additional sensors for windows/doors/security/… Since then, my understanding and expectations have evolved, and my thinking now is: It is NOT because it has WIFI/BT that it must be on OH. Home Automation needs to be done in a very ‘smart’ way … and only where needed. Thus, it is a must that one decides early on what exactly they are after. Otherwise, HA promises to be a hobby with a lot of continuous tweaking (aka wasted time) and no end in sight, a hobby in the true sense.

Let’s face it, OpenHab provides three options (in my simplistic thinking at least):

  1. Home Automation - Close the window blinds when it’s late and TV is On, …
  2. Remote Control - Central access to all smart lights, switches, media center, …
  3. Monitoring Only - Cameras, energy/water usage, electric car charger, …

Ultimately, any given system is a combination of the above 3 … though many of us will likely start with 2/3 then slowly learn and evolve to 1. The reason I say this is many of us come to HA after buying many ‘fancy’ devices, and their apps typically do 2/3 only, whether it’s Amazon Alexa, Google Hub, or else. It could very well be for such amazon/google devices the A stands for Assistant (not Automation)

Would love to do some time travel and get a glimpse/insight as to what HA will be 5-10 years from now.

My advice is:

  • Be deliberate in your choices. It takes some effort to include any device with openHAB or any other home automation hub. Don’t integrate stuff just because you can, make sure you have a reason to do so. The reason can be as simple as “I want to see it on my display” or as complex as “when this sensor detects movement I want to turn on/off a whole bunch of stuff.”

  • While Matt1 quoted one of my posts, there is a nuance there that often gets lost. Yes, I do recommend that “basic” functionality remains at the end devices. The thermostat should run stand alone. The lights (maybe not all but enough) should still work with the wall switches. But that doesn’t mean that the smarts are necessarily moved to the end devices. You still need the central hub for that because it’s really the only place where the different technologies can talk to each other. When an elevator breaks, the capability is gone. You can’t travel between floors any more. When an escalator breaks, it turns into stairs. You can still walk up and down stairs. It’s much less convenient of course but you can still get to your destination. That’s the goal. Degrade to a point where the functionality still exists, if in a reduced and less automated/convenient form.

  • Personally, remote control is not all that compelling by itself. Ultimately it becomes super complex and counter intuitive. Most people have experienced the pain of trying to teach a guest in the house how to use the remote to turn on the sound system, the tv, switch to the proper input, etc. We have these “universal” remotes with 50+ buttons on them to control everything. And that’s just to control the TV. Add in HVAC, lights, cameras, security and all the rest and it becomes overwhelming. Having said that, you can’t get away from that really. You need that in case the the automation fails (escalators again). But the ultimate goal should be to eliminate the controls you need day-by-day with automation.

Let’s take my very first foray into home automation years ago as an example: garage door opener.

  • Fully Automated: When I start the car, Tasker on my phone will pop up a dialog asking if I want to open the garage. I tap that and the door opens. After 45 seconds the dialog pops up again asking if I want to close it. When I return and get close to the house, that dialog pops up again and I can trigger the opener so it’s fully open by the time I pull into the drive way.

  • Degraded: If Tasker fails to do it’s job, I can bring up the openHAB app or, more likely I’ll use the long press power menu or the notification tiles to trigger the opener. Not as automated but still allows remote control.

  • Broken: If openHAB is broken for some reason, I still have the remotes that came with the garage and can open the door with them.

My goal is automated. Stuff just happens, or at least the system offers to do stuff based on events. When that fails I still have a way to control it. And when that fails I still have a way to interact with physical “dumb” controls.

1 Like

@rlkoshak. I like the escalator/elevator analogy very much. Agree with you on many aspects, though here is a simple example about where a Remote Control is needed.

A while back I replaced many of my light switches with Smart Dimmers. The reasoning for this was to give me the following options:

  1. Schedule some automation based on both occupancy (when people are home, some lights should be on)
  2. Some other lights should be turned on/off according to some random schedule, when on vacation/away for few days
  3. Late at night, ability to turn lights off (while in bed) if the kids leave them on, without having to go and check every room/floor.

In that sense, what I’m after here is a combination of Automation and Remote Control. Yes all 1/2/3 can be done by adding motion/presence sensors but it quickly becomes a daunting task to account for all variables/scenarios.

As you said, I’m definitely not after a single/fancy/50+ buttons Harmony RC … and it’s back to your point: the ability to retain flexibility. In the end, and for anyone starting at this, one must give serious thinking about exactly what they want to achieve and the gizmos they have available. It is not because it has wifi/BT/z-wave that it should by default be connected
to OH, or any other HA hub.

Your general statement is valid, however I disagree here. BT stuff ok it is usually unrelated to other devices, but anything Zwave is meant to be controlled by a central controller, and anything WiFi, while usually built to work with an app, might also better be attached to the central because that’s where you can get the most benefit out of.
Think of entertainment media.
Or think of a WiFi coffee maker. Little point in starting that via app in the first place, you have to slip the cup in first anyway.
You can use remote control to start its heating to save some 30 seconds but how often do you grab the phone for just that ?
Then again if your smarthome does that automatically (using presence detection) that is a benefit.

1 Like

I think there is a nuance in JB’s statement that is missed here as well. I don’t think he’s trying to say that these things should not be integrated into a hub. But just because that coffee maker has WiFi doesn’t in and of itself justify adding it to openHAB if there is no other reason to want to automate it. Just because a device can be integrated into openHAB doesn’t mean it has to be integrated into openHAB. That’s the point I was trying to make and what I think JB is restating.

For other concrete examples in my own personal setup:

  • I have dumb motion sensor light switches in the garage and closet. There is no real need for me to know if these lights are on and to control them in any other way so it makes sense for me to not include them.

  • My washing machine has wifi but I’ve never enabled it. It’s loud enough and central enough in the house where I don’t need a notification on my phone to tell me what it’s doing.

  • I have Plex and Rokus and Chromecasts all over the place. It was not until very recently that I’ve come up with a reason to include them in openHAB (I want to monitor when and what my kid is watching).

  • I have some cameras but pretty much just use their native app. I don’t have a need to do anything in OH when they see something so I’ve not tried to integrate them.

In all of these cases I could integrate them with OH. But (except for the media one) I don’t have a compelling need to. So I don’t include them. Others may have more compelling need to include stuff like this though. Everyone’s requirements are unique.

2 Likes

Thank you, that’s exactly my point. It’s not because it can be integrated that it has to be integrated.

When I got started with Home Automation, I looked at all my IOT devices at home (~80 now) and started by searching as to whether Bindings/APIs/Integrations were available … later on, I came to the same conclusion as @rlkoshak i.e., one needs to decide early on about the can vs. has. Back then I had 20+ Apps on my iPhone to control the various devices (lamps, switches, sprinkler, cameras, …), and my intention was to replace them All with a Central App (e.g. OpenHab). Today, I still have all of those Apps, + OpenHab. In the end, it is difficult to decide what is right/wrong for any specific individual as, like @rlkoshak said, each specific situation/user are very different, and have very different needs/goals.

Another good read is the one below, granted, from a competing/complementary system/product. I like the example of a typical home automation: If it’s movie time, dim the lights, turn on back lighting behind the TV, close the shades … etc … All of this is good, but completely breaks down if there is another person in the room, and they want to do something else besides watching TV.

Creating automation that works in a home with multiple occupants is very challenging in some ways and in other ways it makes things simpler. For example, before COVID my wife still worked from home (still does). Since COVID we both work from home. And when we leave, it’s usually not for long. So it actually doesn’t make any sense for us to spend much time creating home/away changes for our HVAC system. It just doesn’t get used enough to spend much effort there.

On the other side, some things can’t be automated very well because it may depend on what each individual is doing in the house and the sensors are not good enough to understand what each one wants. That’s one of the hard problems in home automation for sure.

1 Like

If you still have to find a phone and open an app, to me it does not matter if it is the OEM app or openhab, I still see it as a pain to even find the phone and wait for any app to connect. I prefer to have events happen without me needing to be involved, also using voice is a lot more handy when something is not setup to be automatic. I very rarely open openHAB or any app as it is either voice or an automation that is used. Often it is both, that my voice will trigger multiple things to occur as it triggers a rule in openHAB.

The fact you placed ‘basic’ in quotes perhaps shows you agree that each person may have a different opinion as to how much functionality is considered basic and should be retained. I try to choose hardware and methods that extend the functionality as much as possible, which hardware does not always exist or it does and costs much more and we need to make compromises.

At some point you do have to draw a line as to how much you get openHAB to do if you are into moving everything into openHAB. How about object detection from video cameras, do you chew huge amounts of CPU from your openHAB server just to keep it all inside openHAB or do you simply buy a camera that can do object detection onboard and offloads the CPU load from openHAB.

@JB_63 If you want a sprinkler controller, check out the openSprinkler range. You can tell the device to not water for X hours or days and then if openHAB reboots/crashes or has a hardware failure the sprinklers will still keep operating as you intended as they do the heavy lifting and openHAB can just send commands and get status without being the dictator. You can set it up either way if you wish, you get the choice but you have to consider what happens if the sprinklers get turned on then you take openHAB down when it would normally turn them back to off. Do you waste water before you relise or do you want a controller that already knows to turn off after X time even if openHAB is missing in action.

I agree with this 100%. Any physical interface (remote, phone, tablet, wall switch, etc.) is only useful when it’s within reach, and usually it isn’t. Recognizing that home automation is all about convenience, the only remote I use is my Logitech Harmony. It’s just faster and easier to change channels/volume on my TV with it than via Google Assistant (or the mediocre Harmony app).

I’ve gone as far as setting up virtual items in Google Home that exist solely to trigger OH rules. They work wherever Google can hear me, including in my car via Android Auto.

@matt1. Those all valid points and if anything at all, it reinforces the ‘consensus’ that we are all after different levels of ‘automation’. Many such automations (e.g. lights in a room) can be done much easier with either voice as you said, or presence detection (PIR or else).

As to my sprinkler, I did research this a bit last summer and got an Orbit B-Hyve. Granted it may not look as ‘fancy’ as some new-comers, but it had some of the functionality I was looking for, and the ability to control ‘smart-faucets’ for e.g. individual garden hoses (Yes, I enjoy gardening in the summer months, but dread standing there holding a water hose). Their App has a lot of room for improvement but it does the job fine, especially when, in the past, one had to run back and forth between the garage and the backyard to see which specific zone was watering.

All in all, what I find very ‘appealing’ with OpenHab is the ability to control and see the status of multiple devices all at once, on the same screen, and also to implement automation rules between devices from multiple vendors. Most current HA/IOT devices have their Apps tailored for small smart-phone screens. I guess not many developers are investing into Apps for large displays. What’s annoying is for example, to setup/control my cameras, smart switches and bulbs, I have to go to each device individually and click down multiple menu items to get where I need to. Hardware developers it seems have done very little in optimizing their Apps’ UI/UX. One more example: TP-Link just came up with a KP-115 smart-plug with built-in energy monitoring. It takes few clicks to get to a screen that shows the electrical energy consumption, but such screen is very static and show a number … what about a graph??? For that, you have to invest in a Sense monitor … but that’s another story.

All the above explains the pull towards OpenHab and the ‘freedom’ to develop a nice interface… but then again, one must have the time for that.

I realize I switched topic a bit here … but ok, OpenHab has many plusses that the hardware OEMs have not realized yet … or are unwilling to invest in.

https://www.amazon.com/Orbit-57950-12-Station-Controller-Compatible/dp/B01D15HOTU/ref=sr_1_5?dchild=1&keywords=orbit+bhyve&qid=1613001912&sr=8-5

https://www.amazon.com/Orbit-B-hyve-21005-Bluetooth-Faucet/dp/B0758V2JQS/ref=sr_1_5?dchild=1&keywords=orbit+bhyve&qid=1613001961&sr=8-5

I assume of you were using a network protocol such as MQTT designed for that ir twould work. For Z-Wave or Zigbee devices, not that would not work.

Not plusses for them. Locking you into their walled garden ot a big profitable plus for them.

@Bruce_Osborne - Agreed fully … they want you tethered to their system/cloud … But, what do we do? Start developing our own everything by ourselves? For now, the hardware companies are fighting for dominance (gotta love competition). Even Wyze, that started as cheap/affordable cameras and other hardware, are now pushing their own subscription-based monitoring service. It’ll be few years before this industry ‘settles’ … though the road won’t be smooth. Hopefully the newly formed Amazon/Apple/Zigbee/… alliance would at least encourage more common/open protocols. Then, the risk is that the hardware we’ve invested in today, might not be relevant tomorrow. Good luck to us all, for now this is a ‘fun’ hobby.

There are interoperable standards like Z-Wave and Zigbee that allow local control with no cloud. Some people flash Wi-Fi devices to stay local too.

1 Like

The “walled garden” notion doesn’t hold up when you consider that companies are making products that work with Alexa, Google, HomeKit, and/or Smartthings. In no world am I locked into the TP-Link product line just because I have a few of their switches and plugs.

As for WiFi products offering/requiring cloud services, that just makes sense. People act like it’s a great injustice for a company to charge you $15 for a device and then give you free access to a cloud service. I would counter that any of those people can choose a system that doesn’t rely on a cloud…they’ll just have to pay extra and put in more effort to get it working (which includes exposing it to the Internet safely). Most people (including me) are not capable of doing that work.

Does it suck when a company shuts down their cloud for some reason, or moves to a subscription model to avoid going bankrupt? It does. Does it suck just as much if your RPi or Z-Wave controller dies? It does. It’s just a different kind of suck, and one of them feels more like you’ve been personally injured by an obvious villain.

Moreover, while a TP-Link customer gives absolutely no thought to the cloud servers that are regularly patched and upgraded by the company, we will clone our SD cards, read the release notes, upgrade from OH2 to OH3, and then figure out why our devices/rules/etc aren’t working. From this perspective, a $10/month subscription isn’t bad at all.

If you want home automation, someone has to put in the time and money to maintain a server for it. We are all people who are willing and interested in doing that, and most of us benefit from the OH Foundation operating the free myopenhab cloud. If not for that, I’d probably be hanging out in the Home Assistant community instead, or struggling along with SmartThings (shudder). :wink:

For consumers who aren’t us, it makes way more sense to rely on a company’s cloud service. There’s nothing wrong with that. It just means we aren’t the target audience.

1 Like

I’m ok paying ‘some’ subscription service, but it needs not be too high. I even proposed that somehow we (the User-Base) contribute to OH, but somehow I recall an answer that in the By-Laws of OH, they’re forbidden from collecting $$.

The argument about Amazon/Google and all their integrations, are these ‘legit’ and co-developed by the respective hardware vendors or those companies (Amazon/Google) have figured this out on their own, with the large talent of computer people they employ. The message for me is, if Amazon/Google were able to develop integrations, likely one day we can see those available directly to OpenHab/HA/…

The suggestion of paying a monthly fee for myopenhab access comes up every time our cloud goes down for more than a few hours. It’s not the bylaws that prevent the OH Foundation from collecting money for the service, its that the Foundation is a legal non-profit entity in Germany. If you do want to support it, you can become a Foundation member or simply make a donation.