Closed doudz closed 3 years ago
If I'm not wrong 0x0530 doesn't use the ACK mode and so the 0x8011 should not be expected.
I leave @fairecasoimeme or @badzz to comment
if true, it's a problem because it was the purpose of https://github.com/fairecasoimeme/ZiGate/issues/239 and if ack mode isn't used why am I getting 0x8011 ?
Are you in full mode raw, or the normal one? That could explain
Envoyé de mon iPhone
Le 18 oct. 2020 à 21:19, Sébastien RAMAGE notifications@github.com a écrit :
if true, it's a problem because it was the purpose of #239 and if ack mode isn't used why am I getting 0x8011 ?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
I'm using the raw mode yes
So then forget what I said. This is the behaviour in Normal mode.
Hi, Could you give your environment ? device, command, cluster. I try to get the same issue but with no same result
Fred
@fairecasoimeme do you mean tha in RAW Mode we get x8011 for x0530 command ?
No, I don't get the 0x8011 with v3.1d. only when I execute ZDP command. This is why I need to know the doudz context
I'm trying to improve zigpy support. I made test with firmware 3.1d with Home Assistant 0.116.4 I got msg 0x8011 when during device discovery
Is that on purpose that the command 0x0530 is without Security ? Could it be related to the Zigbee command itself embedded into the RAW command and which trigger an APS ACK
@doudz, the 0x8011 is not a ACK from your command, It's a ACK from a "route record" message. I think your device is a router and every command you execute a route record message is send (not visible with zigate but with a sniffer) and a ACK 0x8011 is received.
But there is no ACK for 0x0530 command and unfortunately it's not wanted from us and I don't know (because the lib) if we could do something.
hum, the device is a Xiaomi vibration sensor, so not a router.
not a good news by the way, I was expected an ACK for command 0x0530 and I was really supposing it worked because I got a lot of message 0x8011 on another installation (with a router)
My understanding is that 0x0530 is a full raw and in such it makes sense not to have the 0x8011 (ACk). At least this was my understanding on the normal mode. However what I have suggested is to get an other API with a not-full Raw mode based on the function ZPS_eAplAfUnicastAckDataReq
@doudz, I think there is a router in your network. I try to test the RAW function with ZPS_eAplAfUnicastAckDataReq but I don't know if this function permit to manage cluster which is not enable in ZPSconfig
The message 0x8011 gives the wrong sequence id, it gives the sequence id of the ack instead of the sequence id of the sent command the original seq id is given by the message 0x8000 after sending a command then the message 0x8011 is supposed to provide the status of the sent command but the seq id doesn't match
example : Send: 0x530 b'02a6ec0101000001040000050005000700 data received 0x8000 b'00d905300000' LQI:0 data received 0x8011 b'00a6ec010000da' LQI:0
other example : Send: 0x530 b'02a6ec0101000001040000050003000700' Send: 0x530 b'02a6ec0101000301040000050104400200' data received 0x8000 b'00d505300000' LQI:0 data received 0x8000 b'00d605300000' LQI:0 data received 0x8011 b'00a6ec010000d7' LQI:0 data received 0x8011 b'a7a6ec010000d8' LQI:0