I’m playing with the database code for AD. In order to do this at least the first time, I need a run once setup type of program. How can I best run an app outside of the AD config file, but that uses the AD functions? Is there even a way? Do I need to make it a class like the other apps, or what?
If it needs to make use of AD stuff then it needs to be an App.I suggest you create an App that runs all the code in the initialize() function, run it once then comment it out in the config file.
If this is a common thing what would you need? A way to run a standalone program that could access AppDaemon state? Make calls into HASS?
Now we have the dashboard I have added ways of doing some of this that could be used in a standalone program, but I would want a better idea of the usecase.
If we do the database thing, people are going to need ways to create tables, and initially populate those tables. Putting that in an initialize function inside an app, seems like it could get rather large especially for something that should only run once. I guess it could be an app in the system that just doesn’t have any callbacks. But does that take up memory once it’s called by appdaemon? In my situation, I have a number of entities that my app will use. I want to load some information on those entities (different attributes, etc (not necessairly the values, but the names) so that I can set default values for the inside my database that the app will read. So I need access to get_state (so I can get a list of valid attributes), split_entity, entity_exists, those types of things to initialize the data for my app. Should it be in the initialize function for the app, I don’t know, it’s more app configuration that app initialization, if you know what I mean.
OK cool, that’s helpful.
So I could definitely write something that would do that, I could create a new version of the API that would call into AppDaemon, however, it sounds like everything you would want is available in HASS in the first place, so why not use HASS’ RESTful interface?
Lack of knowledge of it… 
I went ahead and put it in as a class for now. Just putting in code around the inserts and creates to catch errors which is probably a good thing anyway. There are two ways of approaching this I think.
- Just some helper functions around some of the standard DB functions and maybe some “db” versions of some of the standard AD calls. (db_entity_exists for example). The problem with that kind of thing is that you quickly end up having to rely on a specific database structure of have a database structure defined somewhere in the app that you can use in those calls to determine how to check and see if the entity exists in the database.
- Just document and give examples around the standard DB calls. The good thing here is that they are basically like dealing with a file. Just open, read (select), write (insert), etc. The bad part is having to have a working knowledge of sql.
What level of knowledge of SQL can we assume with these functions?
I would start by assuming that if someone knows they need a database, they would know how to use one 
Ok, fair enough. Then maybe we start with just some helper functions to get it setup.
db_connect()
db_select( query ) - returns a list (to maintain order) of dictionaries (column:data) pairs.
db_insert - again a list of dictionaries, this way they can insert one or more rows at once.
db_update - only one row here, but still a dictionary for the column:data pairs
db_delete - Key_id for the table. If you want to do multiple rows, do it with the execute function.
db_execute - sqlstring returns success or errorcode
those kind of things?
Another question.
for queries like selects where no rows are returned. As a psudo standard do we want to return None, or raise an error? I think most databases I have worked with raise an error that the developer has to deal with. The developer has to deal with it either way, either with an if block or a try/except block. I’m neutral. What would you like to see from an AD consistency perspective?
thats probably why lots of people use a speadsheet or a document where they should use a DB. DB’s frighten lots of people.
i think that its possible to give a set of functions that would give even those people access to DB functions, without any knowledge from DB or sql.
good queries which give back no data shouldnt raise an error in my opinion.
a query Always can return an empty record.
about populating a DB outside AD:
i wouldnt prefer that option.
the db_open does create a db if its not there.
i would like a same kind of option for table, so you could open it in an init if it exist, if not its created.
its also possible to point people to something like sqllitebrowser to fill record that they cant automate,
and for entities and atributes we could create an app that does that automaticly. (fist time collect, after that update)