Command received but not executed

Any ideas for how to make Smart Things more reliable?

I’ve got a new hot water recirculation pump that I’m trying to control with smart things, but I just discovered that, while the trigger in my WebCoRE piston fired and sent the off command to the GE z-wave switch which controls my pump. The command seems to have fallen on the floor and the pump never shut off.

Luckily I discovered this after only an hour or so, and just before going to bed, or the recirc pump would have run all night, causing my tankless hot water heater to run all night.

These kinds of things absolutely CAN NOT HAPPEN Samsung, not if you want this platform taken seriously as anything more than a toy. You can’t just drop sh*t on the floor.

I see in my device for the pump in the smart things interface that it received the command from my piston, it just didn’t execute.

Is this a z-wave problem or smart things? How can I ensure this never happens again? Do I really need to start spamming every command 5x times to ensure that I can actually trust my programmed logic?

+343ms ║║Executed physical command [Hot Water].off() (17ms)
+344ms ║║Executed [Hot Water].off (19ms)
+347ms ║║Cancelling statement #5’s schedules…
+360ms ║║Executed virtual command writeToFuelStream (5ms)
+362ms ║╚Execution stage complete. (51ms)
+363ms ╚Event processed successfully (363ms)
  1. Where exactly is this log from? The IDE? SmartApp events or Device events? Live Logging?

  2. “WebCoRE” is not an official SmartThings App and you won’t get any support from SmartThings for issues related to it at all. You may have to isolate and replicate the problem using a bare bones SmartApp or an official SmartApp like SHM or Smart Lighting.

  3. Z-Wave (and ZigBee) does not have guaranteed command delivery. Furthermore, SmartThings uses an asynchronous message model and that further emphasizes that guaranteed delivery is not a characteristic of the architecture of the platform and this is explained in the Developer Documentation. It is the responsibility of user and/or SmartApp to “listen” for a result even back from the Thing to confirm it changed to the desired State (unless it is not critical that the State has changed, in which case, don’t bother checking).

2 Likes

Great advice by @tgauchat. Following up on that, I suggest that if you’re going to use CoRE you add another task to check the status of the switch after 10 seconds then take the appropriate action if the switch has not occurred.

Isn’t using WebCoRE to check up on WebCoRE kinda like having the fox guard the henhouse? :grinning:

What about a Smart Lighting rule to turn off things like the circulator at a reasonable time every night (in case WebCoRE didn’t do its thing)?

For example, while I have a “goodnight” routine that turns off all the lights and locks the doors at 10:30pm (after my “usual” bedtime), I also have a catch-all Smart Lighting automation that does the same thing (rather than invoke the bedtime routine) at 1am, just in case.

Mike

1 Like

I can see that the message was attempted in the smart things IDE too, so webcore is not the problem, it was just simpler to see the sequence of events in webcore’s logs.

I was unaware of the asynchronous nature of smart things, or of the limitations of z-wave. Both, it seems to me, make the platform significantly less reliable. I guess they can claim this is a feature not a bug, but as user’s installs get larger and more complex, more and more people are going to come to see guaranteed delivery and state consistency management as the responsibility of the platform. Just my opinion…

I guess the upshot for me is to not rely on WebCoRE triggers, and to always back them up with a state condition.

Dunno man, with the Blink acquisition by Amazon last week and their sudden cancellation of SmartThings support, it’s suddenly dawned on me that Amazon might be targeting this space. A little competition for Samsung might benefit us all.

Yeah I actually have a catchall safety piston like that.

I just added this pump a day or two ago. I just added the hot water heater a day or two ago for that matter. It’s my first attempt to use smart things for something that actually has to work reliably or bad things happen. Equipment can get damaged, large sums of energy wasted, etc.

It appears that I’m going to have to add in a couple more sensors to monitor the state. I guess my only question now is for the webcore forum. Are “conditions” safer than “triggers”? A trigger fires a one time event, but if that event is dropped you’re screwed. A condition, it would seem, would fire again as long as the desired state isn’t true. I just need to verify that.

Indeed, an IoT platform that doesn’t result in expected actions “most” of the time (i.e., Actuators react on sent messages, and SmartThings receives messages from Sensors) is useless.

The crux is the definition of “most”, under what conditions it varies (i.e., how likely is it that the SmartThings cloud and/or local home’s networks are unreliable), and how easy it is to mitigate.

SmartThings added the Device Health Check “feature” as one way to mitigate issues. Unfortunately, per many folks’ observations, it often seems to cause more trouble than it solves.

But I would not assume other platforms do not also have similar issues - or worse.

Very true.

The reality is there are several factors that affect system reliability. Many are common to all platforms due to the underlying technology or even the users own environment. While the ST cloud can and does have its glitches, I have learned through experience that some can be attributed to local device communication problems.

Competition is great, and from it we will all benefit. But speaking in practical terms, I highly doubt Amazon has some magic technology that is going to revolutionize the reliability and stability of home automation overnight. After all, as with SmartThings, Amazon is still using a cloud-based architecture connected to a hub with Zigbee radios for integration with HA devices. Plus, they don’t even support Z-Wave, which locks them out of a significant market of 3rd party devices. A limitation I suspect was intentional.

1 Like

I wouldn’t expect magical technology. I’d expect what Amazon always does, workman like progress with a customer focus. They’re not technical geniuses but they deliver sound implementations of existing tech, with a fanatical focus on customer satisfaction, something I don’t get the sense that Samsung is all in on with SmartThings. To me it feels more like a strategic placeholder for them.

That is all well and good, and I happen to agree with you on their excellent customer service. However none of that is going to make any significant difference in ensuring that your light switch turns on and returns the proper status. As I said, there are just too many variables that even Amazon cannot control.

1 Like

Have you ever seen the robots at work in one of their warehouses?

I’m sorry but there’s just too much non-deterministic behavior in SmartThings. It doesn’t have to be this way. It only is this way because Samsung allows it, primarily by not insisting on better results and providing the resources to achieve them.

I’ve seen their robots, and have also on 5 occasions this year alone been the recipient of the wrong item from that which I ordered. It could be argued that people made those mistakes so anything is possible.

I agree, there’s a lot of room for improvement with SmartThings, and I’ve been a frequent critic of the platform and management.

Getting back to your original problem with the switch not operating when commanded, there is absolutely no guarantee that if Amazon built a similar system that it would work any better. You just don’t know where the fault was in your instance. Was the message lost by the Z-Wave network? Did the switch receive the command but ignore it? Did the switch receive the command and ACK it, but still not switch? Did the switch hail the proper status?

There are too many external variables on your one example to just blame only SmartThings as the fault. They deserve a fair share of criticism for sure, but there are other factors too.

1 Like