Link Service.AccessoryInformation to the accessory's one to keep it to date

[afharo]

A plugin I'm maintaining needs to perform some asynchronous operations before grabbing the SerialNumber or the FirmwareRevision.

I was trying to update the parameters via myAccessoryInformation.setCharacteristics calls but nothing was working and found we are copying the values to the Service.AccessoryInformation instantiated by HAP.

This MR intends to keep the HAP instance updated with any updates from the accessory itself.

I know the SerialNumber won't change over time, but the Firmware might because of updates :)

[tobekas]

But note that Name, Model, Manufacurer and SerialNumber must be persistent during the lifetime of the accessory. (by spec)
This may be the reason why these values are copied... Bit since Firmware/Hardware Revision May chance, this issue still has its raison d’être.

[afharo]

@nfarina What are your thoughts about these changes?

[nfarina]

Oh man, it's been a long while since I thought about this aspect of HAP - maybe @KhaosT would have a quicker reaction to it?

[BewhiskeredBard]

I'd also like to be able to update the FirmwareRevision dynamically.

[Sunoo]

Any chance of getting this resolved? Being able to update Firmware Revision would be very nice.

EDIT: I just tried this pull request locally, and it doesn’t seem to get updating Firmware Revision to work either.

[Supereg]

To answer some questions:
As of the HAP spec, after a firmware upgrade the config number (cn) MUST change in the bonjour record. And only then HomeKit will grab the updated value of the characteristic. Maybe we can incorporate something like this into hap-nodejs so this will be possible. Though those values would only be grabbed from the /accessories call. HAP-NodeJS does not call any get handlers AFAIK when it receives such a request (would take too long) and would just grab the last value.
For anybody interested, would be good to know what you would expect from such a feature and how you would use that.

[Supereg]

Some words to this PR:

It is strongly related to #2169 (and #2472). And in my opinion #2169 has a much nicer way of transferring all those listeners. As this PR would create just another listener and not just replaces it.

[afharo]

Thank you for your comments on this!

Though those values would only be grabbed from the /accessories call. HAP-NodeJS does not call any get handlers AFAIK when it receives such a request (would take too long) and would just grab the last value.

I recall testing it locally and seeing things like the SerialNumber and the FirmwareRevision updated to the right value from the device (once connected) instead of the default values from the initial Services initialization.

Maybe HAP-NodeJS has changed ever since and it doesn't work like that anymore, I'd have to test it again.

That said, I agree the solution in #2169 is better performance-wise. Closing this PR in favour of that one.

[Supereg]

Okay I think some misinformation spread my be. Seems like indeed HAP calls read handlers for
manufacturer, model, name, serial-number, firmware.revision and hardware-revision

[Supereg]

and probably all the other characteristics if they are configured