[homekit] bugfix #7701. set correct configuration revision on bundle start.

[yfre]

HomeKit uses configuration revision number to indicate changes in the configuration of accessories and bridges.
Bridge (in our case openHAB) communicates the revision number to all clients (home apps) and should increase it with every change in configuration (in our case items config). This is supported by HomeKit addon. However, on HomeKit bundle restart the revision was set to 1.

e.g. before bundle restart the revision was 34. after bundle restart the revision was set to 1.
This could lead in some cases to a configuration reset in home app so that all changes done in home app (e.g. room assignment, scenes, renaming) will get lost. See #7701

This PR ensures that the configuration revision is set correctly on the bundle start.

Signed-off-by: Eugen Freiter [email protected]

[TravisBuddy]

Travis tests were successful

Hey @yfre,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[J-N-K]

LGTM. I was wondering if we should also store the number of detected accessories and only start the bundle after we either found the same number or a certain timespan has elapsed.

The idea behind this was that there may be some delay with the items on startup.

sequence 1:

1. openHAB starts
2. items are read
3. homekit addon starts
4. app connects and gets all items

sequence 2:

1. openhab starts
2. homekit addon starts
3. app connects and gets no items
4. items are read and reported to the app

My idea was that in sequence 2 the app removes all accessories (and their metadata) and later re-adds them, but the metadata is lost. Sometimes only some of my items are moved to the standard room and I thought that this might be related to the sequential reading of the items. Also sometimes rules report missing items on startup.

[yfre]

LGTM. I was wondering if we should also store the number of detected accessories and only start the bundle after we either found the same number or a certain timespan has elapsed.

The idea behind this was that there may be some delay with the items on startup.

sequence 1:

1. openHAB starts
2. items are read
3. homekit addon starts
4. app connects and gets all items

sequence 2:

1. openhab starts
2. homekit addon starts
3. app connects and gets no items
4. items are read and reported to the app

My idea was that in sequence 2 the app removes all accessories (and their metadata) and later re-adds them, but the metadata is lost. Sometimes only some of my items are moved to the standard room and I thought that this might be related to the sequential reading of the items. Also sometimes rules report missing items on startup.

this is good idea.
is there a way to check with openHAB whether all bundles are loaded and all configs are parsed? e.g. kind of event - openhab started completely?

[J-N-K]

Unfortunately, since eclipse-archived/smarthome#1896 ist still not resolved, there is no such event.

That‘s probably why the idea of the configurable delay (default 30s) was born in the issue you linked.

[J-N-K]

Since this a fix anyway, I'll merge that and we can add more improvements later.