Here it is - the next AppDaemon 3.0 beta!
To upgrade from a previous version of the beta or of 2.0, use the command:
$ pip3 install --upgrade --pre appdaemon
You may need to use sudo
depending on how you originally installed it.
We have a few new features, some bugfixes, but the biggest change is a rewrite of the module loading and dependency tracking code.
This rewrite introduces some breaking changes as dependencies are now tracked at the app level rather than the module level. This gives a lot more flexibility, and solves a couple of problems. For instance, @ReneTode, the undisputed AppDaemon power user has one App that he is running 60 different instances of. Under the old system, a change to one of those instances parameters in apps.yaml forced all 60 apps to reload - not good With the new app level dependencies, just the affected app will reload, along with any other apps that depend on it.
While I was in the code I made another change that I had been wanting to for a while - dependencies used to be a comma separated list, now they are a true yaml list.
So what does that mean for anyone upgrading? Well, if you weren’t using dependencies before, then absolutely nothing, all should work the same.
If you were using dependencies, you will need to make some minor changes, to reference apps rather than modules, and to change the format for multiple entries. Here’s an example of an old style dependency tree:
app1:
module: module1
class: class1
app2:
module: module2
class: class2
app3:
module: module3
class: class3
dependencies: module1
app4:
module: module4
class: class4
dependencies: module1,module2
Under the new system we change the dependencies to apps and change the way the dependencies are listed:
app1:
module: module1
class: class1
app2:
module: module2
class: class2
app3:
module: module3
class: class3
dependencies:
- app1
app4:
module: module4
class: class4
dependencies:
- app1
- app2
And that’s it!
For those of you that are relying on the module based reloading to force reloads of modules that aren’t apps, this will no longer work. You can continue to use a non-app global module as long as it resides in the same directory as one or more actual apps, but the dependency based reloading will no longer work. The way to fix this is to make the global module into an app, and use get_app()
to reference any shared code or variables. You can then use the new app based dependency tracking to make sure dependent apps are reloaded after a change.
Happy Apping!
3.0.0b3 (2018-02-11)
Features
- Added
javascript
widget - Upgraded MDI Icons to 2.1.19
- Add separate log for diagnostic info
- Per-widget type global parameters
- App level dependencies
-
listen_state()
now returns the handle to the callback - added
oneshot
option tolisten_state()
- Add step parameter to climate widget - contributed by
Adrian Popa <https://github.com/mad-ady>
__ - Add internationalization options to clock widget - contributed by
Adrian Popa <https://github.com/mad-ady>
__ - Doc improvements - contributed by
Marco <https://github.com/marconett>
__
Fixes
- Fixed image path for android devices
- Fix a bug with the time parameter for images
- Fixed
disable_apps
- Fixed a bug in
get_state()
withattributes=all
returning just the attributes dictionary instead of the entire entity.
Breaking Changes
- In apps.yaml, dependencies should now be a proper yaml list rather than a comma separated string
- Dependencies now refer to individual apps rather than modules