Jimbo.Automates

Discovery does not use ping, it sends UDP packets, which do not cross subnet boundaries. There is a discussion about this on the python-kasa issues https://github.com/python-kasa/python-kasa/issues/1431 I'll look into that error. Issue created https://github.com/UniversalDevicesInc-PG3/udi-poly-kasa/issues/23

Two separate issues 1. Control all backlighting brightness: https://github.com/UniversalDevicesInc-PG3/udi-poly-ELK/issues/105 2. Enable turn on/off function keys https://github.com/UniversalDevicesInc-PG3/udi-poly-ELK/issues/110 I don't think #1 is possible, if someone knows this is possible please comment on the issue.

The original post Is asking for the ability to control the function key lights, which I originally misunderstood. See my latest post there. In my misunderstating I created this issue which I have updated with the latest information. https://github.com/UniversalDevicesInc-PG3/udi-poly-ELK/issues/110

Sorry all, I totally misunderstood the request. For some reason I thought it was to brighten/dim the entire keypad. But of course now that I read it again you just want to turn function keys on/off. There are of course API calls in the Elk to control the function key lights, I will look into adding this feature. Proper issue created https://github.com/UniversalDevicesInc-PG3/udi-poly-ELK/issues/110

Glad you got it working, and thanks for following up. That's interesting, I guess the discovery packets were not making it to the device when WiFi was weak. But, I'm not sure why it wouldn't work when you manually put in the device IP address. The devices are not "grouped" by name, for Kasa devices that only have one thing to control the plugin sets their "parent" to the Controller. But devices that have multiple, like a powerstrip can not have their "parent" be the controller, because IoX doesn't allow multiple levels of hierarchy, so the powerstrip has no parent, and each plug sets its parent to the powerstrip. You can right click on the Controller and select "Ungroup" and then move them into folders if you desire. I could prefix the name with Kasa and once you restart the AC it will show up near the Controller. I'll think about it.

Fixed in notification plugin 3.6.16.

But you are correct, after reviewing the code I see that changing a group name is ignored. I'll work on a fix.

Restarting the plugin should update the profile, then close/open AC and you should see the new names. But the error above indicates it had issues communicating with the portal. Were there mare WARNING lines before that?

Interesting, can you enable debug log, run discover, download log package and PM it to me? Sent from my Pixel 8 Pro using Tapatalk

I'll order an eisy so I can test this myself in the future, but try entering your real network address in the config and see if that helps. The configuration help explains it. Extra Disovery Networks By default the node server runs a discover on the default network of the machine running PG3. If the machine has multiple networks, or you have other networks on your LAN you can run discover on those networks e.g. 192.162.4.255.

@dbwarner5 just reminded me in another post that if your eisy has WiFi enabled this plugin will not work because the WiFi creates its own network. It may be fixable by entering your real network in the config but I can't be sure since my development box is a polisy. Sent from my Pixel 8 Pro using Tapatalk

Oh yes, I forgot that as well! Thanks for the reminder. Sent from my Pixel 8 Pro using Tapatalk

The controller node "discover" should see your device. If it doesn't then something is blocking it or weak WiFi to the device. Sent from my Pixel 8 Pro using Tapatalk

The HS300 is one of my test devices and works perfectly with the latest production and beta releases of the plugin. Something on your network is stopping the eisy from seeing that device. Also, as I mentioned you should not have to manually enter any IP addresses for devices if they are all on the same network and you have no network rules in your router stopping them and decent WiFi coverage to the HS300. The "Can't find db_getNodeDrivers" is a result of failure to communicate with the IP address you entered. See the earlier errors. 2024-12-27 16:30:20.160 Thread-11 (run_forever) udi_interface ERROR Controller:_add_manual_devices: Timed out getting discovery response for 192.168.1.189 trying to connect to 192.168.1.189 2024-12-27 16:30:21.018 Thread-11 (run_forever) udi_interface WARNING SmartDeviceNode:connect_a: SmartStrip 5091E3A14343: Device 192.168.1.189 responding again 2024-12-27 16:30:21.018 Thread-11 (run_forever) udi_interface ERROR SmartDeviceNode:set_connected: SmartStrip 5091E3A14343: failed: You need to await update() to access the data 2024-12-27 16:30:21.019 Thread-11 (run_forever) udi_interface ERROR SmartDeviceNode:connect_a: SmartStrip 5091E3A14343: Unable to connect to device 192.168.1.189 will try again later: You need to await update() to access the data 2024-12-27 16:30:23.236 Thread-515 (handler_poll) udi_interface WARNING SmartDeviceNode:handler_poll: SmartStrip 5091E3A14343: Node not ready to poll, must be disconnected or slow to respond? 2024-12-27 16:30:23.723 Thread-11 (run_forever) udi_interface ERROR SmartDeviceNode:update_a: SmartStrip 5091E3A14343: failed: Unable to query the device 192.168.1.189:9999: [Errno 54] Connection reset by peer

Awesome! Glad its finally working. The new library has the ability to query features supported by the device so I need to do some rework on how I create the node so it properly shows the features it supports, like voltage and current.

Please try 3.2.4

You should not have to add the HS300 manually, it should be auto-discovered if they are on the same network, if you have multiple subnets at your place then you will can add that sub-net to the list on the configuration page and allow discovery across the subnets. If your device is 192.168.1.38 the error says your IoX is not able to see that device so discovery and communication will not work. Something on your network is stopping the IoX from seeing that device. The "warn: Request for customtypedparams" is a PG3 error, so will need info from @bmercier why that is happening. The change_node_names setting should not be any issue. Sent from my Pixel 8 Pro using Tapatalk

@mjrush Thanks for the log package, it showed there was an install error. Please try 3.2.3.

Must have been an install error, please "Download Log Package" and PM it to me.

You should post in the Kasa sub-forum https://forum.universal-devices.com/forum/313-kasa-tp-link/ It looks like you did a "Add Kasa Device" in the configuration page, but didn't enter a address. I'll fix that crash at some point, but if you "Delete" it, "Save Changes" and restart it should clear the error.

I just updated the beta Standard to 3.2.2, @bmercier said if you own the production standard you can install the beta standard. Let me know.

Thanks, I submitted a support ticket Sent from my Pixel 8 Pro using Tapatalk

And if you activate what happens? It should just authorize thru the portal and let you install? Sent from my Pixel 8 Pro using Tapatalk

Those of you trying to install the beta (non-production) version, are you selecting 3.2.2 - Free - Trial? I just tried on my system and it worked as expected.

@bmercier can you check into this and the beta issue as well? Sent from my Pixel 8 Pro using Tapatalk