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.
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.
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.
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.
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.
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.
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?