Python_script to save and restore switches and lights

Share your Projects! Scripts
41

@pnbruckner
Absolutely perfect patch.
I have a combination of Philips Hue and AEOTEC Z-Wave Nano Dimmers, so I can only speak for them, but it works flawlessly and I can set the transition now so it is just enough to take the harsh edge off the lighting change when coming from the darkness of a movie back to normal lighting.

Has there been any consideration for making this an official add-in? I know it is something a lot of people have asked about over time. I can’t help with any code, but I would certainly be open to testing more.

42

Thank you so much for sharing your script. It has quickly become a big part of my automations. The only annoying thing is that the light_store card pops up on the UI every time it is called. I tried making light_store hidden in customize.yaml but that does not work. Probably due to the entity being created after boot during runtime. Any ideas how I can disable the card popping up?

43

Sorry, can’t help here. I never see any “cards” just popping up. Of course, I’m not using Lovelace, and in the “regular” frontend, I’m using Group Views, so only the entities I want show up in the frontend.

44

This is great! I want to use it in my alarm script.
When the alarm is on, motion is detected, the light’s state is saved

All lights turn on at the brightest mode, after x period or after clearing the alarm, all states are restored :slight_smile:

This might scare people and gives my camera’s the best change in recognizing intruders.

Thanks, I will give it a try soon!

45

This is exactly what I do, and pretty much why I came up with the script in the first place. :slight_smile:

46

Released 1.1.0

Save / restore light effect attribute (if present.)

See doc for more details.

3 Likes
47

Released 1.2.0

Added new, optional overwrite parameter, which applies only to saving, and defaults to True. If True, will overwrite any previously saved states. If False, will only save states if they have not already been saved (i.e., will not overwrite any previously saved states.)

2 Likes
48

Hi @pnbruckner
Would you mind check this code?

  - service: notify.html5_andrea
    data_template:
      message: "ALARM! The alarm has been triggered"
  - service: homeassistant.turn_on
    entity_id: light.alarm_light
  - service: python_script.light_store
    data:
      store_name: alarm_store
      entity_id:
        - light.alarm_light
  - service: homeassistant.turn_on
    data:
      entity_id: light.alarm_light
      color_name: red
      brightness: 255
      transition: 1
  - delay:
      seconds: 30
  - service: python_script.light_store
    data:
      store_name: alarm_store
      operation: restore
  - service: homeassistant.turn_off
    entity_id: light.alarm_light

The problem I am facing is that the light is correctly turned on to “red” but the previous state is not saved (or restored maybe)? Which should be a blue color.

Anything you can see it’s wrong in there?
Please note, I am turning on the light only to be able to “capture” (or try to) the current color status.

Thanks

49

The only issue I could think of is if the light takes time to transition after you turn it on, so maybe the light’s state in the state machine has not updated yet when you call the script to save the state. Maybe add a delay between turning the light on and saving its state? Or maybe you can turn it on with a brightness level, because, at least for some lights, that makes it change state immediately (as opposed to slowly transitioning to the on state.)

You can probably check for sure by looking in home-assistant.log. You should be able to find the service call that turns the light on, then at some point the state_changed event that shows the light on. Then you can see how long it actually takes to update the state in the state machine.

50

Thanks :slight_smile: I will check.

I have to say I did a test in the meantime using those steps:
1 - Turn on the light (it turned on in the last color, blue)
2 - Run the python script from dev-services passing json payload to store the state
3 - Change the light color to red
4 - Run the python script from dev-service passing json payload to restore the state
5 - Light switched to white color O_o

Somehow I guess HA doesn’t actually know the color of the light (specially if is post-reboot) while Tasmota is storing the last state with the color.

I will try to turn on the light passing the color and the brightness as you suggested and I will let you know :slight_smile:

Thanks

51

Easy enough to check. Just look at it on the States page. What attributes does it have after you turn it on (in step 1)?

52

Those are the info:

min_mireds: 153
max_mireds: 500
effect_list: 0,1,2,3,4
brightness: 255
color_temp: 499
hs_color: 240,100
rgb_color: 0,0,255
xy_color: 0.136,0.04
effect: none
friendly_name: Alarm Light
supported_features: 23
53

Ok, then when you run the python script from the services page, what does the corresponding state look like? (Should be alarm_store.light_alarm_light.)

54

It doesn’t store everything apparently, here is the content:

brightness: 255
effect: none
color_temp: 499
55

Ok, so that’s what I expected.

The problem is that your light platform is lying. It’s saying color_temp is 499, but then saying that hs_color is 240,100. But a color_temp of 499 corresponds to an hs_color of 15.981,100. And an hs_color of 240,100 doesn’t correspond to any color_temp. So, either the light should be reporting color_temp, or it should be reporting hs_color (and rgb_color and xy_color), but not both, unless they do agree.

I believe this was discussed above quite a bit. You can also check out this from the light_store doc page.

Given that your light platform doesn’t work correctly, you can work around that problem by changing this line:

COLOR_ATTRS = [ATTR_WHITE_VALUE, ATTR_COLOR_TEMP, ATTR_HS_COLOR]

in light_store.py to:

COLOR_ATTRS = [ATTR_WHITE_VALUE, ATTR_HS_COLOR, ATTR_COLOR_TEMP]

That will cause hs_color to take precedence over color_temp.

56

Thanks for that :slight_smile: But that would also mean that I will not be able to get the updates without breaking it again (and don’t get me wrong, this is just a note to a 3rd person that might be reading :wink: )

I will absolutely test that option, I guess it might simply be something to do with MQTT or a default template that HA is assigning to the light maybe?

Maybe stupid question, what would happen if by default the script give priority to HS color as a standard?

If things are done properly on the light side, that shouldn’t make any difference, while on a messed up side like those Sonoff B1 flashed with Tasmota, therefore MQTT, will fix the issue as you explained.

Thanks for your time and effort :slight_smile:

57

Well then it wouldn’t work with some other types of lights that aren’t doing the right thing either. I think it was that way, but had to switch it before with some type of light that someone was using that reported hs_color wrong when color_temp was right. In your situation it’s the opposite. So it’s a no win situation when there are multiple types of lights out there that don’t report their attributes correctly.

58

Touchè :slight_smile:

I just tried to copy the state, change the color on the lamp and paste the old state, in HA it return to the previous color, the lamp no, that’s okay, but it is interesting that HA it still able to “understand” what got priority.

So now my question would be, what is the command you use to restore the state with the infos?

Wouldn’t be possible for you get the whole state payload, store it and re-set it as it was (or re-send it if you wish)?

If that is possible mantaining the order of the infos, maybe (really just thinking out loud), it will be able to work perfectly for each scenario.

Of course, I am just putting an idea in the mix, maybe it’s wrong :slight_smile:

59

Sorry, not following you. If you’re talking about using the States page to change the state of an entity, that is only updating the information in the State Machine; it does not actually affect the real device. That’s why it says:

Set the representation of a device within Home Assistant.
This will not communicate with the actual device.

So you can’t change the actual device just by copying and “re-pasting” the entity’s attributes. To change the actual device you need to call the appropriate service, which for a light is light.turn_off or light.turn_on. And when you call light.turn_on you need to pick which “color” value you want to change – profile, color_name, rgb_color, xy_color, hs_color, color_temp or kelvin; you can’t use more than one of these in the same service call.

60

Can parameters be added to the restore call? The idea is to allow a different COLOR_ATTRS list with a different element order to be used. Then people wouldn’t need to edit the code to make their lights restore correctly.