Automatically update pairings data when its stale

[Jc2k]

We remember all the discovered BLE characteristics in the pairing file. Do we need to be able to invalidate that cache? Does this need changes to the controller API or the connections between discovery and the controller?

E.g. It looks like if you upgrade the firmware (which might add new characteristics?) then the CN number in the ManufacturerData would go up. Should we remember the CN in the pairing file and repopulate it on connection if the number has changed?

For reference, 6.4.22 of the spec says:

CN - 8 bits for Configuration Number, with a default starting value of 1. Accessories must increment the config number after a firmware update. This value must have a range of 1-255 and wrap to 1 when it overflows. This value must persist across reboots, power cycles and firmware updates.

[Jc2k]

Of course if we do that, do we need to make the Controller automatically save the updated pairings data?

[Jc2k]

Part of the same logic would be to have a version number for this library too - specifically for the pairing file format code - so that we can detect changes like #71 where we actually want to repopulate the pairing data.

[jlusiardi]

I think this affects both type of accessories: 6.4.2 of the spec is for BLE where is 5.4 also has c# (configuration number) for IP. For IP, the configuration number

Must update when an accessory, service, or characteristic is added or removed on the accessory
server.
Accessories must increment the config number after a firmware update.

The following steps would be required:

• upon pairing, also store the CN / C# in the pairing data
• run discovery from time to time and compare CN / C# from the saved data
• if it has increased (or wrapped around) perform list_accessories_and_characteristics on the pairing and update the file with the new values

[Jc2k]

I think its easier for BLE, as we can easily parse the MfrData from within the scope of a connection to a mac address - we don't have to invoke discovery. I'm unsure about how to approach it for the IP transport though. There was a PR to decouple IP connections from discovery because they were slow.

In the land of home assistant i would be able to pass in the current CN/C# from discovery into get_pairing, and that would avoid having to invoke discovery a 2nd time. That feels kind of dirty, though.

I was going to put together a PR that:

• Optionally allows a file path to be passed to Controller.
• Automatically calls load_data and save_data at appropriate times (inside the controller API, rather than as part of the CLI scripts)
• Stores the CN/C# in the pairing data, and calls list_accessories_ if its changed, during the BLE device connection phase.

I wasn't going to touch IP devices yet - and I think its safe to do them seperately/later as the IP backend always refreshes the pairing data when you call list_accessories_and_chars.

Does that sound acceptable?

[jlusiardi]

yes sounds like a plan to be considered