The first log is the zigbee request made by deconz with the “request number” (here 84), you can reconise it with the cluster EF00.
And the second packet (it will be different for you, probably a timeout error) is the return from the device.
You need to use the GUI, it’s the official docker ? It’s possible using VNC, but the procedure will depend of OS.
It’s possible too with command line, but less friendly (and more complex on docker)
Request 124 is the request I sent to the motor.
We can see that the device returns a status 0x00 success, after that an erase from queue.
This is similar what you have sent. I’m wondering if the culprit woulnd’t be the device it self.
I’ve tried to power cycle it (pressing for 7 sec the setup button until the led would flash blue 3 times, waited for a few minutes and then pressing for 1 sec until the led would turn blue), nothing.
FYI, I purchased the units from the Moes Store on Aliexpress, I’ve open a support request from them asking for guidance. I will keep you posted on the reply.
Yes it’s exaclty that. And it’s not on deconz side, but realy zigbee one.
We can see the gateway making the zigbee request (the asdu is the raw zigbee value)
00 2e 0104 00 01 00 > Dp = 01 (DP_IDENTIFIER_CONTROL), type = 04 (enum) , len value = 1, value = 0, it’s a open or close request.
The device have received it, and have answer. So if it does move …
For “set position” request, I know it can don’t work if the calibration is not done, but for open/close, there is no problem.
As you have working and not working device, perhaps you can see a hardware difference, not the same swbuild for exemple, perhaps there is a new model that need a different request (or the tuya unlock sequence)
Remember the issue we have troubleshooted together ? Where the motor would refused when requested through Zigbee and not with the button ?
I think I’ve nailed down what happen, I think the motor was in overload protection.
I’ve run into the same situation with another motor, I’ve figured this out by re-reading the documentation and noticed one side of the string was really tense. I’ve relaxed it a bit (unmount the motor, move 1-2 beads from the other side to the side it was tensed) and voila the motor responded again !
I think this is worthwhile sharing with the community. The Moes support was not helping at all. The minute you would tell them you are not using their hub, boom, the issue is caused by that and they would refuse to collaborate.
For documentation, idk, there is so much place to search (and not necessarily found ^^) information.
I think this topic is easy to found on search engine.
But yes usefull return, but I don’t understand
Where the motor would refused when requested through Zigbee and not with the button
Mean the protection work on zigbee request but not on manual request ?
Mean the protection work on zigbee request but not on manual request ?
No, the other way around, the protection doesn’t work on zigbee request but on manual request.
