It just happened for the first time with the GUI running.
I went to copy the log and it didn’t get anything from the time it happened.
It happened at 2:08, the log I captured starts at 2:09.
Does the debug save to a file automatically? If so, where is it.
I just tried to copy the live output and paste into a file. Maybe it overwrote faster than I could capture?
I just noticed that every time this happens I get the green connection line shown above.
The green one goes right to the conbee, the yellow goes to the next device.
You said end devices only have one connection, how does it then have 2?
Only one is active, it’s because the device have just moved in the network, so it was still in an old neigtboard table.
But can be an hint, can be a connexion issue that cause the device change his parent, or can be the parent change that provoke the connexion issue.
Does the debug save to a file automatically? If so, where is it.
I just tried to copy the live output and paste into a file. Maybe it overwrote faster than I could capture?
If you are using the GUI, no, nothing is saved, it’s only live, to save need to use the command line, but more stressing for hardware.
So this is definitely a Deconz bug.
I added 3 more of these, actually 2 of them are a different manufacturer but the unit is the same, just different firmware, and the 2 Aqara branded units “close” at exactly the same time 3 days in a row now.
The 2 Tuya branded never change status but show no battery level.
I checked the internet and can’t find any problems with the Aqara models if using the Aqara app.
The fact that they “close” at exactly the same time screams protocol error with Deconz, especially since the new one I added is sitting a couple feet away from the conbeeII and never shows any signal degradation.
I also tried with Deconz GUI and headless, happens both ways.
What can I provide to debug this?
I’m headless now, will this command be enough?
/usr/bin/deCONZ -platform minimal --dbg-aps=2 --dbg-info=2 --dbg-error=2 | tee debug.txt
There is a dev with similar issue ATM for sonoff device.
He have solved his issue with increasing bind interval and remove “refresh.interval” from DDF.
This one don’t have bind/report, but you can try with removing all “refresh.interval” from the DDF ? (For the “lumi.curtain.acn002”)
I can’t seem to find the DDF??
Is there another place where it might be?
I checked /usr/share/deCONZ/devices and /home/user/.local/share/dresden-elektronik/deCONZ/devices
No lumi devices at all.
The DDF is this one deconz-rest-plugin/aq_curtain_acn002.json at 52bbb042ac447e3e04a4a560afb68f4f29d66b8e · dresden-elektronik/deconz-rest-plugin · GitHub
That’s what I thought too but if I go to “Edit DDF” in the GUI I get this:
Shows as Draft instead of Gold and Manufacturer as Lumi instead of Xiami.
Where would this file be? And is it using the wrong DDF maybe?
Manufacturer and ModelID are from your device (you can see them in the Basic cluster too) and must match the ones in the DDF for it to be loaded.
May be the “reconnection” of your device haven’t be to the end, is there a way for you to awake the device and in the mean time doing a read in the Basic cluster ?
WTF ?
Effectively there is something strange, why the DDf is not picked when you make “edit DDF” ?
Wich one deconz version are you using ?
The DDF is marked as “Draft” but seesm to be loaded as Battery and
I’m not sure about the influence on routing, but can we consider that it’s normal that a battery powered end-node device is not defined as "sleeper": true, in DDF ?
Sleeper have nothing to see with battery, a doorlock is not a sleeping device, but a battery powered one. Sleeper device realy sleep, some battery device have latency (some seconds, it’s definied in “zigbee rules”) still answer, but are not able to work as router.
Shows as Draft instead of Gold and Manufacturer as Lumi instead of Xiami.
But I don’t understand why the DDF is not picked wjen you make “edit DDF”.
Deconz select the DDF with thoses field
"manufacturername": "$MF_LUMI",
"modelid": "lumi.curtain.acn002",
$MF_LUMI = “LUMI”
And this file is 8 month old, you are sure this one is not visible in your “devices” folder ?
That’s may be the only root cause … If the DDF doesn’t exists on system it can be picked up !
But did you find other DDF in these places ?
And if you try to save the DDF with “Save as …” where did Deconz propose to save that file ? You could perhaps copy that DDF deconz-rest-plugin/aq_curtain_acn002.json at 52bbb042ac447e3e04a4a560afb68f4f29d66b8e · dresden-elektronik/deconz-rest-plugin · GitHub to this folder and see what happens.
I have 55 manufacturers named in the devices folder with various DDF’s in each.
There are none in the /home/user folder.
I haven’t tried to save but I will now.
Does Dresden provide any support for any of this or is it all just community driven?
It saves to the /home/user/.local/share/dresden-elektronik/deCONZ/devices folder.
The DDF linked to is the Xiaomi version. I have that one in the devices/Xiaomi folder but it doesn’t seem to be the one being used since when I go to “Ediit DDF” it brings up a different file that I can’t find anywhere.
For ? a missing file ? It’s not normal as the file was in the package.
you haven’t a file called “aq_curtain_acn002.json” in the “devices/xiaomi folder” ?
Perhaps you have DDF disabled ? in Panel/Control ?
Not for a missing file, to fix this issue.
As I said, I do have that file but when I go to Edit DDF, then Preview, it’s different than that file.
What do you mean “in” panel/control?
Control is just a check box. Is there somewhere else I’m supposed to be looking?
Yep, checking this option will enable a new “tab control”.
IDK, but I think specific support have nothing to see with them. Contact them on the forum can be usefull, but using the hardware support, I have a doubt …
And I have made a search on other zigbee project about disconnection for this device, nothing special yet.
Yes, I already had the tab, but I don’t see a way to disable DDF.
Jutst check if they are enabled, because I don’t see why deconz don’t pick the DDF.