Global system failure today, 2018/Feb/18?

I’ve one custom smartapp that has been working ok during months. Today 2018/Feb/18 it is out of order. A second smartapp also presents same issues at same time.

Individual devices seems ok, it is possible to connect and use them from mobile app. Moreover, its events are logged in the monitor window of the mobile app.

The app fails even when using the simulator with the real hub but virtual devices: it is installed/updated, but events from devices (physical or virtual) are not received nor log messages from the callbacks appears.

Everything is ok in the virtual location / virtual hub.

Is smartthings having a global problem (UK area) ?

Recovered. After remove smartapp using mobile app and installing it again, everything again ok. I do not known if this action has been the cause of the recovery or a global failure has been solved during this time.

There has been no issues for me today (UK).

There are issues everywhere today. My own LAN was down, lots of websites are down… I don’t think this is exclusive to ST

EDIT; oddest thing… my router reset all my internal IP addresses, due to a conflict with my ISP!!

Apparently, the ISP is no longer allowing local addresses other than 192.168.1.x

Mine was 192.168.5.x.

I’m gonna have to rebuild and edit all my devices and configurations, which are hard-coded wherever possible.

mine went out last night as well looks like about 2018-02-18 12:56:06.433 AM MST

I’m not seeing any widespread reports of internet outages. Sounds like that part of the problem was localised to your ISP.

I’m not sure about any smartthings – specific outages.

I should have been clearer definitely SmartThings issue in my case
SmartThings fob presence sensors kept departing and arriving continuously similar to what happened in the January 03/18 outage. Does not list any incidents

Sunday probably no one working
I submitted a ticket
it appears to have fixed itself at 1:28:24.600 AM MST
no other zigbee devices appear to have been affected just the SmartThings presence sensors (I have a couple for the kids)
they all came in and out just fast enough to trigger routines but not disarm the alarm system, setting the alarm system off at 1 am (even though disarming the alarm is part of the routine)
one of the routines is to open and close a garage door for them so when it re-armed and the door was half open it set off the alarm.

That particular problem is often local Wi-Fi interference, particular if you have boosted Wi-Fi. I ran into that myself and it wasn’t even my own Wi-Fi system – – apparently one of my neighbors has boosted Wi-Fi and pretty much every weekday afternoon about five minutes after the school bus came by my arrival sensor went bananas. I worked with support on it for about two months but there just wasn’t anything we could do since I had no control over that Wi-Fi implementation.

It’s similar to what happens when someone uses the microwave and Netflix starts buffering. The signal can be flooded even though they’re not on the same network. :scream:

There is an option in your account to change the detection time, And making it longer can sometimes allow for Handling dropoffs due to local interference. Support will probably suggest trying a change there if you’re not already at the maximum. Basically it’s the amount of time the system waits before marking your arrival sensor as “away.“

does that setting only affect departed or does it delay arrived as well?

I also just noticed that the sensors are on DH type: “Arrival Sensor HA” which for some reason is cloud based I set them to just type: “Arrival Sensor” and they become local will see if that fixes them as well maybe even speed up their response time.

1 Like

What?! Your ISP has no business determining what your internal lan ip setup is, unless you’re using their provided router and they did a firmware update. My advice is always own your router so you have control, if that’s what happened.

Wow your ISP only gives you private ips? That’s nuts. Where are you? At least here in the USA I have never seen that happen, nor would I pay for a service like that.

The arrival sensors are super simple devices. The only thing they do is check in every 30 seconds. Seriously, that’s all they do. Then it’s the cloud (or now potentially the hub for the local DTH version) Which tracks how long since the last check in, and if you go past the set threshold, it just flags the device as “away.”

So if the problem is local interference any interference drowns out the messages that the arrival sensor is trying to send a check in for long enough that the account marked it as away, then as soon as the interference dies down and the next message gets through, the account marks it as back. So this is how you get that rapid fire away/home/away/home/ pattern When the sensor itself hasn’t moved at all.

The parameter just lets you change how long the account will wait before it marks the sensor as being “away” after it hasn’t received a check in message.

1 Like

Well using DH type: “Arrival Sensor” so it was local doesn’t work for the newer presence sensors
Had to go back to DH type: “Arrival Sensor HA” and the cloud. Hopefully setting it to 5 minute delay fixes it but if we have any extended server or internet outages will likely cause the sensors to depart and arrive.
Will have to see if I can get the sensors working on Hubitat when it shows up.
It could be wifi related but they work 99% of the time. Only time I have noticed them do this is when others have posted system failures.

1 Like

Crap, I would be in the same boat as you. I set everything to 192.168…40.x…granted for no reason other than that helped me track the devices as I ported them from my old router to my new router.

But why does the ISP care what internal IP addresses you use? They are internal and everything in the 192.168 family is private, so why just 1?