Help with new zigbee driver

🛎️ Get Help Devices
1

Hi,
I am trying to update an existing driver (Stelpro Maestro) to a new thermostat (Stelpro Allia). I can't seem to get updates from the thermostat. I suspect the following might be the issue. When I pair the device, if I look at the pairing info, I get two distinct signatures:

Manufacturer:	Stello
Endpoint 19 application:	21
Endpoint 19 endpointId:	19
Endpoint 19 idAsInt:	25
Endpoint 19 inClusters:	0000,0003,0004,0201,0204
Endpoint 19 initialized:	true
Endpoint 19 manufacturer:	Stello
Endpoint 19 model:	HT402
Endpoint 19 outClusters:	0003,000A,0402
Endpoint 19 profileId:	0104
Endpoint 19 stage:	4

Endpoint F2 application:	unknown
Endpoint F2 endpointId:	F2
Endpoint F2 idAsInt:	242
Endpoint F2 initialized:	true
Endpoint F2 manufacturer:	unknown
Endpoint F2 model:	unknown
Endpoint F2 outClusters:	0021
Endpoint F2 profileId:	A1E0
Endpoint F2 stage:	4

Could that be the issue ? If so, how should this be handled ?

I posted a more complex thread here (Stelpro Allia (SAT402ZB) thermostat driver?), but I figured having a more specific thread might be better

1 Like
2

This is not a problem with the driver, but an issue that starts to pop up more and more frequently in Hubitat with different Zigbee devices that expose the 'Green Power' cluster 0xF2.

I have the same problem with 3 different Tuya devices, but this one is not Tuya and the same was reported for an Ikea Zigbee device a few days ago.

HE wrongly sets the endpointId to F2 and as result, none of the Zigbee library functions are working.

@mike.maxwell can you advise, please?

2 Likes
3

Bingo! Looking at the logs, indeed, zigbee commands created by configureReporting are sent to F2 rather than 19! The first command is not written by the zigbee object and was rather hardcoded and handcrafted.

cmds:[
zdo bind 0xCF57 1 0x019 0x201 {5C0272FFFEEF524F} {}, delay 200, 

zdo bind 0xCF57 0xF2 0x01 0x0201 {5C0272FFFEEF524F} {}, delay 2000, 
he cr 0xCF57 0xF2 513 0 41 10 60 {3200} {}, delay 2000, 

zdo bind 0xCF57 0xF2 0x01 0x0201 {5C0272FFFEEF524F} {}, delay 2000, 
he cr 0xCF57 0xF2 513 18 41 1 0 {3200} {}, delay 2000]

The code being:

    def cmds = [
    //bindings
        "zdo bind 0x${device.deviceNetworkId} 1 0x019 0x201 {${device.zigbeeId}} {}", "delay 200"
        ]
    
    //reporting
    cmds += zigbee.configureReporting(0x201, 0x0000, 0x29, 10, 60, 50)   //Attribute ID 0x0000 = local temperature, Data Type: S16BIT
    cmds += zigbee.configureReporting(0x201, 0x0012, 0x29, 1, 0, 50)     //Attribute ID 0x0012 = occupied heat setpoint, Data Type: S16BIT

Now, how do we fix that ?

4

interesting, I would need one of these devices to actually trace it in hub code, there isn't any reason i can think of why we are ignoring the first endpoint.

Don't know if this will help but the following commands accept destEndpoint as an additional parameter:
zigbee.command()
zigbee.enrollResponse()
zigbee.readAttribute()
zigbee.writeAttribute()
zigbee.configureReporting()
zigbee.reportingConfiguration()
a few of the above were added into build 2.3.4.118

Examples:

zigbee.configureReporting(0xFC02, 0x0010, 0x18, 10, 3600, 0x01, [mfgCode: 0x110A, destEndpoint:0x05])
zigbee.writeAttribute(0xFC02, 0x0000, 0x20, 0x01, [destEndpoint: 0x03])
1 Like
5

Ok, the issue was that the fingerprint in the driver code did not match exactly, so HE did not recognize it. So it seems that if it does not recognize the fingerprint to match an existing known driver, then it selects the last one ?

Seems like it should select the most complete one.

On a tangential note, given that this device exposes two endpoints, how do I get a driver that supports both ? Do I need to have two fingerprint lines ? Do I need to hardcode which endpoint zigbee commands talk to ?

6

If there isn't an exact match on at least the in clusters then Device is assigned, beyond that all other fingerprint attributes are checked, and the driver with the most matching attributes is selected.

The fingerprint is only used to assign a driver during discovery.

Yes, for any and all other end points beyond the first one...

1 Like
7

Mmm, ok, somehow that did not happen.
This is the driver I started from, and its fingerprint:

I tried many things without success with the fingerprint, until I changed it to match exactly what was reported in the pairing info:

        fingerprint profileId: "0104", endpointId: "19", inClusters: "0000,0003,0004,0201,0204", outClusters: "0003,000A,0402"

There are some new in and out clusters, but also some in clusters that were in the original driver (humidity reporting, 405) which are no longer there.

Could this explain that this resulted in no match and then it selected "Device" and used the second endpoint ?

8

The best way to update a driver fingerprint is to use the log output from the "Device" driver getInfo command.
The fingerprint you posted in the driver is missing quite a few attributes.

9

Ah, yes, thanks! The Device driver getInfo command did not work well before, since it was using the second endpoint, but now that I managed to get it to use the first endpoint, it will probably be more useful. I guess it's a bit of a chicken and egg problem here: can't get the best info without having the somewhat right info

10

If I may make a suggestion, if the Device driver could allow someone to pick which endpoint to use in the case a device has multiple endpoints, it would be useful.

11

This isn't going to help your situation.
The hub selects the first endpoint returned by the device as the endpoint to use when getting the cluster information, then building the fingerprint from the driver, then matching that with the available drivers installed on the hub.
So the getInfo command is specifically setup to do work the same as device discovery.
No matter the endpoints your driver wants to use, the fingerprint in the device and the one the hub uses to assign a matching driver will be the first one returned by the device.
There is one notable exception to this rule and that is for Develco application profile devices, for these devices we ignore that endpoint as it doesn't return all the attributes we need for discovery.

12

So, what is the getInfo command supposed to yield as a result ?
I don't see anything more in the device page, and I see only this in the logs:

dev:2072022-12-06 16:03:28.121infoZigbee parsed:[raw:A81F19020126024021060008402333030000094023D4160000, dni:A81F, endpoint:19, cluster:0201, size:26, attrId:4002, encoding:21, command:0A, value:0006, clusterInt:513, attrInt:16386, additionalAttrs:[[value:00000333, encoding:23, attrId:4008, consumedBytes:7, attrInt:16392], [value:000016D4, encoding:23, attrId:4009, consumedBytes:7, attrInt:16393]]]
dev:2072022-12-06 16:02:58.457infoZigbee parsed:[raw:A81F1902010A0000299808, dni:A81F, endpoint:19, cluster:0201, size:0A, attrId:0000, encoding:29, command:0A, value:0898, clusterInt:513, attrInt:0]
dev:2072022-12-06 16:02:41.818infoZigbee parsed:[raw:A81F19020126024021060008402333030000094023C9160000, dni:A81F, endpoint:19, cluster:0201, size:26, attrId:4002, encoding:21, command:0A, value:0006, clusterInt:513, attrInt:16386, additionalAttrs:[[value:00000333, encoding:23, attrId:4008, consumedBytes:7, attrInt:16392], [value:000016C9, encoding:23, attrId:4009, consumedBytes:7, attrInt:16393]]]
dev:2072022-12-06 16:01:57.782infoZigbee parsed:[raw:A81F1902010A0000299808, dni:A81F, endpoint:19, cluster:0201, size:0A, attrId:0000, encoding:29, command:0A, value:0898, clusterInt:513, attrInt:0]
dev:2072022-12-06 16:01:43.569infoZigbee parsed:[raw:A81F19020126024021060008402333030000094023BF160000, dni:A81F, endpoint:19, cluster:0201, size:26, attrId:4002, encoding:21, command:0A, value:0006, clusterInt:513, attrInt:16386, additionalAttrs:[[value:00000333, encoding:23, attrId:4008, consumedBytes:7, attrInt:16392], [value:000016BF, encoding:23, attrId:4009, consumedBytes:7, attrInt:16393]]]
dev:2072022-12-06 16:01:16.632debuggetting info for unknown Zigbee device...
dev:2072022-12-06 16:00:58.486infoZigbee parsed:[raw:A81F1902010A0000299808, dni:A81F, endpoint:19, cluster:0201, size:0A, attrId:0000, encoding:29, command:0A, value:0898, clusterInt:513, attrInt:0]
dev:2072022-12-06 16:00:57.560debuggetting info for unknown Zigbee device...
dev:2072022-12-06 16:00:57.114infoZigbee parsed:[raw:A81F19020126024021060008402333030000094023B4160000, dni:A81F, endpoint:19, cluster:0201, size:26, attrId:4002, encoding:21, command:0A, value:0006, clusterInt:513, attrInt:16386, additionalAttrs:[[value:00000333, encoding:23, attrId:4008, consumedBytes:7, attrInt:16392], [value:000016B4, encoding:23, attrId:4009, consumedBytes:7, attrInt:16393]]]
dev:2072022-12-06 16:00:55.538debugconfigure() called...
13

Can you look at the general logs, not the zigbee logs? You should get a complete device fingerprint there.

14

it returns the entire device fingerprint line, you then paste that into your driver...
Now if the device refuses to respond to a readAttributes request for model, manufacturer, and software build, then you're SOL.
If the device further doesn't respond to a descriptor request on the first endpoint, then you're also SOL...
You're device seems uninterested in responding like a normal Zigbee device, so unless you want to loan me this thermostat so I can see what's going on under the hood, there's not much I can do...

15

These are the general logs. The Zigbee logs look like this

Testing2022-12-06 16:29:51.709 profileId:0x104, clusterId:0x201, sourceEndpoint:19, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-62
1 Like
16

Like I said before, for whatever reason we're ignoring the first device endpoint and selecting the second one in this case, which is going to cause you nothing but problems going forward.
I can fix this, but need this specific device to do so.

17

I think this fingerprint line is the correct one (it sure makes it work anyway):

fingerprint profileId: "0104", endpointId: "19", inClusters: "0000,0003,0004,0201,0204", outClusters: "0003,000A,0402"

This fingerprint line does allow Hubitat to select the first device endpoint instead of the second one.

Do you see something missing from the initial pairing info ?

Unfortunately, these thermostats are wired to my house, and I can't exactly remove them, I need them to heat my house in the winter :slight_smile:

18

i can loan you a Sinope TH1124ZB if that helps...

1 Like
19

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.