ZigBee destination endpoints

🚧 Developers
1

@mike.maxwell over at Aurora Aone Rotary Dimmer you mentioned that the built in generic ZigBee dimmer driver has hardcoded destination endpoints .... is that true for all built in generic ZigBee drivers?

I just came up against this for a cheap ZHA inline relay - SZ manufacturer, Lamp_01 product - this is mentioned in several places in the forum with various hacked community drivers to get it working, mostly successfully. For example at Cheap uk Zigbee switch for £10

I bought a bunch of these and for mine they all report endpointId of 0x0B so none of the generic ZigBee drivers would work, equally so none of the other community drivers either.

I've pulled something together for now that works, but is it worth you modifying all the generic drivers to use the reported endpoints as you mentioned in that other thread?

I would imagine that this would get many more devices working out-of-the-box with the generic drivers?

Also, somewhat related, for the shortcut commands such as:

zigbee.on()
zigbee.off()
zigbee.onOffConfig()
...etc

Can they be made to respect the reported endpointId?

Or Is there a way to overload those with a target endpointId rather than using raw ZigBee "he cmd .... " or "he attr ...."?

2

These commands use the first reported endpoint for the advertized cluster. Some, but not all the zigbee drivers have have endpoints hardcoded.
It's an easy change on our end.

3

Do you mean as is returned by device.endpointId?

This was the device fingerprint:

ID: E035
Manufacturer: SZ
Product Name:
Model Number: Lamp_01
deviceTypeId: 15
manufacturer : SZ
idAsInt : 11
inClusters : 0000,0003,0004,0005,0006
endpointId : 0B
profileId : 0104
application : 01
outClusters : 0000
initialized : true
model : Lamp_01
stage : 4

None of the zigbee.XX() commands worked, for example instead of zigbee.off() I had to use:

return [
"he cmd 0x${device.deviceNetworkId} 0x${device.endpointId} 0x0006 0 {}"
]

4

interesting, zigbee.off() should return "he cmd 0x${device.deviceNetworkId} 0x${device.endpointId} 0x0006 0 {}"

can you try this: log.debug zigbee.off(), curious what that will return...

5

Yes, definitely something strange going on here because now those work!

def off() {

debug "off() Called!"

//return [
// "he cmd 0x${device.deviceNetworkId} 0x${device.endpointId} 0x0006 0 {}"
// ]
log.debug zigbee.off()

zigbee.off()

}

def on() {

debug "on() Called!"

//return [
// "he cmd 0x${device.deviceNetworkId} 0x${device.endpointId} 0x0006 1 {}"
// ]
log.debug zigbee.on()

zigbee.on()

}

def refresh() {

debug "Refresh() Called!"

//return [
// "he rattr 0x${device.deviceNetworkId} 0x${device.endpointId} 0x0006 0 {}"
//]
log.debug zigbee.onOffRefresh()

zigbee.onOffRefresh()

}

Log:

dev:4042019-09-20 16:46:00.108 infoTEST RELAY eventMap name: switch value: off
dev:4042019-09-20 16:46:00.107 debugdescription is catchall: 0104 0006 0B 01 0040 00 C8CB 00 00 0000 0B 01 0000
dev:4042019-09-20 16:46:00.105 debugParse() Called!
dev:4042019-09-20 16:46:00.000 debug[he cmd 0xC8CB 0x0B 6 0 {}, delay 2000]
dev:4042019-09-20 16:45:59.997 debugoff() Called!
dev:4042019-09-20 16:45:57.527 infoTEST RELAY eventMap name: switch value: on
dev:4042019-09-20 16:45:57.526 debugdescription is catchall: 0104 0006 0B 01 0040 00 C8CB 00 00 0000 0B 01 0100
dev:4042019-09-20 16:45:57.525 debugParse() Called!
dev:4042019-09-20 16:45:57.395 debug[he cmd 0xC8CB 0x0B 6 1 {}, delay 2000]
dev:4042019-09-20 16:45:57.391 debugon() Called!
dev:4042019-09-20 16:45:56.494 infoTEST RELAY eventMap name: switch value: off
dev:4042019-09-20 16:45:56.479 debugdescription is catchall: 0104 0006 0B 01 0040 00 C8CB 00 00 0000 0B 01 0000
dev:4042019-09-20 16:45:56.477 debugParse() Called!
dev:4042019-09-20 16:45:56.405 debug[he cmd 0xC8CB 0x0B 6 0 {}, delay 2000]
dev:4042019-09-20 16:45:56.403 debugoff() Called!
dev:4042019-09-20 16:45:48.017 infoTEST RELAY eventMap name: switch value: off
dev:4042019-09-20 16:45:48.014 debugdescription is read attr - raw: C8CB0B00060A00001000, dni: C8CB, endpoint: 0B, cluster: 0006, size: 0A, attrId: 0000, encoding: 10, command: 01, value: 00
dev:4042019-09-20 16:45:48.011 debugParse() Called!
dev:4042019-09-20 16:45:47.940 debug[he rattr 0xC8CB 0x0B 6 0 {}, delay 2000]
dev:4042019-09-20 16:45:47.936 debugRefresh() Called!

Not sure why they didn't work before, nor why none of the generic drivers I tried worked (unless just unlucky that they were all ones that have hardcoded endpointId ... I tried most of the switch / outlet / bulb ones).

6

dunno, I've added a task to update any of the fixed ep generic drivers...

7

Yeah, now this one also works with the generic drivers Outlet / Switch as well if I switch over to them .... on/off/refresh/config .... bizarre.

Doesn't make sense .... and it's not just me since other people report the same in those other threads too ..... oh well, least I can switch to a built-in driver now and remove mine.

I've got a bunch more of these in the boxes still so will try and reproduce on some fresh ones at a later date.

8

i'm not aware of other threads reporting this, links?

9

Off the top of my head it's mostly these two:

Same experience as me, the device doesn't work with any of the generic drivers ....

Which is what started me down the path of knocking up my own driver to see what was going on.

I'll try and reproduce it later with a fresh one to get the bottom of it, only thing I can think perhaps is the generic drivers try and configure it in some way that it doesn't like.