They both need ‘self.’ In front of them.
1 Like
i could have thought about that myself 
but in the API there is no self
It’s part of the way Python objects work so I was in 2 minds if I should put t in or not …
i think it is best to choose 1 way.
you have used self. on a lot off places in the API
if you then dont put it there at some place it is expected that it isnt needed there (or at least i think in that way )
i now tried out to use datetime just like you have it in the API.
i guess i have to import it? because just using the code you have in the API gives an error.
Yes, you need to import any additional modules you need to use, just as in a regular Python program. Let me know if/when you find examples that don’t work and I will correct them.
1 Like
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
# 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.
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.
Thanks very much - I will take a run through and see about making things more consistent and complete.
1 Like
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
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):
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.
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.
You should be getting a compilation error because you can’t have a module definition without anything in the body.
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.
Nothing in the log about it loading the file and creating the object?
Also a little confusing is it is called “sunsetlights” but the callback runs at sunrise and turns all the lights off -= is that intentional?
thank you. that why it doesnt work
and obvious there no log there.
thats because i have to switch between 3 languages all day long, sometimes i get wordblind
Hehe - I find one language confusing enough!
thank god, that the programming is always english
but with 10 programming languages in a not native language it isnt always easy
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
set_state()? You are now officially the most advanced user of AppDaemon - even I’m not using set_state() for anything 
1 Like
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.