I don’t have these details yet, but our store at http://shop.smartthings.com will in all likelyhood not ship to international addresses or accept international credit cards for US hubs. I can’t say the same for other stores.
I guess the date of Sept. 26 is wrong, oh well. Still looking forward to having a smart home!
A little birdie told me that the most probable date is Feb 30, 2016. Although the pre order will start on Sept 31, 2015. we are like kids… Mommy, are we there? In another 2 minutes… Are we there yet? Replace mommy with @tyler.
That’s the thing with this community, more so than other tech communities I’ve been a part of.
The passion here is through the roof, but it’s a double-edged sword. I think that a lot of the time it reads to the folks with the little blue icons on their avatars as petulance/whining/ingratitude.
So, uh… are we there yet?
@smart, if February 30th, 2016 is the most probable date of release then it is official, we will never see v2 of the hub .
Either way we may never see v2 if they keep pushing that date back.
BTW, September 31st is just as problematic as February 30th.
I am newer to ST and so far I am loving the concept and direction that it is heading. The major hold that I have placed on making any device purchases is the fact for the v2 hub release date. I am really chomping at the bit to start getting some additional automation (I currently only have Nest products), and I am setting funds aside so that I can make my first initial jump into the Home Automation world but this delay is unexpected.
So, since ST had my attention first, and is supported by a great community, I have a few questions for the group and possibly the ST Team (if these have been answered before then I apologize):
-If a v1 hub is purchased and later a v2 hub is purchased, will the v1 hub become a repeater within the Mesh network so in case of network loss the v1 hub can still function?
I like the ease of use of the ST App with Android, and I know there have been questions of improvement for the ST webpage IDE; but there are a few things which kill the fluidity of development.
The ST web IDE appears “late to the party” with regard to development. A SmartApp has to be developed and tested, “Installed” (which is a simulated Install), Uninstalled, Published, then re-Installed from the App to get the proper Thing subscriptions for the functions to work. Why the second install? If it is all cloud based why can’t you move the simulated Install to a production install where it actually works? IFTTT, Wink, Muzzley, etc. allow development of recipes with quick action/reaction items with “bubbly” user friendly icons and verbiage… all from their phone app. This allows for quick setup and testing of devices without having to get behind a keyboard. It would be easy enough to have these easy “recipes” to be created within an app and then have a generated bit of code for that Thing’s actions. This does two things: keeps newbie’s learning curve consistent as not everyone is familiar with .groovy (where they can create an action then look at the code to see how to make it) and makes it easy for the day 1 users to begin installing with Zero programming or coding experience (this is why people like Wink so much, zero “real” programming experience needed). So, having the ability to have the “bubbly” setup of actions from the app, and web IDE, to then allow the user to access the code background to fine tuning or additional development would be very welcomed… at least to me.
I would say “just my two cents”, but I think I just took a loan out for this response. I appreciate any information back to my load of questions.
What about for Canada? Same standards here.
This is a great question, if this where in fact the case then I think I’ll buy a V1 now.
That is my thought as well.
We have already read that the v2 may not support the same Things as the v1. But if both are retained within the same mesh network and the v1 acted as the “slave” or “repeater device” then it may be possible to retain all use of all Things but with the all of the added benefits of the v2.
This could even be a plan for those folks all migrating from a v1 to a v2. Allow the users to move over the devices they want as they need it from one to the other… obviously the only drawback is the loss of power versus the loss of network. I live in an older area and they are constantaly working on the underground network lines. I lose internet access for a few hours every month. With my luck it will be this exact time that I am locked out of my house, at night, in the dark because I expected my outside lights to come on. If current ST users were able to use their current v1 hub and simply purchase and use a v2 hub, where a firmware update to v1 and the soon-to-be-released v2 comes out, this integration could be seamless.
Except, both devices will have to stay plugged in… but then again this can be fixed by the statement above. Allow the users to migrate the needed devices over from v1 to v2 as they see fit.
Sorry… I tend to ramble when I have an idea… with many outcomes.
The idea of possibly using the v1 hub as a repeater in a network where a v2 hub is primary has been mentioned by ST staff in the forums as one future possibility, but it’s tricky because of the multiple antenna setup. It’s not something that’s going to be easy, or necessarily will happen at all.
One of the challenges ST faces is its early decision that protocol distinctions would be, as much as possible, invisible to users. So zwave devices are described as having clusters (which drives me crazy) and device handlers can spawn child devices and a lot of other oddities. But it leads to the ability to combine zwave and zigbee devices in one hello home action, and trigger it from a button press on a Minimote, which is very cool and totally taken for granted by most customers because of the whole ST approach.
But in the underlayers, an ST hub is running one zwave network and an entirely separate zigbee network.
My guess is it would be relatively simple to add a v1 hub as a zwave secondary controller to the v2’s zwave network. But the zigbee is a whole different story. In fact right now you can’t even have two v1 hubs on the same ST network, a good clue that there’s not going to be a simple way to have a v1 and v2 on the same network.
We think of the v1 hub as one thing, but it’s 3: a zwave controller, a zigbee controller, and an Ethernet relay. The v2 hub will add a bluetooth antenna and more complex local code processing.
So for right now I wouldn’t count on ever being able to put a v1 hub on a v2 network. But we’ll see.
We have? Where did we read that???
I strongly suspect v2 will be a far more capable TCP/UDP relay than v1. In fact, it should open up the ability to function as much more than just a relay. The significant boost in on-board resources should allow the use of far more capable networking software on the device (including common, highly functional open-source options), hopefully allowing us, in time, to far more easily overcome previous constraints, e.g. devices with dynamically allocated IP addresses, etc.
The use by SmartThings of existing open-source components for this space would also hopefully free up more in-house developer time for use on higher value, platform specific features.
I think this is false. I don’t believe anyone has said hub v2 will not support all hub v1 devices. However, hub v2 has BLE so it can support additional devices that hub v1 can not.
I agree with you. The quoted statement certainly runs contrary to my current understanding, which is why I’ve questioned it.
I read somewhere on the forum that the v2 may not support some more legacy z-wave devices… Something to do with the 802. protocols. I may be wrong but if I find it then I will post that here in reply.
That seems ubsurd. Zwave is a standard. There are no old zwave devices that use older versions. It is possible, again, that hub v2 might include newer radios to allow more devices to connect. Not the other way around.
Zwave generations are backwards-compatible, it’s part of the standard. As long as the v2 hub is a certified zwave controller, it will be compatible with all certified zwave devices, including any older ones used by someone with a v1 hub.
Will Z-Wave Plus products work with classic Z-Wave products?
Yes, Z-Wave Plus products are fully backward compatible with classic Z-Wave products.
Also, wouldn’t this be a “violation” of the goal of SmartThings. ST was established to connect every device together. Once it’s paired, you’re supposed to forget that it’s ZigBee, Z-Wave, LAN, or Cloud. To say devices are incompatible that previously were doesn’t make sense. Now that we have more capabilities (BT), we should be able to connect more devices than before.
Is there a particular set of devices that ST is going to offer that are Bluetooth, or is it just to add functionality with other smart bulb brands?