I’ve used the blueprint to create multiple automations, one for each room in my home. I can now go into party mode in a single room or the whole house. I tested it with the whole house which is 27 lights and it was AWESOME. Setting them all back to normal was a bit of a pain so I do hope something like the above can be integrated into the blueprint.
For those struggling with getting their lights back to normal after using this amazing blueprint, I came up with the following. It doesn’t actually set it back to what it was but instead back to what you define as default which may well be how they were to begin with. It works for me
I have separate automations for each room that detect when the corresponding room’s input boolean turns off and it then runs the following code (example from one room shown). I did it this way as it meant I didn’t modify the original blueprint code in case in gets updated. It also allows different settings for each room. Basically when the input boolean turns off the lights will stay as they are, in various colours etc. I let that settle for a few seconds, change the lights to how I normally want them in the room and then turn them off.
Here’s the code. I hope it is helpful. If you have any better ideas I’d love to hear them and of course it would be great to get something like this built into the blueprint.
description: ""
trigger:
- platform: state
entity_id:
- input_boolean.party_lights_tv_room
from: "on"
to: "off"
condition: []
action:
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- alias: Set Lights Back to White
service: light.turn_on
metadata: {}
data:
kelvin: 5500
brightness_pct: 20
target:
entity_id: light.tv_room_lights
- service: light.turn_off
metadata: {}
data: {}
target:
entity_id: light.tv_room_lights
alias: Turn Lights Off
mode: single
It would be great if the BluePrint could include the HA service to create a snapshot of the light entity states prior to any changes so we can call the restore service when turning off ‘party lights’.
Great blueprint, it could be added that when the trigger is turned off, all bulbs or groups return to warm white. When the trigger goes to OFF, the bulbs remain lit in color. I solved the problem myself by creating an additional script and automation for when the trigger goes to off.
I saw another similar blueprint to this one and it mentioned that prolonged use would hammer the log & database, making it grow and potentially cause issues for systems running on an SD Card. It mentioned that the best way around this was to turn off logging for the automation but it didn’t say how to do it.
As I am using this automation I thought I would ask the question here as I am sure many of us could be affected by this if you have it running many lights over say the Christmas period.
I’ve got mine all set for 1 second too. That’s anywhere from a single light to 27 if I have them all in party mode. Party lights need to flash quickly and 1 second does this reasonably well.
One thing you will need to be careful of if you set a really short loop time (ie 1 second). As I mentioned above, I’ve had mine set to 1 second since I first set it up but I have really only had the lights on for relatively short periods of time and all was good. However, I had some of them on for a long time last night and the automation crashed as I exceeded 10,000 loops. I’m not sure if there is somewhere to increase that limit. If not, then if you have a 1 second delay, you can really only run it for 10,000 seconds which is about 2 3/4 hours. Increase the delay to 2 seconds and you will get 5 1/2 hours. The problem is, at 2 seconds and greater, the lights aren’t really “flashing”. They are just changing colour slowly.
Not sure it is the same problem. Cause it seems to happen every 2-3 minutes.
I’m trying to tweak a little bit the automation in order to see if it improves.
To have flashing lights that are more similar to a disco I’m using the following parameters. My guess is that time_between_changes is somehow too low, and at some point it overloads the requests the light can support. Initially I had 0, now I put 0.7 which seems to be a good compromise.
I think it makes sense that the light itself was getting messed up since the transition time is set to 0.4 seconds, but you had the time between changes set to 0.
This would mean that the transition is still happening when a new change is pushed. My guess us that the light buffers the new incoming requests and only executes them once the transition is done, thus loading up the buffer and then stalling.
There is a warning message at the transition time parameter about this in order to prevent it, but there is no way of coding a hard stop in the blueprint to prevent users from actually setting it up incorrectly.
