-
-
Notifications
You must be signed in to change notification settings - Fork 348
Zigbee subdevice dp-refresh not working #695
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
Comments
Without more infos it is hard to tell. So what exactly you call? Ideally please provide more log that we also see what is sent before. There are devices that suprt GET and other need a set before ... So please add more log |
Thank you for your reply Apollon77, That's all I'm sending to this ZigBee device in this particular example. Remember, this a a ZigBee device, therefore it's connected to the gateway, so I'm not connecting directly to it. First I connect to the gateway, as usual, and then as I wish to get the power consumption figures from the device, I'm sending the command shown to the gateway, but targeted to this ZigBee device by using "cid". Everything works fine when I try to change the power state of the device, with the set() method, and I receive the state change immediately. The problem lies when I try to get the read-only values, like wattage (dps 19), amperage (18), or voltage (20). These will come automatically every few minutes, but never when I issue the dp-refresh command, as shown in the first post. They do come however every few seconds, when I have the device screen open in the Smart Life app, so the ZigBee device does have the capability the send this data on demand. Here is the log with the 3 steps performed:
TuyAPI IP and ID are already both resolved. +0ms
TuyAPI SET Payload: +21ms
TuyAPI GET Payload (refresh): +825ms |
@serseb hm ... thats a difficult one. also because of that whole data encryption stuff I think we stay with 2 options: What you can try is to issue a "set" ala:
Do you get an snwer then? |
Thanks for the suggestion but still doesn't work. it also triggers an error as it gets not response after that "set": Error: Timeout waiting for status response from device id: bfe5538ec58a300568jmp3 If it would be successful, then I would get something like this (this is what I receive if I keep the SmartLife app open on the "Electric" on that device): TuyAPI Received data: 000055aa0000f4db00000008000000b800000000fcf3f5157f2c475da140340d23291d8553f4f30df288bc5b5b218c05b850593652bd6a464bac941f8ba2f76e6caa3 Well, I guess if it's a difficult one, probably it's best to stick to the WiFi smart plugs and avoid ZigBee ones. Thanks for your help though. |
thinkthe only way is to use Wireshark to sniff the localapp traffic to see what the app sends ... but because it is encrypted that might also be meehhh |
I would have to sniff the traffic between the app and the gateway. Not sure that's even possible. |
At least for iOS there are ways to get the "network" mapped to a localinterface and so see what happens... but yes not easy |
I have a ZigBee plug which I can control successfully (ON/OFF) by sending requests to the gateway and using cid to specify the subdevice. However, when I try to issue a forced refresh in order to get the power consumption, I get a DP_REFRESH event without data, as following:
TuyAPI GET Payload (refresh): +818ms
TuyAPI {
TuyAPI gwId: 'GATEWAY_ID',
TuyAPI devId: 'GATEWAY_ID',
TuyAPI t: '1740192863',
TuyAPI dpId: [ 4, 5, 6, 18, 19, 20 ],
TuyAPI uid: 'GATEWAY_ID',
TuyAPI cid: 'SUBDEVICE_MAC_NO_COLONS'
TuyAPI } +1ms
TuyAPI Received data: 000055aa00004e81000000120000002800000000b82db93d716f2e95a05604143f0971ea5f41bd1fc93423a63c884686d2c630710000aa55 +10ms
TuyAPI Parsed: +4ms
TuyAPI { payload: false, leftover: false, commandByte: 18, sequenceN: 20097 } +0ms
TuyAPI Received DP_REFRESH response packet without data - resolve +1ms
The subdevice does support this feature as whenever I have the device "Electric" screen in SmartLife app I do get the DP_REFRESH event successfully every few seconds. Otherwise, I will only get a DP_REFRESH at every 60 seconds or so.
I also tried to use the device Virtual ID instead of the MAC address, without success.
Please advise if there is a known bug / missing feature, or I'm missing something.
The text was updated successfully, but these errors were encountered: