Just tell the family there’s a new feature and they get to pick their own color scheme.
Well the real story is one for drinking beers lots of beers, cause it just doesn’t make sense.
If HTML ever gets released as shown at SDC (or better?) the replacement for it will be great. But I stopped holding my breath for any future promise ST ever speaks of. I’m a show me, don’t tell me and let me do it myself.
That WORKED like a CHARM! Phew, that’s load off, this was going to be the toughest, big family here
Took my spouses’s DNI and created a new device linked to the new old hub, deleted the old device, she away from home, asked her to fire up the ST app and it promptly changed state to away.
For now… For now… Honestly, no idea if it will break, but given the fragile state of presence as a whole… Don’t be surprised if you have issues.
Do you have the brand of that charger? Have a similar outlet setup near my front door and this will solve an issue about “mounting” an old phone.
It’s just a plug-in dock. There are a bunch of those available. I pulled that particular example from the forum in the following thread because it showed SmartTiles a small device, but it looks like that specific model is no longer available.
Amazon usually calls these a “mini wall plug in dock charger”
Obviously you have to match the plug to your phone model.
Thingcharger is a new one with changeable tips. I don’t know how sturdy it is though, there are a lot of reviews about the phone getting knocked off of it. So you might need to add something additional to secure it. thing charger is different from the other chargers because The other ones have a dock that angles the device and thing charger just holds it straight vertically.
Here is why I think it works without a problem. The DNI contains the email address of the user and a unique device identifier. From what I can make out the device identifier is updated whenever the user logs into a new device but the email address is constant. Hence when moving it between hubs and creating a new device since both the device identifier and email are the same (as her device did not change) it works fine.
I’m wondering if there is a downside to applying the same strategy for wifi devices and other non Z wave devices like MyQ etc which use constant unique identifiers.
I have that exact dock and I use it for Sonos and Fic control in the kitchen.
Of course, it still doesn’t solve my original question as to the status of the conversion tool, which is also needed for replacement of ANY hub of one goes bad.
It’s coming up on a year for when it was promised to ship (originally Sept of last year, right?) and much longer than that from when it was originally announced.
This is actually becoming a concern of mine because devices like this actually do crap out from time to time. As an IT Director, I don’t like not having a way to do this.
It is also giving me great concern that they may have painted themselves into a corner on the backend somehow preventing them from creating the tool. And that, is even a bigger fear because that points to potential future problems we’ll all have.
Am I over-reacting on this and being lazy…perhaps, but I don’t really think so on this one.
There is a lot to (over) react to. In my minds eye, SmartThings has barely been able to tread water since being acquired by Samsung. It has certainly tempered my enthusiasm for the product, and has me wondering how long they can survive in a mode where their is little to no forward progress.
The only reason they survive is because there’s no strong competitor. Still no HA solution from tier I companies (Google or Apple) and I think we all know why. Nobody has figured out how to make money in this market. I doubt SmartThings is making any profits either.
This is a whole industry issue. IoT is struggling. There are early adopters, but the masses could care less. I have spent thousands on a smart house this past year. Now that most my house is automated my spend will probably be a couple hundred a year.
With IOS 10, I think Apple has done the very simplest connected home automation well. They will sell some additional hardware with watches and an iPad on the wall as a control center. The rules engine is extremely simple, but it will work well enough for many people. Everything runs locally, but you do have out of building controls as well. So far all the individual devices that I’ve looked at are very good quality. I don’t see anyone saving money because there is a brand premium on these. But it will be fun and practical. And easy to use.
I don’t think it will meet the needs of most of the people on this Forum. Too simple, too expensive, and not enough device choices. But I think it will create more adoption of home automation.
So then it will be up to the next tier, including SmartThings and Insteon, to communicate their value proposition to those interested in something more powerful.
Home automation and IoT are NOT synonymous. Unfortunately, SmartThings has made their home automation dependant on the IoT. That’s a mistake; requiring needless complexity and IP traffic they can not reliably support.
Philips Hue got it right… running everything locally, unless you’re out of the house. Gawd help SmartThings if they choose to get deeper into HA.
It is unclear to me why SmartThings bet their whole platform on IoT that they clearly have been unable to satisfactorily support. I suppose it is based on big data and revenue generated by it. Google will soon be in the game, and they will be able to scale the big data whereas SmartThings hasn’t.
My feelings are that unless we see a major change in SmartThings strategy, they will be extinct within the next 2 years.
I know I have been considering HomeKit now as someone in the Apple ecosystem. Trying to decide how much complexity I really need. I want to still love ST, but the relationship is getting worn.
I struggle in HomeKit with the number of bluetooth devices in what I am reading…that apparently don’t report data unless you are near them (makes sense), so without a true hub other than the Apple TV it feels like perhaps its not going to be automated enough and remotely accessible as deeply as I want.
HomeKit is very simple, but it works well for most device categories. The Bluetooth sensors are completely useless, however.
On the other hand, the Wi-Fi sensors for ecobee work just like they work in any other platform.
And Phillips just today announced a Hue motion sensor to work with its bridge. We don’t know yet if that information will also be available to HomeKit, but at least it’s there for the Hues.
But, yeah, if you’re relying now on a bunch of different sensors, HomeKit isn’t going to meet your needs at present.
Speaking as an engineer, I’d be willing to give Robert Parker a year to get the culture changed from a proof of concept company to one driven by customer experience.
Of course engineers never get to make those choices, so Samsung will probably give him less time than that.
And he may focus first on getting things right for Samsung TV/camera owners, which isn’t a bad idea if he can actually succeed. There’s still a market space there and it would be a good fit with Samsung. But it has to be focused on QOS, reliability, set up simplicity, all that. It can’t affect customer evaluation of the television overall.
So it’s a challenge, but I imagine it’s an interesting one.
My 2 cents on migrating from the v1 to v2 (essentially hub replacement), it was painfully long. A few things I did to make it smooth:
- Added the new hub to the same account
- Have 2 phones running the ST app, on one open the old/dead hub and on the other open the newly added hub
- Open the IDE and click on the old/dead hub, for each device click an open in a new window and see list of connected smart apps
- Using the ST phone, one by one delete the device from the old hub and then add/pair it to the new hub
- Once that’s complete use the pages in step 3 to go an add all the SmartApps back for each device
- For “phone” presence device I went the old hub page in the IDE, copied the device DNI and created a new mobile phone presence device in the new hub and added the copied DNI to it and then deleted the device from the old hub. At first it shows as “present”, then you start the ST app on the respective mobile phones and it works perfectly.
One thing to note, if you’ve got a large multi floor house and you’ve got stuff all over, I would start by adding the PASSIVE devices FIRST to the new hub and starting with the FURTHER device. Reason being when a Z-Wave device in paired/included it sends a NIF (Node Information Frame) command to the hub to identify and include itself. NIF frames are NOT re-transmitted via active repeaters, hence this is why they say that new z-wave device should be very close to the hub when pairing it because the NIF needs to go straight to the hub. Hence if you don’t have any active devices in your network the chances of pairing a far away device with the hub increase dramatically. I was pretty much able to pair devices 3 floors apart using this strategy (because I REFUSE to remove all my z-wave device just to repair them). Finally I just had one device that was 4 floors apart and couldn’t pair, the good news is that the v2 hub runs on a battery, so I just took it up to the top and plugged it into the hub upstairs and completed the last pairing.
Finally then add the active repeater devices starting with the further away one (for the same reason as above) and work you way closer. After all this I did a Z-Wave Network Repair and so far I’m pretty impressed with the v2 hub. The mesh appears to be stronger, things are running faster, even custom DH’s seem to be responding better. So far so good.
This is no longer true with zwave plus.
More importantly, though, the protocol you describe only works if every device is within one hop of the hub. If your top floor far corner is more than one hop from the hub, it cannot be paired in place without a repeater.
Also, for most devices which are already wired in place, a minimote can be used for exclusion/inclusion. You shouldn’t have to carry a hub up three floors.
So a quick update on this, creating a new mobile presence device and copying the DNI does work fine until the v.2.2.0 app update. So if you look at the Mobile Presence DNI it looks something like this
The hubID is a unique mobile presence string assigned for a hub. So all mobile presence users on that hub will have the same hubID.
If you want to use the same trick to migrate your mobile presence devices from one hub to another, you first need to add a “real” mobile presence device (likely you own mobile from which you control the ST account, that will be the first mobile presence which will automatically get setup on your new hub). Look the DNI for your mobile presence on the new hub, extract the hubID from that string and then you can use that to replace it in the DNI for your other mobile presence devices from your old hub and create new devices in your new hub with the DNI from the the old hub but replacing the hubID with the new one.
Hope this helps.
Due to unusual, intermittent, but persistent problems keeping my hub online SmartThings finally sent me a new hub. Sadly, only after I received it did I discover there is no way to replace the existing faulty hub with the replacement. Starting over is not an option I am yet mentally prepared to do. I about 50 things including a 5 number of Enerwave relay switch modules wired behind the wall switches. I have several times used the IDE to add functionality I learned I could have from reading these forums, but I did that somewhat blindly by carefully following instructions, versus understanding everything I was doing. I am not prepared to completely rebuild this configuration. I am not confident I know everything I must do to make it happen.
I notice the most recent post in this thread is over a year old. What currently is the best process to replace a hub? 2.0 to 2.0 hub? How can writing a migrating tool and instructions possibly be difficult for ST to do? Why have they not done it? Why would anyone buy this system if they every knew if a hub failed they have to start over?
Thanks for the help. Help I hope I get.