Spurious ON or OFF signals (15 September 2018)

(Arun Gupta) #1

I am having a strange issue. Few of my lights are getting spurious ON or OFF signals hub. I can see it in the “Recently” tab of these modules. I have setup these lights to be turned ON or OFF at a schedule via a webCore piston, but these spurious signals are being received way outside of the schedule window.

For example, one light was turned OFF at 11:30 PM by the webCore piston. I personally verified that the light was OFF and it showed the same in “Recently” log. Then, as per ST “Recently” log, at 3:34 AM the light was turned ON. Where did this ON signal come from, I have no idea. Everybody was fast asleep at that time.

The second light was turned OFF at 11:30 PM, again verified personally and by logs. Then the light was turned on by the webCore piston at sunrise at 6:48 AM as expected. The light is supposed to stay on till 11:00 AM. As per logs, the light received a OFF signal at 9:14 AM. Then at 9:46 AM, the light received an ON signal. At 10:48 AM, the light received OFF signal. The OFF signal from webCore piston was never received at 11:00 AM. At 12:26 PM, the light received an ON signal. Again, I have no idea where these ON/OFF signals are coming from.

I have recently moved all the Z-Wave devices from ISY ZW hub to SmartThings hub. I excluded all the devices from ISY hub, factory reset all of them and added to ST. While the devices were on ISY hub, this never happened. The ISY ZW hub was factory reset and all programs deleted. So, it cannot be generating these spurious signals. It just controls the Insteon devices now.

I am at a loss as to where to begin troubleshooting. Any ideas, help, suggestions will be greatly appreciated.


This does happen from time to time, and sometimes the cause is never found. It’s mostly related to issues in the SmartThings cloud.

As you may know, on Friday and Saturday this week there were a number of partial outages. Sometimes what happens is that a command that is not sent during the outage (sent from the cloud, not from the hub) then gets sent from the cloud to the hub hours later. Very annoying, very difficult to diagnose.

You can contact support and ask them to look into it, but it can be very hard to diagnose.



BTW, if you search the forum for “poltergeist“ you can see other similar reports going back years. :scream: :ghost::ghost::ghost:

(DavidK) #4

Can you tel the difference between the device getting a command to turn off or on and another scenario in which the cloud thinks the device is let’s say on, and then later realize it is off?

Would the messages in the log be the same?

I have seen something where the logs shows on and then a minute later off. But I do not think (I think I do not know for sure) that the device did not actually change state.

I am reasonably certain that this has happened at least once, in which logs show on and off and the physical device did not switch.

(Arun Gupta) #5

Thank you so much for your quick reply…!! Now I know why there are concerns about ST reliability on the forum.

The ST hub is so versatile with community created DTH and apps. They add so much more functionality to the devices. webCore adds a whole new level of control.

Is there a way to have best of both worlds? Reliability of local processing and functionality of ST?



Very much a beta project, but some people are trying:

(Arun Gupta) #7

Only yesterday I was reading about the Hubitat hub on this forum and looked them up. Will explore this option further.

Thanks again…


Can you see in the recently tab what “sent” the command to turn on or turn off? If it is a WebCore piston, you will see something like this under “Recently” in ST:
NAME OF PISTON sent off command to NAME OF DEVICE.
That will at least narrow down if there is some problem with the construction of your piston that might be causing the problem.

(Arun Gupta) #9

As can be seen in the image, the Lights Timer is the webCore piston which sent OFF command at 11:30 PM. This is expected.

Then at 3:34 AM, the “Dining Room Deco Lamp” receives ON command. This is the “poltergeist” command. It is not sent by any piston. This is what confused me completely.



No, it doesn’t. It is on, which means it’s report back to ST from the switch. If someone didn’t touch the switch it is most likely a mechanical problem.
An on command would list an on command, just like the off does.

(Arun Gupta) #11

Thank you so much for your insight. I excluded/factory reset/included these two devices and so far, the mysterious messages have not been logged. I am not very conversant with how ST hub works, so your reply was very helpful in enhancing my understanding.