DIM-01 New FW not discovered correctly

[ElbilsChrippe]

I just bought a new DIM-01 unit and it has (called Plejd support to confirm this) a new FW version 0.0.4 (the old is 3.1.8). The discovery script does not seem to recognize this unit.
Debug print
2021-09-21 10:38:40 INF [plejd-mqtt] Discovered -unknown- (light) named Belysning Stora Sovrum (35 : E096970F8DF5_0)

it does not get included. Support said that there should be no interface changes with the new FW, but its sure is different.

The problems seem to originate in, master/plejd/PlejdApi.js:
` // eslint-disable-next-line class-methods-use-this
_getDeviceType(plejdDevice) {
// Type name is also sometimes available in device.hardware.name
// (maybe only when GWY-01 is present?)

switch (parseInt(plejdDevice.hardwareId, 10)) {
  case 1:
  case 11:
    return {
      name: 'DIM-01',
      type: 'light',
      dimmable: true,
      broadcastClicks: false,
    };`

Havent had time to debug further at this point in time. Will try to pull master to look. I'm currently using Current version: 0.8.0-beta.

Best regards,
/Christer

[SweVictor]

Nice catch!

You're probably right that hardwareId is not picked up. I haven't looked in detail, but I would guess that the hardwareId is written at least in verbose mode if you change the log level.

[ElbilsChrippe]

How can I get the logfile offline, where is that file stored in HA install?
Cant find it in config and verbose produce so much info that the component log window cannot catch everything since its truncated to last xxx lines :)

[SweVictor]

The Developing section has a log fetching part.

[ElbilsChrippe]

I could catch the whole log now from the container, thanks for pointing in the right direction. Think I need to debug the PlejdApi.js a bit more with additional printouts since the hardwareId is not printed.. more fault searching right :)

Do I have to alter the container or the image? (I'm pretty new to container id but I guess its teared up and down once the plugin starts from the supervisor right? So best shot is to alter the image or maybe even better add master into addons folder structure to run a local copy of the add-on.

[SweVictor]

I don't know any other way than manually installing master, fiddling with the code and letting it compile on the Home Assistant device.

Regarding the actual problem - what happens? The entire addon crashing? It could be handled nicer (let one device init fail and still init the rest), but for now it looks like something like this would be printed and the entire addon reset: Catastrophic error. Resetting entire addon in 1 minute [Error message, hopefully containing hardwareId]. Is this the case or what behavior do you see?

[ElbilsChrippe]

No no it seem to handle it in the initialization, there is no crash but the device isnt added either - so I stuck with this new device that cant be discovered and thus controlled by HA. If its a reall problem more and more people might get this one problem if it is the new FW. Plejd support said that an Plejd app update will bring possibility to update the FW making potential situation critical I guess :)

[SweVictor]

Alright, strange.

Shout if you want help debugging or adding debug code, or just post a PR when everything is up and running again!

[ElbilsChrippe]

Ahh sorry sorry, I can now see that the unit turns up in the mqtt discovery. So the only problem is really the device ID (DIM-01) is not correct.

[timjackson]

I have a set of DIM-01s installed in November 2021, all with firmware v0.0.4. They are discovered and work fine (including dimming) but show up cosmetically as model "-unknown-", as described earlier in this issue. They all have hardwareId=14, so I think PlejdApi.js can confidently be updated to treat hardwareId 14 as DIM-01.

Here's an extract from the logs showing discovery for one of the devices when running with log verbosity "silly":

{
    "deviceId": "-REDACTED-",
    "siteId": "-REDACTED-",
    "installer": {
      "__type": "Pointer",
      "className": "_User",
      "objectId": "-REDACTED-"
    },
    "dirtyInstall": false,
    "dirtyUpdate": false,
    "dirtyClock": false,
    "dirtySettings": false,
    "hardwareId": "14",
    "faceplateId": "4",
    "firmware": {
      "notes": "DIM-01",
      "createdAt": "2021-05-18T08:29:05.545Z",
      "updatedAt": "2021-08-12T07:21:05.730Z",
      "data": {
        "__type": "File",
        "name": "3435bac096e906bfbbf382723a74e8f6_application.bin",
        "url": "https://cloud.plejd.com/parse/files/zHtVqXt8k4yFyk2QGmgp48D9xZr2G94xWYnF4dak/3435bac096e906bfbbf382723a74e8f6_application.bin"
      },
      "metaData": {
        "__type": "File",
        "name": "5ff5c7323fcb88e1dc58ac54e1121f51_application.dat",
        "url": "https://cloud.plejd.com/parse/files/zHtVqXt8k4yFyk2QGmgp48D9xZr2G94xWYnF4dak/5ff5c7323fcb88e1dc58ac54e1121f51_application.dat"
      },
      "version": "0.0.4",
      "buildTime": 20210511111714,
      "firmwareApi": "6",
      "ACL": {},
      "objectId": "5FrzsZO2ES",
      "__type": "Object",
      "className": "Firmware"
    },
    ...
   }

I do wonder why dimming does work, given that in PlejdApi.js, "dimmable: false" is set for hardwareId 14, but I'm obviously not complaining. Is it possible that the "dimmable" property is not properly propagated to HA, at least for lights? (A separate issue, if so)

[SweVictor]

Thanks for that @timjackson!
I agree - changing Hardware ID 14 from unknown to DIM-01 seems like a safe change. I'll fix that right now and release a new version (0.9.1) after that.

Regarding dimming: We actually read the "traits" of each device. Since the device identifies itself as dimmable, we set it as dimmable in the code. The dimmable bool in the hardware id list is just a fallback (old devices didn't do this I think).

I'll mark this as resolved, please reopen (or create a new issue) if the new release didn't solve the issue.

[timjackson]

Thanks; can confirm my DIM-01s are now discovered correctly with v0.9.1