Calculate hours per day

I was wondering if you had some suggestions on the easiest way to calculate the total number of hours a machine is operated per 24 hour period? The data that I have available is total machine operating hours, analogous to an odometer in a car. This odometer is being sampled periodically throughout the day so it seems I would need to take the first sample of the day and the last sample of the Day and calculate the difference. How can I accomplish that in a workflow?

I will want to be doing that for each device in our fleet (thousands) independently.

Hi @paul_wareham,

We have an upcoming Platform Release that I think may assist in what you are doing here, I will update you on the functionality when it is released. :smile: I have a suggestion but I will also ask around and let you know if we come up with anything better or different. I would recommend making use of device tags and storing timestamps for the beginning of the day and end of day state report. You would have to do conditionals around this and it would likely happen in the workflow where you report state (if you have one) to determine when is the beginning of the day (likely the first timestamp of the day) and when is the last (this value would likely change with every new timestamp up until midnight). You could then lookup (on a timer, maybe at noon and midnight) the state from the timestamp, getting the odometer value from the end of day and beginning of the day and doing a comparison, resulting in the amount of time it was running that day.

Now that I type it out, it’s a bit long winded, and I still think time problems are the hardest to do :sweat_smile: I am going to ask around with our engineers as I am sure some of them have had this problem and see what they suggest! I will follow up shortly :smile:

Thanks,
Julia

Hi Julia

So let me see if I understand your suggestion. The device tags would be used to store two fixed values, one timestamp what is the beginning of the day for the device and another for the end. This would be based on, day the time zone of the device.

Then we compare those values, using a workflow, to the current time as we are reporting device date. When we report state we would report on attributes for the odometer of the first state update and then keep updating the odometer reading for the end of the day until we reach the actual end of the day at which point we do the subtraction to to find the difference.

Does that sound right? It is hard to explain. Perhaps a quick example might be helpful if you think we are not on the same page :slight_smile:

Thanks
Paul

Hi

I am tracking hours of utilization per day (running hour meter) on a non metered asset.

We are sampling every 3 seconds a binary running state.

On each trigger of a workflow (device state) we get the interval (3secs, and the run state) and if it ran in the 3 second period add that many seconds to a device specific storage value.

Then each day we run a workflow that gets the min and max seconds for the 24 hour period to get a reasonably accurate run hours for the day. (our gear isn’t turning on / off rapidly /frequently).

Most of our kit has Meters, but we have a string of pumps off a single controller (which only tracks a single running state, not 4 individual states/meter)

This seems to work quite well.

T

2 Likes

@JuliaKempf you were referring to the new date/time node yes? :slight_smile:

Yes, @paul_wareham, I was indeed! :smile:

Hi @JuliaKempf

After talking to your team, I was wondering if you had any further thoughts on this application?

I’ve tried a few approaches and it is surprising how complex it gets once you get into it.

The other issue we have is dealing with multiple times zones where the timing of first report of the day and the last report of the day should be different relative to a fixed time zone. That we reminds me that we are also looking for an elegant way to manage time zones in Experience pages, alerts, and reporting. Perhaps I should do a separate post on that. Mimicking moment.js Timezone would be awesome.

Just thought you might have some additional perspective upon reflection?

Thanks

Paul