They are on a couple of doors and are “supposed” to trigger lights in several rooms. Sometimes they work well; sometimes there is a long delay in the trigger. Long delay = 30 seconds up to 2 minutes.
I’ve opened the door and watched the history using SmartThings® API Browser+. I’ve had consistant delays today in the 30/40 second range. One of over 1 minute.
What steps can I take to rule out possible issues?
These sensors were in use prior to the Driver days, and were updated by SmartThings. The driver they used is Z-Wave Sensor. I don’t recall what DTH they used to use.
Being that these devices execute locally, I would expect a much faster response.
UPDATE:
I swapped out the Wink Sensor for a Zigbee sensor I had in a box. I used the same rule, (very simple-- If sensor “Open” turn on “switch”).
It worked almost instantly. That was 3 hours ago. Just now I opened the door and just waited… it took 20 seconds to turn on the light. I guess I ruled out the problem being the sensor.
Any thoughts on the SmartThings V3 hub being the problem?
Multiple people are reporting major delays with the newest hub firmware update, which has been rolling out very slowly over the last couple of weeks. Not sure if that’s related, but it might be.
I am still new here and getting my feet wet. I searched, but only found horror stories. Is there any way to temporally pause hub firmware updates to avoid a problematic version? My v2 hub is still humming along nicely at the moment running 000.048.00005.
Unfortunately, not. Smartthings pushes out hub firmware updates whenever they want to, sometimes not even announced, and we as customers are not given any options to defer or deny them.
In the past, they have expressed some concern that since smartthings is still largely a cloud-based system, if they let individual customers be on different levels of the firmware then someone might get stuck with a hub that could no longer communicate properly with the cloud, and there would be no way to fix it short of physically sending in the hub, which they don’t want to do.
But in any case, the short answer is there just isn’t any way for us to do that.
Thanks for the prompt response. This really is no surprise, I was just hopeful. I finally have things running smoothly for the first time in the past few years, at least with the hub… the SmartThings website is another issue altogether. Oh well, I will just keep plugging along until I can’t take it anymore.
Hi,
I don’t have information about that, I just shared your comment and this thread with them.
I’ll let you know in case this requires more information.
The engineering team mentioned this requires further investigation, so, please help us provide the following:
Replicate the delay issue
Take note of the time the main device received an event (not from history, I mean physically, for example, when the sensor opened/closed) and share it here (eg. 17:00 CST)
Share the name of the routine that was supposed to trigger after that event
If the delay happens, share the time when it actually executed the routine (eg. 17:05 CST or 40 seconds later)
Enter the corresponding Hub and click on “Dump Hub logs”
Confirm the process by clicking on “Dump Hub logs” again in the pop-up.
You’ll get a green box at the top confirming the Hub logs were requested.
Enable support access to your account
a. Confirm the email account registered in the forum is the same one you use for SmartThings. If not, please share it with me over DM
b. Enable support access to your account:
Select the time period and confirm - In this step, please select “Until turned off”, once the team finishes, we’ll let you know so you can disable it again.
@Jeff_Gallagher, what do you mean by a delay in “processing data” in your post?
Just as a reference, the API endpoint of “history” which I think is the one used by Todd there doesn’t update live, so, it’s normal you don’t see the event until a while later.
To see if an event is being received on time from the device to the Hub, you can enable the driver logs using the ST CLI and the command edge:drivers:logcat
I just replicated the delay. The local time was 5:19 PM EST. on 9/5/2023
The contact sensor named Laundry Room, DEVICE ID: a8f50a26-b1aa-40c9-b106-10bfaa483a51 was opened and it triggers lights to come (Basement Stairway Lights, DEVICE ID e9bf2fde-393e-4f70-9a8f-635466228b13). I used a stop watch on my phone to time the delay. From the time the sensor opened to the time the lights came on was 21.04 seconds.
The rule that turns on the lights is a SharpTools rule that does nothing but trigger that light switch.
I dumped the logs.
I’m still concerned about the 11 “UNKNOWN DEVICES” that showed up after a Z-Wave repair. Are they thinking this is related?
Thank you for the information.
I’m not sure about the unknown devices, I mentioned it in the report I created to take it into consideration during the investigation
Once we get more info, we’ll let you know.
The Issue only happened after the installation of the new version on the Hub. So I can’t replicate the issue. After the installation of the new Firmware, on Saturday the 9th. All routines were delayed for 2 - 3 minutes and continued for a few hours. A reboot of the hub seemed to help for a while.
ON the Sunday a 2nd Hub was updated, and again for 4 - 5 hours the performance was terrible.
I have some more details to share and I hope this helps.
At aprox. 9:06 AM ON 9/7/2023 (today), I opened the door with sensor named Laundry Room, DEVICE ID: a8f50a26-b1aa-40c9-b106-10bfaa483a51. It should have triggered Basement Stairway Lights, DEVICE ID e9bf2fde-393e-4f70-9a8f-635466228b13. It did not. I left the contact sensor open for about a minute to see if the lights would come on. They did not. I closed the door and reopened it and the contact sensor triggered the switch to come on.
I went into the SmartThings Advanced Web App and noticed that the first instance of the door opening was not listed (around 7:06 AM), but the second one was, (around 7:07 AM). I dumped the logs.
I am assuming that when this happens, the hub is not receiving the event from the contact sensor, or the hub is not processing it…
In this last test, did you submit the Hub logs? It is important that you send them to see the activity there when you triggered the open/close event and its processing.
It would be useful if you could enable the driver logs of the contact sensor and Basement Stairway Lights to see if the events are shown there. You would need to share those logs (in a file) with us. Then, send the Hub logs so the team can compare what it’s seen in the driver and Hub logs.
For the driver logs, you need to set up the ST CLI and run the command below:
smartthings edge:drivers:logcat --all
Copy those logs in a file and share it with us, you can send it to build@smartthings.com.
Note: We use the --all flag to get the logs of devices that have currently some activity (from any driver) because in this case, both devices are Hub-Connected but use a different driver and need to get their activity at the same time.
I sent you a DM, please check your inbox.
Also, do you have a routine registered in SmartThings with this issue as well? It would be important to know if there’s also a delay with automations not coming from third-parties.
