Closed dktrekkie closed 2 months ago
Hey there @markgodwin, mind taking a look at this issue as it has been labeled with an integration (tplink_omada
) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
tplink_omada documentation tplink_omada source (message by IssueLinks)
Thanks for the detailed info. That does indeed look like the problem. I'll release a new version of the library that is tolerant to the missing "wireless" parameter.
I've released a new version of the omada API library (1.4.2). If you could give it a try, that would be great.
In a python environment...
pip install tplink-omada-client
Then use the omada target
command to add a new target name with something like omada --target Omada target --set-default -url https://your-controller-ip --site Default --no-verify-ssl --username admin
Finally try the omada known-clients
command, and check it returns good output.
Once you've confirmed that is working, I will put in an PR to update HA with the new version dependency.
Just wanted to let you know that I gave the new tplink-omada-client (1.4.2) a spin (never used Python much, but got it working! 😀), and it’s looking good! The known-clients command returned a list with no errors, so everything seems to be in order.
By the way, how did you end up handling those entries without the wireless key? Are they just being ignored, or did you find another way to deal with them? Just curious!
Thanks a bunch for the speedy update—really appreciate it!
@MarkGodwin: Is there a way to get this faster, other than just changing the code myself? (even though I will have to do it every time I update my container)
There is a PR in now. Once that is approved, I think fixes usually make it into the next patch release, I think
The problem
I encountered a KeyError in the TP-Link Omada integration within Home Assistant when attempting to load device trackers. In my opinion the issue occurs because some clients in the returned data do not have a 'wireless' key, which the integration's code assumes to be present for all clients.
The error trace indicates that the 'wireless' key is missing from certain client entries in the API response. This causes the integration to fail when it tries to access this key without checking its existence first.
Here's the error log:
What version of Home Assistant Core has the issue?
core-2024.8.1
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Container
Integration causing the issue
TP-Link Omada
Link to integration documentation on our website
https://www.home-assistant.io/integrations/tplink_omada
Diagnostics information
home-assistant_tplink_omada_2024-08-15T10-36-20.745Z.log
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
I believe I have identified the root cause of the KeyError in the TP-Link Omada integration. Below is a snippet of JSON data that I manually fetched using Postman. In this data, some client entries are missing the wireless key, which appears to trigger the error in the integration code. The integration currently assumes that all client objects will include the wireless key, but as you can see from my setup, this is not always the case.
Perhaps this issue could be related to the fact that I have added a significant number of DHCP reservations for devices that have not yet connected to my network. I added these reservations during my setup because I already had the list from my previous network configuration. For example, one of the devices listed has not yet connected because it is associated with an unused Ethernet port on my son's computer, which he currently connects using a different port. My primary use for these reservations is to whitelist only known devices on my network.