I'm running Kasa node server 3.3.27 on Eisy with PG3x 3.4.18.

Two Kasa smart bulbs can be switched on and off through Alexa, but Alexa cannot adjust their brightness.

Testing Dan's Lamp (node n008_58d81288ee81) produced the following results:

• Alexa sends DON/50, confirmed in the PG3x log.

• The Kasa node server acknowledges receiving DON.

• The bulb remains at 100% brightness.

• The IoX Admin Console successfully adjusts brightness using SET_BRI.

• My own application also successfully adjusts brightness through the IoX REST interface using SET_BRI with values from 0–255.

• The ISY Portal mapping is configured as category Light.

Is the Kasa node server supposed to support DON with a brightness parameter, or is there a compatibility issue with ISY Portal's Alexa integration?

Thanks.

It should, but the bulb could be incorrectly identified. Please download log and PM it to me with a reference to this post.

Just pushed production 3.3.36 to fix this issue and it includes a bunch of changes that have been in beta for a while.

Kasa 3.3.36 — Alexa dimming fixed, but status queries failing

I upgraded the Kasa plugin from 3.3.27 to 3.3.36.

Good news: Alexa can now successfully adjust brightness on both KL135 bulbs (Dan's Lamp and Adrianne's Lamp).

Remaining problem: The Eisy Admin Console does not reliably update the bulbs' brightness status. Pressing Query produces:

TCP client read response failed [NS-8-Kasa]

The problem persists after reloading the Kasa profile and restarting the Admin Console. PG3x reports the Kasa plugin as Connected.

I've attached a new diagnostic log package. Analysis of the log found:

• A debug.log approximately 1.04 GB in size.

• Over 1.4 million handler_data entries.

• 87 error entries and 26 traceback markers.

• Communication timeouts involving both bulbs.

• Repeated configuration save/reload activity.

The excessive logging and communication errors may be related to the failed status queries, although I cannot confirm the cause.

The original Alexa brightness problem appears resolved, but status reporting and manual queries still need investigation.

Kasa_3.3.36_Diagnostic_Excerpt.zip

Your AI should know that the authentication issues are a know problem since Kasa switched to a new method and the python-kasa library I use is working on support but it has not been released yet. I could fix the plugin to be less noisy about this if I find the time but hopefully the new library will be released soon.

OK, I am a little confused. My AI acknowledges that it did not know about the KASA authentication issues. But, my previous version did not have any problems with reporting, but it would not allow Alexa to dim or brighten. It would allow Alexa to turn of or off. With the upgrade to 3.3.36 I gained the ability for Alexa to dim and brighten, but UDI no longer reports the correct settings and I get the communication error on a query.

If the library properly reported before, why would it not with the new version 3.3.36? Or does the new version incorporate a different library that is throwing these errors? I guess my next question would be, if Kasa is to release a correction, do we know when? The inability to determine switch position or brightness will prevent some of my monitoring to fail until it is fixed. UDI will alter the setting to the bulb, but does not indicate the change within UDI.

Regards,

Daniel M. Jonas

The latest version had many changes and likely better reporting of the issues, the only option is to stop trying to authenticate when it gets a failure, but it's always retried in case it was just an intermittent issue. I'll look at quieting it down.

I guess my next question would be, if Kasa is to release a correction, do we know when?

It's not Kasa, and I've said many times this plugin uses a reverse engineered method to communicate with Kasa devices. TP-LInk does not support anyone doing this. First section of the https://github.com/UniversalDevicesInc-PG3/udi-poly-kasa/blob/master/README.md mentions this. Personally I don't use Kasa devices for many things I care about, except their plug strips but I do my best to keep everything working with this plugin.

The latest does use a newer version of the libraray, and I'm not sure why your queries are reporting errors. I'll review the log when I have some time.

I found a duplicate entry in the Nodes. After testing, it appears to be working as it should Sorry for the confusion and thanks for the 3.3.36 version. And thanks for the prompt responses.

You are welcome. Released 3.3.37 which should handle auth failures better and resolve the query issue you saw https://github.com/UniversalDevicesInc-PG3/udi-poly-kasa/blob/master/CHANGELOG.md