In order to run appdaemon need to prefix the command line with sudo. Is this a problem?
It runs fine with sudo prefix, but any changes made to the module whilst appdaemon is running cause the following error to be reported:
“You must only call this once per program run. This is a fatal error. Please fix your code.”
resulting in appdaemon stopping and returning to the command line.
Cause as I understand is due to any change made within the py module forces AD to reload the module.
In order to resolve this issue, the following code: wiringpi.wiringPiSetupGpio() can only be called once.
My only other option whilst in the development mode once appdaemon has started, to # out the above.
Any suggestion appreciated.
Current code within my module as follows:
import appdaemon.appapi as appapi
You don’t need to do this in general but if it has to run as root for wiringpi it shouldn’t be an issue.
The way Apps are designed, they have to be able to be reloaded at any time and reconstruct their state, that is pretty fundamental to the way it works.
In order to avoid calling this multiple times per AppDaemon run you could maybe use a an entry in the global dictionary to note that you have called it already and then only call it if the entry was absent.
is there a close function from the wiringpi?
if yes then you could set the close function in the terminate function if i am correct.
that way, if the app closes, also the wiringpi closes and restart wouldnt give a problem anymore.
That’s the basic idea. I’m away from my desktop at the moment but look in the he API docs for the section called “Sharing information between apps”. Any value in global_vars will survive an app restart.
This may be wandering a little off topic here, but it’s kind of related. The depends argument in the config file would make sure the app is up and running and would keep it from being loaded twice. RIght? Also, I’ve been trying to watch for this, but there are to many messages in the log for me to follow it completely. on a Hass restart, do the apps load in the order they are in the config file?
i dont know if @aimc did set it up that way.
as i understood it, it is that if you use the dependency, then will both apps be restarted if you change something in 1. (or actually just the top app)
i didnt mention it because restarting the general app is just what we would like to avoid.
i think that the apps start in order from the config, but in different threads, so actually they start simultaniously. making that the fastest app will be completely started first.
it would be nice if we could give a startorder and delay for apps, but havent asked about that (yet)
The dependencies are enforced at startup time and also if an app is modified that others depend on.
It’s up to you to decide if an App is “running” - its hard to say what that means.
If an app fails compilation, the object will not exist and your other apps will get errors trying to access it. If you then fix the error, AppDaemon will reload the Original App as well as the dependant apps and it should all work.