How to get an unstoppable automation or script?

Configuration
1

I have a multi-user instance and want to avoid that some users stop specific automations by using the logbook. How can I lock those automations or create an automation or script that cannot be stopped within the frontend? It would also be OK if it was just completely invisible in the frontend.

2

Hi, non-admin users have no access to automations.

3

As soon as the automation has been triggered it can be seen in the logbook. And there, non-admin users can disable it.

4

I smell problems with adolescent hackers-2-bā€¦

You could have another automation watch and if itā€™s stiopped, require a password and if not provided, just start it again. kinda thing

5

Yes, kind of. Do you have a source for information about such kind of password protection? Unfortunately this 2nd automation can also be disabled through the logbook as soon as itā€™s being triggered, correct?

6

Disable the logbook for that specific automation, if thatā€™s the problem. No entry, no disableā€¦kindaā€¦ :laughing:

logbook:
[...]
  exclude:
    entities:
      - automation.your_secret_automation
2 Likes
7

What about creating specific dashboards with only the allowed items in the sidebar?

1 Like
8

That wonā€™t work as expected, I just checked. If you disable the entry for Logbook in the sidebar, you can still get there via ā€œmore-infoā€ of an entity. :frowning:

Itā€™s getting interesting, how hard it can be, to lock some persons out. :laughing:

9

Itā€™s also about using the Android app and there the user can enable the logbook again without any problem.

It would already help if the logbook and history side bar items could be definitely hidden for specific users.

10

Only reason an automation should be stoppable is because it is using a delay.
Change the automation to use a timestamp helper instead for when it should do next action.

11

I agree with Wally, everyone is missing the elephant in the room.
Letā€™s see the automation first, then we speak about solutions.

12

The automation currently looks like this.

- id: block-user-access
  alias: Block user from switching off
  trigger:
    platform: state
    entity_id:
      - switch.custom_switch
    from:
    to:
  condition:
    - condition: template
        value_template:
        "{{ trigger.to_state.context.user_id == '3205ceba564d5b9e6de7231eca9e4a25'
        }}"
  action:
    - service: python_script.set_state
      data_template:
        entity_id: "{{ trigger.entity_id }}"
        state: "on"

When switch.custom_switch changes, the automation shows up in the logbook and from there it can be disabled.

Excluding the automation from the logbook or recorder works after a HA restart. But if thereā€™s another way it would also be ok for me.

13

I agree that most likely all the answers are not a real, ā€˜hack-freeā€™ solution.
Itā€™s just that HA is not foreseen to this (yet)

He could built custom a dashboard where even the ā€œmore-infoā€ option is not active.

No matter if itā€™s the desktop/browser to access or the android app: with a custom dashboard for these users you make it harder.

There you go (@paddy0174: was about to come with the same idea :+1:)

The problem is that the OP wants to prevent that someone can disable the automation so it does not run at all.

1 Like
14

Not sure if this is possible but I believe if you create the same automation in Node red then it will not be possible to disable it like that.
And you can password protect Node red.

15

It would be almost instant.
IE the one automation would be killed, this would notice and start it, then be hiding in the automation list . Of course it would be called livingroom light or something. and because this just triggers and ends, they canā€™t ā€˜killā€™ it. It will just flip something that the other automation has a trigger for. Could even be it fires a weird event and there is a new event trigger on the one that needs to stay on. Events are even harder to track.

It could be found, but not easy to find or easy to interveneā€¦

16

Maybe a simple solution could be another automation that just reenables the first one constantly and if course named something that is not obvious to other users.
It might even be included in already automations running, so it does not appear as a new one.

17

He already accepted one post as the solution.
But I was thinking something similar this morning.

Have five automations all triggering on this automation being disabled.
All these five automations have a for: with a random number of seconds (1-5 perhaps), and the action is to enable the automation in question and all five of the ā€œreenableā€ automations.
It would be a nightmare trying to disable them all from the logbook

1 Like