Repository navigation
Implement the new protocol (HTTP over 80/tcp, 20002/udp for discovery) #115
Description
Help needed! New firmware versions are replacing the old, insecure local communication protocol.
If you update your devices to the newer firmware versions, you won't be able to use this library to control your devices until someone adds support for this new protocol.
This issue is for tracking the implementation of the new communication protocol used at least by some newer firmwares.
The previously used 9999/udp is not used anymore, and the new protocol uses stronger encryption for the communication. A response from tplink for some background information: home-assistant/core#43088 (comment)
- Some details on the communication protocol: HS100 Hardware V4.1 Firmware 1.1.0 - No Longer Working - No Port 9999 softScheck/tplink-smartplug#81 (comment)
- Discovery: HS100 Hardware V4.1 Firmware 1.1.0 - No Longer Working - No Port 9999 softScheck/tplink-smartplug#81 (comment)
Related to #114, potentially #113.
Steps required for implementation:
- Adapting the discovery process. Both ways for discovery could be used per default, an enum to allow limiting discovery using a specific discovery could be added.
- Extending TPLinkSmartHomeProtocol to allow changeable encryption handling, as the change does not change the payloads, only the encryption.
- This likely requires breaking the API, or alternatively, adding a separate method to add username/password if those are used for the encryption as hinted in one of the comments above. Latter is preferred, using empty values (which seems to work for non-cloud connected devices).
Help needed from someone who wants to implement this! I have personally no plans nor time in the foreseeable future to brick my own devices, sorry, but I will gladly help however else I can with code reviews etc. :-)
Activity
robbrad commented on Nov 17, 2020
I’d be happy to pony up two broken plugs. Is it easier to liaise test (I’m quite technical and available on discord if that works) or me send you one?
SimonWilkinson commented on Nov 17, 2020
I've opened pull request #117 which is a simple implementation of the new encryption protocol, currently tested with an HS110 and the command line interface. Comments appreciated.
Enzo-Matrix commented on Nov 25, 2020
Please ensure the 9999/UDP functionality remains for devices that have not/will not be updated.
rytilahti commented on Nov 25, 2020
@Enzo-Matrix, in the end, both protocol implementations should be work fine side-by-side with minor change (namely the authentication credentials input) required to use the new klap protocol. There will be no API changes for the 9999/UDP ("legacy") protocol, so no worries.
@robbrad thanks for the offer, if you want to help with testing, check out the PR by @SimonWilkinson. To my understanding it should already be in a working state even when the implementation is not yet finished.
robbrad commented on Nov 28, 2020
@SimonWilkinson @rytilahti - I got Simon's PR cloned but when I do kasa --plug the broke plugs are not returned - any ideas?
SimonWilkinson commented on Nov 28, 2020
@robbrad - so this will depend on how your broken plugs are configured.
If they are associated with a kasa cloud account, you will need to use kasa --user <email-address> --password <cloud-password> to discover them.
If they still don't show up, use kasa --debug, and let me take a look at the output.
robbrad commented on Nov 28, 2020
OK got the debug - anything I should strip from this before sharing?
SimonWilkinson commented on Nov 28, 2020
Have a scan through and make sure there's nothing you'd rather not share.
Providing you are using the PR with all of the changes, it won't log usernames or passwords. It will record device IDs, MAC addresses, names of and (possibly) location of plugs. It will contain some details of the authentication handshake, but not enough for anyone to be able to impersonate you to your plugs.
robbrad commented on Nov 28, 2020
Can I email you it - or im on discord?
SimonWilkinson commented on Nov 28, 2020
Email is probably easiest - simon@sxw.org.uk
robbrad commented on Dec 1, 2020
So @SimonWilkinson and I have been doing some debugging - on v4.1 and HS110 / HS100 plugs with the new PR. Initially it looks like HS110 works fine but HS100 crash/reboot on new protocol connection. Suspected that HS100 v4.1 doesnt like being asked for things it cant do. (energy monitoring?)
SimonWilkinson commented on Dec 2, 2020
Just to update here, we've confirmed that asking a software version 1.1.0 HS100 for emeter information crashes it. We either need to determine type and features from the discovery payload, or from a sysinfo query on its own.
wilsonnkwan commented on Jan 10, 2021
@SimonWilkinson, first time using this repo, so a total noob here. I am not sure what am I doing wrong.
To use your github's repo version which I believe where your changed codes are, I used the manual instruction which is to git clone your repo's code, do poetry install. But problem, after the poetry install, it doesn't have the app "kasa"
Doing the first method will get the latest kasa but that doesn't have your code in it I believe.
Can teach me how to use your code to test? Much appreciated.
rct commented on Jan 25, 2021
@wilsonnkwan - the executable kasa winds up in the /bin of the Python virtual environment after the poetry install. If the python virtual env is activated source <path-to-env>/bin/active then that bin directory should get added to your path.
Steps I used (from memory) which isn't quite what the docs say.
As a regular user:
If you wind up logging back in/etc. don't forget the activate step.
GoliathLabs commented on May 18, 2021
Found a project which might bring some light in the current situation. Correct me if I'm wrong 😄
Kind Regards,
thegoliath
rytilahti commented on Nov 20, 2023
Fixed by #509