DDF is not loading only for one of my two devices

BabaIsYou · July 12, 2022, 12:38pm

Hi,

Yesterday, after rebooting my Raspberry where deCONZ and ConBee II are installed I saw that my two TH1124ZB thermostats didn’t display the same outdoor temperature after a few minutes. My 3 thermostats (2 TH1124ZB and a SMT402AD are updated the same way with a script updating externalsensortemp config parameter that is in respective DDF files for these thermostats.

Before reboot all worked fine. But after reboot one of the two TH1124ZB doesn’t update anymore.

Looking in my script log file, it seems that the externalsensortemp config parameter doesn’t exist anymore just for one of my two TH1124ZB.

Trying to reload DDF file for that thermostat using deCONZ-GUI has no effect. I can open the DDF for that thermostat, doing a hot reload but after closing the DDF window the thermostat seems to get back to the “basic DDF”.

I stopped deCONZ and lauched it in interctive/debug mode to get a log ’ /usr/bin/deCONZ --dbg-info=2 > debug.txt’

Doing a ‘cat debug.txt | grep DDF’ we can clearly see that a DDF is loaded for one of the TH 0x500B91400002CA1C and not for the other 0x500B91400002C436 (exactly same model)

.

All the basics functionnalities are operationnal (putting thermostat mode to Off, modifying heatsetpoint) and accessing thru deCONZ-GUI (thermostat Thermostst Bureau in picture)

What can I do to have the DDF correctly loaded ?

Update : Adding some configuration info :

Smanar · July 12, 2022, 3:57pm

Funny issue ^^
You are sure both device have same model id and manufacture name ?

To check if a DDF is valid the code check for name and descriptor
bool isValid() const { return !name.empty() && descriptor.isValid(); }

Can you show the device json for the faulty device ?
Can try to re-include it, at least partially, don’t delete it, set phoscon in permit join, read again descriptor on deconz (the first circle in node titlebar)

I can open the DDF for that thermostat, doing a hot reload but after closing the DDF window the thermostat seems to get back to the “basic DDF”.

Nothing usefull in logs when doing that ? too much talkative ? (“info” “info_l2” “ddf”)

BabaIsYou · July 12, 2022, 5:28pm

Yes a bit weird, especially since it worked perfectly before the reboot, which I only did because I had to unplug my Raspberry to put it back in the same place.

The semi-faulty thermostat is completely reachable and all the basic functions that the autogenerated DDF allows are operational (when supported of course), including access via Phoscon web.

And also json :

The one that is working fine

{
    "config": {
        "externalsensortemp": 2620,
        "heatsetpoint": 1800,
        "ledindication": true,
        "local_occupancy": true,
        "mode": "off",
        "offset": 0,
        "on": true,
        "reachable": true,
        "schedule": {},
        "schedule_on": false,
        "unoccupiedheatsetpoint": 1800
    },
    "ep": 1,
    "etag": "b69137a13c50cbf5f5f3fb9d9bdc0e5b",
    "lastannounced": null,
    "lastseen": "2022-07-12T17:22Z",
    "manufacturername": "Sinope Technologies",
    "modelid": "TH1124ZB",
    "name": "Thermostat Salon",
    "state": {
        "lastupdated": "2022-07-12T17:22:21.388",
        "on": false,
        "temperature": 2446
    },
    "swversion": "2007",
    "type": "ZHAThermostat",
    "uniqueid": "50:0b:91:40:00:02:ca:1c-01-0201"
}

and the semi-faulty :

{
    "config": {
        "heatsetpoint": 1800,
        "mode": "off",
        "offset": 0,
        "on": true,
        "reachable": true,
        "schedule": {},
        "schedule_on": false
    },
    "ep": 1,
    "etag": "2fdb97e29c2cf0b58aa68ce119d7e766",
    "lastannounced": "2022-07-12T01:11:01Z",
    "lastseen": "2022-07-12T17:22Z",
    "manufacturername": "Sinope Technologies",
    "modelid": "TH1124ZB",
    "name": "Thermostat Bureau",
    "state": {
        "lastupdated": "2022-07-12T17:22:00.678",
        "on": false,
        "temperature": 2565
    },
    "swversion": "2007",
    "type": "ZHAThermostat",
    "uniqueid": "50:0b:91:40:00:02:c4:36-01-0201"
}

I turned the thermostat off and back on but that didn’t change anything. I have not tried to redo a pairing without deleting it. I wanted to see if there was nothing to look at before, in fact I was especially afraid of having to erase it to start the configuration again.

BabaIsYou · July 12, 2022, 6:03pm

Well … I’m completely flabbergasted … During the collect of information to do the previous reply I was surprised that the manufacturer was designed as “Sinope Technologies” because without DDF it was just “Sinope”. But the json was still uncomplete (missing some /config parameters, like externalsensortemp).

While still looking for some troubleshooting I saw that all was return to normal without further intervention ?!!!

{
    "config": {
        "externalsensortemp": 2640,
        "heatsetpoint": 1800,
        "ledindication": true,
        "local_occupancy": true,
        "mode": "off",
        "offset": 0,
        "on": true,
        "reachable": true,
        "schedule": {},
        "schedule_on": false,
        "unoccupiedheatsetpoint": 1800
    },
    "ep": 1,
    "etag": "04c82e3ce4f4efd14671383b859a5412",
    "lastannounced": "2022-07-12T01:11:01Z",
    "lastseen": "2022-07-12T18:00Z",
    "manufacturername": "Sinope Technologies",
    "modelid": "TH1124ZB",
    "name": "Thermostat Bureau",
    "state": {
        "lastupdated": "2022-07-12T18:01:27.667",
        "on": false,
        "temperature": 2568
    },
    "swversion": "2007",
    "type": "ZHAThermostat",
    "uniqueid": "50:0b:91:40:00:02:c4:36-01-0201"
}

Smanar · July 12, 2022, 6:45pm

lol, zigbee is magic ^^.

Hu ?
On your capture of “node info” it s “Sinope Technologies” too, I never see “Sinope” alone ?

I can’t explain the issue, but for me something was corrupted on the device ressource, but I didn’t look any further and idk what deconz is checking in them.

Hoping for not the same issue at next reboot !

Swoop · July 12, 2022, 7:05pm

The root cause for this is the legacy code, as it overwrites the real value reported by the manufacturer name attribute. I spare the technical details and this is one of the bad habits…

If that should ever happen again, it should be enough to read the attributes of the basic cluster. And the device specific legacy code should be removed timely.

BabaIsYou · July 12, 2022, 7:18pm

This is precisely what caught my attention because without DDF it is just “Sinope”. This is precisely what allows me to quickly see if the DDF is properly loaded. And when I took the screenshots a little earlier I was surprised because last night we could still see “Sinope” for one and “Sinope Technologies” for the other?!

Next time I’ll try just to read the basic cluster attributes like Swoop suggested.

Smanar · July 13, 2022, 3:29pm

@Swoop is right, I have found the guilty.

    else if ((node->nodeDescriptor().manufacturerCode() == VENDOR_SINOPE))
    {
        sensorNode.setManufacturer("Sinope");
    }

So the legacy code can overwrite the manufacture name, realy bad idea again to overwrite manufacture name or model id …

If you want you can submit a PR to remove thoses lines if you have too much problem with them (else it will be removed in the future when DDF will replace legacy code)