Announcement - AppDaemon 3.0!

After a dive through the code, I suspect that this might be caused by the way the file is being rewritten. If it is momentarily deleted, then recreated, but AD does it’s check at the exact moment it is deleted, you would observe the behavior above (unloading vs reloading), with the exception that is should have picked up the new version of the code which it clearly didn’t.

What are you using to edit the apps?

Vi - just making changes and then hitting :w

Also editing on the local machine … (same machine with HASS and AD)

1 Like

Old school - I approve :slight_smile:

I know Vi saves .swp files and makes backups etc. so it’s possible my theory is correct - I’ll give it a try locally and see if I can reproduce it.

1 Like

Hahaha - yeah I can run circles around them kids with their fancy GUI editors …:grin:

1 Like

Can;t seem to get it to happen here, even using vi - I tried about 20 times in a row.

What hardware are you using? Might be related to speed of filesystems.

Running Ubuntu on a VM on a Synology NAS. I get the delete and reloading if the file system is slow - but sure seems off that it would reload the old version of the app.

Yes, that part is clearly wrong …

I also use vim and I think I have seen similar problems, but not often enough to tie it down.

1 Like

i also noticed that it wasnt 100% reliable, but i didnt want to mention it untill i had more info (and didnt come around to it yet)
so once again eboon saves me some time :wink:

and you know already about my filesystem :wink:

1 Like

Thanks @ReneTode.
Have added the port and checked it matched the hassio AD value. Alos moved the location of the log files. Will see if this makes difference

thanks again

1 Like

Revisiting this again after giving up for a few days.

When I add the parameters as you’ve written above, I get the following error in my AppDaemon add-on log and AD fails to start:

ERROR:
while parsing a block mapping
  in "<unicode string>", line 8, column 3:
      threads: 10
      ^
expected <block end>, but found '<scalar>'
  in "<unicode string>", line 20, column 36:
      wife_tracker: "device_tracker.{}".format(wife_tracker_id)
                                       ^

Does it have something to do with escaping characters? I’ve tried looking up YAML references but can’t find my answer.

@aimc are there any breaking updates to the example Presence app that require changes?

Not that I am aware of

i just translated from txt file to yaml without looking, but in a yaml file you cant put code like that.
i would suggest you just use:

  notify: "telegram"
  wife_tracker_id: "wife"
  wife_tracker: "device_tracker.wife"

  me_tracker_id: "me"
  me_tracker: "device_tracker.me"

but you were not talking about a global app and also not about globals vars, but about some global py code that i didnt know people use.

the globals.py that you used before isnt changed and just should be in the same dir as your app.

Every now and again, AppDaemon fails to start up:

2018-03-29 19:07:01.724586 INFO AppDaemon: HASS: Connected to Home Assistant 0.66.0.b2
2018-03-29 19:07:03.725158 ERROR AppDaemon: Required attribute not set or obtainable from any plugin: latitude
2018-03-29 19:07:03.725752 ERROR AppDaemon: AppDaemon is terminating
close status: 31522
2018-03-29 19:07:03.730354 ERROR AppDaemon: Required attribute not set or obtainable from any plugin: longitude
2018-03-29 19:07:03.731329 ERROR AppDaemon: AppDaemon is terminating
2018-03-29 19:07:03.732358 ERROR AppDaemon: Required attribute not set or obtainable from any plugin: elevation
2018-03-29 19:07:03.733893 ERROR AppDaemon: AppDaemon is terminating
2018-03-29 19:07:03.735023 ERROR AppDaemon: Required attribute not set or obtainable from any plugin: time_zone
2018-03-29 19:07:03.735845 ERROR AppDaemon: AppDaemon is terminating
2018-03-29 19:07:03.758698 INFO AppDaemon: HASS: Disconnecting from Home Assistant
2018-03-29 19:07:03.760382 INFO AppDeamon Exited
2018-03-29 19:07:04,104 INFO exited: appdaemon (exit status 0; expected)

A restart seems to fix it. Not sure if it’s a bug or what, but thought I’d post it here.

It’s a race condition when HASS is starting up - I’m looking into a fix.

For now, if you set the following attributes in your appdaemon.yaml in the appdaemon section you can avoid this:

latitude
longitude
elevation
timezone

2 Likes

This should be fixed in the next version.

1 Like

I’m working on upgrading to AD 3.0 and updating the occusim to work with AD 3.0.

I have a few questions:

  • In the Occusim.py what does import globals do? I keep getting and error message about it can’t find globals. When I remove import globlas , it seems to work.

  • Also is there anyway to have the simulator turn on without having to manually add the .py and .yaml?

Thank you,

the globals.py is a file that needs to be in the same directory and its called globals.py and contains variables
its in the example_apps directory.

it would be very hard to have an app turn on without an app.
what you ask is the same as: “can i have music from a mediaplayer in my house without a mediaplayer”

the .py file and the yaml file together are the occusim app.

Good explanation Rene - for occusim you can safely comment the global line out

1 Like

Great thanks!