Why would you return to SmartThings?

đź’¬ Lounge
1

This is an opinion piece. I have facts to backup my opinions, but that's neither here, nor there.

Having owned SmartThings when it was better, I understood the potential and experienced the things that could be accomplished, but that was then. Now the experience is so unstable, I wouldn't dare put my entire house or any critical devices in the hands of Samsung's SmartThings. I'm not writing that to disparage Samsung. They make great products, or they contract companies that do really know what they're doing to manufacture product for them. What they don't do well, is cloud. That is more than evident to me. Since the cloud is half of their platform, and their second generation hardware is well designed, then their platform is only half of what it needs to be. In fact, I feel it's important to recognize that the one thing that Samsung is directly responsible for (the cloud), is in fact the unreliable part of it.

I mean no disrespect, but I find it laughable to state that SmartThings is more reliable than Hubitat. A statement like that is, to me simply an inability to recognize a romanticization of the platform, resulting from the comfort that comes from familiarity with it. I've personally never had a more stable hub than with Hubitat Elevation and conversely, I've never experience more issues with the SmartThings cloud than I am today.

The most recent issue is with simple login to the IDE. Yesterday I went to login (because I am still using the SmartThings IDE for use with Alexa until I can trigger Alexa Routines with HE devices), and the message that if I did not update my profile, I would soon lose access, prompted me to finally make the change. So I updated and it gave me access. Today not so much...

29%20AM
Screen Shot 2019-01-30 at 9.17.29 AM.png746Ă—479 10.8 KB

So, I also have an existing SmartThings account that I have not done the upgrade to yet. That account now tells me the password (which is save in LastPass), has not changed since 2016, but is now claimed to be incorrect. A pain, but not insurmountable if I simply reset the password right? No, they don't send the link. It's not in my inbox, and it's not in my junk mail. Twice I've tried and I receive nothing.

So my point is, if your Hubitat hub is not stable for some reason, don't post about how it's not a stable platform. That's simply not true. There's plenty of evidence from users with many different device types, and hard facts to prove that it is very stable, despite its development stage. I'm not saying it's 100% reliable. That's just a ridiculous statement too, Nothing is 100% reliable, despite anyone's anecdotal evidence to the contrary. However, I am not alone in recognizing that the Samsung SmartThings cloud service (half of what make the SmartThings hub operate) is unreliable.

So personally, and lets not forget this in an opinion piece; I think if your experience with Hubitat is unstable, and you can't recognize that after multiple attempts, with multiple hubs and limited devices, that it's still something in your environment, then you have personally decided that you prefer familiarity above all. It's obvious when, despite the advice from the community and Hubitat staff, the person having their own ideas about how things should be done, decides to repeatedly acid test the hub. and than create multiple posts before they eliminate variables, even when they are trying to get to the bottom of an issue, then the true cause of the problem is simply never going to be found. A person with that mindset is almost certainly going to declare, based on improper and ill-advised testing, that they find only problems and no solution, so they give up.

9 Likes
2

I think that there is plenty of data at this point that shows Hubitat can become unstable with some combinations of Zigbee devices / quantity of devices. [EDIT: This was fixed in the 2.0.6 release]

So for those people, SmartThings is more stable/better, as the exact same devices work fine on that platform. And for them, Hubitat is unstable. I see nothing wrong with that statement, as that is their reality.

And don't victim blame... Why should they put hours and days into figuring out why it doesn't work only in Hubitat, when they know for a fact it DOES work on other systems with the exact same devices? Seems to me the burden is on Hubitat in those cases, not the end user.

If that combination/number of devices didn't work on any system, I would agree that it is their problem. But when the same combination of devices work on ST, Wink, and HomeSeer - but not Hubitat... Well...

I like Hubitat very much for the architecture. I like ST very much for its better user interface, much better engineering tools, and vastly superior device support (hundreds more DTH than Hubitat has). Tiles for devices was a VERY powerful feature that I miss dearly - the HE dashboard sucks in its current form (my opinion) and is not a suitable replacement to Tiles.

And RM is not a full replacement for CORE/WEBCORE either, thus forcing me to make a lot more standalone apps. Same reason I didn't use RM in ST either. Oh, and if there is any issue/slowdown on the hub, first support knob is "turn off all those apps we forced you to make due to RMs limitations"... Heck we can't even see WHICH app/driver is bogging things down - no performance data of any kind is available.

So I like Hubitat enough to stay for now, but let's not kid ourselves on the things it does not do well.

7 Likes
3

Which one, which combinations? This is my point. It's anecdotal. Facts are needed to find problems with the HE platform, but all they get from these users are either wild speculation or tests with many devices at once. They never test with one device at a time. Then after a stable period, add another device. The users that actually do this, get to the bottom of their issues and they're still here today, and their happy.

Perception has not been proven to be reality. It's perceived to be stable. The factual email announcements from Samsung that their cloud service is down is the reality.

I can't victim blame someone whom is not a victim of anything. Their repeated posts contain the evidence of their own wrong doing. Things like (I'm not directly quoting anyone) "I decided to press through and keep adding devices as fast as I could". NO. WRONG! That's not how to properly troubleshoot.

But, it does work on Hubitat. Even if there's no one in the community with that combination (although there usually is), then Hubitat themselves try it and can't duplicate it, then it must be something that isn't being presented or disclosed. I can't find another explanation.

Sorry, but that's kind of like comparing a baby to an adult and calling the baby lazy because it can't do as much :wink:

Jason, stuff like that wasn't even in my post, other than what maybe you inferred from the title. This isn't a commentary about how one is better than the other, but rather how I personally feel one is more stable than the other. Not fair to Hubitat, just barely a year old, to compare with a mature platform. What I find impressive about Hubitat is they are where they are in just a year. SmartThings wasn't here in that amount of time. Hubitat certainly has benefitted from the knowledge that SmartThings gave the founders to bring them so quickly to this point, but the fact remains their hub is based on an unstable cloud platform and so to me, it doesn't matter how many devices just work sometimes with SmartThings. I'm only interested in the devices that work all the time with Hubitat.

4

Yup, Hubitat is definitely the hub for you... "If something isn't working it is the users fault." :roll_eyes:

That said, my Hubitat is working great with no (major) issues - so I'm pretty happy. I disagree with you, though, that users with issues haven't worked with support in a methodical fashion. Multiple have, and still had issues such as the zigbee stack/driver/stick dying and going uninitialized.

Some users have legitimate issues, explaining it away as "Hubitat is awesome, and everything is the user's fault" is nonsense. I know you didn't say exactly that, I'm summarizing how it came across to me.

5

I'm also starting to think that because code on ST is run on the cloud it masks the bad code that causes slowdowns on a local hub.

In the cloud it has lots of resources to do whatever it wants. Because of this bad code may look like good code. On our hubs, bad code will do bad things.

On a side note.. there are so many points of failure. Last night went to adjust my ecobee temp and bam... ecobee outage. 1st world problem I know, but never looks good when the wife is next to you saying its too cold.

5 Likes
6

I think the same. When you have a much larger pool of resources, it is a lot less likely that a poorly performing app will kill you,

I still prefer local execution, though. Versus ST, my logic executes MUCH faster on HE. :+1:

7

Interesting. I searched for that quote, but the only place I could find it was in your post.

I'm not faulting anyone that works with support, replaces the hub or stick and resolves their Zigbee problem as an example. But this idea that there's a problem with the Zigbee implementation on Hubitat that is just coming to light for only certain select users after a year of real world use by many owners, and all the development work put in by the Hubitat team is just not believable to me. I recently had my Zigbee radio drop off. I also knew I had just added something that was misbehaving too. I removed that thing and it has not been a problem since, as it was not a problem prior to that. That's how you properly find and eliminate issues. Not by wild speculations. That, by the way, is not directed at you. You have been very logical an methodical in your testing and troubleshooting from what I have read in your posts. Further evidence that if you take the correct approach, you get positive results.

8

I will say, we all want the system to improve.

It is very good now for being only a year old. It has a long way to go to gain more non-techie adoption in my opinion, which is where almost all of the money is.

I am a little concerned whether Hubitat as a company will be around in 2-3 years, or if they run out of cash and just open-source the software and walk away from it. That is always a fear of mine on a young company, though.

So let's hope it keeps growing and prospering.

And on my side I hope they start taking a more developer friendly approach to the community. I and, based on comments I've been reading lately, some other developers are getting a little tired of support's "turn off all user code" stance for troubleshooting.

Well, that and not sharing built-in driver code, but that is another story altogether (if people want to improve/extend your product for free - LET THEM. I even offered to sign an NDA...). I could have written 3x more drivers had I had the approved/sanctioned generic driver to work off of - and it would have been lower risk to the end user as all of the built-in code, by definition, should be OK/tested.

8 Likes
9

Nice mobile apps, phone notification, phone oeresence sensor, webcore. Third party intergration. WAF is so much higher for me on ST. Sure it's not stable but it's not as often and why would you put critical system on ST or HE in the first place.
Not that I am moving all my devices back to ST but I still have many devices on ST. The more choices the better.
I find that I still spend the same amount of time on maintenance on both ST and HE.

10

Unfortunately when troubleshooting anything (not just hubitat) I look at the obvious things first. It sounds like a broken record but usually that eliminates most of the issues. Kinda like back in the day when working help desk, the first thing we use to ask people was if they "power cycled their computer".

Its annoying but there is a LOT of bad code. I'm very weary of apps that subscribe to every event of every device you select in it. That adds a lot of load on the small box.

Maybe a more powerful box would solve it, but that is also masking bad apps as well.

Another side note... ecobee is down again right now. :frowning:

1 Like
11

A very good point.

12

Someone should ask ADT that :wink:

3 Likes
13

I understand, and agree. Even if that needs to be supports stance - and I get it - if it is really bad code causing issues I still think there should be a way to see this in terms of IOPS, CPU, execution time per app.... SOMETHING. We are all flying blind right now.

And then, if it is an app causing issues, how is a developer supposed to figure out the root problem with no diagnostic tools at all? We have to just guess where we think the problem might be, and trial/error it.

2 Likes
14

Because the impression is it can be used for critical systems? Why else would you sell HA compatible leak sensors, alarms etc?

1 Like
15

Oh, and don't get me started with them... I've been a customer for years, and really like the equipment. But I do a lot of automation based on thermostat operating state, etc, and they are killing me - no cloud=no status updates in HE.

So much so that I bought and installed a Remotec ZTS-500US z-wave plus thermostat last weekend to test as a replacement for Ecobee...

1 Like
16

Yuck thats a shame to hear.. I've been using Nest with decent success but am under no illusion about who really controls things which is why Ecobees stuff seemed compelling. I am using centralite pearls for some radiant floor heating.

17

No, they never made this claim. SmartThings doesn't either.. You can use either platform to notify you of events or even take action on those events, but in no way do they, or should they guarantee the hub for this use. You do these things at your own desecration and must fully accept any risk associated with doing that, beyond the $100 purchase price of the hub. It's a home automation hub, not a protection device.

Item 8

2 Likes
18

SIDE-SIDE Note:
Their servers have been intermittent since yesterday evening. My ecoobees just came back on ... again ... several minutes ago :face_with_raised_eyebrow:

2 Likes
19

Totally agree. I remember reading a technical post by one of the team explaining why they couldn't see such things. Had to do with the underlying os of the system and how it works. I think you can't see the individual app's, it just clumps it all together. (Don't quote me on this.)

This is a scary thing. Recently somebody had an issue that could have been a life or death situation. But I don't know if I could trust my system with something like my fire alarms.

All of my sensors though are monitored (especially the important ones). As soon as one stops reporting in or doesn't reply to a refresh I get a notification. Its done on the hour. This is how I know my xioami setup has been stable. I rarely get notifications and when I do they usually check in before the next cycle. They are always working though.

You need a system to monitor the system. :slight_smile:

1 Like
20

Yeah, that is part of the trials and tribulations of troubleshooting Java in general. Unfortunately.

To be fair, the fire/CO alarms in that case worked fine. They just didn't get a notification that the alarms were going off in the rental unit. Anyone in the unit would have heard the alarms just fine - just like any fire/CO system.

So it wasn't REALLY life or death... It was a convenience notification that was missed.

1 Like