Logbook Functionality

[dlashua]

There might be a better way to do this instead of using Function like I have. However, it works.

A few things to note.

• The event fired before the function runs can be named anything we want. I chose "pyscript_running" and then realized Home Assistant uses "automation_triggered". This can be renamed by changing it in both trigger.py and logbook.py.

• While I have confirmed that state.set() is sending the correct context to the best of my knowledge, it seems that states set in this manner don't show up in the log book at all. The state still "sets" as expected, but there is no logbook entry. Therefore, all of the "context" code can be removed from state.set() if desired.

• I've left the original context as part of the trigger function kwargs. This way, pyscript users can still look at user_id to determine who did something. Unfortunately, determining if pyscript did something would mean climbing the context tree, which is tedious.

• I've also left context as an optional kwarg to service.call and event.fire. If a users passes a context, it'll use that. If they don't and we have one from the pyscript_running event we fired, it'll use that. If they want to disable the logbook functionality for some reason, they can pass context=Context().

• The logbook attributes actions to entity_ids. And entity ids can only have one "." between the domain and name. So I'm sending, essentially, __name__, with "." converted to "_". This means the entity_ids are a bit ugly (ex. pyscript.file_myfile_myfunction). This is set in trigger.py and can be changed to anything we want as long as it fits the rules for entity ids.

I've tested events, service_calls, time triggers, and state.set with this code:

@state_trigger(["input_boolean.test_1"])
def test_state_trigger(**data):
    log.info("test_state_trigger")
    input_boolean.toggle(entity_id="input_boolean.test_2")
    state.set("binary_sensor.test", "on")


@event_trigger("PYSCRIPT_TEST")
def test_event_trigger(**data):
    log.info("test_event_trigger")
    input_boolean.toggle(entity_id="input_boolean.test_3")


@state_trigger(["binary_sensor.test"])
def report_binary_sensor(**data):
    log.info(f"binary_sensor trigger with {data}")


@time_trigger("startup")
def test_time_trigger(**data):
    task.sleep(3)
    log.info(f"test_time_trigger {data}")
    input_boolean.toggle(entity_id="input_boolean.test_4")

It results in this logbook:

[dlashua]

Also, this changes the way #61 works. So that PR is not needed if this one is merged. However, I'm leaving that open for now in case this PR needs more work since that change is useful.

[dlashua]

I lied about the state.set() not showing up in the logbook. It wasn't showing up because I was setting it to the same value for state. Once I adjusted my code to actually CHANGE the state, this code logs exactly as expected.

[craigbarratt]

Looks great! Here are a few minor comments...

[dlashua]

I'd like it if the text used to indicate what is doing the work in the logbook was clearer. The logbook is weird, though, so it comes from two places, as illustrated here:

As a result, it makes sense to keep the entity_id and the name the same (but the entity_id would have "pyscript." at the beginning of it, which the logbook does not display).

I think maybe what should be displayed is something like "pyscript function test_script in file/app mytest". This should give the user a pretty clear indication of where to look for what caused this if they are debugging.

Additionally, the function in logbook.py is called WHEN the logbook is displayed in the browser. Because of this, changes made to logbook.py will appear to be retroactive. However, logbook.py also has to be written in a way that no piece of data from the event is REQUIRED, this way if the event we fire ever changes, or if someone should fire a "pyscript_running" event manually, it doesn't result in an exception (which doesn't break HASS, but it does make that logbook entry not show up at all).