Very strange behaviour of Deconz

From yesterday morning, half of the devices didn’t respond even if they are linked.
I tried to reboot and then to upgrade from 2.15.0 no improvements.
Now I upgraded to 2.15.2 and seems better.
The problems were:

  • All Vimar covering devices didn’t respond.
  • Many Lidl smartplugs didn’t respond.
  • One Vimar smartplug became a double plug magically.
  • Aqara Multisensor stopped to update humidity.

Update: The upgrade to 2.15.2 didn’t solve.
Same problems. Vimar covering devices stopped to work again.

These are the same model of smartplug:

If I reset the left one by F5 it becomes corrected as the right one but, after minutes, doubled again!!!

Can you share some logs?

I just made a READ of cluster Basic and it lost the name.

Log time interval is too short. You should be very lucky to catch the issue.
Anyway I’ll try later.

Log is too long to enter in a post and the format doesn’t accespt .txt and.rar,

Pastebin :slight_smile:

@de_employees can you have a look? Please note that the user had issues in the past with his install and that i’ve not seen issues like this before. I am not sure if this is just limited to @LeoeLeoeL .

The moment the smartplug becomes a 2x smartplug should be around 14.20
14:17:09:012 poll node bc:33:ac:ff:fe:59:37:b5-0114:17:09:014 Poll light node - Pastebin.com.
The device is AxA4D3
I hope the procedure I did for Pastebin is correct.

That is courtesy of the quality product you have there. Deconz is not misbehaving, but the device.

Create a DDF for it and make sure you only use endpoint 0x0B. This basically dictates deconz what to use.

But I have 5 Lidl smartplugs.
Why only one is affected? And why after months?

Edit: Now, after a READ in Cluster Basic all of them are becoming “doubled”.
What happens after READ?
I can tell you a difference in Phoscon.
When you pair a LIDL device is recognized as a LIDL device. After READ it becomes TZ3000.

You have a PM

This is a bug in the plugs firmware. Apparently, a read of a certain attribute makes things go wrong there. I do not recall which one it was as this was already enough for me personally to run away from Tuya as fast as I could.

unknown

The above is the response the device sends, note the non-existent endpoint. When deconz receives that response, it things that particular endpoint has been forgotten and adds it. A DDF for that device would not prevent the endpoint popping up in the GUI, but it would prevent creating of an additional light.

Regarding the name change, when deconz joing new devices, the REST API plugin has a function to translate the original Tuya naming (manufacturer and model ID) to a more meaningful vendor/product for known devices. When reading the basic cluster and therefore the respective attributes via GUI, that function is NOT executed. Hence, the true values are picked up and displayed. The translation approach seemed to be a promising way at the beginning, but has proven to be too challenging to maintain due to the naming chaos accros Tuya and their respecive vendors.

Same bug for Livarno lights. After READ they become Tuya too.
For info, Hue Bridge detects them as Tuya directly.
In Phoscon, the doubled plugs kept the old name (plugs continue to work) and there are the new generic name too.
Both can contol the plug.

Today I added a Lidl 3 plugs device.
In Phoscon one has been seen as Lidl and two as Tuya.
Fortunately, Deconz didn’t double them up. :wink:

I read in Deconz changelogs lots of DDFs but for "rare"devices.
Is there an estimate for Tuya/Lidl DDFs?

P.S. I know you can say Tuya/Lidl DDFs are “rare” too! :slight_smile:

That’s due to the fact that Tuya devices work differently (not zigbee standard) opposed to compliant zigbee devices. They need a special approach and that is still in development by @de_employees. Also, most DDF’s are submitted by users at this moment :slight_smile:

Understood.
Plugs should be standard enough but lights give wrong values (when switched on) with NO TUYA hubs.

If the lights do that, they are not zigbee compliant or have firmware issues. Sockets and Lights are something that are fairly easy in Zigbee and that’s why they almost always work out of the box (except for the power meting part on sockets, as that needs special attentions). Until recently, all lights and colors always worked. Why? because they want you to use their hub. What we(you and I) are doing is trying to standardize it to use more devices with 1 hub(instead of Hue, Tuya, Ikea, and Xiaomi). By adding those kind of “customizations” they make it less user friendly/harder to make a standard out of it.