Maybe just create a toggle helper (don’t use this blueprint) and maybe call it “Kitchen Lights Bypass”. Enter it into the bypass. Then ask Alexa to turn ON the “Kitchen Lights Bypass”.
Blacky 
Thanks for your reply. That’s not a viable alternative though, as I want a unified solution.
Turns out, if you expose your entities to Alexa, to control the lights lets say, the blueprint does work. So, if you’re like me and have hue lights, and want to use this blueprint : remove the lights from Alexa app (or the skill) and start over by adding them through the HA skill.
All devices must be removed manually, one by one, this is a pain. But hey, in the end, it works.
Nice one 
thanks for sharing how you got it working! I’m sure it’s going to help someone else out there.
Blacky
Thanks for your blueprints. I try to set it up with the Lighting BP.
I try to create the following: If a user switches a light off (that was switched on by the automation or manually) or if a user switches a light on there should be a timer for x minutes where the automation won’t interfere and after that the light should switch off, if it was switched on.
This way the normal switches (or contorl via HA interface) is maintained.
Right now it seems the Bypass only works for keeping it manually on, but not manually off.
Is this supported or could be supported and if it is, how can I achieve this?
Thx in advance
Welcome to the community.
The blueprint will only turn ON the Toggle Helper when a entity goes from OFF to ON. It will then turn OFF the Toggle Helper when a entity goes from ON to OFF. This is only if it is turn ON or OFF manually.
It will not turn ON a Toggle Helper when your turn OFF an entity manually.
Blacky
Hi Blacky
I have an odd situation where it seems that an automation turning on one of the tracked entities is causing the Manual Control Status Tracker to trigger and turn the Toggle Helper ON.
See this trace for the Tracker automation at 4:43:07:
And this is the logbook entry for the Toggle Helper at 4:43:07:
This is the logbook for the Dining Room Ceiling, showing that the automation turned it on at 4:43:07:
This is the Action in the 1HAS: Dining Room automation:
It runs this the Evening scene that turns the dining room Ceiling and Washers entities on at set brightness settings. The ‘Dining Xtra’ script controls a different light.
This is the Tracker automation config:
(I have temporarily enabled the auto-off option so that the Manual toggle doesn’t get left on all night)
alias: "1HAS: Dining Manual"
description: ""
use_blueprint:
path: Blackshome/manual-control-status-tracker.yaml
input:
manual_tracking: input_boolean.1has_dining_manual
target_entities:
- light.dining_room_ceiling
- light.dining_room_washers
include_auto_off: enable_all_auto_off
time_delay: 120
I see… The light is being turned ON by a scene.
I never tested this.
So what is happening is the automation turn the scene ON but the scene turns the light ON. The logic is only if an automation turns ON an entity not a scene to turn ON an entity.
This is why when the automation turns ON by the sun it also runs the manual tracker.
I not sure how your scene are set in the automation and whether you can just use entities and set the light/s up like that.
I will put this on my list to look at. Thanks for pointing that out.
Blacky
Thx,
so is there a way to achieve what I described (maybe by my own manual control helper and using that in the automation? Or should I just use something completely selfbuilt? I thought maybe two helpers that I create myself and to see if I can use them in bypass off and bypass on or so).
I want to use the original switches, so when someone presses them the light switches ON/OFF and the automation should then pause for x minutes and not interfere and after x minutes the light should be turned on.
Think about someone wanting to go through the dark, because light is too bright or someone wanting to switch on the light in the middle of the day while being in both situations in trigger range of the motion sensors.
(A side question is about the "light ambient mode, you describe that I shouldn’t use an offset if my light sensor is affected by the lamps, so setting e.g. min to 200 and max to 200 would be correct and it shouldn’t be min. 200 max 400?)
Yeah you can do this with it but if your using it to turn a light ON and using it to turn a light OFF or pausing the automation then using just the light switch can really only do one thing. This is where you start getting into short press, long press, double press to do different things through the one switch and is why manufactures have develop these products.
It is also good to note that if you walk into a room and the automation turns the light ON you then have to manually turn it OFF and back ON again for it to register what your doing. Having products that are not linked directly to the light were you can use a single press, double press, long press turning ON different toggle helpers that are used in option 1, 2 or 3 in the bypass (if your using my sensor light blueprint) to then do different actions may be what your really after.
Blacky
Mmmm… So, the Tracker automation is picking up a Scene as a ‘manual’ invocation. I had assumed it would only be triggering on manual invocation via a physical button press or manual use of a dashboard control.
I activate the appropriate scene based on a time-of-day variable:
I had previously been using some manual logic from this post to detect these manual events. This worked well as far as my testing went. However I was happy to change to your blueprint version of the same outcome as it greatly reduced the manual triggers and actions I had to add to my main lighting control automations.
Ok, so I may not be able to use your blueprints then. Because I know in another room this is possible. You can solve that with the following code to create a sensor that tracks how something was pressed, as an example I used this for knowing if an AC was switched on/off manually or not (changing temperature is not recorded, so brightness changes would be ignored, but on/off should be able to work with a lamp), maybe putting this blueprint into a new blueprint (I copied the code from somewhere, mostly):
- trigger:
- platform: state
entity_id: climate.ac
to: null
sensor:
- name: "Switch Context AC"
unique_id: switch_context_ac
device_class: enum
attributes:
options: "{{ ['Physical', 'Dashboard_ui', 'Automation', 'Unknown'] }}"
state: >
{% set mapper = {
0 : 'Physical',
1 : 'Dashboard_ui',
2 : 'Automation',
3 : 'Unknown'} %}
{% set c_id = trigger.to_state.context.id %}
{% set c_parent = trigger.to_state.context.parent_id %}
{% set c_user = trigger.to_state.context.user_id %}
{% if c_id != none and c_parent == none and c_user == none %} {% set state = 0 %}
{% elif c_id != none and c_parent == none and c_user != none %} {% set state = 1 %}
{% elif c_id != none and c_parent != none and c_user == none %} {% set state = 2 %}
{% else %} {% set state = 3 %}
{% endif %}
{{ mapper[state] if state in mapper else 'Unavailable' }}
I then use an automation to start a timer for a specific amount of time, as long as this timer is not idle the manual override is active and the main automation won’t run.
1 Like
Your link to that post is a really nice example showing the source and how they work. He has done a nice job at that.
There you can see we are using trigger.to_state.context.parent_id is none (his example is trigger.to_state.context.parent_id == none)… so this is true for devices and user interface but not an automation. With you reaching out we now know scenes also fall into a none.
If we look at the other examples user_id would allow you to have scenes but you wont be able to control it through the device only the user interface. This is why I have used parent_id.
I must admit scenes are nice but I only recommend using them if you have all different light settings when you turn ON your lights. For automations they make it hard and is why I just use entities. You can use 2 turn on light actions and set different light data.
Now you can see the challenge. It would be nice if HA sees a scene as is not none.
Blacky
@Blacky do you have a path into the dev process/people to be able to raise this ‘scene activation is seen as a manual trigger’ issue?
No, but I have it on the list to look at. It’s all about time and I have been really busy at the moment.
I have another blueprint that I am cleaning up for release and I have other features being added to other blueprints too that I would like to have.
Blacky
Thanks for the update
1 Like