yup in conf appdaemon should have writing access and al dirs below it.
how do you know where AD has access? you should know because you decide which program can do what and where 
to make sure you can always check which user is owner from a dir and or files, and if the user you use to start appdaemon is the same or part of the group that has access.
@ReneTode ok created it in conf and the service started which means the logs directive is ok. but I see no logs
please share how your appdaemon.yaml is now.
at least the appdaemon.log should have been created and have entries in it.
ok so managed to create the logs and give permissions. the problem is the HASS plugin. see below the appdaemon.log. it cant connect. And suspect it’ll also be due to permissions.
So finally got it to work. For users on hassbian or similar virtual environment and upgrading from 2.x.x; two main areas of caution.
You need to add an app folder to the conf folder and delete the old app.yaml file
and do not add “namespace: default” on the HASS plugin.
1 Like
First, thanks for all your hard work! I have been using HAdashboard 2beta and 2 without any real issues. I now have upgraded to version 3 and AppDaemon is not restarting. I am also running HA 0.65.5. Both HA and AppDaemon are run in the same Homeassistant virtual environment.
The systemd status is:
● [email protected] - AppDaemon homeassistant
Loaded: loaded (/etc/systemd/system/[email protected]; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2018-03-20 15:44:58 CDT; 3s ago
Process: 6775 ExecStart=/srv/homeassistant/bin/appdaemon -c /home/homeassistant/conf (code=exited, status=1/FAILURE)
Main PID: 6775 (code=exited, status=1/FAILURE)
Mar 20 15:44:57 raspberrypi appdaemon[6775]: File “/srv/homeassistant/lib/python3.5/site-packages/appdaemon/admain.py”, line 365, in main
Mar 20 15:44:57 raspberrypi appdaemon[6775]: admain.main()
Mar 20 15:44:57 raspberrypi appdaemon[6775]: File “/srv/homeassistant/lib/python3.5/site-packages/appdaemon/admain.py”, line 361, in main
Mar 20 15:44:57 raspberrypi appdaemon[6775]: self.run(appdaemon, hadashboard)
Mar 20 15:44:57 raspberrypi appdaemon[6775]: File “/srv/homeassistant/lib/python3.5/site-packages/appdaemon/admain.py”, line 60, in run
Mar 20 15:44:57 raspberrypi appdaemon[6775]: self.AD = ad.AppDaemon(self.logger, self.error, self.diag, loop, **appdaemon)
Mar 20 15:44:57 raspberrypi appdaemon[6775]: AttributeError: module ‘appdaemon.appdaemon’ has no attribute ‘AppDaemon’
Mar 20 15:44:58 raspberrypi systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILUREMar 20 15:44:58 raspberrypi systemd[1]: [email protected]: Unit entered failed state.
Mar 20 15:44:58 raspberrypi systemd[1]: [email protected]: Failed with result ‘exit-code’.
The are no entries in the error.log and the appdaemon.log looks fine:
2018-03-20 15:44:57.908887 INFO AppDaemon Version 3.0.0 starting
2018-03-20 15:44:57.910269 INFO Configuration read from: /home/homeassistant/conf/appdaemon.yaml
My appdaemon.yaml file is a follows:
log:
logfile: /home/homeassistant/logs/appdaemon.log
errorfile: /home/homeassistant/logs/appdaemon_error.log
log_generations: 5
log_size: 1024
appdaemon:
disable_apps: 1
threads: 10
plugins:
HASS:
type: hass
api_ssl_certificate: /path_to/fullchain.pem
api_ssl_key: /path_to/privkey.pem
ha_url: https://xxxxx.duckdns.org:nnnn
ha_key: mypassword
hadashboard:
dash_url: http://192.168.1.13:5050
dash_compile_on_start: 1
Any pointers would be greatly appreciated. Thank you.
Looks like you are still running AD 2.0 - the error says it is looking for AppDaemon section which has changed tho lower case in 3.0 as you have it in your config
Edit; forget that I misread the log
- if you show yaml as codeblock others can read it too. without the indention its not readable
- if you have Appdaemon and homeassistant in the same venv, then you have a problem because there has been a change in HA that creates conflicts.
the advice is to create 2 different venv for the 2.
but then again, i have them running without problem in the same environment.
all i have to do for that is make sure that homeassistant is updated AFTER the appdaemon update.
so if you have done AD as last, then you need to change your venv or reinstall or update homeassistant.
1 Like
Thanks, maybe the best thing to do for the long haul is to install AppDaemon into its own virtual environment. I will try that later.
I will post my appdaemon in a code block if I am still having problems after the separate virtual environment install for AppDaemon.
Later…
Thanks again. I am up and running after installing AppDaemon in its own virtual environment!
1 Like
WARNING AppDaemon: No app description found for: /config/appdaemon/apps/globals.py - ignoring
I’ve added global_modules: global to apps.yaml and global_dependencies: global to the relevant apps. Is there something else within the new globals structure that needs to be changed?
Hi,
Getting this error consistently around the same time every day. App daemon crashes after and needs to be restart. This has been happenign for the last week since I installed AppDaemon3 and converted all my apps. After re-starting they all work fine
2018-03-23 07:12:31.460742 WARNING AppDaemon: ------------------------------------------------------------
2018-03-23 07:12:31.462162 WARNING AppDaemon: Unexpected error during state_update()
2018-03-23 07:12:31.463276 WARNING AppDaemon: ------------------------------------------------------------
2018-03-23 07:12:31.492343 WARNING AppDaemon: Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 2263, in state_update
await self.dashboard.ws_update(namespace, data)
File "/usr/lib/python3.6/site-packages/appdaemon/rundash.py", line 402, in ws_update
await ws.send_str(data)
File "/usr/lib/python3.6/site-packages/aiohttp/http_writer.py", line 125, in drain
yield from self._protocol._drain_helper()
File "/usr/lib/python3.6/asyncio/streams.py", line 211, in _drain_helper
yield from waiter
File "/usr/lib/python3.6/asyncio/selector_events.py", line 785, in _write_ready
n = self._sock.send(self._buffer)
BrokenPipeError: [Errno 32] Broken pipe
it appears to be around sunset, and i have the following running at sunset, which also hasn’t run since my upgrade to AD3
import appdaemon.plugins.hass.hassapi as hass
import datetime
import random
#
# App to turn lights on after sunset then turn off a time later
#
# Args:
#lights : entity to turn on
#delayoff: time after sunset to turn off
class AutoTurnOnOffSunset(hass.Hass):
def initialize(self):
self.handle = None
self.run_at_sunset(self.sunset_t)
def sunset_t(self, kwargs):
#rnd_brightness = random.randint(80, 200)
if self.args["rgb"] == "random":
rgb = self.getLightColour()
self.log("the random color {}".format(rgb))
else:
rgb = self.args["rgb"]
self.log("the selected color {}".format(rgb))
for light in self.args["lights"]:
device, entity = self.split_entity(light)
if device == "light":
#rgb_color = rand_rgb_color
self.turn_on(
light,
rgb_color = rgb,
effect = "solid",
brightness=150)
notifymessage = "{} turned on coloured Light at sunset {}".format(light, rgb)
self.log(notifymessage)
self.call_service("notify/notify", message = notifymessage )
else:
self.turn_on(light)
notifymessage = "{} turned on standard Light at sunset".format(light)
self.log(notifymessage)
self.call_service("notify/notify", message = notifymessage )
self.log("It is sunset - Turned on {}".format(light))
try:
self.cancel_timer(self.handle)
except KeyError:
# This doesn't matter that the timer doesn't exist. If it did, we should cancel it.
self.log("{} timer does not exist".format(entity))
self.handle = self.run_in(self.turnOff, self.args["delayoff"])
def turnOff(self, kwargs):
for light in self.args["lights"]:
self.turn_off(light)
notifymessage = "It is late - Turned off {}".format(light)
self.log(notifymessage)
self.call_service("notify/notify", message = notifymessage)
def getLightColour(self):
# determine a random RGB value for Fun to set the light this color
# random.seed()
R = random.randint(0, 255)
B = random.randint(0, 255)
G = random.randint(0, 255)
rgb = [R,G,B]
#rgb = [255,255,255]
return rgb
##Auto Light Turn On and Off - Sunset
auto_turn_on_off_front_garden_lights:
module: auto_turn_on_off_sunset
class: AutoTurnOnOffSunset
lights:
- switch.front_garden_light
- light.garage_color_light
delayoff: 9000
rgb: "random"
appdaemon config
secrets: /config/secrets.yaml
log:
logfile: /config/appdaemon/apps/logs/info.log
errorfile: /config/appdaemon/apps/logs/err.log
accessfile: /config/appdaemon/apps/logs/access.log
logsize: 100000
log_generations: 2
appdaemon:
disable_apps: 0
threads: 10
api_port:
api_key: !secret http_password
api_ssl_certificate: /ssl/fullchain.pem
api_ssl_key: /ssl/privkey.pem
plugins:
HASS:
type: hass
ha_url: !secret ha_url
ha_key: !secret http_password
hadashboard:
dash_url: http://127.0.0.1:5050
dash_dir: /config/appdaemon/dashboardsa global app must also be declared as a normal app like:
global:
module: globals
class: a_class_name
@ScottSuine you say it happens around the same time around sunset, but you show that the error appears in the morning?
Yes sorry, your right. But it does kill AD, Any ideas what could be causing this error and crashing AD
it seems that AD tries to update a dashboard and somehow cant do that.
much more i cant get out of the error, this is more the area where @aimc needs to help
OK, i may just disable the dashboard for a day or two and see what happens. that may narrow things down
thanks
I am working on a project, and in this project I got several users with different attributes allocated to them.
Now I want an efficient way to pass these attributes among the different apps that will be used, and I think these are my only options:
-
Use
self.global_vars[user] -
Pass user’s attributes as a state using
self.set_app_state()
I am confused as I don’t know how the set_app_states()'s data is stored. is it stored in the RAM and I can easily just read it using self.get_state() at anytime? if that is the case, will it be retained when an app is reloaded, and only cleared when the full appdaemon service is restarted just ike the self.global_vars?
In my head, I am of the view that the set_app_state is better, so i just read the entities as I go along, and update them in real time; since the self.global_vars isn’t multi-threaded.
Please i could do with some advice.
Kind regards
The state is set within AppDaemon so you can use listen_state() to get a notification at the time, and later use get_state() to see the value. It will not survive a restart of AD though.
That’s a good place to start - let us know what you find. I’m not sure that that error would kill AppDaemon.
Also, when you say the app is not working - what do you mean? Are you getting errors? Have you added any logging to see how far it gets?
Oh that’s awesome, so I guess it is using self.set_app_state then. I Will just be updating the state to indicate which app should work on it, and use the attributes to store all the info as each app works on each user. Then have them listen for state changes, so the other apps knows the working app is done.
Hope that will work, and I am not creating a problem for myself 
Many thanks
1 Like
Sorry, so should the globals.py be changed too? Could you please give me an example?