Why can't simple additions be, SIMPLE?

General Discussion
1

Over the weekend, I added a First Alert combo alarm and 2 GE Dimmer switches. Things did not go well and I’m left with many questions. (I’ll not go on about the annoying outage many of us experienced the other day…)

Let me get the good news out of the way first. I added the First Alert device and the process was EXACTLY what I expect out of a 21st century smart system. I activated the device, told ST to find that device and it did! It even added it to my SHM. All this happened in about 60 seconds. Awesome.

Then came the switches. These are the standard, rocker Jasco/GE things everybody raves over, bought at Lowes so they are Z-Wave, not Zigbee. After I installed them, the door lock (Schlage) stopped working. Now, let me pause for a moment and ask some questions:

  1. Why would the door lock stop working just because I added some switches near the door?
  2. Why, if the door stops responding, would the system not in any way tell me that the door wasn’t responding to anything? This is a SERIOUS problem with ST. If I’ve lost communication to my door lock, I don’t know if it is locked or unlocked or even if I can get into my home. If I request a refresh or change a code using a Smart App, there certainly has to be an expected response. If there is no response, the system just goes on…there are NO WARNINGS to tell someone that there is a problem. Ridiculous and DANGEROUS.
  3. I tried to repair my Z-Wave network first, but never received any feedback to let me know it had completed. I waited several minutes but never heard back from the system that the repair was complete. I only have 4 z-wave devices…how long can it take??
  4. Why is it that a routine will tell me after I start it that the routine has completed…but will lie its digital butt off. Did the light really turn off? Did the lock really lock? Nope. But the system will happily tell me the routine was completed. Liar.

So after I reset my door lock, things started working…but not how I would want them to…

  1. Why would ST think my switch was a plug? Can’t it tell the difference? I know it a minor detail, but I’m bothered that my light switch icon in ST is an outlet.
  2. Why doesn’t ST have control over the fade time of this dimmer? That is the most basic parameter of a dimmer switch for crying out loud. Level, Fade Time. 2 parameters and ST is missing one of them. I see there are some conversations about this so I’ll have to see what’s been written, but really…I expect that sort of thing to just “be there” without me spending an hour researching, downloading, etc, etc for a basic function of a device that is used by more than half the people on here.

All that and the SHM outage. Yikes.

1 Like
2

Others will go into more detail about each of your problems, I’m sure, but they can all be summed up by saying “low power mesh networks are weird and sometimes limiting”.

Sometimes I lay awake at night and wonder if DIY home automation will always be held back by the limitations of zwave and zigbee. It’s really hard to design a satisfying user experience when the base communications protocol you’re working with doesn’t garuntee that a message will get delivered, or report for sure the state of all of its devices at any one time.

4 Likes
3

I’m sorry you ran into so much frustration. (For the record, not everybody raves about the GE switches, just the GE switch price. Just sayin’… :wink:)

As far as knowing what a switch is, no, there isn’t any difference between a switch and a plug in the Z wave standard. Something which turns on and off is a switch whether it’s a wall switch, a pocket socket, an in wall outlet, or a relay. It has “capability.switch” in SmartThings parlance.

The manufacturer has the option of including additional manufacture brand and model information, and then depending on the device handler you use, that additional information might be recognized, but just from a pure network standpoint, on/off is a “switch.”

3 Likes
4

Regarding the doorlock not working after you added the other devices – – that had to be a coincidence. There’s absolutely no reason why adding in the switch, whether it was near the door or not, should cause the doorlock that had previously been working well to stop working. (If you replaced a previous zwave switch near the door with a new zwave switch, that’s a completely different situation, and would probably mean the lock had been relying on the old switch to relay messages. But it doesn’t sound like that’s what your situation was.)

Unfortunately, many factors can add to unreliability in a SmartThings network, and it can sometimes be difficult to track down exactly what happened.can add to unreliability in a SmartThings network, and it can sometimes be difficult

1 Like
5

For fade control:

The device has parameters that can be changed through a process called “configuration.”

Some zwave controllers offer a configuration change screen as part of their basic UI. Smartthings does not.

So you need to find a custom device handler which exposes the parameters that you want to change.

The good news is that the more popular the device is, the more likely it is that such a device handler already exists in the community.

You can just search the community yourself, or ask the question in an existing device handler thread for that device and someone will probably know.

I realize this definitely doesn’t fit the “simple” requirement, but at least it’s doable.

6

For zwave repair utility messages:

This is an area where we’ve been told it will be eventually improvements, but right now what SmartThings offers is really minimal. You can start the utility from the mobile app, but you have to go into the logs to actually see the results. Which again is way more work than it should be.

If everything runs great, all you will see is a message saying that the repair completed.

If there are any problems, there are additional error messages you might see in the logs.

The following FAQ tells you how to look at the logs:

And this thread discusses some of the error messages you might see.

I’m sorry there’s not a better answer on this point, it’s just an area where there’s room for a lot of improvement.

7

And last but definitely not least, figuring out when a device has dropped off your network.

Mesh networks like zwave and zigbee are not intended for continuous communication. In order to keep power draw very low, which also extend battery life, they are designed for very tiny relatively infrequent messages. Many devices don’t expect to talk to the controller more than two or three times a day. Some even less frequently.

Wellness checks

That doesn’t always meet the requirements of a residential system. So many people do what is called a “wellness check” where they just check the device once a day to make sure it’s still running. Or once a week depending on the use case. This is also good time to get battery status.

If you’re going to do the wellness check by actually talking to the device, you have to resist the temptation to do it too often. Otherwise, a light switch might miss a “turn on” command because it was busy answering the question of whether it was still connected to the network. But once a day is usually fine.

An even better way to do a wellness check is not to talk to the device directly at all, but instead to check the log for its last known activity. That way we don’t overburden your network with a lot of “are you there?” Messages.

Several people have written smart apps to do this. One of the more popular is the following:

Of course while this is “simple” from one perspective, I do understand it doesn’t meet your original question. It’s not a built-in feature of smart things. So it’s just another example of how SmartThings is very powerful and flexible, but not necessarily very intuitive.

(Btw, it was probably obvious, but I put each of these topics in a separate post just to make them easier to follow and reply to. You identified a number of issues with the existing architecture, but they weren’t necessarily related except as part of a philosophy that openness and versatility would be the top design priority.)

If only…the hidden costs of versatility

The truth is, everything you asked for would be way easier if SmartThings only supported one protocol. Zwave only or zigbee only or Wi-Fi only. The decision to make it a multi protocol platform meant they can’t just use the out-of-the-box utilities they come with each individual protocol. They have to build an extraction layer for everything and then decide exactly what features to offer and what to do about features that are only available for one protocol and not the others. There are obvious advantages to us as customers in being able to set up zigbee motion sensors with Z wave light switches. And obviously the SmartThings price point is actually pretty amazing for what you get. But the hidden costs that we pay is it everything is going to be much more complex just because what the system is trying to accomplish is much more complex.

It’s true that Wink is also a multiprotocol platform, but it doesn’t allow its customers to upload their own device handlers or custom code. So it has a very limited set of compatible zigbee devices, and even when a new zwave device comes out it takes a while before it’s available on the platform for anything but basic on/off functionality.

With smartthings, you can choose from many more devices and make them do many more things. But what you lose in that is simplicity of both set up and operations.

8

JDR, thanks for all of your responses! I appreciate the time you put into these forums.

I get everything you are saying (I know just enough about networking -mesh and otherwise- to be dangerous), but I have to say that there is really no excuse for ST to not inform someone that a device is not responding after a command requesting a response is given. The system expects to see locks so having one on any network should not be a surprise. As such, allowing a lock on a system comes with great responsibilities on behalf of the system creator as well as the end user. Not having any built in system for letting the end user know that there is an issue with a lock is a serious flaw in my opinion. Take my scenario: there were times when the system said the lock was locked and it wasn’t (and vice versa). When I’m away, I’d like to believe what my phone is telling me about what is going on for every device. Apparently, I cannot. I’m just as worried I “left the iron on” now as I was before I bought into ST since the status of any device cannot be trusted. How can ST think this is OK? Same issue x10 with routines. What’s the point of telling me specifically that a routine has been run when there is absolutely no check to ensure it actually has been done?

I bought into SmartThings because it is completely programmable. I knew there were things I would want to do that would need some effort. I just didn’t know how many utterly basic functions have yet to be programmed by the manufacturer. Frankly, for a product that has been on the market for 2+ years, it is very disappointing.

2 Likes
9

@JDRoberts YOU my friend, are a great person to get a large amount of excellent info from and I appreciate all that you have contributed to in these forums! I just read this and was amazed by how well you summed everything up ( I MEAN EVERYTHING!) and I’m sure many people will have gained a lot of value and knowledge from your posts! Thanks so much! And ya, ST sucks at a lot of things, but it has kept this disabled Veteran from going CRAZY from not being able to work anymore, so for that, I thank ST for being the BIG pain in the ass that it is! :slight_smile: We can only hope that there are FAR better things in the works for us that will cure a lot of our pains and make this more of a reliable platform, versus something that really is no more than just a hobby at this point…

2 Likes