list_accessories_and_characteristics for BLE doesnt return value

[Jc2k]

For IP accessories the values are just there, for BLE we will have to fetch them.

[jlusiardi]

I see 3 quick options:

1. both do not return the values of the characteristics, which means we are loosing functionality on the IP accessories
2. both do return values, but this will be much slower on BLE accessories
3. We document the behavior and accept it the way it is

@Jc2k What do you think? Any fourth option?

[Jc2k]

It's a difficult one.

In HA:

1. Originally it was polling using the list_accessories_and_characteristics API. Which meant that it didn't work for BLE at all, and even if we made it work, it would be very very slow.
2. I changed it to use get_characteristics - but it still uses list_accessories_and_characteristics once at startup. This is the case in HA 0.87.1.
3. Currently looking into caching the output and only re-fetching it when c# changes. With this it should very rarely use list_accessories_and_characteristics.

The only code at HA start time that needs value in the current stable release is to get the serial number of the accessories. That might change to be the entire accessory-information service.

If I can cache successfully then I think from a HA point of view, (2) is most attractive right now.

[jlusiardi]

I think we must be careful for caching and c#:

• BLE accessories use CN (Configuration number, 1-255) to be increased on firmware update. So a change to this should trigger a call to list_accessories_and_characteristics for BLE accesories.
• BLE accessories use GSN (Global State Number, 1-65535) to increase on changes to characteristics that support a Disconnected events. So sadly not all value changes inc this.
• IP accessories use C# (1 to 2^32 − 1) as firmware update indicator
• IP accessories have no indicator for value changes

For BLE see page 124. IP is described on page 69.

So HASS.io should inquire C# / CN regularly and only call list_accessories_and_characteristics if those changed. Also events could be a good thing if values should be updated without polling the accessory?

[Jc2k]

Yes I agree, I think I overcomplicated what I was trying to say. I certainly don't plan on caching list_accessories_and_characteristics values like temperatures or positions or on/off states. What I meant was to do what it say on page 73:

Controllers should cache the attribute database and monitor the current configuration number, c# in Table 5-7 (page 69), for changes, which indicates that the controller should get the attribute database and update its cache. Unpaired controllers must not cache the attribute database.

If an updated attribute database shows that it is missing some services and characteristics, then these service and characteristics will be deleted from the home.

(This is on the HA side, I don't want to complicate things on the homekit_python side, at least not yet).

So my TL;DR is that I don't mind if list_accessories_and_characteristics is slow because I won't call it often. Right now I call it once at start up, and if the c# thing works I won't need to call it at all unless c# changes.

But do I even use the value field? Not really. I use list_accessories_and_characteristics metadata to enumerate what HA entities to create and sort out stuff like if a HA lightbulb supports color / temperature / etc.

The only code that uses value from list_accessories_and_characteristics is a helper function that grabs the serial, model, manufacturer, etc. I could probably do that manually.

I'm still in favour of (2) even though it includes data I don't explicitly need.