Closed nvella closed 8 years ago
It seems that the only thing different in v1.x is authentication. I'll close this issue for now as legacy support shouldn't need to be added.
Let me know what you find out. If the changes are larger I would perhaps add version support to init and move the version specific subroutines (i.e. legacy and non-legacy) to separate files. Then do something one the line of
import version2x import version1x
if self.version > 2.0:
else:
Then only init and the decorated function should stay in the pyW215.py file.
If the changes are minor then just submit a PR and I will have a look :)
You probably already know of the buffer overflow present in version 1.0 - 1.?? of the software, http://www.devttys0.com/2014/05/hacking-the-d-link-dsp-w215-smart-plug/ http://www.devttys0.com/2014/05/hacking-the-dspw215-again/
It is not a pretty solution but the only way I have found of interfacing with versions 1.x
You might also have seen that I have removed all exceptions from the library and only use the logging module to report errors. This is not something I normally do but I had trouble with exceptions crashing home assistant.
Yeah, unfortunately I've tried all the proof-of-concepts and it seems that they've all been patched on versions past v1.10. After doing some tests with the library I've found that the plug seems to be responding normally to authentication; it's just rejecting whatever passwords I'm throwing at it (like the plug PIN, etc). So I'd say at the current point in time legacy support isn't needed.
Next I'm going to try resetting the plug and packet capturing on the wireless network it creates for setup, maybe the app is setting a different password on the plug.
Try also to verify that it is using the same hash method for passwords. I use the https://docs.python.org/3/library/hmac.html library to hash passwords before sending them to the plug. That could also be a issue.
I've captured the initial setup conversation between the app and the plug and have tried to recreate the authentication parameters by following pyW215's method, but with using the parameters in the capture.
Looking to lines 248 and 249 in pyW215.py, I recreated the PrivateKey
and login_pwd
values using the python hmac library in the exact way that pyW215 does. I was able to successfully recreate login_pwd
(it matches with LoginPassword
in my Login request capture), but the PrivateKey
/HNAP_AUTH
token is completely different. It's odd because the PrivateKey
is required to build the login_pwd
which I am doing successfully, but the value itself does not match the HNAP_AUTH
token in the request I have captured.
So I'm led to believe (unless I'm making a mistake somewhere) that the HNAP_AUTH
token sent by the app is not the PrivateKey
like in line 255 of pyW215.py, but rather some other value. I'll continue doing research when I have the time.
Any chance of re-opening this issue with a possible addition of reading the consumption value from the legacy firmware version?
Using a test http post from this code: https://github.com/fake-name/DSP-W215-Poller/blob/master/dspLog.py I am able to read the consumption value from my Australian DSP-W215 on firmware 1.24. Any chance someone could implement such a call? It doesn't require authentication.
Sample http post URL: http://192.168.31.142/my_cgi.cgi?24567868457 Sample http post "raw" data: request=create_chklst
Returns: Firmware Version: ver1.24b01 Firmware Date: Tue, 1 Mar 2016 KERNEL: 2.6.31, Build: 0067, Date: Thu, 21, May, 2015 Application: 2.0, Build: 0604, Date: Wed, 23, Dec, 2015 WLAN Version: ap121-9.2.0.915, Build: 0008, Date: Fri, 03, Aug, 2012 Wireless Domain: 0x23 SSID: DSP-6BFB LAN MAC: XX:XX:XX:XX:XX:XX WLAN MAC 0: XX:XX:XX:XX:XX:XX WLAN MAC 1: XX:XX:XX:XX:XX:XX WLAN 0 Channel List: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 WLAN 1 Channel List: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 Default: 0 checksum: 0x07XXXXXX HW Ver: A1 BL-Version: ver1.00b04 BL-Checksum: 0x00XXXXXX Language: DISABLE CONFIG_VERSION: 2.06 Meter Firmware Version: ver2.16 Meter Watt: 7.5
Sure, we can look in to it. But where do you get the number 24567868457 from? From DSP-W215-Poller it should just be a random number. Is that true? Unfortunately I do not have access to any of my switches for the next couple of month so I can't test any code locally.
Yes, it's just a random number I made up. I'm happy to be a tester :)
I'll give it a shot. I've been able to successfully retrieve the consumption from my W215 through the my_cgi.cgi request.
I've implemented it in PR #10. It seems to work on mine.
Great, @nvella! Thanks for the PR. I will merge your changes tonight so @ozrex75 can test it.
@ozrex75 can you pull the latest from my repo and test @nvella's changes? If everything works I will do a version bump and send a PR to HA for the next release cycle.
Hi, I have pulled the latest from the repo and tested on my australian DSP-W215 on firmware 1.24, and it's returning the current consumption value correctly. Any ideas how long it takes to get pushed through to home-assistant releases?
Great! HA has resumed their bi-weekly release cycle. If my math is correct the next release should be tomorrow (don't think we will get in that). The next will then be about 14 days from now.
The changes have been merged into v0.38. Just update your HA and it should work.
Hi,
I live in Australia and was excited to integrate my DSP-W215 plug into my home automation system via home-assistant, which leverages the pyW215 library. However after I managed to get D-Link's app working the plug firmware would only update to v1.24, which uses a fundamentally different API than v2.00 onwards. I then proceeded to email D-Link Australia Support, where they then confirmed that v1.24 is the latest available version for the Australian plug.
I'd like to propose that legacy firmware version support be added to pyW215. I would be willing to reverse engineer my plug and app and create a PR containing support for v1.24, but I'd need some pointers on where and how you would like that to happen in regards to the greater scope of the project. Would I create a seperate class for the legacy firmware plug, or would it just be a firmware version specifier as an argument to the current SmartPlug init?
Regards, Nick.