Pull Request Test Coverage Report for Build 12845094518

Details

• 0 of 3 (0.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.05%) to 28.368%

Totals
Change from base Build 12845052540:	-0.05%
Covered Lines:	431
Relevant Lines:	1374

💛 - Coveralls

I think this has caused #3773

updatePlatformAccessories() technically expects an array:

I wonder if part of the issue is that in homebridge-lib it is passing undefined rather than an empty array.

https://github.com/ebaauw/homebridge-lib/blob/06772ab5557aa07c3af753538852524162f19193/lib/Platform.js#L279

We could fix the homebridge code to check for the existence of a passed array. changing the type to optional.

I guess this new issue never presented itself before because the argument was never being used, whether any value was passed in or not.

We could fix the homebridge code to check for the existence of a passed array. changing the type to optional.

The bug is in homebridge-lib, as it is calling updatePlatformAccessories() with the wrong parameters. Up until now it has been masked by the bug in Homebridge code. Homebridge should not be "coding to the bugs".

The reason that I recommend against modifying Homebridge code is, consider a scenario where someone removed from this decision decides to reimplement this method. This will end up breaking homebridge-lib anyway.

The fact that the code fix is in a beta, means that a Homebridge release could wait until a fixed version of homebridge-lib was released.

However adding some defensive code would not be a bad idea:

  handleUpdatePlatformAccessories(accessories: PlatformAccessory[]): void {
    if (accessories !== undefined) {
      const nonUpdatedPlugins = this.cachedPlatformAccessories.filter(
        cachedPlatformAccessory => (
          accessories.find(accessory => accessory.UUID === cachedPlatformAccessory._associatedHAPAccessory.UUID) === undefined
        ),
      );

      this.cachedPlatformAccessories = [ ...nonUpdatedPlugins, ...accessories];
    }

    // Update persisted accessories
    this.saveCachedPlatformAccessoriesOnDisk();
  }

Passing an empty array seems to work, thanks.

For truly defensive code, you would need to check that the accessories parameter is indeed of the correct type, not just that it is not undefined. It's probably easier to change the cal to accessories?.find(...) (assuming we'll no longer support old NodeJS versions that don't support ?..

For truly defensive code, you would need to check that the accessories parameter is indeed of the correct type, not just that it is not undefined.

I can't speak about Javascript, as I have limited experience, but in Typescript you cannot call myfunc(param: Foo[]) and pass param: Bar[]. You would get a compile time error. null is its own fun kind of hell that even some strongly typed languages struggle to deal with. I'm not massively experienced with Typescript either, but I think you would have to write myfunc(param: Foo[] | undefined) to allow passing undefined and not get a compile time error ... ?
The problems arise from Typescript getting transpiled to Javascript and losing some of the guardrails in the process.
All of which is why I am not a fan of weakly typed languages in general. I like strict type checks. My personal quote is "with strongly typed languages you catch type errors at compile time, with weakly typed languages you catch type errors at run time". It's kind of like walking through the forest: you can clear cobwebs with a stick or with your face. Either works rather well, but one is a bit unpleasant.

@ebaauw after another thought on this situation it made me wonder what your intentions were with these lines

this._homebridge.updatePlatformAccessories()

this._homebridge.updatePlatformAccessories([])

because even before or after the changes in this PR, it seems to me that it isn't doing anything?

    const nonUpdatedPlugins = this.cachedPlatformAccessories.filter(
      cachedPlatformAccessory => (
        accessories.find(accessory => accessory.UUID === cachedPlatformAccessory._associatedHAPAccessory.UUID) === undefined
      ),
    );

    this.cachedPlatformAccessories = [ ...nonUpdatedPlugins, ...accessories];

If an empty array is passed in:

• this.cachedPlatformAccessories.filter is just going to return all the elements
• so nonUpdatedPlugins will be equal to this.cachedPlatformAccessories
• so the final this.cachedPlatformAccessories will be ` = [ ...this.cachedPlatformAccessories, ...[]) - i.e. - nothing is changing

perhaps I am missing something? or what you are aiming to do isn't actually happening?

what you are aiming to do

I want to force-write cachedAccessories so the accessory context as set by my plugins is persisted. Normally, Homebridge would do this on a clean exit, but not when Homebridge crashes. I do this after startup/initialisation (when the plugin has re-connected to all devices) and once every hour.

All of which is why I am not a fan of weakly typed languages in general.

Couldn't agree more. I started with Homebridge way before TypeScript, so all my plugins (still) are plain JavaScript. I might want to change that to TypeScript, someday, but I rather spend my time on functional enhancements than a technical refactor. Homebridge might very well be obsoleted by Matter, before I'll find the time.

I do this after startup/initialisation (when the plugin has re-connected to all devices) and once every hour.

Do you store the accessory's state in the context? I have accessories with persistent state (on/off, open/close) and I store that in a json file, and handle writing, reading, and deletion. And after reading your statement, a lightbulb just went off and I'm feeling like a complete donkey 🤣

That's what the context is for. I even store the Eve history in there. I was a bit worried about the size when I first tried that, but it works out just fine. No need to delete stale files when the device is no longer exposed as an accessory.