Why the guide is so complicated (and uncomplete)?

[Barabba11]

Hi, this procedure is really a painful thing, horrible, I've put my efforts to solve myself the issues, if you may describe better the process, it can avoid us loose time and write these support messages, please help us more!
American account did, Smart Home" added for both the "Industry" field and the development method (here the site didn't show as you described, but ok), API Key and API Secret found and copied, all authorizations were added already automatically, data center needed to be added manually on "overview" edit (I got a while to found that) and the data center should be selected respect the app.. even if there I've chosem USA it registered in central europe /you need to describe this better), QR code added and device too,
Now tuya-cli wizard is not on the site (I've searched anywhere, why didn't you mention it?) , it's a software needed to install by npm, there i't needed to paste:
Access ID/Client ID:
Access Secret/Client Secret:
and the ID written in the device added.
this app found that with correct name, but its secret seams not working on NR module:
"connectDevice(): An error had occurred with tuya API on connect method : {}"

The IP address is the LAN one? This address is hard to get, but I've found it and it doesn't work. Same if I put the ID of object:
"find() timed out. Is the device powered on and the ID or IP correct?"
"findDevice(): Cannot find the device, re-trying..."

Why? I'm usng PC with NR connected on the same LAN, with my phone and Smart Life I can manage the dimmer.
Smartlife is able to find and connect without any cloud, can NR module just do that as well? Without all this pain.. :(
Thank you for help

[Barabba11]

I've tried also using the ID of the profile but it' not working. Why tuya-cli finds device and NR module not?
Also I don't understand why ID or IP address, ID is useful to drive device by cloud, while IP address is much useless for example if internet is not available, but why it asks for secrets?

[Apollon77]

Thank you for your post. I asked myself if you are aware of the environment we do this? This is all about inofficially reverse engineered protocols and APIs from a manufacturer that does not support this at all. You find things problematic or no longer correct? Then support the project by providing a PR that improves this and adds what you would have missed. This is open source so it all lives from collaboration.

The process in the Tuya developer ports ( which by the way is not developed or owned by the developers here, and we also do not check daily if anything got changed). So if there is a change or something is not working for you then tell us and ideally do a PR. So it is again about collaboration.

For the reason why it's not working I can only guess that it is about the usual "UDP not routed correctly" (what you mean with "PC with NR?"), so make sure that UDP messages can flow between the device and the PC and there are no network segments or anything that prevents this. Additionally close the Smart Life app because only ONE connection is possible to the device, so an open Smart Life App will hinders this.
If the device is battery powered then you likely have no chance at all to get it on network because it is only online when data change and send them into the cloud.

is it complex ... yes and that means you need to work yourself into or use ready projects that use the library and did that for you.

[Barabba11]

Thank you for your kind reply, I'm ready to collaborate to know things better and improve our results.
Please sorry me for misunderstanding, I though I wrote on the Node Red (NR) author's module but I see he linked his guide to your page, as it uses probably your library.
https://flows.nodered.org/node/node-red-contrib-tuya-smart-device
I'm going to write to his page then, anyway it may be intersesting to read the results of my experiment:

My device, which is a S1-B (WT) trailing/leading Tuya edge triac, no battery and direct to AC power, here are the results of my experimenting:

1. When I wrote the post I was working only with Bluetooth, I've understood it today when deelply I've anlaized my LAN trafic and understood the devide wasn't connected to WiFi at all. Since cloud recognized the device I thought it was online, I was wrong.. those datas are submitted by Smart Life app, doesn't matter the device itself, so be careful here.

2. I've deleted, pressed button and paired again, now I saw on my router 2 new MACs, one of them asked for IP and present itself with name wlan0, the second which shares the same first bytes values and differs only on the last 2, disappeared after minutes.
   The dimmer broadcasts regulary on LAN with UDP dest port 6667
   The dimmer keeps alive the connection with 3.76.16.47:8883 and from this address (cloud) receives command when is not connected on the same WiFi name as dimmer, and here I got 2 casesM
   a) if LAN has another WiFi on the same IP subnet/Layer2 broadcast it worked only by cloud, stopping gateway it didn't work more (bluetooth also off), when I switched phone to the same wifi it worked back.
   b) on the second attempt it worked also with the second wifi, the app start controlling the dimmer using broadcast LAN address with UDP destination port 7000. Probably it attempt to connect with broadcast at beginning, if dimmer doesn't reply it fails somehow and don't attempt more.

3. the app is broadcasting UDP to 255.255.255.255:7000 each time a command is set, which is not the LAN broadcast, this packet is probably useless, I'm not sure it becomes with broadcast MAC destination since it's out of subnet, it will die on the router. The app does try use the correct LAN broadcast only when cloud and bluetotth are unavailable. The app never connect directly to the dimmer IP

Anyway I believe your guide needs to be developed/update and become more user friendly, unfortunately Tuya is a standard with too many things to do and remember to get it workingm the guide has to be in my opinion more exaustive

[Barabba11]

Sniffing packets, Smart Life sends broadcast on UDP port 7000, dimmer replies later with broadcast udp on port 6667 (but this is probably just an announce, not a reply).
Here is the pure payload of the UDP packet sent to dimmer to switch it on, it is not containig any understandable data, packet is crypted

00 00 66 99 00 00 00 00 00 00 00 00 00 25 00 00 00 41 8a c2 9e de 88 55 29 fc ba b9 e1 e8 b9 49 22 b7 dd 60 ff 15 69 95 cf 22 05 9b 17 f8 02 0f 64 20 fb 98 66 8d a0 cb b7 46 c4 ec c0 ed  91 c4 bc fe a2 48 7c 73 71 d8 b9 6e 9a 76 23 2b  8c 54 05 9b 4f 00 00 99 66