FEATURE REQUEST: Add an option to not block if entity is already on when triggered

[adec]

Is your feature request related to a problem? Please describe.
entity-controller is currently built on the premise that it will only control the entity if it has not been switched on. However, I would like to switch the outside lighting of the house on dim and/or to a particular colour at dusk but still allow the entity-controller to brighten the light and change its colour when motion is detected. The entity state would be saved when entering active state, this would be used to return the lighting back to its previous state when the timer expires.

If any of the entities are manually adjusted while the timer is running, block mode should be entered as normal.

Describe the solution you'd like
I'm happy to have a go at implementing this but need some advice on the best approach. My thoughts are:

• add a new configuration parameter (e.g. 'blocking_mode') which would take the options 'all' (default), 'when-active'
• (undecided whether) another configuration parameter (e.g. 'persist-entity-state') is required to control whether the state is persisted and restored when returning to idle state or whether the just switch the entity off.

Now one of the things I've been wondering is whether I need to add additional states to the state machine or whether I just need to change some of the state transitions (adding some new ones and/or modifying the conditions of existing ones). Any thoughts?

Describe alternatives you've considered
I've thought about trying to do this using a combination of automations and scripts instead but still think this would be best being integrated into the Entity Controller.

Additional context
I may raise an additional feature request to support scenes (configuration file would include scenes to be applied in different states - e.g. constrained (normally would switch lights off), idle state (in my use case would apply a scene which switches the lights on dim with warm white), active state (would switch the lights on bright and with cooler white). By adding additional services to allow the scenes configured for each state to be reconfigured, a separate automation could be used to allow different scenes to be applied on different days of the year (such as Halloween). Thinking about it - using scenes removes the need to persist the existing state.

[adec]

Thinking about this further - another option for the use case above would be to provide the option to include idle lighting parameters. So when the FSM switches to idle status it turns the lights on. In my case, I’d probably have it call a service to select the appropriate scene for the day of the year.

What I need to consider is how block mode should operate. It would make sense for manual changes to be monitored even in idle mode which would be ease enough to implement. However, the snag is how do we get out of block mode? Perhaps only via a service call.

@danobot please do feel free to challenge my thinking.

[danobot]

i do read your comments, just don't have time right now to respond. ill try to get back to you. Remember that EC is not lighting specific and its designed to be a generic entity controller. Can the functionality you are wanting be achieved using another concept? e.g. if we implement something generic like "plugins" (silly example) can your request be implemented via a "plugin" (again, just an example and im not saying thats the solution.).

[adec]

Completely understand time pressures @danobot- I have the same issue myself.

Thanks for the comments. In particular the reminder that EC isn’t and shouldn’t be lighting specific. I think much could be done using scripts to apply the relevant scenes or persist/restore the lighting. I suspect a tweak may be required to how blocking is triggered - just checking whether the entity is on won’t work in this example. I’ll give it some more thought

[danobot]

Blocking is a very controversial feature in EC. The implementation was altered slightly before but entity lists now don't behave right. If further changes to blocking are required i feel like we are making it worse. see #154 which was closed because of time reasons and discussion was going nowhere.

[danobot]

I resolved a defect in #174 which should enable giong forward with this. Basically what you are asking is an option not to block under certain circumstances. Can you check if you can use ignored state attributes? That might be asolution.

Please raise any other concerns and features separately as to not cause clutter on this discussion (update issue description as required).

[danielbrunt57]

Hi Daniel,
I think all that he needs to accomplish his request "would like to switch the outside lighting of the house on dim and/or to a particular colour at dusk but still allow the entity-controller to brighten the light and change its colour when motion is detected (but return to dim when idle)" is the ability to specify service_data within the on_enter_idle control, or as he mentioned, the ability to call a service...
Something like:

motion_light:
  sensor: binary_sensor.outside_motion
  entity: light.porch_light
  start_time: sunset
  stop_time: sunrise
  end_time_action: "off"
  service_data:
    brightness: 100

  on_enter_idle: "on" or on_enter_idle: "dim"
    service_data:
    brightness: 20

[adec]

Thanks @danielbrunt57. Yes, that would do it. I’d probably go down the call a service route as I want to turn the dim/ambient lighting off at a certain time of night rather than them being on all through the night.

I’ll have another look at this over the next weekend to see if I can get something going.

[danobot]

is this resolved?