Devices becoming unavailable

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.

2 Likes

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.
https://www.xup.in/dl,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

Hello,

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
500.48
Router
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

Does anyone know how I can reinstall the whole firmware with bootloader in my HomeKits lock?

I have received feedback from Paulmann. No changes have been made to the firmware. I have attached the link to this forum post to my reply.
Otherwise we are trying to look at the logs to find out where the error might be. Due to the vacation season we are currently a bit low staffed. I ask for patience here.

Attaching to this issue as I’ve the same irregular disconnects of a Paulmann LED stripe triggered by a motion sensor (unfortunately mainly during the night).

Hopefully we can find the reason together. Providing some log files should be the easiest part. :fist:t2:

No more news, yet?

I just found out that the device is marked as a "zombie"because of errors.

@Florian-Schmidt Is the device covered by a DDF? If not, I’d recommend creating one and observe if the loss happens again. We recently had something similar just for devices being fully handled by legacy code, DDF covered devices behaved as expected.

@Swoop I guess you are talking about the Heiman devices. I‘ve no idea how to create a DDF. :hugs:

The lights worked at the beginning and suddenly started to have this loss. Means I‘m pretty sure that it is caused by an update but unfortunately I don‘t know which version.

@Florian-Schmidt Check out DDF cheat sheet · dresden-elektronik/deconz-rest-plugin Wiki · GitHub for DDF related information. Should contain everything to give you a start, tweaking can be made here :wink:

Hi

I just came accross your post and since years I’m facing problems with lights losing connection in different systems I run.

I also have problems with Paulmann lights. But also other manufactors. Power cycle always brings them back for days or weeks and they keep working with API group commands.

But it is just annoying!

Let me know if you found a solution for your Paulmanns.

Thanks

Here some more info about this.

Here is the connection view in deconz:

You can see all the Wand-Lights have a very green solid connection and also acting as routers

But if I check in Phoscon App it looks like this:

All the Wand-Lights show disconnected as many others do!

And I faced this problem on different systems I setup.

Any idea how this problem could be resolved?

Thanks