Could you elaborate on this Mac + Indigo and HAM bridge solution (URLs, short description…)?
Thanks,
h
Sadly, that’s probably true. ST already missed November app release. They promised monthly releases and until October they kept the schedule. But there was no iPhone app update since Oct. 17th.
Looks like the majority of people who commented are in the ‘yeah this is what we want on paper but it doesn’t deliver right now’ frame of mind and that includes me.
I don’t want to jump ship as no there isn’t another real alternative out there. I have a wink hub but its not as flexible as ST on rules. I don’t mind being a part of the wild west (I am always an early adopter) but I don’t think being able to turn a light bulb on and off reliably is such a tall request.
What also concerns me after the weekend is the local control aspect especially in relation to smoke and CO detection…anything thats related to safety shouldn’t be dependent on an internet connection which is why I am going to buy some nest protects.
Can we get someone to chime in from ST with some kind of road map on whats coming in the future to give us some kind of idea of whats happening with the platform? Specifically whats being done to make the current integrations (Hue etc) much more stable?
I feel compelled to jump into this thread as well. As a former Revolv owner, my move to ST has been both a blessing and a curse. Revolv was limited in what it could do in it’s current release, but it was reliable. No lag, no misfires. Integration with Nest, Sonos, Hue, and Wemo could not have been simpler.
When Revolv stabbed us all in the back (I’m still bitter) I dove headfirst into ST. I’ve dealt with the shortcomings and design shortfalls of the app, I’ve totally embraced and loved this community, and I’ve invested a fair amount of money into the ST ecosystem of products.
But man. To have triggers fire half the time. Lights come on and off randomly. Not even being sensed that I am in my own house. The list goes on, and as time passes, it only seems to be worsening.
I’m holding out for 2.0 - I’m holding out for the hope that Samsung was smart enough to dump piles of money into ST and ST is smart enough to listen to their customers. I don’t want, I NEED a hub that is NOT dependent on an internet connection. I NEED an app that makes sense.
Most of all, I NEED and WANT a system that works.
4 Likes
This discussion reminds me of what a professor said about Unix way back in the ancient 90s when I was in school:
Unix is the worst operating system in the world… except for all the others.
What he meant was that Unix had it’s fair share of problems. There were plenty of things to dislike about it. But, every operating system had it’s problems… and most of them significantly more than Unix did back then. Plus the upside of Unix out distanced all the other OSes as well.
That’s how I feel about ST right now. It’s by no means perfect. But as others have said here: There is no perfect HA system right now. Some might be much more solid than ST as far as dependability goes, but lack flexibility. Some might be flexible but have even less support or dependability than ST.
ST isn’t perfect… far from it. But it’s pretty good and has the promise to get even better. I like the system a lot right now. That doesn’t mean I won’t investigate other options if someone points one out that’s really good. But given the level that HA in general is at right now, I think ST is the best option; or rather, it’s the worst option…except for all the others.
1 Like
Good points. I think most of us think SmartThings is the best solution in the long run regardless of the problems now.
1 Like
Just wanted to add my .02
Was probably the right IP at one time but your router assigned a new IP. For anything you do over IP I would recommend setting a static IP. This is not SmartThings fault, its the nature of doing local IP based communication.
Sounds like a mesh issue. I would recommend a Zigbee range extender. I had the same issue, added one of these and my lights work great now. Again not something SmartThings can directly improve.
This has a lot to do with Nest. Not saying its all nest just that there is push and pull from both sides. SmartThings is working on it, but one of STs major concerns is security. The best question to ask is, does Nest’s security in the API meet STs penetration tests? It may not? But it could. I say this just to illustrate a point that STs doesn’t just hack together some code and put it out. They do many many weeks/months of testing. I am ok with this. I would hate for STs to be lazy with testing and then find out later that something bad happened to someone because the nest API isn’t secure.
2 Likes
Good points but it did have a static IP for the hub. I think I need to rebuild my network.
Which range extender did you go for as this may be a good option?
Hmmm I see what you are saying with the Nest integration. I guess the community based solutions are not API based or ST wouldn’t really be happy having those around if there was a security issue?
Honestly its a love hate thing with me and ST
Totally get it. Sometimes there is so much negative be thrown around though that I just like to highlight the positives too. That way when someone comes along to read this they aren’t poisoned by all the emotion tied to this thread and others like it.
They are based on a “unofficial” API that didn’t exist but it did, maybe, in the dark recesses of the internet. LOL. JK. But seriously it was half backed API from nest so it doesn’t work because there was nothing really good to tie it into to begin with. STs doesn’t care about the community solutions. There is no risk for them there. The risk is on the person who created the app.
You assigned the static ID for the MAC at the router level? If you used the app to do it the router will still give it a new IP lol. Home networking sucks lol.
Any “powered” device should act as a repeater. I don’t know if the ZigBee LightLink stuff does it or not, but in my experience it seems not to. You should be able to add a Zigbee lamp switch to your setup to help the mesh. Thats what i did.
Indigo is HA software for the Mac. HAM Bridge is an HTTP bridge to running scripts on the Mac.
I have been using Indigo for over a decade and it has been rock solid, but wanted to play with more internet integration, and Zigbee (Hues mostly), so went with SmartThings. Problem is SmartThings Hue integration is not up to snuff so I started controlling scenes via the Hue API from my Mac. I use some SmartApps I created to communicate with the Mac.
Also, Indigo has no Android app, but the SmartThings app is so slow and painful, it makes a lousy remote (internet or local). I ended up using iRule for mobile device control, with HAM Bridge as the gateway to the Mac/Indigo. And even though I wrote a perfectly functioning device-type for my Venstar thermostats in SmartThings, I have pretty much moved control of that over to the Mac as well.
At this point, most of the ‘things’ that are triggered in SmartThings are sending commands to HAM Bridge.
Both Indigo and Universal Devices ISY series are tried and true, rock solid solutions for HA, so it is not that there aren’t good alternatives to SmartThings. I was hoping that going the SmartThings route would simplify things but that has clearly not been the case so far.
Thanks!
I will take a look at Indigo as well as iRule! Looks interesting! The ST iOS App is OK but flaky and a bit confusing and messy in terms of UI. It is also painfully slow. I wish ST would make the app open source. I am an iOS dev and would love to contribute to the App…
Well, actually, it IS SmartThings’ fault.
As you’ve pointed out, this is the nature of doing local IP based communication, and dynamic IP addressing has been around for many years. It is the de-facto standard used in the consumer space and for good reason. It is unreasonable to expect the average consumer to know or learn how to reserve IP addresses on their DHCP provider based upon MAC addresses.
If you are going to sell a product into the consumer space which is meant to integrate with other consumer products over an IP network and is meant to be installed, configured and managed by that consumer, then you need to:
-
Work with those products in their default configuration in a consumer environment (dynamic IP addressing and the dynamic discovery methods those products support, e.g. UPNP, MDNS / Bonjour, etc.)
OR
-
Provide exceptionally clear documentation on what needs to be configured and the support services to back that up to allow consumers to manage their networks with static IP addressing.
If you think through the actual ramifications and requirements for option 2 I think you’ll quickly come to understand why every manufacturer in the consumer space opts for option 1.
Don’t get me wrong, I have no problem managing static IP addresses myself. I’ve been working with data networks for over twenty five years and was already using reserved addresses on my network before SmartThings was even in Kickstarter. But just because we early adopters are extremely comfortable with this technology does not excuse SmartThings from doing things properly rather than taking shortcuts. Whilst shortcuts may give US (the early adopter) more product integrations more quickly in the short term, in the longer term it will be far more harmful to both SmartThings and ourselves as average consumers dismiss the product as too unstable, too hard, etc. and we miss out on the benefits that widespread adoption would have brought.
Hopefully Hub v2, with its expanded resources and re-architecting of communications, provides the opportunity to remedy the currently parlous state of support for dynamic addressing and dynamic discovery.
If you have zigbee devices I don’t think indigo is an option. I don’t think they support zigbee but if you are all zwave it might be worth a look (they also support insteon). No experience with it myself but I was looking at their web page when I was at my most frustrated with ST. 
Agreed. Question is does the Hue hub allow for this? Maybe it does… but also maybe it doesn’t.
I’m not familiar enough to know for sure or motivated enough to find out.
The support team is amazing. Althought the documentation could be better.
1 Like
Correct; the exception being Hue and GE Link lamps as they can be controlled via the Hue hub’s API (which supports many things the SmartThings integration does not - flashing, color cycling, transition times and groups).
It seems to me a lot of people put too much faith and hope into V2.0 hub. Yes, we’ve been promised Bluetooth LE, USB host port and “some” local functionality, but I’d rather keep my expectations fairly low to avoid disappointment. The new hub, when and if it comes, will most like bring its own problems and it’ll take months and multiple firmware upgrades to iron out major bugs. If you think otherwise, you probably have not worked in the hi-tech industry.
3 Likes
Agreed, especially in the context of this thread. In my humble opinion, “up and down” issue can be addressed in the existing hub. I would also argue performance. Haven’t we all tapped a switch and instantly a light goes on even though it goes to the cloud and back? Why can’t it be consistent? It can, but SmartThings doesn’t have the expertise to pull it off yet.
Distributing more of the control locally in Hub 2 brings new problems such as synchronization and queue management. Yes more devices will connect because of additional radios, but don’t count on Hub 2 as the answer to performance, reliability and robustness.
@scottinpollock @Linda While we mention hues here, the log clearly shows that ST definitely polls the hues every five minutes then how come it does not update the state. What I fail to understand is if Logitech Harmony Home remote can get the right status, then probably anybody can. I luv the app OnSwitch and use it for Christmas colors on my hues and it detects all the bulbs every time irrespective and all 13 of them turns on like that instantly.
1 Like
I am pretty sure polling has been screwed up for a long time.
2 Likes
Both the Phillips Hue and Sonos systems natively use UPNP to operate in a dynamic IP environment. It seems both systems currently require you to use static reserved IP addresses if you want stable operation with SmartThings. (This is certainly the case for Sonos, which I have).
I’m not faulting the support team, but I also don’t believe they (or many much larger teams) would want to take on the task of supporting a large customer base with discovering MAC addresses and reconfiguring the myriad of third party router models out there, especially as the demographic centroid of that customer base moves further and further from the technically proficient early adopter.