Can someone give me a hint how to build an analysis that will give a machine-by-machine state overview? Similar to what you get when using the widgets but without using them?
X-axis: % of total time
Y-axis: The different machines of the given type
I saw something similar in some of the movie clips but I just cannot figure out how to reproduce them.
The best I was able to do was a chart that would only sum the state changes that have occurred until that time cutoff. But then the chart is obviously incomplete.
Hi @sebme - I have a request out internally to get you some advice here. In the meantime, where did you see this in the movie clips? Was it a Tulip University of Library video?
But it seems to reference a table rather than a machine trail and there is no mentioning how to set it up they way it intended. On the API page I only see these archive links that are terribly complicated to parse.
There are a couple ways you can accomplish this, depending on what you’re looking for. Here are two suggestions.
Total Durations, Stacked
First, you’ll want to declare your grouping, since you’re looking for machines on the X in your graphic, let’s add that. You can also add your machine state as a grouping here, we’ll use that as the ‘compare by field’.
Now, you can simply plug in the sum of your duration as the Y by setting it as an operation.
Now, the previous method gets you to a dynamic view of your total durations, but I see you mentioned you’re interested in making this out as a percentage. Unfortunately, the analysis editor for machines currently can’t support a dynamically referencing expression function. Intuitively, something like SUM(DynamicStateDuration) / SUM(TotalDuration) makes total sense, but the DynamicStateDuration isn’t able to be referenced in this way.
If you want to get around this, you’ll need to explicit tell the analysis what operations you want. I’ll also note that this option is really only necessary if you have more than two states you’re monitoring. If there’s only two, you should be able to use something fairly close to the top option with percent where true operators. However, let’s assume you’ve got at least three. In this case, you can explicitly state the desired calculations, similar to below.
@BrianHaselton thank you for the suggested approaches. The key problem here is that all those methods you suggest only capture either the start- or the end state at a certain point in time. For a true picture, you will need to truncate that data, e.g. if a machine state is crossing the day barrier to the next day. Otherwise the states are not counted in the right periods of time.
Support has now suggested to apply a workaround that triggers a state change every 3600s (or one hour). This will artificially truncate the state. The residual error will go down to just a few seconds which is neglectable. The key here is for this to work you need to artificially change to a fake state and then immediately back to the current real state.
Definitely. The granularity loss of the current state can be a big issue for reading accurate data. Refresh states are a good workaround to this.
I do find that depending on the application set, it can sometimes be optimal to model your state data collection into standard Tulip tables in a status history table, rather than the machine activity history. This may not be feasible for every machine connection use case, but I generally recommend it for increased flexibility and granularity when it can be used.
The other option I’ve seen thrown around a bit is using automations to funnel machine information into standard tables. However, it is not immediately clear what the automations pricing model is, so I would not yet advise for or against this method until that information is available.
I believe there are a few great feature requests for the machine data pipeline based on this conversation to improve the overall machine data experience.
