How do I debug the issue
veonua opened this issue · comments
Zigbee Water Leak Sensor zigbee-water encountered error: [string "st.buf"]:695: buffer too short
how do I download and patch the st.buf to fix the buffer
how do I download and patch the st.buf to fix the buffer
This wouldn't be an option at the moment but we can try an figure out what might be going on if the libraries on the hub need to be updated.
It looks like that error is coming from read_bytes where the provided length argument is larger than the bytes remaining in the buffer. Can you provide any more context about when this issue is occurring?
I think the context is https://github.com/Coinscup/xiaomi/blob/18360b1a1121066229644020f3e5ea26089c06f4/devicetypes/bspranger/xiaomi-aqara-leak-sensor.src/xiaomi-aqara-leak-sensor.groovy#L188
Xiaomi has a special status message that can't be even read in lua
In this case the buf library isn't doing anything wrong but the Xiaomi device is incorrectly stating that an attribute has more bytes than it sends. However, I do agree that the handling of this isn't ideal. I have reproduced locally and we will look into options to allow a failure to still fallback in a way that a driver can still handle the message.
@varzac in the newest version the buffer is here, but still, it seems to be impossible to handle the message
2021-09-17T21:42:42.092072327+00:00 WARN Zigbee Water Leak Sensor Zigbee string reported length 34 but was actually only 33 bytes long
2021-09-17T21:42:42.100395327+00:00 INFO Zigbee Water Leak Sensor <ZigbeeDevice: 9631d82f-6ff0-438c-a8cd-3aaf214d5789 [0x7548] (Aqara Leak Sensor)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x7548, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: Basic >, lqi: 0xE0, rssi: -44, body_length: 0x0043, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x1C, mfg_code: 0x115F, seqno: 0x1E, ZCLCommandId: 0x0A >, < ReportAttribute || < AttributeRecord || AttributeId: 0x0005, DataType: CharString, ModelIdentifier: "lumi.sensor_wleak.aq1" >, < AttributeRecord || AttributeId: 0xFF01, DataType: CharString, CharString: "\x01\x21\xC7\x0B\x03\x28\x1B\x04\x21\xA8\x13\x05\x21\x39\x00\x06\x24\x00\x00\x00\x00\x00\x08\x21\x04\x02\x0A\x21\xD8\xA6\x64\x10\x00" > > > >
2021-09-17T21:42:42.124126327+00:00 DEBUG Zigbee Water Leak Sensor Aqara Leak Sensor device thread event handled
zigbee_handlers = {
cluster = {
[clusters.Basic.ID] = {
[0x0005] = xiaomi_attr_handler,
[0xFF01] = xiaomi_attr_handler
}
}
},
can_handle = function(opts, driver, device, ...)
return true
end
I can't tell from the context provided here, but this should be doable now. I have one of these devices and I had a driver that was successfully parsing that message. I will create a ticket to investigate again, but I probably won't have bandwidth for a while since it is no longer a crash. If you can provide more context/details of the overall driver here I might be able to spot something quickly. Otherwise I have been adding support for Xiaomi/Aqara drivers in my personal time over at https://github.com/varzac/EdgeDrivers and I was planning to add support for this device at some point so I will have a chance to check it out myself.
it should be
zigbee_handlers = {
attr = {
[clusters.Basic.ID] = {
attr instead of clusters