ALL Zwave devices dropped, module dead, hub replacement on the way, I'm gonna be sick

Devices & Integrations
21

I had to send my hub in, and that got things back in sync. Has that option been given to you, even though it’s inconvenient?

I have 292 device (only 3 are virtual), and use to have tons of those messages. Since my original post I have literally gone through every device and DTH to weed out as much message chatter, and to get to a clean mesh.

I have discovered that my energy reporting devices, which I have a lot of, where the single largest contributor of my problems. I had those reporting way too frequently, and it didn’t raise a problem until I added almost 8 additional energy reporting devices.

As I slowly started to get those new devices online, and configuring them like I did all the others, I started to see more and more “err” messages, and eventually more zwave radio restarts, and eventually significant performance issues.

Because of the number of devices I have that can cause a lot of chatter on the mesh, I had to rethink my use of the data I was getting to determine and what value that was providing. It wasn’t much to be honest because I just don’t have the time to analyze all that data yet, and the automations it was feeding were pretty basic.

3 Likes
22

Do you believe you were overrunning the ability of the system to handle message traffic, John? If I read correctly, that would be on the device protocol transport (ZWave or Zigbee), rather than the cloud side?

Hmmmm…

1 Like
23

I’ve tried to avoid getting into this discussion in the past, but to be honest, energy reporting devices are pretty much antithetical to the whole concept of a mesh network. I know there are a number of them made, and I know they are popular, but they just aren’t a good match.

Mesh networks are intended for Devices that send very small messages and send them infrequently. A light switch is the classic example. Even the sensors that report have pretty wide gaps in how frequently they report, just to keep from overloading the mesh.

Mesh networks are also intended for situations where the devices are not on a synchronized schedule. You don’t want all your devices to wake up at the same time and try to send in a report, it creates traffic jams.

Energy reporting that happens once an hour, or once a day, shouldn’t be an issue, particularly if you set them up so different devices are on different cycles. That is, they don’t all try to report at the top of the hour.

Energy reporting that happens every minute is likely to be a problem. Obviously, you’ve increased a lot of traffic on the mesh, but you also have problems because that particular device is probably marked as a repeater in your system, but it will be too busy with its own reports to do the repeating for other devices, and that creates additional inefficiencies in the network.

Also note that the problem doesn’t happen until the device tries to report to the hub. If it’s just recording the information in its own internal log and then you’re picking it up a few times a day, you could record values for every minute and it wouldn’t matter. What matters is how often the device reports to the hub, because that’s what generates traffic on the network.

Speaking just for myself, if I needed energy reporting more frequently than once an hour, I would use a Wi-Fi device, not zwave or zigbee home automation. But that’s just me. :wink:

4 Likes
24

Just a statistic from ActionTiles:

As our number of customers have grown, we were able to do more analysis on the traffic and load on our Platform. We figured out that Energy & Power made up over 85% of all SmartThings Events.

SmartThings’s power-reporting smart outlets (and/or their DTHs) are set to report far too frequently (i.e., they are far too sensitive to tiny deltas in power utilization … fractions of a Watt).

It is beyond my comprehension that SmartThings hasn’t made this observation and determined that this is an extreme waste of resources of the SmartThings Cloud (and household’s local ZigBee networks and Hub). Tuning the DTHs to report fewer events is pretty easy.

ActionTiles has implemented filtering in our SmartApp to discard relatively trivial Deltas in power values and that saved us a ton of expenses.

1 Like
25

Yes, I have noticed in the logs that you have thresholds set before you will allow an updated value to reflect in AT. Is this documented anywhere? I spent hours a while back trying to work out why certain changes were not updating in AT.

Many DTHs causing this are not stock handlers so what is ST supposed to do? Impose limits somehow?

26

No. That’s just an engineering analysis — and it is sound, JD! No argument here…

But, like it or not, it is what it is: a lot of devices exist with the “wrong” protocol. (I worked with a hardware engineer once who always used i2c even when other protocols like SPI or even a TDM channel would have been “better” — he was kind of a One Trick Pony!)

What I think I’ve learned from your protocol discussion as it applies here is:

  1. don’t go nuts with lots of devices that generate lots of traffic, and
  2. think of “tuning” those that might/do generate a lot of traffic.

Folks with lots of devices may see issues earlier than others. That’s pretty clear.

Some devices — you mention power monitors, but others exist, as well — can be throttled to reduce traffic. I don’t have lots of devices, but I have line-powered temperature/humidity/motion sensors in both of my locations with report rates cranked higher than defaults. These same devices report lux (do I really need lux?) and UV index (useless indoors) that could report less often or be totally disabled.

Good food for thought, JD, thanks :sunglasses:

2 Likes
27

Not documented, but we figured power-users would check the logs :wink:, and others would contact Support@ActionTiles.com. Our KB/FAQ section of our support site is where we will document it … if it becomes an actual “Frequently Asked Question”. We informed our Beta participants of this change and none of them had any concerns, so we avoided rocking the boat out in Production.

Yes… I definitely think that SmartThings should impose limits.

But frankly, the vast majority of SmartThings Customers do not use “non-stock handlers”. They use the Add Thing function in the SmartThings App and don’t even know there is an IDE to login to. So that would cover most of the excessive data.

1 Like
28

No doubt, Terry, you’ve noticed all of the useless logging left in stock handlers quietly generating logging traffic in the cloud, taking cycles that benefit no one. A ‘Debug’ switch in each handler would turn down the noise for all but the instance being debugged. Support could use it; power users could use it; developers could use it — and the vast majority would never know or care…

2 Likes
29

@Barkis, @tgauchat, @Nezmo, @JDRoberts,

I’m stuck in Atlanta’s airport, with time for a quick reply.

I agree with all your points. Every single energy metering device has been set to report based on a large percentage change instead of watts change. Now on to the zigbee iris plugs.

4 Likes
30

Without a migration/Backup/Restore tool how does Smartthings expect you to move to V3 hub if one should ever come out? Wonder how you market that new hub version informing people you need to manually reconnect all your devices…

31

I’d say at least 100,000 Hub V1 customers went ahead and purchased Hub V2 despite the lack of migration tools. Or put another way, I’d say at least 70% of Hub V1 customers migrated.

The lack of a migration tool must not be a serious impediment to Samsung-SmartThings’s goals; otherwise such a tool would … exist.

2 Likes
32

SmartThings to current users: drop dead.

2 Likes
33

I was recently having a discussion with @ajpri about this. He inspired me to start doing this with my DH. I have recently updated one of my biggest offenders.

@ajpri has done the ST power sensor.

This is why I suspect they have not created a v3 hub. I don’t think there are enough people (yet) for them to make money off a v3 hub if 90% of us don’t upgrade because we don’t have a migration tool. Yes, I think a lot upgraded to v2, without a compelling reason to upgrade to v3, I suspect we will all stay with v3 without a migration tool.

3 Likes
34

Not sure why they have not even come out with a monthly subscription option for better support and back/restore/migration utilities. At least there would be something. This would also bring in revenue for them.

35

no they did not give me that option… did it work… was it intact… how long did it take. id gladly do overnight mail and be withoutu for a week if they could do this?

36

John, Were you able to modify any of the ST smartplugs to lower the reporting?

37

@ajpri already did this.

4 Likes
38

One Question does this surppress the info from showing or remove/stop it all together?

39

He gives options in the device setting to prevent the messages from displaying in the activity feed. I have no idea on the actual impact to the ST infrastructure, I’d suspect there is some positive impact.

Basically, in the sendEvent method there is a parameter called displayed. Instead of hard-coding it to false, you can use a value obtained from the device settings.

sendEvent(name: "switch", value: "on", displayed: false)

1 Like
40

Because their target market aggressively opposes monthly fees.

If backup / restore were available only for a monthly fee, the majority of customers would be upset that it wasn’t added for free to the “lifetime” service they presume they purchased with their Hubs (despite the fact that the Terms of Use clearly allow for fees to be added for anything at anytime).

We don’t know what Samsung-SmartThings’s long term strategy is; and add-on fees sure don’t seem like a crazy idea … except to the majority of customers.