i want to be able to delete all recrd from an entity i am not using anymore, or i want to be able to correct values from a temperaturesensor if i found out it has been 1 degree to high for a certain period of time.
a want to be able to add data from dbs i have from the past
and i can think of many other things why i like to manipulate the HA db.
(by the way i have it not recording at this moment, just because almost all data was worthless for me)
a find_record function can be more simple then you think.
you make a query on a table(which name you give) and in the kwargs you give the selection criteria.
could even be:
find_record(query,criteria)
where you could give a complex selectquery if you like or just a table, in the criteria you give the where statements from a select query.
so this:
test = find_records("table sensors","livingroom=23,4")
It’s fine for single tables. But how about something like this.
Select objects.object_name,
thermostats.min,
thermostats.max,
locations.floor,
locations.room
from objects, locations, thermostats
where objects.object_type="thermostat"
and objects.object_name=thermostats.name
and object.location=locations.location
This is what I’m talking about when I say a “free form query”.
I hadn’t thought about manipulating history. In my world, that would get me thrown in jail by the FDA. First I would recommend you not do that, but that may be my fear of the FDA talking. Secondly, you have at least two different types of databases with HA. Some people use the standard default one, others have migrated to mysql or something else. If HA made changes to their data structure, your code would break until you could figure out what changed and update it. I just know that from experience, when you start messing with the data associated with a 3rd party application (which from an AD perspective HA is a 3rd party app), the supportability of the application goes down hill quickly and the maintenance requirements on you go up exponentially. The best model I can describe for this is SAP. You don’t change SAP core code or SAP just says, “thanks for calling and hangs up”. You use the extension languages provided with SAP to attach through provided user exits to extend the functionality of the system.
But in the end, that function could certainly be provided. Just use at your own risk.
test= find_records("objects,locations,thermostats",object.object_type='thermostat' and objects.object_name=thermostatsname and objectlocation=locations.location")
and a function doesnt Always need to give an answer to every question.
it could be that find_records only works for single tables and for the other parts you could use do_query
manipulating history is not a problem at all.
you record the history you want by includes and excludes in the last few versions from HA.
i dont even have history recorded at all since quite some time now.
my history is collected in some files i created myself.
history is not a core part from HA at all.
you Always get risk that things will break. every update from HA there are breaking changes. and some of them may also effect AD. thats just the way it is.
i would love it if the devs from HA would change to another update system.
HA core and HA components seperate.
then you could add a single new component without updating everything and breaking things that work alright.
Ok, looks like we are going the same place. I think the idea of giving two methods to do this is good. The find_records method will be confusing to people who have grown up with relational databases. But the do_query method could be overwhelming for people who don’t know databases well.
I agree completely, that would be nice. I just think we should be cautious uncontrolled access into HA’s database. I don’t know what all is in there now, or what may be in there in the future. I would like to hope that maybe in the future they would load the group’s, etc in there so that they can be changed dynamically without having to reload the groups file (although that is much better than having to restart HA anytime we made a group change).
