Passing configuration from AppDaemon Config file

Third party integrations AppDaemon
1

A while back in one of my earlier posts, I was cautioned against bringing in python data structures from the appdaemon.cfg file. I’m trying to get my apps more in line with how AD would typically want them to be. But to do that I need to bring in a configuration information that tells the app how to process a certain room or light. If I shouldn’t bring a data structure (dictionary) in from the config file. How do I get the data to the application? Here is a draft of the data structure below.

targets={“light.overhead_light”:{“triggers”:{“light.overhead_light”:{“bit”:8,”onValue”:”on”},
                                             “device_tracker.scox0129_sc0129”:{“bit”:4,”onValue”:”home”},
                                             “media_player.sam_directv”:{“bit”:1,”onValue”:”playing”},
                                             “sensor.sam_motion”:{“bit”:2,”onValue”:8},
                                             “input_boolean.samishomeoverride”:{“bit”:16,”onValue”:”on”}},
                                 “type”:”light”,
                                 “onState”:[11,12,13,14,15,16,27,28,29,30,31,32],
                                 “callback”:self.light_state_handler},
         “light.sam_fan_switch”:{“triggers”:{“light.sam_fan_switch”:{“bit”:1,”onValue”:”on”},
                                             “sensor.sam_temperature”:{“bit”:2,”onValue”:self.check_temp},
                                             “input_boolean.samishomeoverride”:{“bit”:4,”onValue”:”on”},
                                             “device_tracker.scox0129_sc0129”:{“bit”:8,”onValue”:”home”}}
                                 “type”:”fan”,
                                 “onState”:[11,12,13,14,15,16,27,28,29,30,31,32],
                                 “callback”:self.fan_state_handler}
}
2

Sit tight - in the next beta I am introducing YAML config as an alternative to the cfg file - this will allow you to supply arbitrarily complex data structures as parameters to apps

1 Like
3

Ok,
You realize I’m talking about normal AD not the Dash. Right?

4

yeah he means AD.

1 Like
5

Yep, and i’m including a conversion tool as well.

6

Awesome, that sounds good. Also welcome back. :slight_smile:

7

Thanks but I’m not back yet - just had a little downtime and snuck back to my hotel room to catch back up with HASS developments :slight_smile:

1 Like
8

You could also load from a JSON or pickle file. This would be done during the app initialize section. It does introduce “another config file” into the mix, but it really comes down to what you’re most comfortable with.

9

What I would really like is a database. LOL I’ll get to that one-day.

10

all you need to do is install a db server.
you can also let HA write its data to it.

11

Already doing that. I just have to figure out the python syntax and decide on the schema structure. It’s just not at the top of my priority list right now. Dictionaries are easy for me to understand so they work for now. The scary part is that once I get a database integrated into my code, I will probably move back toward one app controlling everything since right now my dictionaries include all the information on what to do based on different inputs.

12

i will move my config to a db in the near future also.

what i have planned is to put some extra fields in the records.
for instance:

  1. which app has effect on the entity
  2. which app can use the entity in its initialize
  3. treestructurelevel (devicetype,area,subarea,entity)
  4. …

i Always try to split part up. just like i have a seperate file for each entity in the dashboards and a seperate dashboardfile with only the layout.
building trees makes it possible to see clearer.

13

Exactly,
Most of that is what I have in my dictionary now. Maybe I’ll start working on the schema this weekend. It’s supposed to be raining here so I won’t be able to get any yardwork done. :wink: :slight_smile:

14

i dont like dicts :wink:
i rather have old fashioned connected tables.
i cant see through complex data structures when they are put in a dict.

i am not really able to query a dict in every direction.

if i implement a new app i just want to be able to add something like this to my db:

table app_entity_connection
  new_app, entity.a
  new_app, entity.b
  new_app, entity.c
...
15

Agreed, a database will be a major step forward. But I guess it’s my warped coding style, but Dictionaries just make sense to me.

1 Like
16

I’m more than happy to build some DB stuff into AD as I think it could add a lot of value. I’d be interested to see what folks would want.

If nothing else, I want to make it easy to access the HASS DB from AD to avoid duplication of data.

2 Likes
17

My database background is in Oracle so forgive me if some of the concepts don’t transfer to mySql correctly, but hopefully what I am saying will make sense.

  1. Any access to the HA database needs to be through an API. We should not have direct access to their database. If it’s updated the API should be updated along with it. Also we don’t want our fingers in there if something goes boom and our code is accessing it.
  2. The same goes for any AD specific tables. These should only be available to us through API calls. The last thing let’s call us 3rd layer programmers should be doing is updating data in the levels above us.
  3. We should create any schemas/users in our databases separate from HA and AD users, again so we can do things without potentially stepping on AD or HA.
  4. The interface should be through some type of ODBC like interface allowing us to use whatever database backend we want.

As for functions

  1. Ability to open/close a database based on a connect string
  2. ability to run free form queries and bring back dictionaries (or at least JSON data). (yes Dictionaries Rene. :slight_smile: :slight_smile: ) That way the column name (key) is associated with the column data (values). The good thing is you probably won’t have to deal with dictionaries inside of dictionaries. But if mysql supports multivalued fields, you may have lists embedded in dictionaries.
  3. functionality to allow, insert, update and delete of data. (in some DB’s these are not something you can do through a free form sql query).
  4. if it’s not supported by the free form queries, we also need to be able to do some database schema changes through it, like creating/modify/delete tables, and other database objects.

I’m sure there is more, but that’s a start.

1 Like
18

When you are ready to start on it, if you need someone to help let me know.

19

i dont see why i shouldnt be able to manipulate the HA db.
its something i would want to be doing.

I dont know what you would call AD specific tables.

the parts i would like:

  1. possibilities to query the HA db easy with mysql type querys (perhaps some default query’s as functions
  2. possibilitie to create/read/delete/query tables
  3. maybe the option to use another platform then HA is running on, allthough i think i wouldnt use 2 kind of db programs

i dont need data ported to dicts if i can query right, then the query is a dict.

i think about some basic functions:
connect(dbname)
create_table(something)
list_from_values(table,field)
add_record(table,kwargs)
find_record(table,kwargs)
…

20

What would you want to Add, Update or Delete in the HA tables? To my understanding they are primarily history anyway.
If all you want to do is select (query) data from the HA tables, then it’s better to do it using an API that has been written to provide the information. If you dont know and understand the table relationships in a schema, you stand a chance of joining tables together incorrectly and not getting correct information. Using a Common API to get to that data ensures that we are all getting the same expected results.
We have talked in the past about maintaining information like where an event got pushed onto the stack from, there are other things that in the future we may want to track at the AD level. I can’t really think of any at the moment, but just setting the expectation. Again there that Andrew would know how the tables should be joined. And in going with the some of the reasoning that was given recently when I broached the subject of object oriented libraries, it needs to be done in a way where someone just learning can access the data.
I agree with the parts you listed. The differences there were mostly semantic.
Data from queries may be one row or many rows. Give me the name of the primary light in the bedroom may only return one row, but give me all of the lights in the bedroom could return many rows. If it’s a dataset, meaning multiple rows, returned, then you could retrieve it one line at a time, or you may want to bring it all into a local data structure for further analysis.

Adding functions like you have shown are not as simple to implement as you might think. for example find_record assumes an understanding of the table structures of the database and how they are joined together. And since table names, structures, and relationships would probably be different from program to program, that is something that would likely have to be developed by each person individually. Make sense??