Sengled lights stopped working in Rummelsnuff

I have 20 Sengled Tunable White Bulbs that have been working great with Conbee II/deConz/Phoscon for several years. Also, I have six Sengled PAR38 Flood lights with motion sensors.

With the upgrade to Rummernuff and Desert Mountain Table, which supposedly added SENGLED specific cluster definition, these no longer work.

They are part of my Zigbee network and appear in the Phoscon app. But turning them on or off through the Phoscon app or the API (Home Assistant deConz integration) has no effect.

Model id for Tunable bulbs is: Z01-A19NAE26
For the Par28: E13-N11

Can you please insert some sceenshots of clusters displayed in GUI for these devices ?

For Z01-A19NAE26

image

Node Info:

Basic info:

Identify cluster:

Group cluster:

Scene:

On/off:

Level control:

Color control:

Simple metering:

Diagnostics:

OTAU:

For the Par38 Bulb
Note: this has never fully worked in deConz. It is supposed to expose light (state, brightness), power_on_behavior, occupancy. Occupancy shows up on some of my bulbs and not others.

image

Node info:

Basic info:

Identify:

Groups:

Scenes:

On/off:

Level control:

Color control:

Simple metering:

Diagnostics:

OTAU:

IAS Zone:

Sengled Control Specific:

Thx.
As I could see these devices are directly managed by legacy code and not using DDF.
Then I have some trouble to understand in what adding 0xFC01 cluster definition in general.xml could change something in behavior of these devices.

Nothing as changed in OnOff cluster (0x0006).

Could you try to supress lines added in general.xml thru PR #6569 and restart DeConz just to be sure that it’s the source of the issue ? Don’t know if it’s easy in your confiuration.

What would it take to migrate them to DDFs?

May be tough to find root cause. The lights work intermittently, often with a long delay. Rest of the Zigbee devices are working fine. This problem was introduced with the latest builds.

Possibly the host Windows machine is old and slow.

But deConz has been stable on this machine for four years. No problems with each software update.

I’m looking at the general.xml file. Not sure what you mean by “supress lines added thru PR #6569

Hello,

Im sure that passing them to DDF will change something but the faster way to do it is to select the device in Deconz-GUI, select the far right radio button to display the clusters list
image
Then after slelecting the basic cluster, make a read on the left panel, cluster info


Then after that you could do a CTRL-E to open DDF editor and do a File / Save
image

but the auto-generated DDF is not always complete and I think that we can help you to review it.

Thru PR #6569 some lines were added to general.xml to explicit Sengled spcific clusters and attributes. If that introduced an issue (I don’t hink so because you mentionned that some of the lights works intermittenly) you can try to suppress this line with a text editor in general.xml and restart DeConz. The lines are listed here

My conclusion is that the problem was not introduced by the deConz update. I need to strengthen my mesh network with additional routers/repeaters. And it may be time to upgrade the 10 year machine that hosts my deConz/Conbee II. There are other processes running on it that are slowing it down.

WRT DDFs. Here is the auto generated for the P38 Bulb. I don’t see where it includes the Sengled specific Cluster and Occupancy readings.

{
“schema”: “devcap1.schema.json”,
“manufacturername”: “sengled”,
“modelid”: “E13-N11”,
“product”: “E13-N11”,
“sleeper”: false,
“status”: “Draft”,
“subdevices”: [
{
“type”: “$TYPE_DIMMABLE_LIGHT”,
“restapi”: “/lights”,
“uuid”: [
“$address.ext”,
“0x01”
],
“items”: [
{
“name”: “attr/id”
},
{
“name”: “attr/lastannounced”
},
{
“name”: “attr/lastseen”
},
{
“name”: “attr/manufacturername”
},
{
“name”: “attr/modelid”
},
{
“name”: “attr/name”
},
{
“name”: “attr/swversion”
},
{
“name”: “attr/type”
},
{
“name”: “attr/uniqueid”
},
{
“name”: “state/alert”,
“description”: “The currently active alert effect.”,
“default”: “none”
},
{
“name”: “state/bri”,
“description”: “The current brightness.”,
“refresh.interval”: 5
},
{
“name”: “state/on”,
“description”: “True when device is on; false when off.”,
“refresh.interval”: 5
},
{
“name”: “state/reachable”
}
]
},
{
“type”: “$TYPE_CONSUMPTION_SENSOR”,
“restapi”: “/sensors”,
“uuid”: [
“$address.ext”,
“0x01”,
“0x0702”
],
“fingerprint”: {
“profile”: “0x0104”,
“device”: “0x0101”,
“endpoint”: “0x01”,
“in”: [
“0x0000”,
“0x0702”
]
},
“items”: [
{
“name”: “attr/id”
},
{
“name”: “attr/lastannounced”
},
{
“name”: “attr/lastseen”
},
{
“name”: “attr/manufacturername”
},
{
“name”: “attr/modelid”
},
{
“name”: “attr/name”
},
{
“name”: “attr/swversion”
},
{
“name”: “attr/type”
},
{
“name”: “attr/uniqueid”
},
{
“name”: “config/on”
},
{
“name”: “config/reachable”
},
{
“name”: “state/consumption”,
“refresh.interval”: 300,
“default”: 0
},
{
“name”: “state/lastupdated”
},
{
“name”: “state/power”,
“refresh.interval”: 300,
“default”: 0
}
]
}
],
“bindings”: [
{
“bind”: “unicast”,
“src.ep”: 1,
“dst.ep”: 1,
“cl”: “0x0006”,
“report”: [
{
“at”: “0x0000”,
“dt”: “0x10”,
“min”: 1,
“max”: 300
}
]
},
{
“bind”: “unicast”,
“src.ep”: 1,
“dst.ep”: 1,
“cl”: “0x0008”,
“report”: [
{
“at”: “0x0000”,
“dt”: “0x20”,
“min”: 1,
“max”: 300,
“change”: “0x00000001”
}
]
},
{
“bind”: “unicast”,
“src.ep”: 1,
“dst.ep”: 1,
“cl”: “0x0500”
},
{
“bind”: “unicast”,
“src.ep”: 1,
“dst.ep”: 1,
“cl”: “0x0000”
}
]
}

You told earlier in this thread that " Occupancy shows up on some of my bulbs and not others.". Does this autogenerated DDF come from one in which Occupancy does not appears ?

Everything is working, so I’m putting the migration to DDF on hold. Thanks for your responses and support. I’ve been using product for three years and it has been great for my Zigbee needs.