Appdaemon lightschedule

Third party integrations AppDaemon
21

i really dont understand why people like to change their lights at random times. :wink:
it could be implemented but i like you to give that a try yourself. :wink:

setting dimmer percentage in an automation would make sense in combination with sunset or a lightsensor i guess, but i have no way to test that out, so i am sorry i cant give you that.

yeah, you need to restart the app. and for that you have 3 options right now:

  1. restart appdaemon
  2. edit the app (add a comment with the date from your file update for instance)
  3. edit the cfg (make an entry in the light app section with the lastchanged date for instance)

in all 3 cases all old schedules are removed.

i use(d) input_booleans for 433 mhz switches with a mysensors remote.
now they are switches because i made a custom component from it.

and last: i have no idea what you mean with dynamic sensor creator.

22

Thanks for following up. Random is so I can use it for when traveling and want to deviate from a set schedule. I think I have a few ideas on how to build on your code to add it. I’ll give it a try. I also want to add overrides so I can pause a schedule if needed.

The “dynamic sensor” is a reference to a post you had in the appdaemon Q&A thread. I was wondering if it is possible to use appdaemon to create entities on the fly and configure them without putting them in HA config files.

23

if you normally have a set schedule running and set a random when you are traveling, you tell everyone that you are not home :wink:
but if it is for that case you can add

random_start = -300, random_end = 300

to the run_at_sunrise, run_at_sunset and run_daily lines.
you could also make an input boolean in hass, which sets random on and on.
in that case use get_state to know if it is on and if it is on set the value to a specific amount, else to 1 (i dont know if random 0 would give a problem, thats why i say 1)

i didnt implement overrides because you can use callback constraints inputboolean in the cfg file.

yeah you can create an entity on the fly.
and you can change that value anytime you like.
just use setstate(“your_own_domain.your_sensor_name”)
the first time it will be created and after that updated.
i havent been able to create attributes for it though.
and setting states from existing entities still isnt working like expected.

24

I made the adjustments to allow for overrides. I’m new to Python, so if I’m wrong I apologize, but I think I found a bug or am misunderstanding the logic.

The spreadsheet shows something like “sunset + 00:59:55”. When the code splits this value based on “:” and then references int(sunsetparts[1]) to create the offset, it looks like the “+ or -” is lost and just the 59 is picked up. When you set the offset in the call run_at_sunset it will offset by 59 seconds (offset value is in seconds). I’m not sure if this is what is intended. Does the code match up with the spreadsheet or has the format of the spreadsheet changed?

Thanks.

25

yeah sorry, the format from the spreadsheet has changed a little.

it should now be:

sunset:60 for an offset from 60 seconds.

that is intended because run_at_sunset works that way.

26

You could also take a look at the Occupancy Simulator I wrote for AppDaemon.

1 Like
27

Thanks. I figured something was off with the old screenshot of the spreadsheet and the code.

Adjustment made. Thank you for all your help…and code.

28

I’ll take a look. That’s probably what I need to do and keep the lightschedule simple.

BTW, is there like an “App Store” where all these ideas are posted and maintained? HASS has the examples, but I don’t see anything where Appdaemon is highlighted or a repository. I’m just picking up Appdaemon in the last 24 hours, just searching in the forum.

Thank you for all the great work. I hope to have all my scripts\automation ported to Appdaemon today. :slight_smile:

29

lol, nice idea.
the appdaemon store.

but no all there is is on the forum and in the examples from andrew (aimc)

if i make an app which i think is worth sharing i post it here in third party integrations with appdaemon in the title.

30

I have been discussing the idea of an App Store with another forum member - I might also raise it with @balloob

31

can i then also ask 1 dollar for each download? :stuck_out_tongue:

32

Appstore doesn’t necessarily mean monetary gain you know :wink:

33

cant you let me dream of making millions and millions by creating some apps? :wink:
but the idea is cool.

2 Likes
34

Ok, just to make it a little clearer for me, you know I’m kind of dense. Because run_at_sunset actually kicks off a listen_state(callback, “sun.sunset”), the listen state makes it so I don’t have to re-schedule it every day. Run_at_sunset is equivalent to run_daily(callback,self.sunset) (but with the sunset time corrected every day). Right???

35

i thought so to, but andrew told me that the time gets calculated inside appdaemon, but that he is using the same calculation as hass.

but the effect is the same.
the difference between run_at_sunset and run_daily(callback,self.sunset) is this:

run_at sunset will always be triggered at sunset.
run_daily(callback,self.sunset) would take the time that sunset is on the time the app is initialized. and then run at that time daily.

so if thats what you mean, then you are right.

36

It was more about what you answered in the other post. That run_at_sunset is a recurring schedule and would be better named run_daily_at_sunset :slight_smile:

1 Like
37

maybe that @aimc would think about that :wink:

38

You are correct but I’m not renaming it this late in the game - it will break stuff :wink: Maybe I will deprectae it and add the new name or something.

39

LOL, As long as I understand, you can call it foo. LOL

1 Like
40

You could start with being more explicit in the documentation, that would go a long way. :slight_smile: