I thought I did
jarvis_core:
module: jarvis_core
class: jarvis_core
jarvis_weather:
module: jarvis_weather
class: jarvis_weather
dependencies: jarvis_core
Hmm, so I started thinking about plugins more since I could see them being very useful, but would really require a little tweaking to work the way I am thinking.
One thing I think would be very cool is to make one app be able to work with different plugins which would obviously require changing the way imports are done in the apps.
Bit of a grand idea but, my thinking is I’d like to implement a standalone plugin (really just an mqtt listener for my purposes) and probably an OpenHab plugin, and my app would be able to work with all of them (not necessarily at the same time!). Any thoughts?
MQTT support as a great idea for a plug-in. You have to have 2 apps though as each app can only have one parent object. Apps can be in the same file though. Also apps using different instances of the same plug-in can work together using namespaces. I envisaged apps cooperatively sharing access to dissimilar plugins using get_app()
Ah, gotcha, that’ll work since I could just have a small ‘app’ in my other app file to bridge between the plugins.
as i see it:
MQTT could be at both ends.
as component from an app to give it through to a plugin or as a plugin itself.
openhab or simular programs like HA, that are only there to be a collection of entities, are plugins that can be used side by side or just exchange one another.
And here we go!
Something you should know: This add-on can now communicate with Home Assistant directly using the internal network/proxy Hass.io offers. (So no more looping back externally or ignoring certificates to connect to Home Assistant). This is the default setting for first-time installations as well.
3 Likes
So I put the start of my app up here in case you want to see why I am causing so much trouble for you!
1 Like
OK, what is happening here is as follows:
In beta1 and earlier, if you changes the yaml for an app it would be reloaded, but it wouldn’t reload any dependent apps. I put in a fix for this, but it re-used the logic for a changed .py file. If a .py file changes, of course all the apps using it should be reloaded, but that is a different case from the yaml changing. So, I need to go back and write some additional logic for just the yaml changing - I’ll put this in b3.
1 Like
Is there a way to get a list of all known entities?
get_state() with no parameters.
1 Like
I’m getting the following error after attempting an upgrade. Any suggestions? No log: lines are defined in my appdaemon.yaml.
Did pip3 install an old version?
Loaded: loaded (/etc/systemd/system/[email protected]; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2018-01-30 14:15:59 EST; 8s ago
Process: 17437 ExecStart=/srv/hass/appdaemon_venv/bin/appdaemon -c /home/hass/appdaemon (code=exited, status=1/FAILURE)
Main PID: 17437 (code=exited, status=1/FAILURE)
Jan 30 14:15:56 raspberrypi systemd[1]: Started AppDaemon.
Jan 30 14:15:59 raspberrypi appdaemon[17437]: Traceback (most recent call last):
Jan 30 14:15:59 raspberrypi appdaemon[17437]: File "/srv/hass/appdaemon_venv/bin/appdaemon", line 11, in <module>
Jan 30 14:15:59 raspberrypi appdaemon[17437]: sys.exit(main())
Jan 30 14:15:59 raspberrypi appdaemon[17437]: File "/srv/hass/appdaemon_venv/lib/python3.5/site-packages/appdaemon/admain.py", line 230, in main
Jan 30 14:15:59 raspberrypi appdaemon[17437]: conf.logfile = config['AppDaemon'].get("logfile")
Jan 30 14:15:59 raspberrypi appdaemon[17437]: KeyError: 'AppDaemon'
Jan 30 14:15:59 raspberrypi systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
Jan 30 14:15:59 raspberrypi systemd[1]: [email protected]: Unit entered failed state.
Jan 30 14:15:59 raspberrypi systemd[1]: [email protected]: Failed with result 'exit-code'.
Is that upgrading from appdaemon2 or 3 beta 1? Check here https://community.home-assistant.io/t/announcement-appdaemon-3-0-beta-1/38916
pip3 by default installs the latest non-beta or alpha version, which is 2.1.12. If you want the beta add the --pre flag. What you have above looks like 2.1.12 - the beta is looking for appdaemon instead of AppDaemon. FOr all the details check the original beta thread. (I just added a link at the top of this topic for convenience)
That was it, I forgot the —pre flag when I upgraded. Good to go now. Thanks!
1 Like
Noticed a small typo in the docs and/or code for HADashboard.
Under HADashboard Installation and Configuration, you have:
Optionally, you can place your dashboards in a directory other than under the config directory using the dash_dir directive.
But Appdaemon is looking for : dashboard_dir
if conf.dashboard_dir == None:
if config_dir is None:
conf.dashboard_dir = find_path("dashboards")
else:
conf.dashboard_dir = os.path.join(config_dir, "dashboards")
Also in the Docs you have:
Next, you will need to create the dashboards directive either under the conf directory, or wherever you specify with dash_dir.
You do not need to create a dashboards directive when specifying a custom dashboards directive with dash_dirs/dashboard_dir
Loving the Beta so far, I’ve been using Appdaemon since the beginning and don’t know what I’d do without it, so Thank You. 
1 Like
I have finally got a chance to try this out, but I’m getting a fatal error when starting up. I can’t see any references to the priority of apps in the docs, so I’m not sure where to start looking for the problem
(appdaemon3) homeassistant@graham-lubuntu17:~/appdaemon3
$ appdaemon -c /home/homeassistant/testing/
Traceback (most recent call last):
File "/home/homeassistant/appdaemon3/bin/appdaemon", line 11, in <module>
sys.exit(main())
File "/home/homeassistant/appdaemon3/lib/python3.5/site-packages/appdaemon/admain.py", line 341, in main
admain.main()
File "/home/homeassistant/appdaemon3/lib/python3.5/site-packages/appdaemon/admain.py", line 337, in main
self.run(appdaemon, hadashboard)
File "/home/homeassistant/appdaemon3/lib/python3.5/site-packages/appdaemon/admain.py", line 79, in run
loop.run_until_complete(asyncio.gather(*pending))
File "/usr/lib/python3.5/asyncio/base_events.py", line 466, in run_until_complete
return future.result()
File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
raise self._exception
File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
result = coro.send(None)
File "/home/homeassistant/appdaemon3/lib/python3.5/site-packages/appdaemon/appdaemon.py", line 1292, in utility
await utils.run_in_executor(self.loop, self.executor,self.read_apps, True)
File "/home/homeassistant/appdaemon3/lib/python3.5/site-packages/appdaemon/utils.py", line 121, in run_in_executor
response = list(completed)[0].result()
File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
raise self._exception
File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "/home/homeassistant/appdaemon3/lib/python3.5/site-packages/appdaemon/appdaemon.py", line 1843, in read_apps
mod["priority"] = self.get_app_priority(mod["name"])
File "/home/homeassistant/appdaemon3/lib/python3.5/site-packages/appdaemon/appdaemon.py", line 1735, in get_app_priority
for name in self.app_config:
TypeError: 'NoneType' object is not iterable
(appdaemon3) homeassistant@graham-lubuntu17:~/appdaemon3
Fixed - thanks!
1 Like
Can you post your apps.yaml?
The docs on loading priority are here:
http://appdaemon.readthedocs.io/en/latest/APPGUIDE.html?highlight=priority#loading-priority
My apps.yaml is 328 lines long, so I think I’ll try and simplify it to something that is causing the problem before posting.
Setting the priority of every app didn’t solve the problem though.
You shouldn’t need to set any priorities at all unless you want to. I think the issue is somewhere else and the priority piece is where it’s getting caught up.