LogBook entries for HomeKit

Just wondering if I’m missing something (don’t think so but wanted to check).

I can see a whole bunch of different entries in the logbook, but none from HomeKit. Is it possible to get entries in there as well from HomeKit (i.e. status changed, something being turned on/off)? I understand that the underlying sensor/switch/… would normally make an entry in logbook, but it would also be nice to be able to see in there what the Homekit component is reporting.

I do not have anything for logbook set to include or exclude BTW.

LogBook entries for HomeKit are not yet supported.

Mind if I take a “stab” at it to add so that whenever a state is changed from HomeKit an entry is made in LogBook?

Did some updates on my own copy here and been able to get LogBook entries in there whenever a state is changed from HomeKit.

Go ahead. I’ll definitely have a look.

However, I just looked at the way the Alexa Smart Home component is doing it and it seems we would need to change quite a few things to get it right. E.g.: Start with firing an event each time a change request comes from HomeKit.


OK, it took me a while to find for the Alexa Smart Home component. I kept on looking in the alexa component but the change for this is done in the logbook component itself.

How I currently am doing it is to call log_entry from the method that receives the state change itself. For example, for locks (class Lock) in method set_state I call log_entry providing the display name as provided to HomeKit and a message relevant to the state being set.


        self.hass, self.display_name,
        ' from homekit has initiated ' + service,
        'homekit', self.entity_id)

Advantage I think with this is that what is put in the logbook can be set more specific to respective accessory and state being changed resulting in the message being tailored to what is being done.

Disadvantage clearly is that this needs to be done in every method handling a call for changing something from HomeKit but it really is a one-liner. :slight_smile:


The devil is in the details here. Adding one line might not be that difficult, but it would be more around 2-3 and that as you said for every setter_callback. Additionally we would need to add test for each and every one of these. It adds up quite quickly.

The reason I mentioned the Alexa Smart Home component is that with firing an event in each case you can get pretty much the same result, but with more customization options (say triggers in automations). The log_entry call would then be moved to the logbook component. However this still leaves the issue that each setter method has to be modified (as in method one).

To solve this I would propose to move the first _LOGGER.debug call and the event firing into a new method (probably in the HomeAccessory) class. Then each setter only calls it and we reduce complexity. For the test, we could add a fixture to mock it automatically and then it’s just a matter of testing it once.

What I haven’t decided yet is what the best format for the log message would be. Personally I like the debug message and it might even be enough information. I wouldn’t include display_name, the entity_id should be enough. What do you think?

OK, thus add a new method in HomeAccessory class which would include both _LOGGER.debug and firing of HomeKit event for logbook, changing HomeKit component and logbook component (to include HOMEKIT event).

I like the display name just because I see the logbook more as an “end-user” visibility in items whereas the debug really is more from a developer/support perspective.

Looking at the lock component, debug is: <self.entity_id>: Set to
For logbook however I think it would be better to be a descriptive item instead of the actual value (i.e. value could be 1 for lock but in logbook it should say lock then).

We could call the method with 2 arguments. First one message for _LOGGER.debug and 2nd one for logbook. In this method it would then be:
_LOGGER.debug("%s: %s", self.entity_id, debug_message)
hass.bus.async_fire(EVENT_ALEXA_SMART_HOME, {
‘ATTR_ENTITY_ID’: self.entity_id
‘ATTR_MESSAGE’: logbook_message

That would allow a debug message to provide actual value(s) as received, whereas the message going into logbook would be more useful from an end-user perspective. Showing for example “locked” instead of 1. :slight_smile:

In the log book component I would then do something similar as what was done for Alexa, if the event received contains the message then that is what would go there so it would show like:
HomeKit send command for
i.e.: HomeKit send command lock for Front Door.

and if no message, then it would be:
HomeKit send command for .

Note, message here could also be: “turn off”, “start play”, “paused”, “speed increase”, “direction reverse”, “oscillating on”, …

That’s basically it. Just some smaller details:

  1. We need to pass the _LOGGER instance as well, since otherwise the type_locks would be lost.
  2. We would fire the EVENT_HOMEKIT_CHANGED (or similar) event.

Do you want to go ahead, start working on it and create a WIP PR?

@cdce8p Considering I’m the one who started this. :slight_smile: Yep, more then happy to.

Just thought of 1 issue with putting it in the beginning where _LOGGER.debug is right now. To be able to put a more meaningful message out a certain level of the existing coding needs to be gone through depending on the accessory. This means that the call for this method would not be able to go on the 1st line. Putting it later however would mean that there is no debug entry until later, not good I think either.

When something is changed from HomeKit, in the end the self.has.services.call method is called to execute the respective service. How about I create a method in HomeAccessory that will do this call instead and as part of it create the logbook entry?
That makes it that for a state change the 1 method is called like it is now; but it will then create the logbook entry and call the service?

Last quick question. Do I just pre-fix the PR summary with WIP? Do I do anything else to identify it is a WIP?

Will be putting some initial stuff together here and once tested will create the PR and commit my changes to it. That works? First time I would be doing this type and hence wanna make sure I do it right. :slight_smile:

1 Like

PR: WIP: [Insert PR title here] should work :slight_smile:
Workflow: It might make sense to start small otherwise you’re doing things that might need to change. My advice would be to just focus on the event calling part with the first PR and if that’s good (and merged) start working on a second the logbook PR. Also only change one type first so we can get the basics right (during the reviews) and then do the other later (saves a lot of work :wink: ) The earlier you open the PR, the earlier I can give feedback.

Combine with service call
I have mixed feelings about that. In theory it should work, although it would result in some pretty big changes. I don’t know yet how the debug statement would fit in there, but we could see how it goes.

If you have more questions, we could also chat on discord (same username).

1 Like