For anyone interested, here’s a link to whatever open-source software is used in SmartThings hub:
Impossible is nothing.
I read the EULA for everything I’m considering buying before I buy it. I also read the users manual, including all the fine print. And I look up the FCC licenses. And I remember most of that because I’m weird.
Your SmartThings TOU, which you agreed to when you created a smartthings account, included the following:
You represent, warrant, and agree that you will not contribute any User Submission (as defined below) or otherwise use the Services or interact with the Services in a manner that:
Decompiles, reverse engineers, or otherwise attempts to obtain the source code of the Services (except (i) for sample or tutorial code examples that we provide on the Services which are clearly marked as such, or (ii) to the extent such restriction is prohibited by applicable law).
People usually read too much into the TOU’s. Yes, it’s a contract, but contracts are meant to be breached. The question one should ask is what is the implication of breaching a contract? In any civil lawsuit, the onus is on the plaintiff to prove damages to the court and the remediation is usually limited by the amount of actual damages, except for extreme cases, where the court may award punitive damages. So, yeah you’d breach a contract by reverse engineering the protocol or the software and thus you’d terminate your warranty and the company may terminate your account according to TOU. But no one is going to sue you unless there’s hundreds of thousands of dollars to be made in legal fees for the army of hungry lawyers.
[usual “I’m not a lawyer, don’t take my opinion seriously” disclosure]
I think that if you reverse engineer the whole thing, or even part of the entire platform, and come up with GekoThings that somehow magically interacts with the ST hub, they’re gonna come and sue you.
If you come up with a similar setup that uses the GekoHub and behaves slightly alike, unless they have some of these parts patented and can dissect your code to see that it’s the same, then you’re probably safe.
He-he… Don’t be so sure. It’s been done before. Here’s a good read for you:
Sure…in the 1980s.
US laws have changed significantly since then, and now specifically address reverse engineering, which they did not when Compaq was founded.
But again, there’s a difference between something that someone reverse engineers and then sells on the open market and something that someone does for their own use or solely for the purpose of building an integration.
If you proxy all the calls you will lose the functionality of the mobile app.
True, but like I said this could be simply a backup option, for those times when there’s an outage.
And during those times the mobile app is dead in the water anyway.
I try to run as much locally through smart lighting, so when there is an outage the majority of my rules still execute. Hopefully ST will start expand more local processing.
It would still be a proxy, that will forward calls to see if ST is live, if not then send back the mock response. it would increase latency and would be another point of failure.
With the last outage the the biggest issue I had was the inability to disable smart Alarm. Luckily my siren was disconnected a few days before.
Well overall you could argue that some backup is better than no backup though.
I can certainly envision a setup where you would check if ST is up every few minutes, and only intervene if it’s not. At that point there would be no latency and you significantly reduce your exposure during an outage.
I would also point out that in your case you were lucky to have dodged the inconvenience, but it came at the cost of actually disabling the siren before the outage. Plus your situation might not reflect the great majority of people that don’t have a lot of items using local processing today.
You also have to consider the worst case scenario. What will happen when SmartThings shuts down the cloud like Revolv or TCP did?
I have, and use mostly z-wave light switches. Worse case I have to use my hand. Cloud outages are an annoyance, but not the end of the world.
Using non-proprietary devices will allow me to migrate to a new platform.
Not the end of the world, sure. But when it comes to home automation, I want it to be predictable at least. With ST, when something does not work, you’re left guessing what the heck is it. Is it your device, RF, Internet, cloud, or is it some hack at ST pushed the commit button too early? Sure, Echo integration is cool, but I’m willing to trade it for a predictable platform.
I’m not willing to give up Echo integration, but then I haven’t had to.
What I have given up is the idea that every single use case for every single device will be controllable through echo.
This one is pretty interesting, albeit a little hard to figure out. If I weren’t so invested in ST and had more personal time I’d go full in on this system.
The yaml is gonna change your mind real quick…
That’s one of the advantages of ST, which has led to wider adoption and in turn more integrations and more functionality.
When you see something like this:
automation: - alias: Set Foscam to Away Mode when I leave home trigger: platform: state entity_id: group.family from: 'home' action: service: script.foscam_on
And the script itself has a call to curl to get the URL to turn the foscam camera on, and the fact that a single white space can throw the whole thing off…
I understand the potential, but it’s just nasty to deal with for Average Joe, so it always remains the domain of hobbyists and hardcore hacker types
that’s an interesting problem description. I recently encounter a similar condition almost every time that I ask “Alexa, Turn On TV Mode” (then Alexa says “OK” and the first command works), then I ask “Alexa, Turn On TV Mode” (yes the same thing). And she usually says “That command does not work on that device” for the second attempt to turn the system on.
I wonder if you are issuing the same command multiple times as I have above. I surmised that Alexa or ST thought the “TV Mode” virtual switch was already on, so one of them refused to send a redundant command.
My Alexa has never failed. It’s scary. ST has been good to me but not great. Alexa to ST has been perfect so far a couple months in. I realize it depends on ST.