All:

 

Let me remind you that this is NOT an app problem.  It cannot be for anybody having an Alexa issue.

 

1)  I've proven the switches talk ONLY to Kasa servers (hosted by AWS).

2)  We know Alexa is at least included in reporting to devices on or off line.

3)  We know (or you should now), that the smart app running on your "Fill in the blank" is only a management interface for you.  It is NOT running your switches or the logic they execute.

 

Had the problem been exclusily related to the ap then yes, it was possible it was an app issue.   Example:  How long does it take to populate the App screen, screen freezes, etc.  That is clearly not the case is most aspects here.

 

I cannot say with any confidence if this is a backend issue or wifi comms issue yet.  I need TPLInk to answer open questions.  I can say this at the very least:

   1)  As devices rebooted many (all I tested) returned to very low ping times and very good signal strength readings.   "Something" had seriouly deprecated their performance.

   2)  When something like this happens network comm is always the conduit of corruption, and usually is corrupted itself.   

 

Guy's, I've spent most of my life in IT, and quite a bit in network.  Read this next part carefully:  All we/you can say is "other devices were not noticebly affected".   The odds are very high that, at least in my case, rogue Kasa devices F'd up my Wi-Fi sufficently that the Kasa's back-end couldn't keep straight status of the devices (and reported same to Alexa), while other wifi devices (presumably with better/more stable drivers and better back-ends) remained operational.

 

In fact, it's entirely possible, even probable, that the Kasa switches were in fact going back and forth in status.   Here we'd need to know what triggered that error state exactly, but it's pretty likely screwed up wifi comms was forcing a condition that the back end interpreted as "offline".  My guess?   Excessive dropped packets and / or  missed replies to periodic polling from the backend.

 

At present I'm inclined to tell Kasa their network drivers are beyond bad.  I also suspect they have poor error trapping in the backend, although if the devices availability was flapping, as I suspect they were, there isn't a lot they can do to buffer that.  That said, Kasa has much work to do.  At the very least:

 

1)   Get us better network drivers!

2)   We need a schedulable "auto-restart" routine we can implement that returns the device to it's previous state.

3)   It would be nice if there was a summary report available that showed device signal strength.

4)   It would help if the device info screen showed the device IP address.

5)   You really need better information for us on error messages.  EG:   What event triggered the "offline" conclusion?

6)   Devices should be enough error trapping that they can detect their own error state and reboot themselves.

7)   For that matter, any device, and this has come up in many aspects on many posts, that doesn't receive a regular "I'm here" from the backend should restart itself.

 

@Riley_S 

Comments?

I need this answer sir:

 

Q1)  "When a switch restarts is it pulling its configuration from itself or from the cloud?"

 

 

OK - my "success" with the Android test App was short lived (approx 28 hrs behaving normally) 

My wife just came through to tell me Kitchen Sink Light not responding 

Actually have a bunch of my Kasa devices that suddenly dropped off again from both Kasa and Alexa Apps - here is sample, plus some specific on the aforementioned Kitchen Sink Light, which still shows connected in my Asus Router Network Map (refreshed to be sure it is still connected) 

 

 

 

 

  @DEcosse 

 

re:

 

"Try rebooting your router and see what happens - this should renew the local IPs by DHCP "

That's mostly incorrect, but may happen that way in some circumstances.

 

A DHCP client will request a renewal of it's existing device when it's lease period, usually 24 hours, passes.  Rebooting a DHCP server will have no affect on lease expiration.  

 

Technology tangent:  In fact, rebooting a DHCP server is sort of a pita.  The server comes back up with no idea who has what address.   Which is why the later DHCP server feature of "conflict resolution" is nice.

 

It's at least possible a client might initiate a renewal request if/when it disassocaites, was would happen with a router reboot.  This might look, for a guy running only one router and DHCP services on the same box, to be the same thing.   It's not, and on bigger networks it would not.  My house, as an example:  Devices, as one example, associated to other AP's would never know, and none of the devices ethernet attached would know either.  The coming and going of the DHCP server would, to all of those, be invisible (so long as their lease didn't expire).

 

Hope this makes sense somehow.

 

all the best,

 

-d

 

 

 

DE:

 

Well that sucks.  I was hoping for your own sake it was fixed.

 

Consider power cycling your home.  At this moment I suspect we're (well, at least me) being victimized by local deprecation of Kasa devices.   That said I've seen other threads were other devices affected the Kasa backend, so that too remains possible.

  @rmhart 

 

Rebooted my router.  Still had several offline.  I reinstalled them and now online.

 

I usually have much better success with the app when on my home network as opposed to remote.

 

I would like to know what changed about a month ago.  All was stable up to then (at least for me).

 

Guys, 

 

Read this

 

 

Whatever they chucked up corrupted a whole bunch of stuff...

 

 

Rebooting a router won't usually do much.  (see above discussion).

 

Power cycle the house is the fastest solution, although it wont' detect device configs that have been corrupted.  You need to watch the reload and cofirm a "green light" reboot and not an "orange light" reboot that indicates an error state.   Which required a reset and reconfigure.

 

None of this changes my "your drivers aren't any good" comments

  @dafish I'm pretty sure if I Just reboot my Router they will all come back - I've done this a couple of times now to recover the situation, the last time was yesterday an hour or so before I applied the new App - I believe now my temporary 'success' over the last 24 hrs was down to this, rather than the App 

OK, so just did that and sure enough, both apps populated with everything back online. 

 

Incidentally while it was still showing all the offline devices, I tried first a different WiFi connection to my phone (directly to the cable modem rather than the Router) and then turning wifi off on my phone, so using the Cell Network connection. Made no difference in either case to the status of the devices in either App, even with a refresh. 

 

Since the devices appear to remain connected to the Router, I have to think that they should be but are not being seen by the TP-Link server - or the server sees them but does not relay that info back down to either App

 

i.e. I think that once you have set up the device, the communication goes from device via web directly to the server, NOT from the App - and then comes back to the apps. 
So again, the problem is at the Server end I would have to say. 

 

p.s. Rebooting the router is obviously not resetting the Devices communication with it, since they were showing good already - but somehow is re-establishing a new link back to the server. 

  @rmhart 

 

I know of no reason, aside from an occasional bad network, why your phone/tablet/whatever and associated app work better on the same network vs remotely.   There is certainly no intrinsic reason for this.

  @dafish 

the only thing I can figure has to do with the remote control settings. However, I have no idea how to access that setting.