Aqara FP2: adding device doesn't work anymore #1648
Comments
|
Hey @ldeora - Thank you for reporting this issue. I am sorry for the inconvenience. SmartThings has recently introduced a new driver to support the Aqara FP2 device, and today we made a change that may resolve your issue. Could you please delete your device and attempt to rejoin? If the issue persists, can you please share the device firmware version the FP2 device has? Thank you for your time. |
|
The driver worked very well a month ago. When I came back from vacation I wanted to switch from the PR driver channel to main (or beta). See my comment(s) here: "today we made a change that may resolve your issue" Can you please be more specific (which commit)? |
|
The change wasnt related to a commit made in the driver itself, it was elsewhere. The action we took was just to install the newly deployed LAN Aqara Presence Sensor driver on Hubs. It may take up to 24 hours for all hubs to get the change. I would encourage you to wait 24 hours, then reattempt. Also, if the issue continues, please remember to report what version of firmware you have on your Aqara FP2 device. |
|
I'll try again tomorrow. Device firmware: 1.2.7_0011.0080 |
|
Got a full log now. The interesting part: Complete: |
|
I'm pretty sure now that the very last commit (the whole lunchbox updated to the latest version and more), right before the PR was merged into main broke the driver. I was on vacation when I saw it and thought that this is quite a large change and this should be tested extensively. When I came back I just did that and yeah... First I thought that the firmware has an expiration date for the REST GET /authcode - see get_credential(). Then I thought that the SSL certificate has been replaced for the next firmware update, but it's the same. The log confirms that the SSL/TCP/HTTPS connection is successfully established. There's a change from Request to HttpMessage, function recv_additional_response(original_response, sock) has been removed completely and this could be the culprit, because in the luasec documentation it says that wantread is also a response to an incomplete response. And so on... Quite a lot of changes to break the REST communication with the FP2 REST API and get_credential is the very first call, from what I can see. Or maybe the SSL connection dies right before or in the middle of the first request. I might be wrong but there were absolutely no changes on my side: same firmware (device, hub), only after the commit, I can't re-add the device. |
|
Thanks, ChatGPT! The "wantread" error in luasec (a Lua library for SSL/TLS support) typically indicates that a non-blocking operation is expected to read more data from the network (e.g., receiving SSL/TLS data) but hasn't yet completed. It usually happens in a context where the underlying socket or connection isn't ready to read data immediately. In simpler terms, the socket is telling you that it wants more time to read data, and your program needs to try again later. This is common in non-blocking or asynchronous networking operations, where the program doesn't stop and wait for an operation to finish. Possible solutions:
Example:
By dealing with the "wantread" error properly, you can ensure your program handles networking more smoothly without blocking or failing unexpectedly. The "wantread" message is not specific to luasec alone but is commonly associated with Lua's socket library (specifically luasocket), which is often used for non-blocking network operations. In the context of luasocket, the wantread message indicates that the socket is not ready to read data yet and the operation should be retried later. This happens in non-blocking mode when you're trying to read data from a socket, but the data isn't available at that moment. Where it's seen: luasocket: In non-blocking socket operations, the "wantread" message is returned when trying to perform a read operation on a socket that is not yet ready to provide data. luasec: Since luasec builds on top of luasocket for SSL/TLS connections, you may encounter the same wantread behavior if the SSL/TLS connection is waiting to be able to read more data. In summary: luasocket commonly returns "wantread" during non-blocking I/O operations. luasec, being built on luasocket, inherits this behavior when using non-blocking SSL/TLS connections. In both cases, the solution generally involves checking the readiness of the socket using a select mechanism (like socket.select), or adjusting the socket to blocking mode if non-blocking is not required. |
|
@seojune79 Is there a reason why the FP2 can't be added anymore? Maybe a hidden expiration date for /authcode or the whole REST in firmware version 1.2.7_0011.0080? |
|
If something goes wrong while removing FP2 from the ST app, the device won't be onboarded. |
|
Thanks, @seojune79 |
|
Not fixed. Another user has the same issue. Read the comments here (conversation between Andreas_Roedl and ewimer2): https://community.smartthings.com/t/aqara-fp2-tested-with-smartthings/270688/136 User has hub firmware 54.x, FP2 firmware 1.2.8x. Keep in mind that the rollout of the FP2 firmware isn't completed yet and these are the first users who are trying to connect the FP2 to ST. |
Doesn't seem to work for some users. |
Can you check if FP2 and SmartThings hub are connected to the same network? |
|
This is from the logcat of the user: Connection established. |
|
More and more users report that it doesn't work: https://community.smartthings.com/t/aqara-fp2-tested-with-smartthings/270688/176 |
|
Make sure to read through the comments in this issue: #1654 |
|
Looks like the REST API isn't (correctly) activated, despite having the device added to the Aqara Home app / cloud. I had the same problem, but after removing and onboarding it, it worked. At least two users now report that even that doesn't work. If I remember correctly, the first request is a GET /authcode and this fails. Haven't looked at the code since weeks. |
|
I am attaching the procedure, video, and logcat that I tested, so please check it recorded screen |
|
Going to communicate that to the affected users and give feedback here. Thanks. FYI: they tried all that multiple times without success. I'll make sure that they reset the device correctly. |
|
I can replicate this issue here with the driver from the original PR, the production and the beta driver. Here's the log that is pretty much identical to the logs from other people with the same problem: That's all. These warnings and errors from previous versions are gone: Since there's no real logging in the driver to see if there's even an attempt to get the auth token, it's impossible to debug. Several users tried everything over the curse of a week now. Deleted the device everywhere, reset everything, tried every available driver version. It would be helpful if you would explain why it is necessary to remove the device from the Aqara Home app and re-add it, @seojune79 . Does it activate the REST API? I've read through the code a dozen times and I'm on my wits end. BTW: the mdns discovery doesn't even work on TV hubs, driver isn't started, but that's a different issue. Read this thread from bottom up to see that we tried everything: https://community.smartthings.com/t/aqara-fp2-tested-with-smartthings/270688/235 Does anybody care at all if it works? And no, code reviews and "LGTM" is NOT enough - these are drivers that deal with and should be tested with real world devices. Deleting and adding the device, testing the functionality after every single commit. (I'm starting to believe that it only works in bright daylight because the illuminance sensor is involved in creating the auth token... or something like that...) Tagging, @lelandblue @FreeMasen @cjswedes |
|
@ldeora FP2 basically does not generate additional credentials once it generates credentials.
if a problem occurs, method 3 cannot be used and reset through 1 or 2 is required. And, in the case below, onboarding may fail. in the case of A, I understand that @cjswedes has already solved it. if onboarding fails once due to the case of a or b, onboarding is not possible again until initialization because the credential has already been issued. The guides that can be done at the moment are as follows:
|
|
Thanks for the clarification.
|
|
Dear @ldeora Your opinion is correct as a whole. Is the problem reproduced in very latest version (2024-10-21T19:30)? the problem that mdns is not found on TV seems to need further analysis. |
See my comment above... (Nr. 3 in my list) sigh
I'd guess that the environments of the affected users are very different but almost identical at the same time - different set of devices, but the same V3 hub with the same firmware and the same FP2 with the same firmware. Network works of course - see the logs: TCP connection established. |
|
Dear @ldeora |
|
Dear @ldeora |
|
THIS WORKS!!!
See channel and version string:
And you know what? That's what I was trying to tell everyone involved: the latest commit that updated the lunchbox broke the driver! Here just one example: And if I remember correctly several times right after the commit! So now we have to create a diff between the current version and the one that works for me. I'd do it, clone/branch the driver, add some more logging and so one, but I realized that I don't work for Samsung, SmartThings or Aqara and I'm not getting paid for it - quite the opposite: I paid for the device and spent countless hours to debug the driver. To summarize: roll back the lunchbox update, do some rebasing to include the important changes/commits. |
|
Dear @ldeora |
|
Just send me the upcoming Aqara Light Switch H2 EU (no neutral) for all the troubles... In the meantime I'll try to convince the other affected users to try the working version (lunchbox rollback), but I think they are fed up by now. |
|
BTW: reports are coming in increasingly that the current production driver doesn't work:
https://community.smartthings.com/t/aqara-fp2-tested-with-smartthings/270688/239 On the other hand, there are reports that it works out of the box... |
|
Food for thought: What would happen if the current production driver suddenly worked after the driver from this PR worked, which I will test later. That would mean that the cache and/or the fields would survive a delete/add. I don't know how persistent the fields are stored. The fields contain everything important for the adding to work. That would explain why some users don't have any issues at all. Users with the installed production version of the drivers who tried to add the device to ST the very first time. Not like those users who tried it before with the very first version from the PR! What if deleting/adding works only for those who's device gets a different IP every 24 hours, invalidating the fields and/or cache, especially It still doesn't explain why the lunchbox rollback makes a difference or does it? Just thinking out loud... |
|
Sooo... I tested it now back and forth: Installed driver from PR (see above): works Between driver changes, the exact same procedure: delete/add device in Aqara Home app, scan in ST. In short: 2024-10-10 and 2024-10-21 doesn't work, 2024-10-22 works. This is the proof that the lunchbox update broke the driver! |
Edit: there's the problem:
Can't add the device anymore! Removed the device, deleted the driver, added driver, tried to add the device. Tried it with main, beta, and PR channel to make sure.
It worked about a month ago. Since then, changes were made to discovery.lua, init.lua, device_manager.lua...
Can someone please check if adding the device still works?
Device firmware: 1.2.7_0011.0080
Hub firmware: 000.053.00019
ST app (Android): 1.8.18.21
Device works with the Aqara Home app.
This is the complete log and it looks like the driver lifecycle ends?
The text was updated successfully, but these errors were encountered: