AppDaemon Q&A

Yes, that should work as long as you aren’t using global for anything else.

1 Like

probably i oversee something (again) but

File "C:\Users\rene\AppData\Roaming\.homeassistant\apps\minutely.py", line 44
    for arglist in self.global:
                             ^
SyntaxError: invalid syntax

and

  File "C:\Users\rene\AppData\Roaming\.homeassistant\apps\minutely.py", line 44
    global_args = self.global
                            ^
SyntaxError: invalid syntax

edit:

sel.global is self.global_vars :stuck_out_tongue:

1 Like

to bad that it doesnt work.

i only get back 64 vars.
all others are lost.
seems like there is a maximum set.

edit:

strange, strange, strange.
suddenly i thought: wy making everything global if i can read out the cfg with configparser myself.
i did that at the same place and counted if i got everything like i did before.
i only got 21 vars back.
and then suddenly they were all there.
nowhere any error or info why i only got it partly.

the only thing i can think of is that it has somthing to do with memoryspace?
but it shouldnt be possible that the code functions like it is correct when it isnt.

dont know what to think about this.

It’s a regular Python dictionary - there should be no limit on the number of entries. If the interpreter ran out of memory it would more likely crash! Not sure what is going on, but glad it worked in the end :slight_smile:

i really have no idea what was happening.
i keep checking now, but it seems that all keeps working.
i must say that the PC was running for 10 days in a row and i restarted it, because of those strange things.

by the way to get all vars out of the cfg in the global it is most easy to set in 1 init:

    global_args = configparser.ConfigParser()
    global_args.read('directory\appdaemon.cfg')
    self.global_vars['conf'] = global_args

from that moment on in every app i can use:

self.global_vars['conf']['any_app']['any_apps_var']

If you think that’s useful I can add it to the next version.

Wow, @ReneTode, that is awesome. Yeah, @aimc I would also find that useful as a built-in feature :smiley:

OK, I will add it :slight_smile:

1 Like

FWIW, you can get the args for any other App already:

someapp = self.get_app("SomeApp")
some_apps_args = someapp.args

I just thought of it - its a nicer way than adding them to global vars I think.

I can still make the entire list available though.

that is nice if you want something from 1 specific app.
but i would be harder to get everything from 1 module or 1 class.

and i dont want the args from 1 specific app hardcoded in my code unless it is a general app.
so then i need to add more args to read out the args from 1 module.

so if you can add a global var that contains the entire cfg that would be usefull i think.
that way we can also use the appdaemon section as super global section.

Yes, sounds like a good idea - especially the super global section :slight_smile:

1 Like

@aimc i was reading the api (again) and there is something which might be confusing.

the examples from listen_state:

# Listen for any state change and return the state attribute
self.handle = self.listen_state(self.all_state)

# Listen for any state change involving a light and return the state attribute
self.handle = self.listen_state(self.device, "light")

# Listen for a state change involving light.office1 and return the state attribute
self.handle = self.listen_state(self.entity, "light.office_1")

# Listen for a state change involving light.office1 and return the entire state as a dict
self.handle = self.listen_state(self.attr, "light.office_1", attribute = "all")

# Listen for a state change involving the brightness attribute of light.office1
self.handle = self.listen_state(self.attr, "light.office_1", attribute = "brightness")

# Listen for a state change involving light.office1 turning on and return the state attribute
self.handle = self.listen_state(self.entity, "light.office_1", new = "on")

# Listen for a state change involving light.office1 changing from brightness 100 to 200 and return the state attribute
self.handle = self.listen_state(self.entity, "light.office_1", old = "100", new = "200")

# Listen for a state change involving light.office1 changing to state on and remaining on for a minute
self.handle = self.listen_state(self.entity, "light.office_1", new = "on", duration = 60)

are maybe not as obvious as they seem.
you use different callback names in different examples, i think it would be less confusion if you put my_callback there.

so you get:

# Listen for any state change and return the state attribute
self.handle = self.listen_state(self.my_callback)

# Listen for any state change involving a light and return the state attribute
self.handle = self.listen_state(self.my_callback, "light")

# Listen for a state change involving light.office1 and return the state attribute
self.handle = self.listen_state(self.my_callback, "light.office_1")

# Listen for a state change involving light.office1 and return the entire state as a dict
self.handle = self.listen_state(self.my_callback, "light.office_1", attribute = "all")

# Listen for a state change involving the brightness attribute of light.office1
self.handle = self.listen_state(self.my_callback, "light.office_1", attribute = "brightness")

# Listen for a state change involving light.office1 turning on and return the state attribute
self.handle = self.listen_state(self.my_callback, "light.office_1", new = "on")

# Listen for a state change involving light.office1 changing from brightness 100 to 200 and return the state attribute
self.handle = self.listen_state(self.my_callback, "light.office_1", old = "100", new = "200")

# Listen for a state change involving light.office1 changing to state on and remaining on for a minute
self.handle = self.listen_state(self.my_callback, "light.office_1", new = "on", duration = 60)

i came upon that because i was looking up if i had it correct and the self.all_state almost confused me.

Sure thing - you know the answer - will be fixed in the next release :slight_smile:

1 Like

i have to do something to keep you busy :wink:

You are doing a great job! But I like your suggestions so it is all good :slight_smile:

1 Like

found another 2 issues:
after restarting HA i get a warning:

but after that everything goes on as expected.

something i cant figure out where its coming from is this error:

2016-09-08 02:54:54.829850 WARNING ------------------------------------------------------------
2016-09-08 02:54:55.049996 WARNING ------------------------------------------------------------
2016-09-08 02:54:55.050997 WARNING Unexpected error during process_message()
2016-09-08 02:54:55.051498 WARNING ------------------------------------------------------------
2016-09-08 02:54:55.052499 WARNING Traceback (most recent call last):
  File "c:\python34\lib\site-packages\appdaemon\appdaemon.py", line 550, in process_message
    process_state_change(data)
  File "c:\python34\lib\site-packages\appdaemon\appdaemon.py", line 524, in process_state_change
    check_and_disapatch(name, callback["function"], entity_id, cattribute, data['data']['new_state'], data['data']['old_state'], cold, cnew, callback["kwargs"])
  File "c:\python34\lib\site-packages\appdaemon\appdaemon.py", line 485, in check_and_disapatch
    dispatch_worker(name, {"name": name, "id": conf.objects[name]["id"], "type": "attr", "function": function, "attribute": attribute, "entity": entity, "new_state": new, "old_state": old, "kwargs": kwargs})
UnboundLocalError: local variable 'new' referenced before assignment

2016-09-08 02:54:55.052499 WARNING ------------------------------------------------------------

i get a few of those (amount changes) since i started trying to use:

self.listen_event(self.set_controle_objects, "ha_started")

and

self.listen_state(self.save_object_value)

at the moment i am not able to pinpoint where it is coming from.
i get several when restarting HA, but also some randomly after a while.

edit:
after deleting the listen_state it seems gone.
seems like he gets state changes which are not as expected.

I have fixed both of these in the dev version - I think the second one is actually a change in HA behavior, and is triggered usually when HA restarts. They should both be harmless errors. The fixes will be in the next release.

1 Like

I just did the simple install using the PIP option and when I launched it, it seems to hang up on me.

Here’s what it shows when I run it and no matter how long I wait, that is all that is shown on the screen

When I use cntrl+c, it then throws this error:

What am I doing wrong?

i think nothing is wrong, but it seems you have no apps written yet?
in the screen you only get info, warnings and/or errors out off youre active apps.
so without running apps it stays blank.

Yes, Rene is correct. When running from the command line you need to hit ctrl-c twice to exit. Add some apps and you should see log entries about them being loaded.