Announcement - AppDaemon 3.0!

Third party integrations AppDaemon
81

Thanks for all whoever put effort in making AppDaemon more awesome. I couldn’t live without it anymore.

My Lights system alone is over 400 lines by now!

82

You’re welcome :wink:

83

Hi All,

Just want to say a big thanks to all who have made this a fantastic product, after reading excellent instructions and a few tweaks to the code have successfully transitioned to 3.0.1!

So thanks again.

Rob.

2 Likes
84

@aimc - any updates on this issue? I probably see this about half the time that I do a save - need to do multiple saves for my changes to be noticed when editing.

Thanks!

85

dont save so much :wink:
i think it has something to do with the moment you save (depending on on which point AD is in the reading loop)
i have it sometimes too. but not that much.
i think that has to do with speeddifference (RPI with SD versus beebox with SDD)

86

I have tried to reproduce this and didn’t have any success, so I suspect Rene may be right.

87

I’m sorry to say, but I have been suffering from the phenomenon of AD not noticing app changes and thus reloading them upon change for quite some time (versions) now.
Running on Pi, editing using WINSCP on Windows.
AD NEVER notices anything (be it py or yaml), and thus forces me to manually restart after every change and for every test, costing me each time close to 2 minutes :unamused:

88

there is one other thing i can think off.

saving a file that is modified is actually:

  1. removing existing file
  2. saving the new file

depending on how a program handles that, and the speed that that is done there can be a short timeframe that the file doesnt exist.
with slow editing programs, slow connections (in case from working on another device) or slower devices, that timeframe can be bigger.
AD checks every second if the file is changed or deleted.
so if the timeframe is to long on the wrong moment AD deletes the file where it should reload it.
the second later AD finds the file again and loads it again.

but it seems that at that point it finds a cashed file and not the new one. (dont know what can cause that)

maybe if the deletion from a file would be delayed for 1 or more seconds the problem would be gone.
for example if a time is added to the deleted_modules list and only delete when more the 2 seconds old
in the terminate function.
and in the found new file part look if it is in the deleted_modules list, if so remove from the list and reload.

the other option is off course checking what the difference is between reloading and loading.
why does the loading not take the new file, but a cashed file.

89

thats a complete other issue and for certain not what others experience.
what version are you running now?
is there no mention from a change in the logs at all?

i also use winscp on windows, so thats not the problem.

90

Running the latest and greatest version of AD (and of Hass, for that matter), but as I said : this has been going on for quite some time, so with a number of (beta) versions as well as with the current final version. I do remember a time when this worked, although I cannot vouch for it working ALL the time then.
And no, the log shows nada.
Just my humble opinion, but I think the app change tracking mechanism is flawed somehow …

91

did you try uninstalling and reinstalling AD?
the app change mechanism might have (had) some small problems, but you are the first i hear from that it isnt working at all.
you dont have a specific setup, so there must be something wrong at your side. (so lets figure out what)

92

For me this began with AD version 3.0. I went from 100% working to the current flakiness of sometimes changes are seen and sometimes not. I can always get around this situation by doing multiple writes (I am using vi on the same virtual machine that has HASS and AD installed) - eventually AD sees the change. When I see unloading instead of reloading, I know there’s an issue. I then just keep hitting write until I see the reload.

1 Like
93

but you always see something in the logs, like everyone else.
thats why i know that there must be something else wrong for @pav

but i think i might have found where the difference in loading and reloading is and where it might go wrong.
ill talk with andrew if he sees it my way and what can be done.

at least you helped pinpointing it.

1 Like
94

@eBoon - with the assistance @ReneTode I reproduced the issue and I think I have fixed it.

What you will see in the corrected version is still that the file is removed, but it will be picked up a second later, re-added and the changes will be honored. The removed message is unavoidable if as we suspect this is just due to the file being searched for when it is in the middle of being deleted and recreated. At least this way you just need to wait a second more and the change will be picked up.

This will be in version 3.0.2.

@pav - it seems like your issue is different.

3 Likes
95

Awesome! Thank you both @aimc @ReneTode

1 Like
96

In terms of un- and re-installing AD I recently bit the bullet and installed AD in its own venv (iso in Hass’s), not specifically to maybe get rid of this annoying problem but merely because of it being a cleaner setup. I did not notice any before/after changes for better or worse in anything though. Apart from that, my setup is as plain vanilla as they come, ie Hassbian on Pi3 …
Anyway, as @aimc is cooking a new version with some changes in this area, I will patiently wait and see what gives …

97

that wont change anything in your case.
its just a minor change, but you dont even see the changes in the log and on that part nothing changes.
please humor me.

add this app to your apps directory as test.py

import appdaemon.plugins.hass.hassapi as hass
class test(hass.Hass):

  def initialize(self):
    self.log("test app is initialised")
    self.log(self.args["variabele"])

with this yaml file:

testapp:
  class: test
  module test
  variabele: "testrun 1"

clear your appdaemon log and restart appdaemon.
after that change the value from the variabele
after that change the first log text in the py code
then save your log and show it here.

if really nothing is there then please start AD manually in debug mode and do the same.

98

Sorry for not getting back sooner, Rene - but I think I cracked it.
I’m not sure which of two things exactly made the problem go away (at least for now), but today I cleared all contents of the pycache folder AND I moved a folder containing some wip-apps and alternative versions of some apps away from under the appdaemon folder - because I started wondering whether AD was not getting confused by their presence.
And lo’ and behold, AD started working again as advertised, so I’m good !
Thx for chiming in though …

99

glad you got it working.
i knew that it was somehow specific for your situation.
if the folder with alternative versions contained files with the same names and classes in it, you would probably have had more problems.

an app can only have 1 code file and when you have more of the same AD doesnt know which one to take and probably will take the one he sees last.
if you then change the first it wont do anything because AD doesnt know its an app.

100

I just upgraded HA to 0.68.1 and then tried to upgrade AppDaemon from 3.0.0 to 3.0.1.
Last line of the install ends up being this:
homeassistant 0.68.1 has requirement aiohttp==3.1.3, but you'll have aiohttp 2.3.10 which is incompatible.

Despite this I tried to run appdaemon using the command I’ve always used
appdaemon -c conf

This get stuck here:

2018-05-03 19:21:09.023211 INFO AppDaemon Version 3.0.1 starting 2018-05-03 19:21:09.023449 INFO Configuration read from: conf/appdaemon.yaml

With the python process pegged at 100%

Any ideas?