You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although considered gold support, the last version of Deconz these worked properly with was 2.15.0 Beta (here, back in March 2022).
I've checked many versions since, up to 2.28.0, and behaviour is now that the lights will - one by one - 'drop off' the Zigbee network altogether and not return until mains-power cycled. This happens over the space of a few hours; meaning that typically a day later none of the lights are operational and all need to be power cycled.
In all scenarios described I'm using the Docker Image distribution of Deconz, in case that's significant.
On versions 2.15.0 and previous; behaviour is rock solid (and for this reason my home setup is 'stuck' on that version).
Steps to reproduce the behavior
Provision any version of Deconz after2.15.0 with one or more 3A Smarthome light using the 3A12S-15 support.
Switch the light(s) on/off a few times, wait an hour, do it again. It won't be long before the light stops working due to having dropped off the Zigbee network (observed as disconnected in Deconz Conbee II node graph and not responding to reading binding table commands etc. shows 'red' indicator).
Expected behavior
Light remains on the Zigbee network continues to respond to on/off commands reliably.
Screenshots
No response
Environment
Host system: Server PC (HP Workstation Z800)
Running method: Docker Container on Ubuntu
Firmware version: 26720700 (Read from about screen when working reliably on 2.15.0
deCONZ version: Problem occurs on any version after2.15.0
Device: ConBee II
Do you use an USB extension cable: Yes
Is there any other USB or serial devices connected to the host system? No
deCONZ Logs
No response
Additional context
I will see if the drop-off is recorded in logs as above.
The text was updated successfully, but these errors were encountered:
chris-hatton
changed the title
3A Smart Home LED controller (3A12S-15) broken since 2.15.0
3A Smart Home (3A12S-15) support broken since 2.15.0
Oct 7, 2024
Tracing the history of the current DDF file for this device, it strikes me that @BabaIsYou apparently added this DDF in Oct 2022, while the 'good' version of Deconz that I'm using is from March 2022 - so how were they working before this DDF?
The 'Preview' tab in the VNC UI of my older Deconz 2.15.0 instance does show a DDF file specifically for this device. I might be lacking some understanding about how Deconz device support progresses in general, but based on the evidence it seems the new DDF file may be the culprit.
Does the issue really belong here?
Is there already an existing issue for this?
Describe the bug
I have six of these 3A Smarthome downlights, which contain these 3A12S-15 strip controllers.
Although considered gold support, the last version of Deconz these worked properly with was
2.15.0
Beta (here, back in March 2022).I've checked many versions since, up to
2.28.0
, and behaviour is now that the lights will - one by one - 'drop off' the Zigbee network altogether and not return until mains-power cycled. This happens over the space of a few hours; meaning that typically a day later none of the lights are operational and all need to be power cycled.In all scenarios described I'm using the Docker Image distribution of Deconz, in case that's significant.
On versions
2.15.0
and previous; behaviour is rock solid (and for this reason my home setup is 'stuck' on that version).Steps to reproduce the behavior
Provision any version of Deconz after
2.15.0
with one or more 3A Smarthome light using the 3A12S-15 support.Switch the light(s) on/off a few times, wait an hour, do it again. It won't be long before the light stops working due to having dropped off the Zigbee network (observed as disconnected in Deconz Conbee II node graph and not responding to reading binding table commands etc. shows 'red' indicator).
Expected behavior
Light remains on the Zigbee network continues to respond to on/off commands reliably.
Screenshots
No response
Environment
2.15.0
2.15.0
deCONZ Logs
No response
Additional context
I will see if the drop-off is recorded in logs as above.
The text was updated successfully, but these errors were encountered: