DJonas

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.

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

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

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.

I went into my Eisy using the IoX finder and saw a notice that updates were available. I started the updates and about 15 minutes later got a notice on my Phone UD program that the server was restarting, but the Eisy remained unavailable even though it is showing on my network. I also can't log into Polyglor. eisy running IoX 6.0.5. Update available in Configuration tab. Clicked Update. PG3 reported restarting. After update: my.isy.io shows offline. Polyglot login page loads but authentication fails. Admin Console loops back to login. Cold reboot performed. Waited 30 minutes. Symptoms unchanged. I'm not sure where to go from here.

I started many years ago with an ISY and upgraded the system a few years ago to an Eisy. These primarily control Insteon devices but have grown over the years to include a few Hue devices, some Yolink. It has all worked pretty well. Except integration of voice control with Aleza. While I have been able to make Alexa voice control work, it is inconsistent. Alexa loses the connection. Worst of all, Alexa, hands down, has the most frustrating and unintuitive interface I have ever experience. They should be ashamed to produce it. I am looking for a good approach to create some simple voice controls that will work with the Eisy. Basically, I am controlling some office and bedroom lights. All are Insteon based and work within the UD interface. Two of the bedroom lamps are Phillips Hue bulbs. I have the Hue add-in for Eisy but that has also stopped working. I can control the Hue lights directly with the Hue App. I'm wondering which way to go, of give up. Apple Homekit with hub? Home Assistant? Or something else. Whatever it is, the interface needs to be user friendly. I am more than happy to spend a few bucks to throw the Alexa product in the trash., Any Suggestions?

Dennis, Thanks. It isn't that I am new to the Eisy, I set most things up many years ago when I had the original Isy, The problem is that I rarely need to access to modify anything and I am old and forget. I think I have it back on track.

Thanks, Confusion gone. I figured out (fount) the portal user name and password. Why the change?

I am confused. Maybe I don't understand what the "portal" is. I thought that was where I had additional add-ons setup and I've navigated to that information from within the UD program launched with the icon. I am not aware of a separate username and password for the "portal". So I guess the question is how do I reset my password in the "portal".

I selected update, which it did, and now I can't log into the Eisy from IoX launcher. It does not seem to know my username or password (probably password) any more. I can log into it using the user name and password with eisy.local I cleared the JAVA cache and all programs already. Did not help. How do I fix this?

Yes, it is a sectional garage door and I have it mounted to the back of the top panel. The door is currently closed and it is reporting nothing. Neither open or closed. Battery is 27%, which is surprising as the sensor is only 30 days new.

I am trying out a Zooz tilt sensor to determine if a garage door is open or not. It appears to be working part of the time. In particular, it works when the door is open or closed for a longer period of time. But if the door is opened (it reports properly) and then shut within a few minutes, the sensor continues to show open. I think I have the settings correct, but who knows. I find the Zooz documentation, particularly as it relates to use within the Eisy rather lacking.

Looks like that is the problem. I understand the issue but seems like the email provider could allow specified exceptions. A text is usually a better notification process than email.

That got me most of the way there. Was it the time out change 1000-8000 or the FROM? I thought the FROM was optional. The email notification worked. I included phone#@vtext.com and received a permanent error message in my email for that. What works for text message?

I've done all of that, multiple times. Using both Default checked and inputting the email settings. When testing, I get an SMTP error code 1 or 18 depending on the settings.