AppDaemon Q&A

Third party integrations AppDaemon
61

i think it id wise to mention that import is neccesary if you use examples like this:


# Run at 4pm today, or 4pm tomorrow if it is already after 4pm
runtime = datetime.time(16, 0, 0)
handle = self.run_once(self.run_once_c, runtime)

this one probably wont work :wink:

# Run daily at 7pm
time = datetime.time(19, 0, 0)
self.run_daily(self.run_daily_c, runtime)

this one is beneath run hourly:

# Run every hour, on the hour
time = datetime.time(0, 0, 0)
self.run_daily(self.run_daily_c, runtime)

i think you forgot an enter here:

self.turn_off("switch.patio_lights") self.turn_off("light.office_1")

and in that part some more.

this one i already mentioned the missing selfs

time = parse_time("17:30:00")
time = parse_time("sunrise")
time = parse_time("sunset + 00:30:00")
time = parse_time("sunrise + 01:00:00")

i think it is wise to read it yourselve 1 more time slowly, i think you can find and update more than i. :wink:

but i am still very glad with it.
right now i’m moving other automations to apps.
another advantage i see is that you can easyly create logfiles just like you like them.
i missed an easy way to look back if an automation had fired or not, now i made an automations.log and can find them in a second.

62

Thanks very much - I will take a run through and see about making things more consistent and complete.

1 Like
63

Please Read Carefully - there are breaking changes!

OK, I just pushed a new version 1.1 - The higlights are Docker support and pip3 installation. There are a number of breaking changes (apologies) - please see below for details.

1.1.0 (2016-21-09)

Features

  • Installation via pip3 - contributed by Martin Hjelmare
  • Docker support (non Raspbian only) - contributed by Jesse Newland
  • Allow use of STDERR and SDTOUT as logfile paths to redirect to stdout and stderr respectively - contributed by Jason Hite
  • Deprecated “timezone” directive on cfg file in favor of “time_zone” for consistency with Home Assistant config
  • Added default paths for config file and apps directory
  • Log and error files default to STDOUT and STDERR respectively if not specified
  • Added systemd service file - contributed by Jason Hite

Fixes

  • Fix to give more information if initial connect to HA fails (but still avoid spamming logs too badly if it restarts)
  • Rename ‘init’ directory to ‘scripts’
  • Tidy up docs

Breaking Changes

  • As a result of the repackaging for PIP3 installation, all apps must be edited to change the import statement of the api to import appdaemon.appapi as appapi
  • Config must now be explicitly specfied with the -c option if you don’t want it to pick a default file location
  • Logfile will no longer implicitly redirect to STDOUT if running without the -d flag, instead specify STDOUT in the config file or remove the logfile directive entirely
  • timezone is deprecated in favor of time_zone but still works for now

The existing init script will no longer work as is - I’ll push a fix tomorrow.

2 Likes
64

i’m afraid i will have to start all over with taking out lines if i update, isnt it?

and can you tell me, why this doesnt do anything, not even an error?

import appapi
import datetime

class sunsetlights(appapi.AppDaemon):

  def initialize(self):       
    self.run_at_sunrise(self.sunset_lights,int(self.args["offset"]))
      
  def sunset_lights(self, args):
65

For this release yes, I am afraid you will have to re-apply the changes if you upgrade. I have a list item to make a windows friendly version though.

Regarding the App - most likely you don;t have the correct module/class name configured in your appdaemon.cfg file.

66

in the cfg i have this:

[lichtaanbuiten]
module = sunsetlights
class = sunsetlights
offset = 0
omschrijving = buiten verlichting
total_switches = 2
switch1 = terras
switch2 = moestuin

the filename is sunsetlights.py

but the def doesnt run at all. in the first lines it should log what it is doing, like i have in my other files working, but nothing.

67

You should be getting a compilation error because you can’t have a module definition without anything in the body.

68

there is something in the body. i just did copy the part where it goes wrong:

the complete file:


import appapi
import datetime

class sunsetlights(appapi.AppDaemon):

  def initialize(self):       
    self.run_at_sunrise(self.sunset_lights,int(self.args["offset"]))
      
  def sunset_lights(self, args):
    switchlog = open('C:\\Users\\rene\\AppData\\Roaming\\.homeassistant\\switches.log', 'a')
    runtime = datetime.datetime.now().strftime("%H:%M:%S")
    switchlog.write(runtime+",'automation','"+self.args["omschrijving"]+" aan'\n")
    switchlog.close()
    for counter in range(1,int(self.args["total_switches"])+1):
      self.turn_off ("input_boolean."+self.args["switch"+str(counter)])

it is a fast identical copy from my rfswitch.py which works.
the only thing that doesnt work is the trigger.

69

Nothing in the log about it loading the file and creating the object?

70

Also a little confusing is it is called “sunsetlights” but the callback runs at sunrise and turns all the lights off -= is that intentional?

71

thank you. that why it doesnt work :wink:
and obvious there no log there.

thats because i have to switch between 3 languages all day long, sometimes i get wordblind :wink:

72

Hehe - I find one language confusing enough!

73

thank god, that the programming is always english :wink:
but with 10 programming languages in a not native language it isnt always easy :wink:

i just completed a new component, which i find very helpfull, thanks to apps.

i now have a page where i can see the time on which sensors are updated the last time
not all off them, but just the few i think are important or are buggy.
time in tekst and as a slider, so i can see if sensors are regularly updated or not.

guess i have to thank you again, because you have taken the time to be complete. i use the set_state :wink:

74

set_state()? You are now officially the most advanced user of AppDaemon - even I’m not using set_state() for anything :slight_smile:

1 Like
75

i only came upon 1 thing i think is normally unwanted.

if i use:

        self.set_state(controle_sensor, state = last_changed)

HA sets the name in the frontend from the friendly_name to the entity_id
i dont really mind, because i set the friendly name anyway like this:

        self.set_state(controle_sensor, state = last_changed, attributes = {"friendly_name": last_time + " " + self.friendly_name(entity)})

that way i can see the time AND i see the friendly name from the original sensor

works like a charm.

76

That’s interesting - musdt be a side effect of HA - I have never seen it do that. I like your workaround though :slight_smile:

77

the workaround works fine, untill it is 23:59

it seems like that setting the input slider works only if i set it at a higher level.

i tried the same with an templatesensor which has a value template zero, but the it sets the old friendly name back immediatly after it is changed. so thats not working either.

now im trying to set the slider value to 0 in automations when its 0:00

if course i can make an commandline sensor also if this fails. (probably better, but it takes more yaml coding and i’m not familiar enough with commandline :wink: )

edit:

to bad, i cant become it stable.
but giving up isnt in my dictionary.
i have it rewritten, and now i have a controle tab which displays a persistant notification for every sensor i want to trace.
it is not as nice in the gui, but it seems stable. and im not working around anything :wink:

78

Just pushed a bugfix - the sample init script should now work with the new configuration options, if you are using it you will need to copy the new version and re-apply any changes you made.

1.1.1 (2016-23-09)

Fixes

  • Fix init scripts
79

Today we have a nice little addition - it is now possible to add an arbitary number of nested directories under app_dir and they will all be checked for Apps - this allows you to organize your collection of apps in an appropriate directory hierarchy.

1.2.0 (2016-24-09)

Features

  • Add support for recursive directories - suggested by jbardi

Fixes

None

Breaking Changes

None

1 Like
80

@ReneTode - I just tested AppDaemon in the Bash environment in Windows 10 and it works perfectly with no changes. MIcrosoft have done a really good job of it, it supports the signals and Daemonize works perfectly. May b easier than running it in a command she’ll and editing all the the time. If not I can add code to disable the parts that break.

1 Like