You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I need to implement a "universal" device, which being an end device can control other end devices located in the same network.
I have no problems working with standard Zigbee devices. But Tuya devices cause me big problems. Their proprietary protocol is relatively clear to me, but the fact that all the "responses" (which are commands judging by the sniffer logs) go only to 0x0000, i.e. to the coordinator is not clear to me. I need to read the states of the devices, but I do not know how.
Actually, is there any solution to this situation, somehow intercepting traffic on the network going to the coordinator, in order to parse it later? Or maybe some other way to make such devices respond to my address?
I will be satisfied with unproductive solutions, the only thing is that I cannot make the device a coordinator.
Additional context.
The device I work with:
Manufacturer is "_TZE200_e3oitdyu"
Model is "TS0601" Device link
The code for sending a command to a device (the payload is written based on the example of a command sent from the coordinator via a mobile application):
Here is the request that goes to the device, it is processed successfully.
And here is the result that is sent to the coordinator after updating the attribute.
The text was updated successfully, but these errors were encountered:
github-actionsbot
changed the title
How to receive commands that are intended for the coordinator
How to receive commands that are intended for the coordinator (TZ-1520)
Feb 3, 2025
Question
I need to implement a "universal" device, which being an end device can control other end devices located in the same network.
I have no problems working with standard Zigbee devices. But Tuya devices cause me big problems. Their proprietary protocol is relatively clear to me, but the fact that all the "responses" (which are commands judging by the sniffer logs) go only to 0x0000, i.e. to the coordinator is not clear to me. I need to read the states of the devices, but I do not know how.
Actually, is there any solution to this situation, somehow intercepting traffic on the network going to the coordinator, in order to parse it later? Or maybe some other way to make such devices respond to my address?
I will be satisfied with unproductive solutions, the only thing is that I cannot make the device a coordinator.
Additional context.
The device I work with:
Manufacturer is "_TZE200_e3oitdyu"
Model is "TS0601"
Device link
The code for sending a command to a device (the payload is written based on the example of a command sent from the coordinator via a mobile application):
Here is the request that goes to the device, it is processed successfully.
![Image](https://private-user-images.githubusercontent.com/36107602/409183066-d13dcd33-4789-4124-a45b-d8fcf2360449.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkxNDE2NDcsIm5iZiI6MTczOTE0MTM0NywicGF0aCI6Ii8zNjEwNzYwMi80MDkxODMwNjYtZDEzZGNkMzMtNDc4OS00MTI0LWE0NWItZDhmY2YyMzYwNDQ5LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMDklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjA5VDIyNDkwN1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTJkYmQyZWM0ZTI0ZTdhYmViNjE0YTY3ZGQyZTBlZmUxMGZlNzE5MWNjMTI3ODVjMmY1YWMwYmU5OGJhMzI5YTcmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.WSVI14DQ4V8UfzXIJy68EsKu6mVnSSx2E7IPmcQA2bw)
![Image](https://private-user-images.githubusercontent.com/36107602/409183328-3a584960-add8-4271-8ce2-b19efb0065a4.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkxNDE2NDcsIm5iZiI6MTczOTE0MTM0NywicGF0aCI6Ii8zNjEwNzYwMi80MDkxODMzMjgtM2E1ODQ5NjAtYWRkOC00MjcxLThjZTItYjE5ZWZiMDA2NWE0LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMDklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjA5VDIyNDkwN1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTQ5NjkxNTIzYmIyZTk2NjAxYThmZTM4ZWYzNzhhMjFhNzA1YmEyMzMzMzE1ODg0NTRhZmJmZDkxZTllODAxNzMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.2JdZrq30XqJnFPBiV3yrAhhwdD4gdWVVydTFTP5A9iU)
And here is the result that is sent to the coordinator after updating the attribute.
The text was updated successfully, but these errors were encountered: