Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kasa KP125M not reconnecting after disconnection from power #113196

Closed
infinitytec opened this issue Mar 13, 2024 · 13 comments · Fixed by #120060
Closed

Kasa KP125M not reconnecting after disconnection from power #113196

infinitytec opened this issue Mar 13, 2024 · 13 comments · Fixed by #120060
Assignees
Labels
integration: tplink waiting-for-upstream We're waiting for a change upstream

Comments

@infinitytec
Copy link

The problem

First, a bit of a disclaimer: I found these somewhat related issues that are closed: #102088, #99857, #97247, #94947 so I apologize if I am saying stuff that is already known. This issue might be due to these being Matter devices but I am unsure.

The integration almost works perfectly for me. I was unable to get Matter working but I totally get it since it is still in a beta stage. I was able to get the plugs connected in the Kasa app and then connect them via IP. That works pretty well, however I used different outlets for testing than where I want to deploy them. When I moved them I noticed that the plugs did not connect to Home Assistant.

I then accidentally discovered that if I allowed Internet access to the plugs, Home Assistant recognizes them and can connect. The integration continues to work with the Internet access blocked. Disabling and re-enabling the plug does not help. Deleting it an re-adding it by IP yields the error message Connection error: Error querying device: 192.168.90.7: TIME_ERROR(-1601) for method: get_device_usage.

While disconnected from the Internet after moving the plugs I can still control the plugs using the Kasa app. Other smart plugs integrated with HA have the expected behavior and reconnect with HA without needing Internet access.

In summary:

  • Integration of the KP125M works great until it is disconnected from the power source.
  • When re-connected to the power source, the plugs do not re-connect to Home Assistant without Internet access.
  • Other smart plugs on the network re-connect as expected. The Kasa app can still locally control the devices on the network.

I have two of these plugs. Both exhibit the same behaviors.
The first:

  • Firmware: 1.1.3 Build 230801 Rel.092557
  • Hardware: 1.0

The second:

  • Firmware: 1.2.1 Build 240103 Rel.170408
  • Hardware: 1.0

I'm new to HA and really enjoying it! Great job!

What version of Home Assistant Core has the issue?

core-2024.3.0

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

TP-Link Smart Home

Link to integration documentation on our website

https://www.home-assistant.io/integrations/tplink

Diagnostics information

config_entry-tplink-e68768ebcba36e0fbb5ccf310ceb2609.json

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Device reports as unavailable after unplugging and remains so until Internet access is provided.

Additional information

No response

@home-assistant
Copy link

Hey there @rytilahti, @TheGardenMonkey, @bdraco, @sdb9696, mind taking a look at this issue as it has been labeled with an integration (tplink) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of tplink can trigger bot actions by commenting:

  • @home-assistant close Closes the issue.
  • @home-assistant rename Awesome new title Renames the issue.
  • @home-assistant reopen Reopen the issue.
  • @home-assistant unassign tplink Removes the current integration label and assignees on the issue, add the integration domain after the command.
  • @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
  • @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

(message by CodeOwnersMention)


tplink documentation
tplink source
(message by IssueLinks)

@rytilahti rytilahti added the waiting-for-upstream We're waiting for a change upstream label Mar 13, 2024
@rytilahti
Copy link
Member

rytilahti commented Mar 13, 2024

The error implies that the device clock is not synchronized with a time-server, so allowing NTP traffic could fix the issue even when other connectivity to the Internet is cut off.

Now, I am not sure why you are not receiving that error when reloading, but this will likely be fixed when a new python-kasa release is done (with python-kasa/python-kasa#754 included that changed how errors are handled).

@infinitytec
Copy link
Author

The error implies that the device clock is not synchronized with a time-server, so allowing NTP traffic could fix the issue even when other connectivity to the Internet is cut off.

Now, I am not sure why you are not receiving that error when reloading, but this will likely be fixed when a new python-kasa release is done (with python-kasa/python-kasa#754 included that changed how errors are handled).

Ah, good to know. I will look into getting NTP working and provide an update today or tomorrow.

@rytilahti
Copy link
Member

Ah, good to know. I will look into getting NTP working and provide an update today or tomorrow.

Oh, and you could also set the time manually by doing something like kasa --host <ipaddr> command set_device_time '{"timestamp": 1710353937, "time_diff": 60, "region": "Europe/Berlin"}. But this issue itself should indeed be gone when we have a new library release and when the integration starts requiring it.

@infinitytec
Copy link
Author

Ah, good to know. I will look into getting NTP working and provide an update today or tomorrow.

Oh, and you could also set the time manually by doing something like kasa --host <ipaddr> command set_device_time '{"timestamp": 1710353937, "time_diff": 60, "region": "Europe/Berlin"}. But this issue itself should indeed be gone when we have a new library release and when the integration starts requiring it.

Would that be run before or after Home Assistant is connected to it?

Thanks for the assistance!

@rytilahti
Copy link
Member

Before, it should set the time so that the device doesn't error afterwards.

@infinitytec
Copy link
Author

I think I have it fixed (at least for now!) by redirecting pool.ntp.org to a local NTP server. I'll continue to monitor and see if the coming changes fix it without having to do this.

@Maarten69
Copy link

I've got the same error: TIME_ERROR(-1601) for method: get_device_usage on a P110.
The problem was I blocked internet access to it in my router :(
Plan was to use it local only.
Fixed it by unblocking internetacces so time could sync with a time server.

@rytilahti
Copy link
Member

Yes, it's a known problem and is waiting for upstream. The next upstream release will fix this by not failing the complete query even when one or some individual queries fail.

@infinitytec
Copy link
Author

I've got the same error: TIME_ERROR(-1601) for method: get_device_usage on a P110. The problem was I blocked internet access to it in my router :( Plan was to use it local only. Fixed it by unblocking internetacces so time could sync with a time server.

You might want to try to set up an NTP server and redirect DNS to it--it worked for me!

@aidanharris
Copy link

Ah, good to know. I will look into getting NTP working and provide an update today or tomorrow.

Oh, and you could also set the time manually by doing something like kasa --host <ipaddr> command set_device_time '{"timestamp": 1710353937, "time_diff": 60, "region": "Europe/Berlin"}. But this issue itself should indeed be gone when we have a new library release and when the integration starts requiring it.

Thanks for this.

I'm now running this every 60 seconds in a cron job:

kasa --username '' --password '' --host '' command set_device_time "{\"timestamp\": $(date +%s), \"time_diff\": 60, \"region\": \"Europe/London\"}"

Maybe the library should be able to synchronise the time between devices automatically?

@aidanharris
Copy link

Ah, good to know. I will look into getting NTP working and provide an update today or tomorrow.

Oh, and you could also set the time manually by doing something like kasa --host <ipaddr> command set_device_time '{"timestamp": 1710353937, "time_diff": 60, "region": "Europe/Berlin"}. But this issue itself should indeed be gone when we have a new library release and when the integration starts requiring it.

Thanks for this.

I'm now running this every 60 seconds in a cron job:

kasa --username '' --password '' --host '' command set_device_time "{\"timestamp\": $(date +%s), \"time_diff\": 60, \"region\": \"Europe/London\"}"

Maybe the library should be able to synchronise the time between devices automatically?

This was for an LB510B by the way. I don't know why a lightbulb needs accurate time synchronisation for in the first place but it's working now.

@rytilahti
Copy link
Member

Maybe the library should be able to synchronise the time between devices automatically?

Perhaps. python-kasa/python-kasa#951 adds a command to do this without passing payloads manually, but we could potentially perform the sync automatically when encountering out-of-sync errors.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
integration: tplink waiting-for-upstream We're waiting for a change upstream
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants