Aaahhh... ok. I read it like it was a life or death situation. Good to know.
Agree completely. Nothing in my home doesn't either operate stand-alone, and control is extended to the HE hub, or can't be controlled without the hub.
1 Like
Yes I fully understand all that and do agree with you! These should NOT be used for critical systems except when they are.. or people think they should be because they can do it..
If your HA hub supports critical devices like water main shutoff valves, smoke alarms etc it seems like you could be exposed to some liability regardless I dunno..
1 Like
I most certainly think it does open companies up to litigation that could bankrupt the small ones. I'm pretty sure that even the systems like Nest Protect and LeakSmart for example, that are designed to protect your life, property or both, also have disclaimers that prevent you from taking legal action against them if their devices fail to notify you or function as expected.
Everyone knows I'm one of the most vocal regarding zigbee and special regarding Xiaomi devices. I had never had this questions raised in ST. If a device works in a given system it should work on others as well. If other systems have customized their zigbee stack to support this means there is still work from HE to improve on.
As Jason said disable app or driver code is not a solution.
Because incompatible code can be either in both sides.
A certain routine/class (even though is properly coded) can trigger a failure on the native code.
If you disable the custom code obviously the fault will disappear however it still lays there dorment on the native code.
How many hacktons companies run to discover fails on their code. Look at Google.
This does not mean that there isn't very poorly written code but as said Developers need tools to properly debug such failures.
I have mentioned before that proper documentation needs to be developed for HE. Don't ask people to use ST guidelines and than say that they have bad code for HE.
Lastly user experience, as expected, is still on the back seat with HE.
They are a young platform but after over a year is already expected that their MVP (Minimum Viable Product) start to incorporate customer experience into account.
What they partially do but just for a tiny segment of the market that is the early adopters/Power users. They need to bridge these gap and start working towards mass adoptation this year if they want to be successful otherwise the market will move to the next thing.
From all the posts I have read in almost every HA platform the same expectations come to mind:
- Plug and Play devices
- Easy of use interface, notifications, alerts.
- Easy rule setup.
- Friendly development API/3rd Party integration.
Let's give HE time. But they need to be conscious that the next best thing can be at corner.
5 Likes
This is true and one of reasons why most companies don't deploy certain products in EU. Certain EU regulations in particular situations has such clauses declared as voided.
Sure but there are higher priority items on their list as well. It's just a matter of what's important to you most. To me, I like to have reliable xiaomi devices on HE too but I rather have a nicer dashboard.
I am curious who really likes to set up their home automation system on a phone? Not trying to be inflammatory but I have always thought SmartThings was extremely limited by not having a web app. That is the one thing I LOVE about Hubitat, I don't have to use my phone for it at all.
10 Likes
I have found ST to be less “buggy” compared to Hubitat...I would like to say that Hubitat is more reliable but I had the Hub crash twice in my simple setup. Hence, I find Hubitat and ST to be equivalent in reliability.
I might go back to ST for the following reasons
- WebCore
- Issues with August Lock Intergration
- Issues with Homebridge
- Unable to password protect specific tile on dashboard
- No mobile app yet
- Unable to use Iris Keypad in Rule Machine to receive codes and run actions accordingly
I think I would prefer HE to concentrate on (seemingly) systemic device/protocol/rule instabilities before UI changes but that's just me..
5 Likes
I agree completely. I hate setting things up in an app, and I have always disliked and criticized the SmartThings app. It is without question on of the worst apps I've ever used.
2 Likes
Well when I had to reset everything - it was a whole lot easier to use the phone and the web interface to walk around and pair everything again.
1 Like
My Surface Go tablet worked great for that
2 Likes
What? Pull up the UI on your phone. It's very simple.
1 Like
My priorities are particular regarding coding.
- Better Driver/Devices support.
- Better rule engine.
The rest is behind, but not very far behind.
1 Like
Yep thats what I did - it was very helpful. Also using the Aeotec Z stick to exclude stuff after the factory reset.
No complaints on having a web interface - I have a VPN so can even access remotely.
1 Like
True. The disabling of the app is not the solution. Its the step in troubleshooting. If you disable the app and things work properly again, then the user needs to go back to the developer of the app for them to troubleshoot their code. If the developer finds an issue with the HE side then they can raise a ticket to work with the HE team to get that fixed. The problem is that the HE support team can't go through all of the custom code to troubleshoot issues.
It was nice of them though to point out some problem apps. They probably know why its a problem but its the developers responsibility to fix it.
1 Like
Not seeing your point how these things directly relate to reliability.
• WebCore is a choice, not a feature of HE. Wouldn't you agree?
• August lock isn't supported by ST or has that now been added?
• Homebridge isn't a supported workflow on either platform. Not an HE bug.
• A missing feature in dashboard is a missing feature, not a bug.
• The mobile app will come. Up to you how important it is or will be. Again, not a bug though.
How do expect the developer to troubleshoot if the only thing that they know is that there was a conflict? No more data?!
Since I am the one who wrote the post about returning to SmartThings, I am going to assume that you are directing that statement to me. If not, I apologize but with all due respect , I've got 5 years in this space, 3 of which with SmartThings, 2 with Iris before that. I'm not romanticizing anything. Those are my findings based on hundreds of hours of testing SmartThings, Iris, and Hubitat since December.
This one was obviously directed at me. I'm going to go out on a limb and say you do not have any kind of real engineering background. In QA testing, you test as many scenarios as you can envision, even ones in which the system is being used in a way that it was not intended to. That kind of testing is known as "stress testing" where tests of specific limitations, conditions, or parameters of a particular system are tested until the break and the results are collected for analysis.
It appears that you have decided to cherry picking facts. If you had actually taken time to read all of my posts, you would see my first migration to Hubitat from Smartthings was over a 2 week period. That is a very reasonable time period for a system the size of mine.
So here are the facts, obtained through testing, analysis, and re-testing... I observed absolutely no issues with the mesh after moving the exact same 43 target test devices, left in the exact same locations to either the Iris Hub or SmartThings hubs. One set of tests was done at a normal pace over a 8 hour day. The second test was done as quickly as possible. In either test case, the end result of a stable mesh was easily obtained by both the SmartThings and Iris hubs. In each case the meshes were stable for 24 hours after initial formation. Hubitat was the only hub in which I could not build a stable Zigbee mesh, first over a 2 week period, then over a 8 hour period, then as fast as the hub would let me add devices. All of those data points lead to a single conclusion.... It was NOT my environment or device selection...
How do you know it does work? Are you aware of every scenario out there?? And if they doesn't fall into your view, then you accuse user of being deceptive since they cannot achieve the results that you think they should? All I can say is spoken like a true cheerleader....
How about this explanation... There is a confirmed problem with the Hubitat Zigbee stack. I have Wireshark captures to back that statement up and have an acknowledgement from Chuck to the same. Those capture show that the hub is not always consistently sending out route discovery requests as it should. Why? Who knows.. I will say that I am currently testing some Zigbee stack config changes that are so far having a positive effect, although stopping short at completely fixing the issue.
But this all must be the users fault, right?
6 Likes
