So for the last several days to a week or so my V2 hub has been exhibiting some strange and unusual behavior. It started with getting notifications my hub is offline during random times (day night doesn’t matter) I was coughing this up to my internet briefly going offline. I don’t think this is the case anymore, it looks like the hub has been rebooting itself. In the past 48 hours it’s rebooted 6 times, now one of those was me. Over the past several days the response time is very slow for some devices. My presence sensors would fire off down the street like they should and may not disarm the alarm for 20 more seconds.
Last night brought the issue to a head with my wife because she came home before me and I can see in the log the app recognized her arriving home at 4:55 and triggered the disarm routine. Then 3 minutes later I got a message from ST & her that the alarm just triggered. Looking in my log it saw her and ran the routine but it apparently didn’t actually run since the alarm didn’t disarm. So she pulled in the garage and the motion sensor in there tripped the alarm. The act of the motion sensor tripping told me something bigger was wrong since we have garage door controllers and it should have detected it opening.
Long story shorter I needed to go through my devices 1 by 1 and check them and like 6 of them were showing OK in the app but were unresponsive. When i was looking at the hub events I started seeing some new strange behavior not in the older logs.This is new in the past few days; here are some examples.
Lastly I’ve got 4 processes trying to communicate out pretty routinely a couple times a day which are aparently internal. My first guess are my Arlo cameras since I have 4 of them but the times are odd and don’t correlate with my arm/disarm for them.
I know this is a lot of info but if anyone has suggestions I’d appreciate it.
There have been several reports recently of weird Z wave behavior. The first thing would be to contact support, because they can see some things from their side that we can’t.
Yours sounds like a more extensive problem, since the presence sensors are zigbee and Arlo camera is Wi-Fi/LAN integration.
So I’m not really sure what to say. I’m sure it’s very frustrating. But I would start with support, they may be able to see something going on.
Meanwhile, here are some of the other reliability issue reports from this month, in case any of them seem to match yours.
The one thing that does seem to help in some cases, but not all, is to turn off the “device health” feature. This is a fairly new feature, and it does seem to create delays for some people.
Turning it off is one of those “can’t hurt, might help” things that you can try.
Note that if a device has become unreachable due to device health reporting issues, you may have to do a replace utility to get it back after you turn off device health off.
Again, that might not be related to any of the problems that you’re seeing, but it is something you can try.
So I’ve been running without the device health feature on and everything seemed OK for a day. Yesterday was uneventful in the context of this thread. Then at 0 dark 30 all hell broke loose again and a garage door was reporting it was opening (same one I found was not responding and had to remove and reinstall). The later moisture sensors started reporting a wet bathroom which set off sirens repeatedly. Through all this my wife is giving me more and more scowls. I think whats left of her patience for this is somewhere between these things ><.
OK, I have an interim update. got a response from support and was told this about my error code:
Err 120 is the code we use to identify stuck Z-Wave devices. Essentially there is an issue with a specific Z-Wave device and it is causing the system to get stuck.
Now for the 4 items I see called index 17 &18 popping up every 6 hours like swiss clockwork. I decoded the base64 log entry and I’m getting this:
HTTP/1.1 400 Bad Request
X-Powered-By: Express
X-ST-Application: Video-Core
X-ST-Version: 0.8.16.3
X-ST-Method: POST
X-ST-Url: /cameras
X-ST-Class: Camera
Content-Location: /dev/<SNIP Arlo serial#>
Content-Type: application/json; charset=utf-8
Content-Length: 115
ETag: W/“73-bf118a1f”
Date: Fri, 16 Jun 2017 17:21:17 GMT
Connection: closenr{
“missingParams”: [
“url”
],
“code”: 4,
“message”: “One or more required body params were not found”
}
It appears to be an error entry from my Arlo camera’s of which I have 4 hence 4 entries. Now the question is what is it trying to actually do? It looks to my untrained programmer eyes that it’s trying to check some website. But for what and why I don’t know.
Checking in with an update. On Friday (3 days ago) I followed the suggestions of the ST support team and removed the item that appeared to be hung up (the Aeon Labs Siren). Similar to another thread I commented on I was unable to remove it by putting the hub in exclusion mode via the IOS app. When I put the hub in exclusion mode via the developer website it removed first try. It may be isolated to my setup but that seems unusual. After removing the siren I waited several minutes and added a new device where it was found right away pressing the button. I also found that it updated to the overall awesomeness of a DTH for this device that I never implemented by Kevin @krlaframboise found here: Aeon Labs Siren DTH.
I’m happy to say that while the turning off of the device health didn’t fix my problem (can’t say it didn’t contribute though) the removal and re-installation of a single items so far seems to be working for me after several days. I didn’t think to try this with the siren before because it would still work when it was needed. If anything changes I’ll follow up on this thread.
schemas-upnp-org:service:WANIPConnection:1, ssdpTerm:, ssdpNTS:
But I would start with support, they may be able to see something going on.