Don’t do it Terry, repeat after me. NDC, NDC…
I have 5 Arlos and I love them. Small. Weatherproof so far (bring on the upstate NY winter) and wireless. Integrate those and a v2 huh is a no brainier for me especially as I am about to move to a new house and will be doing a fresh setup.
@tyler So should we be migrating our current Minimote apps to using the Smart Lights or whatever, instead of the Button Controller?
I’ve only seen Smart Lights in the current app, what should i do for other actions like using my MiniMote to Fire Hello Home (well I guess Routines) now?
I would like a clear direction on this, as this is something I can do before I have to make the migration to the new hub.
Thats weird. When I fired up my new app, it had all of my groups listed as rooms already. I just had to finish configuring them (which device to show as default for the room, the picture, etc.) but they were all there from the previous install. Or are we talking about something else and I just completely missed the point? lol
If you had shortcut groups in the previous version of the mobile app and you install version 2.0 of the mobile app, it will take your old groups and re-create them as rooms. And they will also show up on the dashboard.
However, you can’t create any new groups after that, just new rooms. And if you delete the last device in a group, it will disappear forever. You won’t be able to add it back to the dashboard.
Apparently, there’s a new feature coming in a few weeks called “sets” which will let us group things differently from the rooms. We’ll see what we get when we get it.
Does the new Hub support Somfy RTS. I did hear about that on the rumour mill.
SmartThings is the only home automation platform that supports Samsung Home Protocol over LAN.
This must be the absolute dumbest thing to put on a ‘pro’ list. Of course you are - this is a proprietary Samsung protocol - your own thing. This isn’t a pro - it’s a huge CON. Please stop talking about ‘open platform’ when you can’t be bothered joining everyone else in the AllJoyn Alliance.
SmartThings currently supports zigbee and zwave, both third party standards with many different device manufacturers. That’s pretty much as open as it gets in home automation right now.
AllJoyn is new, not yet widely adopted, and their primary mover is LG who wanted something for their smart appliances to compete with Samsung’s Tizen. Microsoft jumped on board because they needed an entry into
IOT that wasn’t Google or Apple.
And since alljoyn is an open, protocol-only project that can be added to anything just with software, there’s no reason to jump in early. If it turns out to be important, it can be added later going to pretty much anything. If you do want something that’s already playing around with it, go with Insteon.
Most industry analysts believe thread will be much more important. Samsung is already a member of the thread group. And Qualcomm (the other big alljoyn partner) just joined the thread board a couple of months ago.
AllJoyn can run on top of Thread which can run on top of Zigbee, so SmartThings isn’t left out of any of this stuff.
But while SmartThings itself is owned by Samsung, and Samsung has big research departments doing all kinds of preparing for the future stuff (Sami and Artik for example), SmartThings itself is a practical consumer products division focused on delivering retail home automation now.
So they have neither the resources nor the mission to get involved in all the possible future home automation standards. There’s nothing about the SmartThings architecture to prevent them from adding AllJoyn later. And no compelling reason from a consumer point of view to add it now. There are no significant devices currently available for consumers to add to their home automation set ups that require AllJoyn.
AllJoyn will continue to have a place, at least for a while, because of Microsoft’s interest. It looks like Insteon will provide a means to use that. But I don’t see it ever becoming a very big part of the home automation market.
Qualcom’s very recent decision to join the thread group seems more of an indication of which way trends are flowing.
Oh, and Microsoft also quietly joined the Thread group (of which Samsung was a founding member) about 6 weeks ago, with the intention of running AllJoyn over Thread. The future is coming, but there are a lot of paths to get there.
Submitted with respect.
Apples and Oranges. Tizen is more of an OS (what I like to call Samsung’s perversion of Android) while AllJoyn looks to be more of a handshaking mechanism. They wouldn’t compete.
You’re an engineer. Say what you mean.
History of technology. It’s often apples and oranges.
LG was going beyond the OS concept, but Samsung did the same thing with Thread. Still the original push came from the $4,000 refrigerator smart appliances market niche, not IOT. Now both have expanded considerably and will likely end up overlapping rather than merely competing.
@JDRoberts While some of what you say there makes sense, some of it doesn’t - as someone already said “apples and oranges”. Thread isn’t an AllJoyn competitor. It’s a ZigBee/ZWave competitior, and I am excited to see what Thread can deliver - it sounds like the best of both worlds (open spec like zigbee, interoperability that actually works like zwave). Neither of these are IP capable, or offer any means for bringing together multiple standards. Actually it only makes the need for AllJoyn even bigger, since there’s now yet another set of devices that can’t talk to all the other sets. Exposing your devices to IP is important so your phones, tablets, PCs etc can interact with them.
What AllJoyn does is ensuring all these specs can work together through Device Service Bridges. I want the SmartThings hub to act like an AllJoyn DSB. This would greatly open up the app development world to build apps that works on any home automation standard. I would be an idiot to spend lots and lots of money on building an app that only works on one single ecosystem - my user base would be heavily limited - or I would have to build an app that can do all protocols, have a device that can speak all the standards etc - basically duplicating what AllJoyn tries to do - and very expensive and time consuming.
Saying the AllSeen Alliance is just LG and Microsoft is quite an understatement. I mean look at this list: https://allseenalliance.org/about/members “ADT, AT&T, Cisco, Sharp, Philips, Canon, Qualcomm, D-Link, Honeywell, HTC, IBM, Insteon, Iris, LIFX” just to name a few more.
My ultimate point is: We need local access APIs, and lots of developers in this community site are asking for it. So what I’m saying: Make it a standard local access API, and enough with the Samsung smart home protocol and what else proprietary protocols you have that makes it uneconomically for developers to bet on. On your website you brag about how the SmartThings hub is “the only hub to implement SHP”. Yeah no wonder - It’s your own Samsung “standard”, and it’s absolutely in no way a good thing you’re the only one, nor is it a good thing that there isn’t an open board that controls it.
The SmartThings hub with all it’s device support has an amazing ability to be a great AllJoyn DSB for other apps and devices, and anything it doesn’t support it could also consume and control through other AllJoyn DSBs.
AllJoyn is the ONLY open IP spec I’ve seen that tries to solve the problem of multiple protocols while realizing we still need many of them for various scenarios.
I understand that it’s in your best interest to completely lock in customers to SmartThings and Samsung appliances/devices. But it’s in no way in the best interest of your customers, and sooner or later your customers will realize that.
Simple scenario: I need a new smart light bulb - I can use the older more expensive SmartThings compatible one, or I can use the amazing new bulb that does more at half the price - but I would need to replace my entire existing HA system to use it. So I end up not buying it after all and going incandescent and go home grumpy promising to give up on this homie automation crap thinking about how I used to just be able to buy a bulb with the right socket, and it would just work - I had literally 100s of different bulbs to choose from - but somehow we ended up in this dystopian society where no one talks to each other. But if I could use bridges to expose new technology to old and vice versa, I can start migrating seamlessly to the new fancy smart bulbs, and still use my existing smart things all without running different apps, separate controllers etc. No need to worry about any sunk costs.
There are no significant devices currently available for consumers to add to their home automation set ups that require AllJoyn.
This isn’t about devices - it’s about apps. And yes there aren’t any apps, because there aren’t any hubs apart from a single expensive Insteon hub. I’m sure if there’s some great Home Automation apps out there, they would list the hubs they are compatible with, and you would be looking really good on that list. But you are not going to see the next big home automation killer app until the developers building it has the user bases required to make the effort worthwhile. Building for just one ecosystem in the current fragmented state of HA just isn’t feasible today, and that’s why your statement above is self-fulfilling and completely meaningless. Be the egg instead of waiting for the chicken.
Next Developer Call will be on 09/09/2015 - Guest : Alex Hawkinson
I have no connection to SmartThings other than as a customer, so your post is rather confusing.
And SmartThings doesn’t try to lock anybody into Samsung devices, so that part is confusing also.
And Thread isn’t a zigbee competitor. They originally thought they might be, then realized they needed zigbee’s energy-efficient sensors, and agreed to play nice.
I agree the comment in recent SmartThings releases about being the only ones to support the Samsung protocol was silly.
@JDRoberts my bad - I misunderstood your position. In any case, I still think they lock in - in the sense that their APIs aren’t open. Yes you can use ZigBee and Z-Wave and several other devices (but SmartThings controls which ones that is). Also you can only control them using the smart things hub, and you have to use their own proprietary cloud API. I’m saying we need non-proprietary local access APIs, and we need a standard so we don’t need SmartThings to be the ones to implement support for new devices - they should just autodiscover AllJoyn devices on the network and roll with them. And likewise if a new better controller comes out, I want my SmartThings hub to switch over to just being a dumb DSB bridge for the better controller.
I have written my own LIFX and Philips Hue DSB, and the Raspberry PI 2 Windows IOT image comes with a ZWave DSB built in (just plug in a zwave usb controller). This means my PI is running several independent set of DSBs - any AllJoyn enabled controller can now use all these devices. The architecture is pure beauty and nicely pluggable. It effectively means I have several different kind of lightbulbs (and still buying more kinds ) but they can all be controlled with the exact same code and works in one simple app I built. When a Thread USB controller; comes out, I just plug that in, start up the DSB service, and I’m done. No reason to touch the app or any controller/hub device. You can hardly grasp how HUGE this is - we can effectively disconnect two things that shouldn’t be so tightly connected and grow them each independently and faster.
And Thread not being a ZigBee competitor? I’m aware of the collaboration, but they both seem to try and solve the same problem, working together or not. AllJoyn effectively sits on top and therefore doesn’t have this huge overlap that Thread and ZigBee has.
I’ll admit to not knowing a lot about AllJoyn (maybe @dlieberman can add color) but I do know we plan to support Thread in the new Hub.
As for openness, and particularly with regards to SmartThings controlling what devices are added. Individuals can add many devices to their own setups without any intervention from SmartThings. You are not going to ever get that from many other platforms.
@Ben So what does it mean when you state “we support over 200 different devices” ? To me that sounds like a limited set. By using AllJoyn introspection, you could support all devices that are exposed to alljoyn, meaning essentially unlimited.
Great to hear Thread support is coming - that’s like the first proper detail I’ve heard about the new hub
@dotMorten - You can think of ZigBee (at least in the HA context) as three distinct layers - the MAC/PHY layer which is defined by the IEEE 802.15.4 specification, the transport layer known as ZigBee Pro, and an application layer framework known as the ZigBee Cluster Library that defines methods, behaviors, and messages. The last two are defined and maintained by the ZigBee Alliance.
Thread is also based on the IEEE 802.15.4 specification for MAC/PHY, so you can use common radio silicon for Thread and ZigBee. Instead of ZigBee Pro for transport, the Thread specification defines extensions to 6LoWPAN (IPv6 over 802.15.4). That’s where it stops - Thread is purposefully application layer agnostic.
This is where the ZigBee Alliance and the Thread group are collaborating - the intent is for the ZigBee Alliance to make the ZigBee Cluster Library available to run over Thread. This is significant because it will then be relatively straightforward for existing ZigBee device manufacturers to convert their devices to Thread with an OTA update since they’re using the same silicon and firmware development will be familiar. It’s likely the the ZigBee Alliance will continue to develop the ZigBee Pro transport layer, as there are still contexts in which IP transport may not be the right answer.
I don’t think Thread and AllSeen have made any official announcements as to what AllJoyn could look like over Thread, but with Qualcom joining the board of the Thread Group I’m sure you can read between the lines. It’ll be interesting to see what happens though, since AllJoyn is not designed for constrained networks - the messages are rather large and the protocol is pretty chatty, which is never good for wireless devices using batteries. The ZigBee Cluster Library is already designed for those conditions. There are also new protocols like the one being defined by the Open Interconnect Consortium, which is also designed from the ground up to work well over networks made up of constrained devices (it’s based on IPv6 with COAP).
As for the ability to decide what ZigBee or Z-Wave devices you use - as @Ben suggested, you can easily write your own device type handlers for any ZigBee or Z-Wave device and install it into your own account without any intervention from SmartThings. We’ve open sourced (mostly Apache 2.0) the vast majority of our own device type handlers and example SmartApps, and we publish documentation (which, thanks to our Documentation Development team is getting better and better every day). But yes, you’re using our APIs, as you’re using the platform and infrastructure that we’ve built.
There are definitely other frameworks that you can use to roll your own - Windows 10 IoT, OpenHAB, etc - but they’re far more complex to build working systems from the ground up, and they don’t come with the back-end, user experience, or community that SmartThings does. Those tradeoffs will be worth it for some, and for others they won’t.
Am I the only one that can’t help thinking of Big Trouble in Little China when they see 6LoWPAN mentioned?
3 posts were merged into an existing topic: Hub 2 Backordered vs ships 5-7 days
Close this thread, Andy wins the internet for the day.
2 posts were merged into an existing topic: Hub 2 Backordered vs ships 5-7 days (AKA all shipping related posts, please)