Yeah… I’m very close to throwing in the towel and setting up a DMZ for a RPi with a server as a proxy to my LAN.
1 Like
If you want to interpret it that way, yes. (runs for cover, dodging tomatoes)
I bought ST for what it can do now. I see the bluetooth possibility and am hopeful, but its existence as a possible future expansion has zero to do with why I opted, just a few months ago, to invest it Smartthings.
My point was, that for many of us that have been with SmartThings for years, much of what it does for us today was not possible out of the box when we got started. One of the “Major Promises” of the platform was its openness and the ability to design device handlers and SmartApps with the supplied development tools, and that experimental features initially offered and advertised, would evolve.
I actually built an ‘infrequent polling’ device type for MyQ based on Adam Heinmiller’s original code, but withdrew last year after discovering it was using an unofficial API, and hearing from SmartThings that an official integration was coming. In the meantime I have jury rigged something to meet my needs, but IMHO, that doesn’t let SmartThings off the hook.
Why not just fix the app so that it doesn’t have bad behavior?
I did, by eliminating the polling using a multi-sensor to determine when the door had stopped moving. But that didn’t change the fact that I was using unauthorized access to an unofficial API (which is against their TOS).
Additionally, this API was documented elsewhere on the net, and used by many that were not involved with SmartThings. Who knows how many other implementations were pounding their servers.
Interesting. Thanks for chiming in again, I appreciate it. Just really bummed since this app actually worked without fuss - seemingly a rare thing on this platform.
Looked into the GoControl/Linear solution and its not compatable with my MyQ Liftmaster. I am guessing most modern myQ enabled garage door solutions fall into this category.
http://www.nortekcontrol.com/info/Linear-GD00Z-Product-Compatibility-Notice.pdf
If ST was putting a high load on the servers, though an unofficial API, then why wouldn’t they kill it immediately.? Everywhere I have been that is how we handled it.
If Chamberlain really just wanted to shut the door (no pun intended) on this, why would they give ST and us any notice at all? They could have simply blocked the ST cloud IPs and been done with it.
I have a hunch this is all more complicated than it seems (as is the case with most business negotiations).
The frustrating thing about all of this for me is that ST continues to rely on voulenteer community developers to create and support key functions of their platform. It’s not right to use “openness” as an excuse for slow development. At some point, ST will have to step up to the plate and deal with these themselves. It’s a dangerous game they’re playing.
1 Like
I have to agree - right now ST has a stronghold in my house but there are factions trying to move to Apple’s HomeKit…if it ever really arrives/takesoff.
May the Game of Things be in your favor! (Man, I mucked this one up, I was going for game of thrones reference and ended up with hunger games…D’oh!)
For everyone, go to the Chamberlain web site https://myqcommunity.chamberlain.com/chamberlainmyq/topics/open-letter-to-the-myq-community?utm_source=notification&utm_medium=email&utm_campaign=new_comment&utm_content=reply_button&reply[id]=16864830#reply_16864830
and read about Chamberlain and Homekit, still years behind. Forget using Chamberlain for anything. They yes you to death and deliver NOTHING. Glad I found this info about other brands that actually work, and the company that makes it, understand what the word WORKS mean. Chamberlain is the worst company ever !
1 Like
First note Chamberlain does not care about its customers, read about Homekit https://myqcommunity.chamberlain.com/chamberlainmyq/topics/open-letter-to-the-myq-community?utm_source=notification&utm_medium=email&utm_campaign=new_comment&utm_content=reply_button&reply[id]=16864830#reply_16864830
second: read the first again
third: read the Chamberlain web site about Homekit
Fouth: go to something that works.
1 Like
Because “bad behavior”, to Chamberlain’s rules, will likely forbid most SmartApps and other interconnection like Amazon Echo Alexa (even if only via a Virtual Switch or other non-trivial hack). Chamberlain (and Nest) want significant restrictions on how their products can be used, irregardless of any kind of cloud overloading or lack thereof — and are making SmartThings enforce these restrictions which is not currently possible!
1 Like
Just opened my doors using the ST app. Also sue ST each day to close the door when I leave the ST geofence, and my wife uses if to open hers (hit or miss but mostly due to her phone not being a reliable proximity sensor.
So the question still is: Are they closing the IP door, or disabling new access?
Sounds like they are going to block ST’s IP address range. So it will be for everyone.
First off Samsung had Ecobee 3’s displayed at their product booths and Ecobee had SmartThings listed on their website as “officially supported” for 6+ months before any official device was released. Its why I bought both to find out it wasn’t really supported. Secondly yvesracine charges for his app (which is way overly complex). I shouldn’t have to buy two products that are listed as officially supported by each other then pay more for someone elses program that makes them actually talk. If they never said they worked together it would be a different story but both companies advertised each other which is false advertisement. Thankfully @StrykerSKS wrote a device/app that was free, easier then yvesracine, and still better then the “official” EcoBee 3 device that was finally released a month or so ago.
And whats the point of Community developed devices and apps if they stop working like this one? Can’t someone at SmartThings look at all the holes/gaps in their official devices/apps and start pulling community ones in and making them official and improving on them? I’m sure there are a lot of users, maybe even half, that have never installed a community app because they don’t know how and on the same token aren’t expanding or even buying in the first place because what they want to control isn’t on the official support list and they don’t know about the community apps.
-Allan
2 Likes
That’s why I keep emphasizing to @Tyler that there really is a need for the platform to support multiple published DTHs for a single manufacturer-model of device: Customers have different opinions, preferences, and needs. Some value the features from @yvesracine’s and don’t mind its complexity, and others will prefer @StrykerSKS’s, and others prefer something coded by SmartThings.
Give customers the choice!
Oh is is far, far, far, far less than half of all users. This is where the “30,000 Developers” number comes from … anyone that has used the IDE to “publish for me” at least one DTH or SmartApp. I think that’s less than 10% of SmartThings’s Customers. I have read a hundred times that folks want an “official” Device Type – but we know that some would be satisfied with any “published” Device Type … does “published” == “official”?
So I totally agree that SmartThings critically needs to ramp up its ability to approve publication requests (resources and efficiency) for both DTHs and SmartApps; and we all know that this ought to lighten the workload on SmartThings because they will save on their own development efforts if the Community code is sufficient (or better!).
In the case of MyQ, though, the Community DTH (actually, the API it was using) was shutdown by Chamberlain (not SmartThings). SmartThings can’t just refine and publish that DTH because Chamberlain wants feature restrictions on it that are currently not in the platform’s architecture.
1 Like
Me neither, google accounts fail to logon…
While the various security complaints make some sense, IMO the “polling load” is a cop out. All that needed to be done was to remove the polling in the SmartApp and require some kind of trigger to force a refresh. @copyninja already implemented that via the contact/acceleration sensor support. Then, instead of each user polling their servers every 5 minutes each user would likely only poll their servers a handful of times per day. This would be similar load to what the iOS app does (as it polls every 10 seconds but only while it is the active app). Even if a user polled 20-30 times in a day, this would be a dramatic reduction from the 144 times/day.
This whole “unofficial API” stuff is bogus too. The SmartApp was hitting the exact same API endpoints the official iOS/Android apps hit. The only thing that was unofficial was that it was using the iOS MyQApplicationId vs one that had been “officially assigned”. If there was a way for the app to execute requests from the hub’s IP address vs the ST servers, Chamberlain would likely be unable to determine which came from an official app vs the ST integration.
Right, but there’s no way for SmartThings to enforce that its users update to the latest code. My MyQ code was probably 8-9 versions behind the latest.
@vseven, unless you’re part of my list of contributors, I do not see how you can judge if my device is more or less complex than the ST stock device or any other “open-source” solutions.
My ecobee device has a Service Manager (just like the ST device with EcobeeConnect), so it takes basically less than 5 minutes to set up when you’re familiar with the IDE.
And, as soon as ST has its own appstore, then the setup will take no more time than the ST stock device.
Also, your complexity assessment may come from the fact that MyEcobee device is feature complete (contrary to other ecobee implementation).
I have more features than any ecobee device implementation on ST, so (naturally) there are more options and more smartapps available…
Some users may just want to change their thermostat’s setpoints, and the ST stock device implementation is just enough to do so.
Others may want:
- Set their thermostat to away or present based on their ST hello mode
- Schedule some custom climate/program at a given day and time
- Control their humidity level inside their home
- Use the ‘free cooling’ feature to save some energy
- Orchestrate their smart vents in conjunction with their thermostats’ setpoints in order to
direct more airflow to their colder/hotter rooms - Change their Minimum Fan Time value based on their current climate/program
And much more…
Usually, each use case has a specific smartapp, so my contributors can pick and choose the smartapps that they really need…
Regards.
2 Likes