Your opinion is respected very much Stephan. Thanks for offing it. I really don't want to keep on with the idea that I wrote this to single anyone out though. Not the intent.
3 Likes
I will go back to ST. I am in the winter house. The Summer house was ST when I left. I disconnected the ST hub after a couple transition days, having received HE. I hope to plug in the. ST hub, spend a couple of days setting up RM, and unplugging it. I have found HE to be much better overall. The biggest advantage has been, running on a WiFi hotspot, much better reliability. Data runs out, WAF is still there, she does not notice! Overall a bit of a learning curve switching from WC to RM. RM is running flawless, other than my own "oops" occasionally. Works so well that I am board! Need to try something new. Humm, that must be what the second HE is for. (that and I see a huge advantage to the USB stick for me) The moment that I cought wind of the internal radios, second HE went my way, either for backup, or for experimentation. A fantastic piece of kit, with some great software. Fix some rough edges, add functionality, at the pace HE's team requires, it works great for me. I cannot remember a time that a "glitch" was not my logic! This is my opinion, no reply necessary.
2 Likes
There have been a lot of strong opinions expressed in this thread, and I’m not trying to pick on you, @Somel, but I think this is a little unreasonable.
Standards like z-wave and ZHA (the zigbee profile HE uses) exist for a reason. If a device manufacturer (Xiaomi) wants to design devices that will work with their own hub but don’t conform to widely accepted wireless communication protocols, that’s fine.
But expecting other home automation platforms to go out of their way to support a device that wasn’t designed to be supported? That just seems unfair to me.
2 Likes
Let's say I respect your point of view.
However I disagree with you.
The only thing where I could point as potential not being conform is on the rejoin process other than that they are in line with the standard. Please see the other threads on Pro and cons of zigbee devices and the Xiaomi/Aqara.
It’s not really my point of view; Xiaomi devices use zigbee but they don’t conform to the zigbee home automation 1.2 profile. This post by @JDRoberts in the ST forum explains it far better than I ever could.
I'm not going to hijack this thread further.
This is being discussed on another thread, feel free to join the discussion there.
1 Like
@Somel, this gave me a good laugh. After reading what u said afterward, I realized what you meant, but I'll admit I was expecting fireworks. I'll have to add this phrase to my arsenal. 
2 Likes
No thanks. You brought it up in this thread and implied it’s a failing of HE if the devices don’t work well, which I think is a fallacious argument to make and thought it was worth commenting on that.
I would never begrudge anyone who wants to take the time and effort to get a non-compliant device to work with their HE hub, but that’s up to the individual, not the platform itself.
2 Likes
Good phrases can be used everywhere and in so many situations.
One of my favourite when you are negotiating with Top100 C-suite is: "I really appreciate your time on this, you raised several areas that we could really improved our efforts and look into provide better finess on our offer. By the way did you consider this implications as it might hurt as both, potentially we could work this as an addendum to the current offer to avoid the timelines to slip"
This reads, we have provided our best offer just sign it, any changes can be added at a later stage...
What did I brought on thread
Let's translate for better reading.
"If a device works in a given system it should work on others as well."
What this mean is that's technical feasible to implement a solution that works.
"If other systems have customized their zigbee stack to support this means there is still work from HE to improve on"
This translates to: If one of the options of other platforms was to customize their stack this is an area that HE could improve on and explore.
I never said that HE had to do XYZ. Only them know their roadmap and where they would like to go.
If this is bad mouthing them?! Please....
Hey @Somel , I'm a little confused with your writing, sorry, my first language is not English and I'm writing this not to offend you or to start a fight, just a conversation to better understand.
In my testing with Xiaomi sensors they were working fine with just the HE hub and Xiaomi, when I tested the Xiaomi with my other mesh with Iris plugs did not work properly, then testing Xiaomi with Tradfri only they worked fine and the RSSI was improved. I know Xiaomi devices are sleepy, this is why they drop the mesh, but I believe HE can't do anything about, because if you see, the problem here maybe is Iris plugs, maybe if they release a firmware for Iris plugs this could be corrected. I think the real problem is Xiaomi unfortunately did an Incompatible firmware with most devices so the only options are Xiaomi fix it or everyone else like Iris fix it. I'm lost here, or I'm getting this correctly?
No fight no worries 
In Essence all your statement is mostly correct. This based on all the readings I have done. Please be understandable that the terminology might not be entirely correct.
Your HE Hub has a ZigBee stick that acts as a coordinator and a router. As a coordinator he can support other routers with child devices. As a Router itself he can have child devices.
As a coordinator/Router the USB stick has a ZigBee stack that will poll the direct connected to it child devices and the routers.
The routers will have a ZigBee stack of their own that will manage the polling of the individual child devices on that specific router.
The coordinator is still responsible to translate the information received from the routers.
Regarding the Xiaomi devices.
If a device is directly connected into the USB Stick than its the definitions of the built in ZigBee stack that will define the check-in period and the rejoin policy's.
If they are connected through a router than is the built in ZigBee stack of each individual router that will manage that information.
As such if an outlet is a bad or good repeater depends on each individual outlet stack, that can vary as well based on the firmware.
From what I also have read ZigBee 3.0 is much more resilient than ZHA 1.2, as such it's likely that you will get better results from an ZigBee 3.0 router that from one with ZHA 1.2. Even if a ZigBee 3.0 outlet will need to communicate with a ZHA 1.2 Coordinator.
On a side note OpenHab for example official support the Xiaomi devices through the Xiaomi gateway Lan capability. The IKEA outlets are also detected by Xiaomi Aqara gateway. This is a similar integration to Philips Hue.
1 Like
Thanks.
You welcome.
Just an addendum.
I disagree just with the statement that they are not complaint as there is definitions that can be done at stack level to enable the Xiaomi devices or any other device brand with similar behaviour to work as expected.
The Above does not mean that I advocate that it's HE jobs to do it, but it's something that they could improve on or explore as ST did.
I however do not consider that this is the best approach for HE in the particular instance of the Xiaomi devices.
I believe that they could and should consider an approach as OpenHab (as they did for Hue).
Is too much of a sensor market to not consider or test the waters. This way they wouldn't need to worry with Xiaomi Mesh and polling just to ensure that the Lan connection worked.
Hope this clarifies once for all my view.
Thanks
What ST did? Xiaomi works there with Iris?
I agree, same as HE did with Yeelight, a brand from Xiaomi.
No one gives a straight answer some say they changed the polling settings on the ZigBee stack, others say they updated the firmware on the ZigBee radio.. just rumours. But at some point they did something as the Xiaomi devices when connected directly to the Hub become very solid and reliable.
1 Like
I don't think ST will ever be a viable return path. A samsung is never going to poor the effort and resources into this particular product that it would need. Look at their quarterly\annual filings....this will never be rightsized for the effort it takes to manage this monster. A higher margins pathway would probably be the only thing that could help, but I really don't see it.
I think several factors is what turned ST into the current situation and to be honest, the same can (might even suggest will) happen to hubitat. Any new development attempts to optimize the organization\reuse that is visible at the moment in time and perhaps a bit ahead. In my history of ALL great commercial platforms, they eventually break down amidst the chaos that comes with growth. Unintentional code "rot" while growth is a formula for bad things. ST had some misturns and over commits...quite common with startups that experience growth. When you factor that with a buyout, turnover, and not getting the right support\focus, it's amazing frankly ST works as well as it does.
There are practical things to be done to continuously rightsize the monstrosity and complexity of code involved with what is home automation today, but to be honest I've not seen a company ever keep the train rolling smoothly with something similar to the complexities of this.
I love the current hubitat state, but I believe the ultimate solution will have to be open source with a good core and a large open source following\participation. There really is no point in going back to ST.
1 Like
In my humble opinion:
The Hubitat Elevation is only 1 year old, and as a result, is somewhat less polished and less mature than other Home Automation alternatives (in particular, things like the Zigbee Stack).
Nonetheless, the company and staff are dedicated and focused on developing and supporting the platform, apparently for the long term, even though I know very little of their financial backing to be in the business for the long term.
The strategic decision to be code compatible with SmartThings was a clever move that allowed it to get started with a HUGE head start.
Furthermore, the decision to emphasize local execution (instead of cloud execution) was designed to overcome the #1 strategic problem of the SmartThings platform.
The one major deficit (IMHO), appears to be the lack of a android/IOS application. This results in two major deficiencies:
-
The lack of native notifications (and text messages) to inform the home owner (e.g. "the garage door is open").
-
The lack of a easy to use input device to input parameters, changes, and presence etc. (e.g. turn on the light in the kitchen when the home owner comes home).
They have gotten around these deficiencies via the following approaches:
a. After the most recent re-write of the UI, it is now possible (given a proper VPN implementation), to use the hub from the internet on the home owner's portable devices.
b. Presence sensing is now possible to be tested and used via the popular Life360 app, and other approaches.
c. Notifications/text messages are now possible via the PushBullet app. (I believe that they have a limit of 10 text messages per day)
d. There are a variety of easy to use "dashboards" that allow control of all Home Automation activities via portable devices (e.g. SharpTools, OpenPanel, etc.)
There is apparently an app in alpha testing that will handle these deficiencies in a direct manner.
While the platform doesn't support the breadth of devices that SmartThings does, it certainly supports the overwhelming majority - more than enough for any complete Home Automation installation.
I know that I'm probably wrong about some items in this summary, but I wrote it to a non-technical individual to explain why I thought the HE platform has a lot of potential and promise, even if it is somewhat immature.
1 Like
I still have ST hub V2 and a few iris plugs there. My 4 xiaomi temp/humid sensors dropping like flies when they are connected to the plugs. I don't think ST is any better than HE on this.
1 Like
I have read this entire thread. While it does take several not so pleasant turns, I am going to address only one thing, which is the title of the thread: Why would you return to SmartThings?
I have been a ST customer for several years. It has certainly had its ups and downs. I started with a few smart bulbs, and worked my way up to a point (unbeknownst to me) where I reached the limit of the number of Zigbee endpoints supported by the hub. Somewhere around 1-1.5 yrs ago, while the ST platform was improving, my reliability was degrading. I tried new things, did research, reworked my rules, etc with limited success. Then I added 8 new bulbs to the party. That pushed me to start thinking my hub was fading, and it was either replace ST or start shopping.
One month ago, I bought an HE, and was overjoyed by the possibilities of local processing, Zigbee group messaging, and so on. I had browsed through the community prior to purchasing, so I thought I knew where the shortcomings were.
Once the HE arrived, I got straight to work adding all of the bulbs on the main level of my home (~30), as well as the motion sensors and the office lights (another 20). As I continued with my setup, things were going OK up to a certain point, then the reliability plummeted. Bulbs were unable to stay connected, and needed reset every day. I tried everything I could think of, and read what felt like every single thread in this community. I even posted a few seeking advice and answers. Based on what I learned, I immediately bought a couple hundred dollars of Iris plugs to help with repeating. This did nothing in HE to help. I would push a button, and 30 seconds later, only 6 of 25 bulbs had turned on. This did not work.
The reality is this: To this point, I have spent 3 weeks and nearly 60 hours working on HE. Only this week did I reach out to Support, and will begin to go through the process of receiving official help with troubleshooting. I have also gone back to ST. I don't have time to deal with resetting bulbs multiple times a day just to have others drop. Things that function at this low of a level create mental anguish for me, and since I work from home, I was constantly reminded of how much work I had ahead of me to continue troubleshooting HE.
Let me be clear. I want HE to work more than anything, and I will spend as much time as necessary communicating with support. The 2nd attempt at using HE will be a controlled experiment that does not cause my home to appear as though it needs an exorcist.
I expected, as I believe every new HE customer should expect, to be able to plug the hub in, attach my devices and go to town making exciting new automation that improves my quality of life, and gives me a sense of pride that "I was able to do that." This expectation should not have to come with a disclaimer about the number of devices, or the makeup of your specific device combinations, but unfortunately it does for me.
Until the day comes that Support gets my hub, or the stack, or the code sorted, I will, with the new repeaters I have added, enjoy the way ST is running sweeter than ever. I can push one button and all of my lights come on every time. Time will tell if this holds true, but I never reached that point with HE. I'm still going to be here, reading the posts, testing, and hoping for the day I get to ditch ST for good.
This is in no way a personal attack on the Hubitat team. I like the direction things are heading. I have no concerns about the future of the company as I do see continual improvement. I like being part of new, exciting products. This one just happens to affect my day to day life too much to go all in until I see that it can perform the way I need it to.
Jon
6 Likes
