-
-
Notifications
You must be signed in to change notification settings - Fork 346
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
Antela Smart Bulbs cause tuyapi and upstream apps to crash #676
Comments
I'm seeing the same issue using [email protected]. |
Please post the esception with 7.7.0 because I assume line number must be different. Ten I can have a look. Ideally with enhanced debug by using DEBUG=TuyAPI* node .... |
I've extended the 'Received UDP message' debug statement to display the message.
|
Ok, in the code there seems to be a return missing when such a parsing error happens. Other then that ... which version is set for this device from your side? Because seems not to be 3.5 |
Interesting question. I've not set a 'version'. I'm expecting the 'find' to handle that.
Does not include a version.
If a non version 3.5 device is processed first then I get
If, by chance, a version 3.5 device is processed first then I get:
It looks like the connect times out.
Again, this looks like a timeout - after 30 seconds |
I try to optimize the version detection ... if you like install from this branch here #690 and see if it is better when you do not provide a version |
Partial success.
I must go. I though I would pass on the partial good news as soon as I could.
No time today. |
Ok, please have a look again when you find time. I updated the branch ... |
Hi Ingo, In the device constructor I need to specify either 'ip' or the 'version' for joy. My reading is that the 'find' operation should find the required device if either the ip or the id are not present and fill in the missing fields. I have devices of version 3.3, 3.4 and 3.5 in my system.
On a version 3.4 or 3.5 device I get:
I'll continue digging as time permits |
Please try the branch I mentioned above ... The "connect toi undefined" should not happen with that anymore at all! For 3.4 and 3.5 the content is encrypted and I think that the real key needs to be used to decrypt ... if that assumption is right then .... Do you wanne try something just for the 3.4/3.5 case !? change Line 1014 in a8212a8
to be
Does it then correctly decode the payload? If yes I can add handling to try the device key as fallback if the normal key is not working |
The connection to 'undefined' does not occur any more. I changed line 1014 as suggested. The v3.4/v3.5 payload is still not decoded. In its original form, the v3.3 and 3.4 payloads are decoded. The v3.5 payloads are not decoded.
|
Hm ... but there is a 3.4 decoded as you can see ... could it be you tried with the 3.4 key? Can you try with the 3.5 device key? |
Ahh wait, I found another place where the version was not updated to the "detected" one. Please update again, so that one manual change again please and test again. if that works with 3.4 the I think i have an idea how to fix it for all |
Jackpot. Works for 3.3, 3.4 and 3.5 devices |
My one observation is that the UPD data.payload.version does not always match the UDP data.version
|
Thanks for picking this up chaps. You've both gone way above my understanding! Can you confirm we're both running this the same way @ddpurdie and I'll check it with my bulbs. I last ran it by doing:
...using the example code you posted above. I was only specifying I haven't tried the latest branch yet, I'll do that when I'm home tomorrow and once I know I'm running correctly. |
I used the tinytuya module for python to determine other information - version ... |
@ddpurdie That the version is different when this is the log of the "find" then in fact the "payload" version is the one returned via discovery and the other is the "assumed" version which always defaults to 3.1 ... some lines later this gets then fixed ... so it is this log only. I will cleanup and release a new version soon |
I think I have the same issue as some of the commenters on #325.
I'm using https://flows.nodered.org/node/node-red-contrib-tuya-smart-device in v4.0.5 of node-red on a raspberry pi 4.
Since adding some Antela bulbs to the Tuya app, node red crashes with the below error...
I think some minification might be happening, as I have traced the error to this line: https://github.com/codetheweb/tuyapi/blob/master/index.js#L1013
(which is 985 on my local version. not 1013.)
Payload is indeed undefined. If I hack a
console.log(error)
into the try/catch on line 1003 I get:UPDATE:
Suspecting the node-red plugin was using an older version of the API, I have since checked out the latest version of this repo and tested it with my problem bulbs. I see the prefix error above has now been fixed, but I get a further error when I put the problem device details into the Asynchronous example in the readme. Ultimately resulting in the same undefined payload. It looks like this second error needs to be resolved before 'node-red-contrib-tuya-smart-device' updates their dependencies.
I have run out of talent at this point. https://github.com/codetheweb/tuyapi/blob/master/lib/message-parser.js#L216 😆
I'm happy to assist in debugging this. If I can't control these lamps using the Tuya API, I would at least like them to not crash the api and in turn, crash node-red. I need to have the bulbs in the Tuya app to control them. I have tried removing them from the linked App account in the Tuya dashboard, but they continue to appear in the list of devices and crash the API.
Thanks.
The text was updated successfully, but these errors were encountered: