Hi,
I think you’re right that transaction groups would be the easiest way to go. We need to beef up our tag history query capabilities over time, and SUM definitely needs to be added soon.
With groups, you have a few options:
- You can do exactly what you had in mind: log every second, query with SUM(), maybe set the group(s) to delete after 1 month or something.
- Items in groups can actually be “Hour Meters”, which are pretty much what you want. You take your on/off tag, set its data type to float (or int), and set it to be an hourmeter “on 1”. While the tag is 1, it will accumulate value (the group can run at any rate). When it goes to 0, it will reset or not, depending on whether it’s “retentive”. With 7.5, there’s an additional option for when to reset the value. So, instead of logging history and calculating a sum, you could have hourmeters set up to record to the last row of a table. If you want to really get tricky, have the group set up as “bi-dir, db wins”. Then, you can just insert a new row with 0s in the columns to reset the values and start over (for shifts, or per day, for example).
Now, for your group questions:
- Overhead for logging probably won’t affect your device communication much. You already have the items subscribed elsewhere, so it won’t be a big deal.
- You can definitely have 200 groups, though I prefer to minimize the number of groups when possible, as it can get a tad cumbersome to work with so many. But, 200 isn’t too bad, 1000 is rough. Still, if you have 200 motors, it would probably just be better to make a “motor_runtime” group with 200 columns.
- You can definitely just add new items to a group. It will just add the columns onto the table for you.
Hope this helps,