Calling run_in to turn off/on variable switch

Third party integrations AppDaemon
1

Hello everyone,
I am in the process of writing my first Python script. I decided to create an app that monitors various sources of weather info and then decide to water my plants or not. I have two sprinkler systems that I can activate through zwave Fibaro switch. For this purpose I have written below subfunctions, which work but I am not happy with the design. The first function is called whenever the main function thinks it’s time to water (this is checked at sunrise).

def activateWater(self,waterSystem,minutes=2):
print(f’Supposed to activate {waterSystem} now, and deactivate in {minutes} minutes’)
self.systemToOperate = waterSystem
self.turn_on(waterSystem)
self.run_in(self.deactivateWater, int(minutes*60))

def deactivateWater(self,kwargs):
self.turn_off(self.systemToOperate)

Is there a better way without use of global variable? I don’t want to write one sub function for each sprinkler either. Since I have two valves to activate, I will need to expand the main function to activate each system with some delay.

2

i think you should read some info about how apps work, so you know how to build them.
i wrote AD for beginners for that.
when you read that you can apply that on your system to avoid writing things several times the same way.

i remark already:
use self.log instead of print

and also reading the docs can help you a lot:

http://appdaemon.readthedocs.io/en/latest/APPGUIDE.html

3

Thanks, that solved it. I did this:

self.run_in(self.deactivateWater, int(minutes*60), switchToOperate = waterSystem)

def deactivateWater(self,kwargs):
self.turn_off(kwargs[“switchToOperate”])

It just surprised me that whenever someone asked how to do this before, they were pointed at solutions where you have to write separate functions for each light. Like this one for instance.

The reason I use print instead of self.log, is that when I run my app with -d to demonise appdaemon, then my apps don’t do anything. If I run the same app without -d then it works perfectly, so I run appdaemon with nohup and forward the output to a separate logfile with “>”. Perhaps it’s not the best way of doing it, but it worked.

4

It is normal to run appdaemon as a systemd service. What kind of os are you running on?

5

Ubuntu server, I am using init.d for autostart, not systemd. I haven’t gotten around to running it at boot yet (since I basically never reboot my machine), but it’s on my todo list.

6

in your appdaemon.yaml you can set the place where your logging goes like this:

log:
  accessfile: /complete/path/to/appdaemon_dashboard.log
  errorfile: /complete/path/to/appdaemon_error.log
  logfile: /complete/path/to/appdaemon_normal.log
  diagfile:  /complete/path/to/appdaemon_diag.log

self.log then goes to your logfile.
if you use STDOUT it goes to the terminal screen when you dont use deamonize.

7

Thanks, I had three of them, but not the diagfile. However, if I demonise, it won’t actually switch switches or turn on lights, but the exact same program does it if I don’t demonise. The only difference is the “-d”. I figured demonisation was broken and stopped using it, but perhaps something else is wrong. Perhaps because I’m running two appdaemons (one with and one without -d), even though threads is 10.

8

i actually never used deamonise.

are both instances from AD in seperate venvs?
or do you have just 1 time ad installed and started it twice?

and why and how do you use 2 times AD? just out of curiosity.

9

I only have one venv and start it twice. I have two apps in my apps.yaml, one runs every sunrise (handles actual watering and weather check), and the second is a test app that just runs on start (to check SQLite query or turn on/off switches). Then I run two instances of AppDaemon so that one can keep running in the background and the other I only start and then kill to test things in my test app. They both utilise the same helper subfunctions so that updates in the helper app applies to both.
Perhaps there are other ways to keep a test app. Of course I realise the first AppDaemon will also run my test app when I save the file, but it’s easier to see what happens when you directly control when it starts and can follow the log.

10

starting appdaemon twice and using the same configuration dir is an absolute terrible idea and doesnt bring you anything.

in that case your apps are running twice at the same time and that is asking for trouble.
appdaemon picks up every change you make in a test app immediatly.
so in your case both instances will pick up the change.
they will both try to write to the logs the same time too.

when you dont want to play around in your live environment i suggest 2x a venv with AD and 2x a configuration dir. in 1 the live apps and in the other the test apps.

but i just run 1 instance from AD, have a seperate subdir in my apps dir called test apps.
everything i change there just runs the second i save it.

you only risk to blow up your running AD instance when you do really terrible stuff.
but then you stop and start the service again. (and for sure when you only have active apps around sunrise.)

11

Of course you are right, except laziness it’s also since I do most of my editing by iPhone/iPad so when I save I can’t have a separate terminal up. I will improve :slight_smile:

1 Like