Feature Discussion: automation switches

[dlashua]

One nice feature about native Home Assistant automations is they all come with an "automation.whatever" entity that can be turned off or triggered manually (usually for testing). Pyscript doesn't have this so turning off an automation either means commenting it out or adding @state_active('input_boolean.my_automation == "on"') to the methods and then creating the input_boolean.

Is there any interest in letting pyscript do this for us, perhaps even on an "as requested" basis?

Example code:

@state_trigger('binary_sensor.living_motion == "on"')
@automation_switch('common_area_lights')
def living_on():
  light.living.turn_on()

@state_trigger('binary_sensor.kitchen_motion == "on"')
@automation_switch('common_area_lights')
def kitchen_on():
  light.kitchen.turn_on()

In this example, two methods use the same "automation_switch". Pyscript would create the switch on the first invocation, and realize it was already created on the second invocation and do nothing. If these methods are deleted, pyscript should realize there are no more methods that use this automation_switch and delete it from Home Assistant.

Additionally, each of these functions would have the equivalent of @state_active('switch.common_area_lights == "on"') attached to them. If the switch is off, they don't trigger. Even better would be to give the function the same treatment as a "filename comment out" so that the "shutdown" functions happen when turned off, and the "startup" functions happen when turned on.

Creating the switch in Home Assistant is the hardest part of the puzzle, likely, only because pyscript does nothing like it so far. We can't just state.set the switch entity because 1) a switch with that entity id might already exist and 2) that doesn't create all the home assistant hooks to listen for turn_off and turn_on service calls. So we have to use the switch platform to create the switch.

If we don't want to get into all the platform entity creation stuff, another option would be to provide (pyscript.automation_turn_on and pyscript.automation_turn_off services that take automation: common_area_lights as data (with possibly better names than I've come up with). This would make it really easy to turn on/off a pyscript automation from code/native automations, but a little more difficult to do it from the UI since users would have to use a button card (or something like it) to handle this instead of just adding the switch entity to a row. It's less nice, but MUCH easier since platform entities can be a bit cumbersome.

Thoughts?

This feature discussion brought to you by me playing "flashlight tag" in the dark with my kids the other day and realizing this was impossible since pyscript kept turning all my lights on. So I had to comment everything out, enjoy the game, and then turn everything back on. I would have still had to manually turn something off and then on again with the above in place, but I could have written a single pyscript to handle the on/off functionality (to be used then and any time again in the future) instead of having to find and edit the "state_active" bits of every applicable automation.

I really like the idea of each function classifying itself with the decorator. This gets really fancy when I can supply multiple names:

@automation_switch('common_area_lights', 'living_lights', 'lights')

Thus providing me with three switches, one to turn off all common_area light automations, one to turn off all living light automations, and one to turn off all light automations in the whole house. They end up working a bit like "tags" for the functions that the function authors can use as they see fit.

[wsw70]

Is there any interest in letting pyscript do this for us, perhaps even on an "as requested" basis?

I believe very much there is.

I will work around that in the HA frontend by setting an extra state that I set or unset in the UI (in a specific card), and test in my automation its state before going forward. Having that built-in would be awesome.

[wsw70]

This feature discussion brought to you by me playing "flashlight tag" in the dark with my kids the other day

For my curiosity (my kids are teens so I am not sure this is still relevant for me :)) - what is a flashlight tag game?

[dlashua]

@wsw70 teens seem to enjoy it too. very young kids will need a buddy. basically.... turn off ALL the lights. Then play "hide and go seek" (except the hiding is different since you can hide in plain sight since it's dark). The "seeker" gets the only flashlight. If you get lit up by the flashlight, you're out.

[wsw70]

@dlashua oh that's great! I will actually use it as a game for my kids and their friends (probably somewhere outside) after we are free from COVID (in France we have a curfew starting at 20:00 and nobody meets noone anyway). Thanks for the idea!

[wsw70]

Is there a place where the current, loaded automations (functions) from pyscript are registered? A place that could be queried from within pyscript?

I just found the list of the files the automations are ran from (pyscript.list_global_ctx())

[dlashua]

It depends on exactly what pieces you're looking for. These bits aren't designed for user interaction (i.e. you can break things if you mess around with it) but... you can get a list of all the names of all registered triggers, for instance, like this:

import custom_components.pyscript.global_ctx as global_ctx

@time_trigger('startup')
def test_startup():
    for gctx_name in global_ctx.GlobalContextMgr.contexts:
        gctx_obj = global_ctx.GlobalContextMgr.contexts[gctx_name]
        for one_trigger in gctx_obj.triggers:
            trig_obj = one_trigger.trigger
            if trig_obj is not None:
                log.info(trig_obj.name)

[wsw70]

I will work around that in the HA frontend by setting an extra state that I set or unset in the UI (in a specific card),

This ended up being more difficult than expected (for now :)). While I can manage states for automations (mostly thanks to @dlashua code) and display them nicely with https://github.com/thomasloven/lovelace-auto-entities in a dynamic way, this is just a display of their status.

Adding a switch at the place where on is apparently requires https://www.home-assistant.io/integrations/switch.template/, which in turn probably means that the templates need to be hardcoded in a file (which is directly in conflict with the dynamic nature).

I will think about that a bit more.

[raman325]

Instead of creating a switch, I would suggest we create something similar to either

• the AutomationEntity: https://github.com/home-assistant/core/blob/dev/homeassistant/components/automation/__init__.py#L212
• the ScriptEntity: https://github.com/home-assistant/core/blob/dev/homeassistant/components/script/__init__.py#L247

This will give us the flexibility to define services that make sense for pyscript and we can add states and attributes that can provide extra information, such as what is requested in #130

[dlashua]

@raman325 not a bad idea at all. Thanks!

[raman325]

I'd be happy to take a crack at this unless you already have thoughts on how to do it. I stumbled on this because of a recent need for such an entity 🙂

[dlashua]

@raman325 Take a look at PR #129 because it's part of the way there. Then, add comments/codes to that?

[raman325]

#129 is for user defined entities whereas I understand this to be about providing entities automatically for each pyscript service/automation. If you agree, then where do you see the intersection? I imagine that implement this feature, we'd have to create entities while loading contexts from files.

[dlashua]

This is about handling them somewhat automatically, though there would still be a decorator to request the behavior, I imagine.

However, they both require the entity platforms to be handled on the Home Assistant side. So, while they are not the same thing, the code behind them is similar and related.

[raman325]

The way I envisioned this, there would be an entity for every automation, service, or app that pyscript is aware of (I see this use case as very similar to the automation and script platforms). I don't see the harm in providing this by default, so no decorator would be required. Is there a problem you are trying to solve in using a decorator that I am missing?

The work you are doing in #129 is related in that in both cases, we are trying to create entities, but the difference is that you are using existing platforms in that PR (switches, sensors, etc.), whereas here we'd be defining our own EntityComponent. I don't think the code will end up being all that related, but happy to be proven wrong. Perhaps since you have made progress on #129 already, we should wait to see what comes out of that and then we can decide how to address this one.