Where's the SmartThings Support Group Meeting These Days?

First off, I’m yet another current SmartThings user suddenly wandering the halls of openHAB-land, feeling like I’ve just woke, lying on the dirt at the bottom of a very dark and strange rabbit hole lol (don’t worry, I realize it’s not you. it’s me)

Anyway, I’m looking to gain HA redundancy by adopting an alternate, open source (OK, I guess ‘Free’ is technically and realistically more important for me right now) solution to run contemporaneously alongside my SmartThings universe, as a semi/fail-over controller for my HA system.

(I suppose this is where I should probably give you an out. So, tl;dr lol )

It obviously won’t be any sort of automatic fail-over type thing (unless you guys actually found magic and injected it into openHAB), but if ST ever burns down (it’s already STB a few times. So, that metaphor breaks down), at least I’ll have something else to use until they rebuild.

In such an event as a complete FAIL, or even one that is extended much longer than this current bought, it will likely take a concerted effort on my part, over at least a week for me to get all of my devices excluded from my ST environment, migrated into my openHAB system, and integrated into their pre-created counterpart rules, etc, or however it works here. :slight_smile:

In fact, as long as virtual devices, and the ability to temporarily disable a rule and/or a device (but certainly a rule) are a thing in openHAB, I should be able to pretty much mirror my ST environment in openHAB (using a separate, distinct virtual device in place of each and every real one on the ST side, so that, to do the migration, all I will need to do is an exclude-from-ST/include-into-openHAB, and things should work exactly the same…well, except for the part about how ST really isn’t working at all right now (I mean, not up to the par of what it’s supposed to be).

However, that (at least a week for migration time) is not accounting for whatever ramp-up time I will need checking out the documentation, asking questions in the forum, practicing this and that, and generally getting up-to-speed on what this is, how it works, etc before day zero of the week-long migration process even begins.

Also, ya never know…if openHAB really kicks my ass, I may someday reconsider which of the two should actually be my primary. I am totally open to a ‘change in leadership’ if deemed necessary. Either way is fine, and if openHAB gets the nod from all of my department heads, I and/or my gear will just have to adapt. :slight_smile:

So, I won’t necessarily put openHAB into full production mode right away, but I will repurpose a few ‘standby’ devices (which are not currently in use) from my current IoT zoo into openHAB, and use them as test devices while I am learning how to work in openHAB.

Once I’m up-to-speed, and have done enough testing to feel comfortable, I will likely migrate a certain portion of my current, live-production HA environment over to my openHAB system. This will allow me to do a real-world comparison of a number of things:

  • local processing (this would be a must prior to ever really considering the ‘complete swap’ scenario)
  • stability, consistency and reliability of the core system as well as all relevant, touching parts (and/or counterparts)
  • broad spectrum of HA-protocols supported (e.g. WiFi, Bluetooth, Z-Wave, Zigbee, IR, Insteon, X-10, Others?)
  • device compatibility and full feature-set support (should be, but isn’t necessarily always covered by the entry immediately above)
  • secondary system/service integration and interoperability (e.g. IFTTT, etc)
  • community participation and peer-support
  • developer support

By the way, I’m not really a coder in groovy yet (or any programming language for that matter), but I’m quite familiar with how and where to find things over there. So, let me know if anyone needs links or whatever (did I just say that? what a dork; anybody tech savvy enough, and/or courageous enough to venture out into something like this obviously knows how to search).

It has always been somewhere in the back of my mind, but I never thought I’d be constructing a redundant HA infrastructure before procuring the router needed for establishing redundant connections to the internet via two ISPs on two WAN ports, with monitoring, automatic fail-over, manual or event-based restore, and system configuration backups. My how quickly things can change.


  1. Virtual Appliance?
    Are there any openHAB ‘virtual appliances’ available, or is building from scratch the only option here?

  2. Testing in a VM?
    As long as it’s just for testing, I assume running a Linux-based openHAB VM is OK (in my virtual infrastructure based on VMware vSphere ESXi running on a modified Dell XPS 8500, with i7 CPU [I could dedicate a core or two if need be], 32GB RAM (maxed-out), and plenty of SSD, HDD, DAS, NAS, and iSCSI RAID disk space to go around.). Please let me know if that scenario won’t work for any reason.

  3. Production on Discrete Dedicated Hardware?
    Even without thinking about it much, it occurs to me that it may not be acceptable to run my production environment as a VM, because every time I’d need to go reboot my ESXi box, the openHAB system would need to be temporarily shut down (This could be mitigated with redundant ESXi boxes and a live VM replication/migration system, but…). I guess that’s not horrible though; I’d just as soon experience that than what’s going on with ST right now. lol

If you have any advice, or pointers, or just a link to something that you’d like to share, please do!

Questions first, then comments.

There are some Docker images posted I know. I don’t know if there are any pre-made VMs or anything like that but would be shocked to learn there wasn’t. And if you are on a Debian/apt based system installation is as simple as adding the repo and running apt-get install.

The only gotcha I can see is if you are looking to use zwave or some of the other technologies you will need to expose the USB dongle to the VM. I’m pretty sure this can be done but I’ve not done it myself. A lot of people here (most maybe?) run OH on a Raspberry Pi 2 so you have plenty of resources to run it in a VM.

Like I said, a lot of people run it on a Raspbery Pi, and I bet it screams on a Pi 3. I personally run it on an old laptop. In a lot of ways this approach might be simpler than trying to work out how to get the hardware pass through to work in ESXi, particularly if you are looking to do Vmotion type stuff.

And now for some additional comments and questions.

How easy this will be and what is and is not possible will largely depend on what specific technologies you are looking to integrate. For example, direct zwave support is through one of a relatively small set of USB dongles or through a third party hub like Wink or SmartThings. Zigbee support isn’t there yet but is in work for OH 2. Similarly with BT support.

Also, some technologies do not lend themselves to a simple backup server scenario like you are looking for. For example, zwave devices often only support being joined to more than one controller. So you might be stuck with your weeks long work moving to the backup anyway.

Also, be aware that there is a SmartThings binding that will let OH talk to SmartThings so that could be a migration path for you.

All processing in OH takes place locally. The my.openhab service is optional but not required.

This will largely depend on the technologies and parts. The OH core is pretty rock solid. I’ve had no failures nor problems with it. However all of the bindings are individually developed and despite the best effort of the maintainers, vary in quality and capability. So how reliable the system is will largely depend on you technology choices and configuration. There are tons and tons of variables.

There are over 150 supported technologies in OH including generic technologies like HTTP REST, TCP/UDP Sockets, and Serial devices. Also there is the ability to call local programs and scripts from OH. So the list of supported devices is massive. However, for some technologies the support is not complete. For example the Security Command Class is not yet supported by the zwave binding, though some folks have made some progress. Bluetooth support in OH 1 is a bit anemic (presence detection only) but OH 2 is adding better support. As I said, zigbee support is in work. X-10 support is available for certain controllers. Read the wiki binding pages for limitations and caveats for each individual binding.

Most technologies seem to be pretty device independent. For those that are like zwave, there is usually an effort to continuously add new devices. However, even commercial options fail to have 100% complete device databases.

OH has a REST API that lets you query for states of Items or set Items to new states. For IFTTT integration you must use the my.openhab service.

You can browse this forum to answer that. I personally think the community support is pretty good.

All of the developers are also active on this forum.

It sounds like you are looking to put OH into a more commercial environment than a home environment. One thing to keep in mind with OH is that it has pretty poor support for user and role management. In short, there are no roles and once you authenticate every one can do the same things. There are ways to implement better support for roles through a reverse proxy but you wont get that out of the box in OH.

1 Like

I do use openHAB 1 in a xen DomU as the productive system (16GByte RAM and Core i5, no dedicated Processor) and it works quite well, though all real hardware has to be coupled with tcp/ip, I don’t have any USB-coupled hardware yet, so no problem :slight_smile: .

1 Like

Dude… wayyyyy too many words.

Well, you could do it that way…

…or you could buy a secondary controller (such as a z-stick) and join it to your existing z-wave network, and then run openhab against that z-stick. It’s a little bit of a pain to execute and maintain (every time you add a node you have to manually get a network update by a utility outside of openhab currently), but if you do then you could get your feet wet with openhab by giving it the ability to control the same network rather than having to re-pair all your devices in a “company burned down” type of situation.

As a user that’s migrating from Vera, you’ll be absolutely shocked at the performance difference.


I went so far as to set up my entire system in vmware workstation, passing through my usb z-stick into the vm. Did all my initial os setup, patching, then completed my openhab setup and did lots of testing. Then took the disk image, wrote the disk image onto a SSD, and installed both the SSD and the Z-stick onto dedicated real hardware. Way easier IMHO than doing the multi-keyboard multi-mouse shuffle!

Anyway, point is usb z-sticks pass through perfectly well to virtual machines. Only gotcha is the z-stick 2 doesn’t handle power management well (read: completely faceplants), so if you go this route unplug your z-stick 2 before the machine goes to sleep, or you’ll have to reboot before it ever works again. (Z-stick 5 doesn’t suffer from this issue.)

I could have easily just moved my VM from my workstation to my always on server, and chose instead to go with a fanless always on ion box. Truth be known the ion box was just sitting in the closet doing nothing so there wasn’t much pain to go this way. :grinning: But the reason for this is that every once in a while I wind up doing serious maintenance on my home servers; either hardware upgrades or oh-crap-things-have-really-gone-off-the-rails type events. Point is, I don’t want to lose my home automation in the case things have gone off the rails with the server. That would turn a barrel full of suck into several barrels full of suck. So by deploying additional hardware you limit the number of eggs that can be broken by one basket.

1 Like

Sorry, guys…I’ve been away for some days, and just getting back to this.
I will read from the top, and respond accordingly as time permits.

Thank you, very much for coming in here and interacting with me about this…

Oops…I meant this to be an EDIT of my last post, but whatever…

(since the forum software would only let me (a new user) mention two users at a time in this post, I decided to only include the first two)

Thanks for the responses (all three of you). Most of the info you’ve all just provided is very valuable, and I owe you one. :beer:

Just one quick point and then I’ll respond more later where/if appropriate…

[quote=“rlkoshak, post:2, topic:8792, full:true”]
…some technologies do not lend themselves to a simple backup server scenario like you are looking for. For example, zwave devices often only support being joined to more than one controller. So you might be stuck with your weeks long work moving to the backup anyway.

Also, be aware that there is a SmartThings binding that will let OH talk to SmartThings so that could be a migration path for you.[/quote]

I’m not interested in connecting openHAB (at least, not this particular instance of it that I’m talking about here; though, if there is any way I could use an openHAB setup as part of my SmartThings setup that would be worth the effort, I would certainly consider doing that with another instance) with my current SmartThings environment.

Also, I’m not looking to have ANY of my ‘smart’ devices somehow connected to both my SmartThings environment AND an openHAB setup (or any other system).

For me, for this instance which this thread is about, I’m only considering openHAB as a backup to my SmartThings system in the sense that, if SmartThings takes a dive, I will have another HA system to move over to relatively quickly (weeks is fine).

In my current state, if ST STB, I’m completely sunk (don’t get me wrong, for me, losing my entire HA system would NOT be the end of the world. I’m just talking about ‘sunk’ in the sense of the barrels and barrels of suck mentioned above).

So, I figure, if I start out on something like an openHAB setup, and work on it on the side over the course of weeks (or months), I stand a better chance of having an alternate HA system to transfer everything over to at time of ST STB.

As I mentioned, I would only have a small number of devices that I would put in my openHAB testing environment (i.e. devices which are NOT yet in my ST env.; but which are just ‘extras’ I have on the shelf). Then, at melt-down, I would go through the process of transferring all of my devices into the openHAB system.

It’s a lot of work, but with an openHAB (or other?) system already up and running, and with already having been in and out of discussions, device drivers, and gotten familiar with your HA world over here, etc, I’ll be in a better place from which to conduct such recovery activities. :slight_smile:

p.s. Thank you for allowing me the decency and respect to be able to ask whatever questions I need to ask in whatever way is customary for me to do so without being made to feel like I have three heads (2/3 is better than 1/3 or 0/3). lol It’s so cool to have a community like this that is willing to step in and lend a hand to the noobs. :slight_smile:

Given your clarifications I might suggest connecting your OH to your SmartThings if for no other reason then you can give OH the same information your SmartThings hub has which can help drive rules you write for those devices connected to OH. And because OH provides a layer of abstraction between your devices and the rules logic, you can start building up your rules now to use the information from the SmartThings hub so when you do have to move things over the rules logic will already be in place.

To elaborate with an example, if you have a Thermometer on SmartThings and a HVAC controller on OH, you can read the Thermometer reading from SmartThings and write rules to control your HVAC that run in OH. Then when your SmartThings Hub dies you can update the Thermometer Item in OH to connect directly with the actual thermometer device instead of through the Hub but you do not have to change your sitemap or your rules.

1 Like

Thanks again for more good info.
This sounds like it may be a possibility.

So, hmmmm…in such a scenario, would my SmartThings hub or account ‘know’ anything about the OH system, or would the OH connect to it like I have connected other things (such as the Android app named SharpTools on my Android devices, in order to get trigger data from my SmartThings system into the Androids; for wall-mounted control panels, leave screen off (Android itself still completely ON), and only wake the screen upon motion in the room, etc), where it (OH) just needs to connect to the account with the same credentials as I use to log into the online admin interface for SmartThings (the IDE), in order to ‘listen’ to activities in my ST account, and use some of them as triggers for the Androids?

It depends. I misspoke earlier when I said there was a SmartThings binding. Smart is a pretty common name in this industry.

But the integration between the two can go one of two ways. IF SmartThings provides an API that external programs can use to query for information, then you can use the appropriate OH binding (e.g. if it is unencrypted REST with basic auth use the HTTP binding). It sounds like something along these lines is what your SharpTools app may do. I see a couple of examples using curl in their docs so I bet this will work.

If something like that cannot be made to work then you will probably need to add some SmartAps that forwards state updates to openHAB through openHAB’s API.

1 Like

Wow, I knew that things were a bit dodgy in SmartThings land for a while, but I had no idea things were this much actively on fire. That’s… bad!

(Even crazier because more than 5 seconds from button push to device action I’m a really unhappy camper! I’d be losing my fricken mind if I was a ST customer right about now!)

Given that ST seems to be melting down right now, it doesn’t seem that interfacing to your smartthings controller would really get you very far or tell you much. You sure you don’t want to go the self reliant route and get the data from your smartthings devices yourself, locally, cutting samsung out of the loop entirely?

1 Like

This is why I replaced my contact and motion sensors with zwave compatible ones and dug out a pi2 I had been given at a conference, threw OH1.8.1 on it and spent a weekend moving all my switches and other devices to OH. Now my system isn’t dependent on the internet and the only person that can break it is me.

I had too many days with ST where I would wake up and nothing would work and then there was the time they “fixed” the Sonos integration and took the whole system down.

1 Like

I never understood why anyone would consider an internet service as a better solution than servicing it at home :slight_smile:


Unfortunately, even with all of the research I did prior to going with SmartThings, the issue of local processing wasn’t one of the things I even thought to investigate. :frowning:

Eventually, I WILL have a HA system that does all of the processing locally, and it may very well end up being openHAB. Till then, I will be doing my best (with what little time I have available for this project) to get to know openHAB, AND you guys.

Ya @TheKorn the melt-down going on at SmartThings right now is embarrassing.

The main reason I’m still hanging on (for now), is that, with such a massive, innovative, rich company like Samsung behind them (bought ST in 2014 or something), I sort of assume (I know, I’m already an ass) that they’ll eventually come to the rescue, but I’m beginning to wonder…

Some would rather just know the time, rather than building their own watch! But the reality of the choice sinks in after you’ve made it. :smile:

1 Like

There are good arguments for both local and cloud services. For example, most users would have no idea how to open up a port in their firewall and of those that do not many realize the security implications of doing so. So by making the part of the product work in the cloud they can let users access their systems without needing to do that. Even openHAB has done this through my.openhab.

Another good reason is that by moving heavy processing off of the devices and onto the cloud it reduces the cost of the devices they sell. The update/upgrade/patch management path also becomes cheaper and more uniform as the company can update and upgrade or add capabilities on the cloud side without needing to deal with the long and difficult problem of pushing updates to devices. So, from a user’s perspective (particularly a non-technical user or a user who is not interested in this as a hobby) they get more capability for less money and/or time.

Of course all the negatives I think are obvious which is why many if not all of the users on this forum tend towards the local processing approach. Though the majority of the users here are also HA enthusiasts and so are willing to spend the extra time.

It depends.If ST becomes a drag on profits they can just as easily shut it down. And despite how important this industry is to us and how much we see mention of it in the IT news and such places, the home automation and Internet of Things market is tiny compared to almost every other industry Samsung is involved in.

In my observations I’d say that Samsung purchasing ST makes it more likely to experience this sort of problem and eventually shut down than otherwise.

1 Like

Wow! Why would that be?
I don’t have a contrary opinion. Just wondering (really loving getting in on this industry…even though I agree with your assessment of its place in the Samsung universe).

Often these big companies see a shiny new object (i.e. a new or emerging market), want to get in on the action and so buy a smaller company. Then over time they impose their corporate culture on the smaller company, founders and leaders of the smaller company leave (they got their F@#$ You Money as part of the deal) and much of the technology, market, and corporate knowledge leaves with them. And thus the big company is left holding what was a company in a new market without really understanding how that market works any more. And they just spent all this money acquiring the new company and so are loath to invest even more into it in order to make it profitable. Eventually the acquired company either gets spun off or closed down. This is how I see the Samsung purchase of ST.

Another story is a bigger company sees a smaller company that either now or it thinks will come to compete with them. In that case they may buy that company to acquire some patents or technology which they will merge into their own products and shut down the competitor. I’ve seen Apple and MS do this quite a bit.

Another story is the bigger company buys the smaller company because it has synergy with their products and they slowly merge those into the bigger company’s products and slowly the smaller company disappears into the larger company.

Another story is that the bigger company thinks it wants to be in the new market, buys the smaller company, realizes the market isn’t as good as they thought and eventually let the smaller company die through neglect and starving it of resources.

1 Like

That may not turn out to be the best prediction you’ve ever made. :wink: Samsung has a history of abandoning support for products fairly quickly (see S3, S4) once the “ooooh, shiny!” marketing has worn off. That said, their durable products division (refrigerators, washers, etc.) is quite on the opposite side of the scale. My gut feeling is that somebody inside Samsung got a wild hare up their… and Samsung whipped out the checkbook. Typically support from then on hinges on whether that person still is with the company and hasn’t lost favor (“face”) in my experience.

…but that’s enough smoke ring and tea leaf reading for one day!

Not to mention there’s always the possibility when building it yourself of accidentally winding up with a watch with two 3s on the face!


Yes, but all in all if the home automation shall be powerful, the configuration will cost a lot of time, regardless if cloud or home serviced :slight_smile: