Hello,
My end goal is to find the closing reading at the end of a month.
I have tried the system.tag.queryTagCalculations and system.tag.queryTagHistory functions. I know system.tag.queryTagCalculations will not return the 't_stamp' along with the calculation. The 't_stamp' returned using system.tag.queryTagHistory is always returning the first day of the month at noon (ex. 10/01 12:00).
october_1 = system.tag.queryTagCalculations(paths=[path], calculations=['Maximum'], startDate=start_1, endDate=end_1)
october_1_value = october_1.getValueAt(0,1)
october_2 = system.tag.queryTagHistory(paths=[path], startDate=start_1, endDate=end_1, returnSize=1, aggregationMode="Maximum", returnFormat='Wide')
october_2_timestamp = october_2.getValueAt(0,0)
october_2_formatted_timestamp = system.date.format(october_2_timestamp, "MM/dd hh:mm")
october_2_value = october_2.getValueAt(0,1)
I see if I make 'returnSize' bigger than 1 then I can get other 't_stamp' values to be returned but I am not sure how large to make 'returnSize'.
Is there something simple I am bypassing here?
I'm not super comfortable with the history query functions, they're... weird. Or rather, they often return unexpected results.
But you should probably remove the aggregationMode parameter, if what you want is the last record of the month.
Another approach would be to skip the built-in functions entirely and go straight for the database.
Even if you end up using the queryTagHistory function, because that's probably the way to go, it can help you validate the results (I often check the tables directly to make sure the functions aren't messing with me.)
You can find the right partition in the sqlth_partitions table, by checking that the last day of the month is between the partition's start_time and end_time.
Then go fetch the record from that partition.
I know it may sound weird going through that trouble, because it seems obvious that passing the first and last day of the month as a parameter to queryTagHistory then grabbing the last record returned should be enough, but I've just seen to much weird stuff with that function that I don't trust it blindly anymore.
Thank you for your thoughts. I had considered skipping the built-in functions but I was hesitant because it would require extra code by scanning the 'sqlth_drv' table, retrieving the proper 'tagid', and then correctly constructing the table name that houses the data (ex. 'sqlt_data_2202410').
This is also easy to do in python.
You don't have to build it, you can fetch it from the sqlth_partitions table.
Thanks again for your input. I was able to grab the tags and timestamps for the report.
A bit of coding was required because tags are spread among different drives.
I had to fetch a tag from a custom database table, find which drive the tag is stored within which helps with knowing the partition.