I have a number of state trails configured to track the status of machines, running or stopped based on inputs from the machine for every minute. if count is more than 1, then running and if not stopped. that is working perfectly fine. However, although i have initiated the flow for all the lines at the same, time, the start time of the statetrail is differing over period. the end line is always same, (the current time). the period value in the state trail are also same for all. i have copied one trail and just wired them to different inputs so the configuration of all the trails are exactly the same.
The oldest value is the timestamp which satisfies the period rule - "is younger than latest input timestamp minus the period". The state from where the left-most timestamp is taken is is actually the next one. Oldest is rendered as past and fades out to the left.
So the scale is not current time minus period.
Combining similar states produce states with different duration, depending on the input. When some state gets removed as "too old" the next one which will represent the oldest (fades out to the left) may have different duration thus the timestamp of the first state is different for each widget.
You may say that this makes the widget pretty useless for your case, and that is true. This widget is targeted to represent state changes of single process over the time. To compare processes, takes different tool - with some kind of multi-line representation of the data.
Thanks for the explanation.
I will continue to keep this widget. Its wonderfully done, I will live with the inconsistency of start time,
is there a way to logically feed the live data into the state_trail node to keep the start time constant for many nodes ?
btw, Will be eagerly waiting for you to update the next version with multiple lines in a single state_trail.
One way I can think, not absolutely sure but you can try ...
If you have state change event on one machine, send it to the chart. Same time also send last known state for all others. Then they have similar timestamps from where the oldest to throw away is same for all.
As you are using the "combine similar states" this does not harm the performance too much, just the amount of messages sent over the socket increases.
Well, the performance is one big obstacle which holds it back. I'm not sure if low end machines can handle the amount of data moving around if you use the widget. Even for single line and long periods the performance drop can be recognized so this current solution can not be just converted to be multi-line. Must be something smarter...
