Here is something that might be helpful.
You have a date and a time for your events. In Access, a date/time variable is actually a "typecast" (alternative viewpoint) of a DOUBLE variable, where the value of a date is just the number of days and fractions thereof between the calendar date and the program reference date, which is midnight of either 1-Jan-1900 or 31-Dec-1899. Excel uses one of those, Access uses the other, Windows itself matches one of those two. I have to admit I can never remember which date is used by which facility. But I digress....
To do a computation of how long something has been in a particular state, you could do this: Make a table of the devices. (I'm sure you already have this.) Then make a child table of device transitions from one state to the next. (I.e. device X was off and was switched on at this date/time.) This has a FK to your device record and a date field and a state field. Whether the state is itself a code from a table of legitimate states is up to you. This transitions table might have other operational data if needed, like names if you needed to know who changed the device state, or stuff like that.
I propose that you add one more field, a DOUBLE, to that table for your state-time accumulation. If you have a DOUBLE variable in the table of transitions, you can compute the time something was in state X by finding each record that shows something went INTO state X and then finding the next transition to see the time when it LEFT state X - and store the elapsed time into the "Entering X" record. (Or the LEAVING record, your choice.)
There are those who would say you should not store this difference since it is easily computable, but I'm being more of a pragmatist here. By storing the amount of time in state X for device Y, you can then treat this as an "Inventory" type of question by summing the elapsed time counters for each state for each device. Do an "ORDER BY" on device first, state next, and compute running sums across the device transitions. THAT is a trivial exercise compared to the continuous re-computation of state-times.
The last part of this is the display of the elapsed times, which are not really dates at this point (because of the typecast to DOUBLE). You can do a "FormatDateTime" function in which you give it an elapsed-time type of template rather than a named time format. Use "hhhh:nn:ss" on the reversed typecast: CDate(DOUBLE) is treated as a time, so the format will work on your individual or summed elapsed-time fields.
You could also do this: Take that raw double in a query where you multiply the field by 24 for display purposes, and show it with a fixed number of decimal places using a numeric Format$ call. That would give you the hours and fractions in a particular state if you want time that way.
In case you were wondering, your DOUBLE variable offers up enough bits for about 55 bits of precision in its mantissa. We are only about 42,300 days (give or take a couple) from the reference date, so the date part fits comfortably in 16 bits = 65536 days, and will continue to fit in 16 bits until about June of 2079.
Take out the 16 bits for the date from 55 bits in total. That leaves us with 39 bits of precision for fractions of a day. One day is 86400 seconds which fits into 17 bits (= 131,072 seconds.) That leaves us 22 bits for the mantissa, which is enough for storing time to the microsecond. (You need only 20 of those bits bits to store numbers from 0 to 999,999.)
Anyway, to store elapsed times to a second for a single device, we will need to look at numbers representing times to about 33 bits. A SINGLE isn't that precise - but a DOUBLE is. Further, there are enough bits left over in that DOUBLE to assure no significant round-off errors or loss of precision in the number of seconds. That ought to be good enough for tracking your state-times to the second.
