@Hank21 I have been tsting this for about a month now. I moved one of the two APs onto a POE injector, and put all equipemt onto a PDU that has measurable power distribution. 

So far, neither the AP on the injector or the AP powered by the switch has had a reboot event. The switch power draw has been stable over the last 36 days, and there have been no spikes in the power draw for the AP. I will probably move it back to the switch to see if that changes anything. If it does, I will swap the switch with another one toi see if that makes a difference. 

I'm still a bit confused as to why both work fine now even though onle one things has changed, even if none of the other PoE devices experince issues, but the switch is the common thread. 

I am chasing down some EAP670's that are having problems on my Cisco 2960X  switches. 

The exact same symptoms as have been seen here.

 %ILPOWER-3-CONTROLLER_PORT_ERR: Controller port error, Interface Gi1/0/20: Power Controller reports power Imax error detected
Feb 23 16:20:02.046: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/20, changed state to down
Feb 23 16:20:03.052: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/20, changed state to down
Feb 23 16:20:10.008: %ILPOWER-7-DETECT: Interface Gi1/0/20: Power Device detected: IEEE PD
Feb 23 16:20:10.749: %ILPOWER-5-POWER_GRANTED: Interface Gi1/0/20: Power granted
Feb 23 16:20:29.124: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/20, changed state to up
 

The AP is about 15ft from the accesspoint and is on a Cat6 general cable drop.

I am going to try using a inline power injector. and see if it resolves it. 

But I am very sad that TP-link is not providing a product that can comply with IEEE standards.   Its even more sad that this is seen on one of the "higher end" ap

Is there any power settings I can change on the AP that can keep it from surging?

Further detail - I have had one of my two EAP670 on a PoE injector plugged into a PDU for 60 days now without issue. The device using PoE ran without issue until 2 weeks ago, when it started exhibiting issues. 

Notably, there was no one in the location when this started as it was essentially closed for 2 weeks. It has continued to misbehave, not just the rebooting, but this morning it exhibited the old "I am running and announcing SSIDs and accepting clients but not briding" issue. So far, the device on the injector has been stable. 

I upgraded my controller to the latest and will upgrade the problematic AP to 1.0.15 today, as they have both been on 1.0.13 since January (1.0.14 was completely broken for me). We shall see if 1.0.15 fixes anything. 

nb

Well, the 1.0.15 experiment lasted 4 hours. As of 10m ago, the device upgraded literally 4 hours ago to 1.0.15 is disconnected from the controller. It is no longer pingable, but it shows up in the LLDP neighbors of the switch, and continues to announce SSIDs and seemingly has clients on two of the SSIDs. I would really like to know how extensive the regression testing is on the firmware of these devices. My configuration and design is very standard and uncomplicated and I have had nothing but heartburn with them. I am going to move back to what seems to be the only usable firmware for these devices (1.0.13)

And this is why I want them connected to PoE devices - when they stop working, the only way to get themn back online is to cycle power. This can be done manually (yuck), by cycling power on a PoE device or, if one is lucky enough, a controllable PDU. Like I said, I am very happy to provide whatever I can to make this work, but I don't feel like there is any sense of urgency on the vendor side. 

After moving both APs to a PDU I have, so far, seen no power related reboots and have 20 days of uninterrupted uptime. I still maintain that this is a problem with the AP software, no other PoE devices have issues on any of my installations using these very common PoE switches (aruba JL256A 2930F-48G-PoE+-4SFP+). these installations include other brand AX access points. 

Now that I am satisfied that these are reasonably stable, I'm re-attempting the upgrade do 10.0.15. So far, the only stable build I have seen is 10.0.13, which also contains a DNS bug that causes the AP to make a request for an A record with the contents "del" every few seconds. See: this post. 

Lets see if power is any kind of factor in the APs dropping all transit bridging capabilities (see here) 

I tried no end of changes ranging from turning radio power all the way to low to disabling LLDP and setting the max power output on the switch. I do not believe there is much as far as regression or compliance testing here. Otherwise, we'd not see the type of egregious issues that we're seeing.

It took 13 hours, 45 minutes, and 9 seconds for the AP to miss a heartbeat and disconnect running 1.0.15. I can't be the only one seeing this? It is *very* reproducable. Back to 1.0.13. Again. 

I cannot recommend anyone purchase these APs. I have had them just under a year and have yet to have a solid month where they aren't in some kind of problem state, and the support has essentially gone dark.  

@Hank21  any thoughts? 

  @ndb217  I tried the Access point on 3 diffrent managed POE switches that respect POE+,  each on would put an error or a heartbeat loss over time.

I have been told that the recomended solution is to us an unmanaged POE inline injector.   Not going to work in a manged enviroment, but its good for a few access points when the users a cheap.

More testing to be concluded.