Devices becoming unavailable

I also have devices which becoming unavailable. The strange thing is, I am able to controll the lights by using my switches, connected with a push-button coupler (SR-ZG2833PAC-FOH). Reconnecting them by power cycling the device is also working

And like @nicoscholl already said… Device becoming unavailable - deCONZ / General Support - deCONZ Community (
The devices then work again as they should, but a few minutes later one or two other random device(s) become unavailable.
Deconz Addon: 2.20.1
Conbee2 Firmware: 26780700
Home Assistant 2023.3.4
Supervisor 2023.03.1
Operating System 9.5

How can I grab the logs from the light if the debug view only show a timespan about the last five minutes? Got it…will discribe later


Looks like your connecitons aren’t that good.

Additionally, can you tell more about the devices? Where are they? What brand?

Can you also add some logs? Just to make sure interference isn’t an issue.


hm, the conbee2 is ~5m away from all the “Kuechen*-Devices” and “Wohnzimmer*-Devices”. The conbee2 is placed in the working room which is next to the kitchen and the living room. Kitchen and the living room is an open space.
The “Wohnzimmer Deckenlampe” is a Paulmann LED Panel SmartHome Zigbee Velora. The “Kueche Pendellampe*-Devices” are Hue Filament Bulbs.
I´ve created a automation so i get notified if the device changes the status to unavailable. Or do you want the logs now?

For others running Home Assistant Supervised and wants to get logs.

  1. Install “SSH & Web Terminal” add-on and disable “Protection mode” and start the add-on
  2. docker logs --since=60min addon_core_deconz >> ~/config/deconzlog
  3. Install “File editor” add-on and download the “deconzlog” from “config” folder
    Modify the “logs”-command for your purpose

Okay, homeassistant sent a notification…
11:26:36 - Deckenlampe Wohnzimmer became unavailable
Here are the logs from 11:23 till 11:26

If you want to have a look in the logs of the last two hours… too large for pastebin.,39574890/deconzlog1145.txt/

I could only find 0xA7 NO_ACK

But that’s about it. Looks like it might be just the network quality.
@de_employees can you check?

1 Like

But there are other devices (lights) on the first floor which are more far away and not having this kind of issue.

As you can see in my first post the device (light) “Buero OG Deckenlampe” is also unavailable like “Wohnzimmer Deckenlampe”. But I also can turn it on/off with a push-button coupler (SR-ZG2833PAC-FOH). I pushed the switch at 14:47:01 and the light turned on.

14:47:01:780 trigger rule 27 - Rule PUSHDIMUP_ON14:47:02:598 Skip idle timer c -

Can you please post a picture of the lamp itself here or DM it to me?

1 Like

We first suspected that the design of the lamp shields too strongly. However, there should be no problems with the model. We simply assume a poor connection.
Is it possible to place another router or repeater between the gateway and the lamp?
A re-learning of the lamp should not be necessary. Please observe how the routing runs.

Otherwise, please also check whether the ConBee II is attached to an extension (necessary) and whether there are other routers, dongles or hard drives in the direct vicinity.

I do not think that the cause is a bad connection. Like I wrote the light is not far away and between them there are hue bulbs etc which can also act as router.
Should I place the light next to the conbee2 stick to prevent the problem of a bad conneciton?
The ConBee II is attached to an extension and is not in the direct vicinity of routers, dongles or hard drives.
And how is it possible that I can controll the lights by the push-button coupler (SR-ZG2833PAC-FOH)?

I am seeing an increased amount of reports saying devices are dropping without any reason.

1 Like

If several people, who have been working with deCONZ for a long time or are involved in the programming, say that it is probably due to the connection strength or network quality, this approach should at least be considered.
Have you tried source routing?

1 Like

I agree with you there. But it’s always easy to say “it’s because of a bad connection”.
Therefore my suggestion to place the device directly next to the conbee2 to exclude a bad connection.
No, should I enable source routing?

At least it is worth a try.
In this short video we describe how to activate source routing and how you can also manual route:

From a distance it is really hard to say where the cause lies with such connection problems. We do not want to make it easy for ourselves with the answer. Troubleshooting can only become very tedious.


Yesterday I´ve activated source routing and today in the morning I reconnect the device by power cycling it.
An hour ago HA sent a notification that the device is unavailable again. And in deconz there are no routes from “Wohnzimmer Deckenlampe”. Here are the logs from the last two hours, maybe you can have a look again? Its too long for pastebin or other platforms.,20737825/wohnzimmer1322.txt/

I dont wont to take over your case. But I’m running also with a raspee and some lamps from Paulmann. I also loose connection after a random time. A power cycle bring them back into the network.
So my conculsion is, that it is not a problem in the air / shields a.s.o. as they work after a power cycle normally for some time.
To me it looks, like the problem occured the first time with deconz version 2.16 or 2.17. Like some heartbeat timing has been changed in this versions and Paulmann zigbee implementation does not perfectly fit anymore. As other devices continue to work.

In my case, it is possible to control offline devices by sending a command the group, they belong to. Is this also possible in your case? If yes, then we face probably the same problem an I have no soloution yet.
(My case was mentioned here: Partial lose of connections)

Hope this helps to get an idea who to resolve the problem.

1 Like


I seem to have the same/similar problem.
I also have various “Paulmann Licht 500.48” LED dimmers.
There are 5 of them installed in a shelf. After quite a while (sometimes weeks), one or more are no longer accessible. However, it is not possible to predict which one.
In deconz, it is displayed as offline and can no longer be addressed via Alexa. A query of the basic cluster in deconz is also not answered.
However, it still responds to a group command from a directly paired TRADFRI switch.
When the “shelf inside left” no longer responded, I started a debugLog. Using the Alexa group command, I switched the shelf (all 5 dimmers) off/on, but as I said, only 4/5 responded.
Using the TRADFRI switch, however, all 5 dimmers could still be switched off/on simultaneously without any problems.
If anyone is interested, the debug log can be viewed here: DebugLog.

Details about the dimmer that did not react this time:

Regal links innen
Paulmann Licht
MAC-adress: 0x00158d00044d8569
NWK adress: 0x7644

With Paulmann Amaris LED panels that are recognised as “Paulmann Licht 371000002”, there is also the occasional problem that they can no longer be switched off. From this point on, they are seen as offline in deconz and no longer react to anything. After a power reset (fuse out/clean), they function normally again.

Hope also this helps to get an idea who to resolve the problem

1 Like

Any news on this? Is there anything else we can do?

Hey guys,

this problem is unfortunately difficult to reproduce for us. We have no other reports from Paulmann devices regarding limited functionality or connection problems.
We also don’t have the affected devices on site to test anything. I have contacted Paulmann to hopefully get the affected parts for testing.
Different connection strengths can vary greatly due to local conditions, which is very difficult to track anyway. Repositioning at your home will probably be difficult. Otherwise you can try to rebuild the gateway at another position (relocate).

I will keep you informed as soon as I get feedback from Paulmann.

1 Like