Obviously “Device handlers” aren’t gonna cut it. Isn’t AllJoyn supposed to be the “solution” to the IoT interoperability nightmare? Wouldn’t AllJoyn support negate the need for having to create device handlers for each and every gadget that wants to work with the SmartThings platform?
Probably not alljoyn, for a bunch of different technical reasons. It’s been available since 2016 and has very few certified devices so far.
Insteon announced a alljoyn – compatible version of their hub at the same time they announced the HomeKit version, which they still make. They sold a few of the alljoyn ones, but not many, and discontinued the line after two or three years.
https://www.insteon.com/insteon-hub-alljoyn
The Simple Deployment Winner for Now: Amazon Echo
The closest thing that’s actually being practically deployed in a significant number of global households is Amazon Echo. “Echo, discover new devices” works quite well with more and more brands every day, and has become something that many consumers look for before they buy something new. And it even works with inexpensive third-party brands like some of the Chinese manufacturers. Amazon’s customer support is also quite good.
And it can also work as a “ Man in the middle“ for otherwise incompatible devices, something that many community members are taking advantage of:
Ship a Kit options: good for home security, but may not be flexible enough for a Home Automation
What manufacturers creating systems for the DIY security market Have always done is to send you a kit of preconfigured devices to limit first time install headaches. And to strictly limit the specific brand/models that will work with their system. That tends to work OK for security systems where you have a limited number of use cases, but not for Home Automation.
HomeKit: works well for some people
If you’re willing to go to a “walled garden” ecosystem and you use iOS devices, HomeKit has been very successful in making it super easy to add devices from different brands as long as they are all HomeKit certified. And they have been improving features and device selection over time, although it’s still a small selection compared to what smartthings supports. but it’s good enough for a lot of people, particularly those who are already using iOS devices, and right now, you can do more complex logic then you can with the echo platform. And both of these platforms continue to add new features regularly.
Initially, the biggest negative with HomeKit was that very few manufacturers could meet the HomeKit requirement and those are usually expensive brands.
But after Apple changed the certifying requirements, We are starting to see more manufacturers and some budget brands like Xioami and TPlink and KooGeek and IKEA jumping on board.
certified “works with smartthings“ devices
It’s also important to remember that smartthings staff have said multiple times, including in this forum, that their typical customer has 15 or fewer devices and never uses any custom code. If you limit yourself to the devices on the official “works with SmartThings” list and you are using the new app, then installation is pretty simple. Not as good as Echo, and not quite as good as HomeKit, but much better than the old system.
The Future of Open Standards like AllJoyn, Dot Dot, Thread, etc
There are a lot of big open standards initiatives underway, and most of the big manufacturers, including Samsung, join the working groups, but they never really go anywhere. Look, it’s 2019, and we don’t even have a universal power cord standard.
At the end of the day, these guys compete against each other, and they all have their own reasons for choosing particular features.
The most effective way to get universal standards is doing it from the consumer demand side. That’s what has happened with the echo. Over 100 million echo devices have been sold worldwide, and those customers want to see “works with Alexa” in the product description. It’s been happening with big manufacturers and little manufacturers and big Chinese manufacturers you’ve never heard of in the US. At all price points.
So that’s a good trend, and I think we will see more of it going forward. But not coming out of the initiative projects.
Amazon Echo has been great for Zigbee and generating interest in IoT in general but aside from that every non Zigbee “works with Alexa” device is proprietary in the sense that it’s only guaranteed to work with Amazon’s API.
Sure, but the point is that neither the customers nor the manufacturers care about that.
And I’m pretty sure that Amazon doesn’t require that you own an Alexa device to use their app, so the “man in the middle” integration would be free. But even if they do require that you own a device, the Echo Dot goes on sale multiple times a year for around $30.
So very low barrier to entry, huge manufacturer incentive to participate, and high end consumer satisfaction.
It’s not an official open standard, but it’s a very popular alternative.
It’s not an official open standard
It’s been my observation that “works with Alexa” is a very broad “standard.” I’ve got smart blinds that “work with Alexa” that only work in the context of an awkward Alexa skill and don’t actually show up as smart home devices in Alexa so that they can work with Alexa Routines. It would be nice if Amazon would tighten the requirements for devices to claim they “work with Alexa,” especially now that the Alexa smart home functionality has matured a bit.
And I’m pretty sure that Amazon doesn’t require that you own an Alexa device to use their app, so the “man in the middle” integration would be free.
That’s an interesting take. I hadn’t thought of that. In other words, so long as SmartThings can talk to Alexa’s API then anything that works with Alexa’s API can in theory work with SmartThings. It’s a Rube Goldberg to be sure but an interesting thought nonetheless.
Come to think of it, any cloud to cloud integration feels like a precarious Rube Goldberg which means many of the “works with SmartThings” devices that aren’t either Z-Wave or Zigbee are by default Rube Goldbergs. I suppose that’s the real problem. In 2019 IoT is one big Rube Goldberg held together by precarious proprietary cloud to cloud integrations.
In 2019 IoT is one big Rube Goldberg held together by precarious proprietary cloud to cloud integrations.
Why do you assume they are “precarious”?
I’m serious here.
The most critical and ubiquitous functions of the internet are, literally, “cloud-to-cloud” integrations.
How the heck do you think an email gets from a sender’s Gmail Account to the recipient’s Hotmail Account? How does a Netflix (or any online vendor) receive payments from their customers’ credit cards? How do millions of Wyze Cam subscribers get alerts and receive their video feeds instantaneously on their smartphones (hint: Wyze doesn’t run their own video streaming cloud; they don’t even directly use AWS - they use a 3rd party wholesale video streaming / hosting provider…'s cloud).
There is nothing inherently wrong with cloud-to-cloud integration.
Does it make sense that 1, 2, or “n” clouds are involved in activating a lightbulb that is 4 feet away from a motion sensor? No… but, 90+% of the time it actually works.
Does it make sense that the same light can be activated when a particular smartphone tells the SmartThings Cloud that it has crossed into the geo-presence area (as assisted, by the way, by the Google Location Services Cloud which uses knowledge of WiFi access points to increase speed and accuracy)? Absolutely.
In other words: There’s nothing inherently wrong with clouds. But there’s nothing inherently wrong with increasing fully-local-execution capability and compatibility for efficiency and reliability. I question whether or not this can be done without actually increasing complexity, though. The industry just doesn’t have it’s act together.
It used to. As far as I know, “local association” was (and still is) a fundamental feature of Z-Wave and ZigBee. Too bad the platforms aren’t leveraging it.
@tgauchat
Zigbee has association? How does that work?
I was not aware of this!!!
I have zwave association for some 3 way light switches.
Can I use zigbee association with 2 Ge zigbee in wall switches?
Why do you assume they are “precarious”?
Unless you or anyone else can prove that (insert vendor here) is committed to providing API access to their cloud for the foreseeable future it’s precarious. They are under no obligation to keep their cloud API’s available. The moment it doesn’t make financial sense they can and WILL stop providing access and then all of a sudden that cloud enabled outlet you purchased will become a great doorstop. That’s exactly what happend to users using the WiFi interface of the Halo Smoke Alarm not to long ago. Since I access the Halo Smoke Alarm via Zigbee I’m unaffected and continue to use my Halo smoke alarm to this day.
Is it going to happen anytime soon? I don’t know. It might but then again it might not. My point is that without standards and local connectivity options we’re all at the mercy of the cloud.
How the heck do you think an email gets from a sender’s Gmail Account to the recipient’s Hotmail Account?
SMTP - Simple mail transport protocol. It’s a STANDARD that’s been around since the early 80’s. I can setup an SMTP server from my living room couch if I wanted and be able to send and receive email. That’s the beauty of standards. That’s 40 year old technology that’s still in use today and regardless if Google and Hotmail are around in 40 years I can count on the fact that if SMTP is still in use, I’ll be able to send email 40 years from now Google or no Google.
How does a Netflix (or any online vendor) receive payments from their customers’ credit cards?
I’ll tell you what they DON’T DO and that’s build proprietary connections to each and every financial institution they want to do business with.
Wyze doesn’t run their own video streaming cloud; they don’t even directly use AWS - they use a 3rd party wholesale video streaming / hosting provider…'s cloud
And when they decide it’s not profitable anymore they’ll shut the service down and all of sudden notifications and video feeds don’t work anymore.
Does it make sense that the same light can be activated when a particular smartphone tells the SmartThings Cloud that it has crossed into the geo-presence area (as assisted, by the way, by the Google Location Services Cloud which uses knowledge of WiFi access points to increase speed and accuracy)? Absolutely.
Currently we’re reliant the cloud for that. But if it were standards based your phone would reach out to the light bulb directly and turn it on when it found it was within the geo referenced area. That’s where AllJoyn comes into play.
There’s nothing inherently wrong with clouds.
I agree. I do use SmartThings after all. but there needs to be a fail-safe in the form of standards for when the inevitable happens so you and I can still control our devices 40 years from now. It’s one thing to be able to CHOOSE to use the cloud versus being FORCED to use the proprietary cloud API.
If you don’t think it can happen here’s a few notable examples:
Halo Smoke Labs, the maker of the IoT smoke alarm left all their WiFi cloud users in a lurch when they went belly up. Users accessing their smoke alarm via zigbee are unaffected
Logitech tried to force everyone to use their cloud by disabling the standard XMPP interface on their Harmony remotes. Fortunately sanity prevailed and they did a 180 and re-enabled local access.
CinemaNow suddenly shuts down leaving users unable to access their movies.
The cloud based Ultra Violet Movie cloud locker is closing down. Fortunately users didn’t lose movies in the process but they did lose the ability to share movies with friends and family.
You’ve definitely pointed out genuine risks of dependency on Cloud services to access one’s own devices.
But consumers have not demanded isolation / protection from those risks - despite the real-life examples.
The opposite - in fact: Wyze Labs is growing at an unprecedented rate for such a young and low-funded company. Their customers are happy as pie that they get $20-$30 cameras with lifetime App/Cloud access and, really, if you were to poll them, no significant proportion would say they fear that Wyze will shutdown the service nor add any fees for the current service level. At best (or worst?), they would “expect” Wyze to refund each and every purchased camera in such a situation. Of course - that would not happen.
With such success in the market, good-luck convincing the industry (i.e., all the examples you and I gave, and many, many, many more) to completely change its direction on this.
Zigbee has association? How does that work?
I may be mistaken as I cannot find a current reference. I just “seem to recall” reading such a thing, and perhaps digging through the ZigBee specs (which I’ve skimmed a few times in the past), I may have jumped to a conclusion or just mis-remembered.
Google it?
It exists, although it’s not called direct association, and it depends on the zigbee profile being used.
You’ve all seen it in the ZLL ( zigbee light link) profile such as with the Philips Hue dimmer switch and a hue bulb. No coordinator required.
https://www.amazon.com/Philips-Hue-Installation-Free-Exclusive-Assistant/dp/B016AEHU70
And if you’ve ever read the community FAQ on why the hue bridge is a bridge, not a hub, it references it as well.
Warning: super technical network engineering explanation follows. But the short answer is just that it’s a bridge by definition. The longer answer: A bridge (or gateway) converts requests in one protocol to that of another. The hue bridge is a Wi-Fi/ZLL Bridge. The bridge does not, however, “establish” the network. That is it does not assign network IDs to other devices that join to it or control which devices join. Instead, because the hue bridge is a ZLL device, there is no establishing coordinator on its network. [IMG_4091] A ZigBee Light Link network has no ZigBee network coordinator, even a bridge device merely acts as a router {repeater} So it’s a bridge per the definition of bridge in the ZLL specification. The end devices don’t need the bridge in order…
Just as one example, if you add an IKEA handheld remote to your network and then join it to an IKEA bulb, you could then take your smartthings hub off of power and The remote will still control the bulb. Same end result as zwave direct association, but for a different set of device classes.
@professordave
ZLL controllers cannot generally be The targets, so you can’t really do it with two switches. You could have two switches each of which control the same smart bulbs if they’re all ZLL. Like two Hue dimmer switches and some hue bulbs.
So it’s a little different than zwave direct Association in terms of. The device classes that can be targets, but you can definitely set up a virtual three-way, but only with a zll light as the shared target.
https://www.reddit.com/r/Hue/comments/5ef2pc/can_i_assign_multiple_dimmer_switches_to_one_bulb/
But I agree with your general point, we need more local control!
Not everything should be cloud!
But I agree with your general point, we need more local control!
Not everything should be cloud!
If you want all local except for third-party integration such as with voice assistants, there are several low-cost home automation platforms on the market now that provide that.
Hubitat is a recent entry that runs the same code language as smartthings for custom apps and device handlers, but runs it all locally.
The open source home assistant software runs locally, but does require a lot of technical expertise to set up.
Indigo domotics is laptop software that has been around for quite a while and runs locally.
Insteon runs locally.
Apple’s HomeKit runs locally except for the voice control interface.
Homeseer runs locally.
There are several other choices as well, although some may require the Internet to set up the account initially but run all your automations locally.
So if that’s what matters to you, you have lots of choices.
(They don’t all run the same set of devices that smartthings does, that’s just something you have to check model by model. )