Feature: Define a timeout for blocked mode about entity-controller HOT 18 CLOSED

I have to admit that toggledbits/DelayLight component for Vera looks damned-sweet with some of its configuration options.

A separate manual timing delay is initiated by activating one of the controlled lights manually. If DelayLight is not already in a timing cycle, it starts a manual timing cycle, but does not turn on the "on" list devices. During manual timing, a trip of a configured sensor or a change to another controlled light will cause the timing to be extended (the event indicates ongoing presence). At the end of timing, all devices on the "off" list are turned off.

from entity-controller.

How is this different to override mode?

from entity-controller.

from entity-controller.

Blocked means that one or more control entities are already on when the sensor entity is triggered. The component will stay in blocked state until all control entities return to off. only then will the component take over. This cannot be handled using a timeout.

Are you able to achieve what you need using automations and an input_boolean as an override?

from entity-controller.

I can. Was hoping to keep it inside the component without additional automations, but not a problem. Thx for the time & feedback.

from entity-controller.

I will implement services such as take_control at some point, which can be called in automations to tell the component to take over control.

Actually.. this may sound crazy, but you might be able to create a second instance of this component, whose sensor is your manual switch and it controls the same light. That way you have a timed switch and once it times out, the existing entity takes over as per usual. How about that?

I would need to see this emerge as a common usage pattern before implementing it in the component itself. In the meantime, try what I suggested and let me know how it goes. I'd be happy to share your configuration in the documentation for others to see, given we can define a good use case for it.

from entity-controller.

I'm going to give it a bash! Thx Danny

from entity-controller.

This did not work... making the entity and the sensor the same has the undesirable effect of setting the mode to blocked. Ultimately until there is something better I will make use of some automation & scripts

from entity-controller.

You can't set entity and sensor the same. That won't work. Create 2 different instances of entity_controller. One of them will be blocked while the other one is active

from entity-controller.

@jwelter1971 and @tiaanv: please upgrade to v3.1.0 and test in your environments.

The documentation was updated to reflect this new feature.

Edit:
On reflection, I have already identified errors in the documentation. The described use case is incorrect, however it does fulfill the mentioned scenario.

My request is for the blocked mode to have a seperate timeout triggered by the state device when manually switched on/off but then return to idle after a configured delay.

Edit (again):
I think what you meant there is for the control entity to be turned off. I just realised that implementing this has no effect on the control entities, only the state of the controller is changed. 😊

Would it suffice to make this small amendment: "When the timeout expires, return to idle and turn off all control entities" ?

from entity-controller.

Hi Danny. That is 100%. A more clear description of my request.

Edit:
Even thought this is a big step in the right direction (for my personal needs), it still does not quite apply to my exact use case. My primary requirement is for a manual trigger of an entity in the list to "block" as it currently does, and now with the new additional block_timeout, expire the blocked state (this part is perfect). Then as you mentioned( not sure if you are implementing this) execute turn_off action. The only missing part is for the blocked state to also act as a "override" mechanism in itself... Thus. When switching a light off, whilst in active_timer, would put the entity_controler into the same blocked state, or "override". Whichever is more appropriate. This would effectively stop the light form coming on automatically if I forced it to off.

I don't want to dictate what you component should do, as you have a primary use case for it. But just to give you an idea of what I am use to with a similar component on the VERA ecosphere.

PS. Sorry about the poorly strung together explanation. I hope it makes sense.

from entity-controller.

I tested the current code, the mode changes to idle after a while, but when the sensor it triggered, it simply goes back into the blocked state. I think you already came to the same conclusion, but just for reference.

from entity-controller.

See v3.1.1.

from entity-controller.

See v3.1.1.

It works as explained, and expected.

from entity-controller.

No issues so far? Stable?

Regarding your edit above, I encourage you to implement this yourself. Acting on state change of control entities brings a few problems. High level implementation steps are:

• register state change callbacks for control entities
• within callback for control entity state change, trigger a state transition to override (to stop light coming back on)
• When do we go back to idle in this scenario? When all control entities return to their original state? (Presumably all on?)

Problems:

• Moving out of active state turns off control entities (current implementation). This is not desired. The location where control entities are turned off will have to change. (now need to turn them off in multiple places)
• turning off control entities triggers a state change, transitioning the component to blocked. You then need a mechanism to determine if the change happened because of external influence or the controller itself.

from entity-controller.

Testing now and so far it seems to work fine. Thanks for the update!

from entity-controller.

I recently (before changing from Vera), started using delaylight. I preferred smartswitch, because I contributed to the code, but mostly because it was easier to dynamically change parameters via scenes. Functionally delaylight was far superior. If you learn a few tricks from it, this will be the best intelligent lighting controller available for HA.

from entity-controller.

I'll think about how to do some of the features delaylight offers. This issue is resolved with the 3.1 release. Let me know if there are any issues turn the track.

from entity-controller.