Invalid Password on Newer Firmware Versions

[kq9914]

Firmware 1.2.2 (maybe lower too) of the A!-2002w seems to implement a generated password much like the Edimax plugs do now. The "app" password to connect to the device does not match the one on the edilife.cgi page. The plugs have a work around, but that does not seem to for the AI-2002w. The http://<sensor_ip>:10000/tnb2 page does not return "OK" and Telnet does not seem to open up on port 1355.

Here's a link to the issue in one of the Edimax plug repos with the instructions for the plug:
mwittig/edimax-smartplug#17

Not necessarily expecting a "fix" here but this script won't work as designed on units with current shipping firmware, so hopefully saving a headache for others.

I'm still trying to figure something out myself, but no luck so far.

[willmoffat]

Hi @kq9914 - I've been meaning to get back to this project so thanks for pointing this out! Not sure when I'll have time to look at it but I'll definitely update here if I make any progress. Please let me know if you find out anything more, the link was already very helpful.

[kq9914]

I've been messing around with the unit and trying to look at wi-fi traffic and such. Exchanges with the cloud seem to be encrypted if there's any interesting information and the local app hitting the edilife.cgi endpoint uses digest auth. I left the unit sitting for a while after it connected to wifi, but I didn't complete the setup process of giving it a name and password, and, by chance, the password I gave it in that case actually worked against edilife.cgi. Not sure if it had anything to do with it, but I did hit the edilife.cgi endpoint and login with the admin/1234 creds before coming back and assigning a password. Your script did not work at that point though, but that wasn't really a valid test either because I found out later for the script to work, it needs to be running from the same subnet.

I'm hesitant to reset the unit and keep testing since I have it working at the moment. My guess right now as to how I ended up in this state:

• Reset unit
• Connect unit to wifi
• after wifi setup, but before giving it a name and password, hit edilife.cgi with admin/1234 (your script might work at this point if on same subnet) (I don't think cloud services will work at this point, but I don't want cloud services anyway)
• wait a bit (maybe?)
• Set name and password by opening up the app again and letting that prompt pop up

[kq9914]

So I ended up resetting the device again and your script seemed to work this time with no issues when connecting from the subnet (I had hardcoded the EdiGreenSensor instead of using search). The password created in the setup process worked. I think maybe it returns bad password from outside the subnet regardless of if the password is valid. I should probably test that again to confirm it, but no issues this time around.

So bottom line: I don't think there was an issue with your code, so sorry about opening an "issue".

A little bit of additional info though:

I wanted to use this device without the cloud. I was able to block it from talking outbound at the firewall and use your script to poll it, but it would reboot every 25-30 minutes since it didn't think it had internet connectivity. I found another configuration item basic: cloud.keepalive.domain (and cloud.keepalive.port) and used your set_led function to modify them to point at a local server returning "Sky" (which is what their server returns... did not confirm if that was needed or if it just wants http/200 or something). It now has the blue LED on the front and stays up. I also set basic: uploaddata.enable to 0 and it has stopped trying to load data to airbox.myedimax.com.

[willmoffat]

Hi @kq9914 thanks for the update. Good idea to set uploaddata.enable = 0. Long time ago I tried blocking traffic at the router level and noticed that everything seemed OK for a day or so but then the measurements started returning bogus values. Something to keep an eye on.

[kq9914]

Hi @willmoffat appreciate the heads up on that. I was seeing the temperature ramp up and CO2 stay at 400 quite a bit after blocking it at the router. Is that what you were seeing too or something else? After I changed the cloud.keepalive.domain to something I controlled that behavior stopped. When it would fail to hit sky.edimaxcloud.com` it would reset itself causing the temperature to raise from the reset process and the CO2 sensor to stay in a calibration state and give the bad values. The status LED is now blue too as well.

[willmoffat]

Yes, that's what I was seeing. So it sounds like you've solved it.