@Steve28 - I’m going to have to do some more thinking on what could cause the flow you laid out. I would not expect force quitting the app to make any difference. When the app launches (or returns to foreground), we activate the GPS to check the location and then create an event if anything has changed. I would have expected step #1 to fix the issue, but then really would have expected #2 to do it if #1 hadn’t because we also activate the GPS and check again when pull to refresh happens (even if you aren’t on that specific device detail page). Like I said, I’ll think more on it and see if I can come up with an explanation.
In regards to the events you were seeing, here’s what the different things mean:
Grey BG event == this is a device event we sent to the phone, but marked as display=false to make it not show in the feed. We do this in several scenarios, but most commonly when there wasn’t a state change. That way, if we poll a light and it is on, but was already shown as on in the interface, we don’t show another message in the feed saying it is on. Doing so would eliminate your ability to reason about when it turned on.
Blue BG event == an internal message from the phone showing what it is doing around managing registering you as an active user, keeping your socket open, etc.
“iPhone Active” means we’ve gotten an event from the phone within the past several minutes. This is something we use internally to track if we’ve heard from a device recently. Eventually this will show in the UI as well and alert users to devices that may be having problems. We haven’t done that yet because some devices (like phones) aren’t very chatty and we don’t want to alert users to a device that is working as expected.
“iPhone Inactive” is the opposite (duh) of active and means our health check service has not heard from the device recently.
“Replacing client registration” means the phone has gotten an updated client code from the server.
“Received new client registration” is just the ack that the server heard our request for a client and it gives us a new client code.
“Socket is Unhealthy” means our internal check has determined that the socket is no longer open. When it isn’t open you cannot get any real-time events.
“Registering with Client Connect” happens when the phone first launches and wants to register to get socket events.
“Registered with Client Connect” is just the ack that the server heard our request for registration.
All of those messages are pretty normal and don’t seem to indicate any particular problem. When you are looking at the feed (at the top level), do you see some events flowing in? Multis, for example, send quite a few periodic events, so if you watch for a couple minutes you should see some events coming in. Or you could trigger a motion sensor. Just something that proves to us you are getting events over the socket.