Yes you are right ...
I would simply add to the readme page:
When no end time (or duration) is specified, a time slice:
Will run until the start of the next time slice.
Will run until eternity if no next time slice available.
When an end time (or duration) is available:
Gaps will occur when the endtime is before than the start time of the next time slice.
Overlaps will be removed when the end time is after the start time of the next time slice. The end time will become equal to the start time of the next time slice.
Indeed, we prefer that you develop this year 20 smaller nodes instead of only a single large one...
And all for free of course
Indeed I don't think an SVG/CSS wizard like hotnipi won't have much fun reusing existing components...
I assume you can only solve it by showing multiple lines below each other. But if nobody has real life (iot) use cases, then I would drop this functionality. Unless you want to be able to build a project planning tool in the Node-RED dashboard ...
Oh I'm definitely not the one. I'm an 25+ years ActionScript developer, if anybody even remembers what that was. Just trying to familiarize myself with technologies the world accepts for today
But OK, I'v got something to think about. (which I tend to spend more time than coding the stuff)
I have found some strange behaviors using the node. I use it in my dashboard to visualize the state of a door. I use a full 24 hours as the interval that is being shown. What I noticed is that the time marks and the state representations are not being shown correctly. It works for the first few hours but the longer the time frame is that the graph represents the more the two are shifted in relationship to each other.
For example this morning an event that happened at 21:45 last night will be shown before the 9pm time mark. It was shown right last night but the longer ago the more it will shift in relationship to the time label. The shift is always to an earlier time.
Have you noticed this behavior before?
Thanks for the great node. Johannes
I started putting values into this chart at 8:01 this morning.
There is CLOSED(grey) and OPEN(green).
The first two values are CLOSED until at 8:23(timestamp 1583393020921) the first OPEN arrives. it gets rendered correctly at the time but now a few hours later its beeing shown at the 8:01 mark.
Same rendering when I inject the Object as an array with timestamps.
The closer the number scale gets to now the more accurate it is the further in the past and the longer the period shown the more it shifts.
Johannes
-yes it angular(but the same happens with the nodered theme)
-the widget is set to 6x2
-Two states strings OPEN/CLOSED
-5 ticks(tried different numbers, didnât make a difference)
-no persistable storage(tried both, didnât make a difference)
-combine similar states!!!
-no legend (no difference)
-format hh:mm(tried different formats no difference).
I know more about what happens now. It has something to do with the combination of similar states.
What I can reproduce is that if the chart receives CLOSED several times after deployment or after resetting it the error occurs when it first receives OPEN. OPEN gets pushed to the time of the very first received CLOSED and for some reason all the previous states of CLOSED get completely ignored.
So I depoyed a chart today at 1:50pm. It received CLOSED as a state 9 Times and showed it correctly as grey. Than it received OPEN(blue) for the first time at 5:24pm and this happens:
The period length of OPEN is shown correctly now but its moved to the very start.
But if i now take the same data and inject it into another graph widget which has combine similar states turned off it shows it correctly Rendering the blob for OPEN at the correct time :
So it is 100 percent something that combine similar states does when applied to several similar states at the start of a graph.
Here is the csv with the data as a txt: KitchenWindowState.txt (250 Bytes)
I hope this helps to narrow it down, Johannes
I'm using state-trail to display the temperature of my solar diverter, and have configured the node to 'Show current states', thinking that it would only display the 'current state', but it appears to display all of the states that are present in the chart (it's a 8hr chart)
For example, the current state is 16 deg, so expected just to see 'More than 15C', but in fact it lists all of the states (and runs out of space).
I suppose the emphasis is in the trailing 's' in 'Show current states'.
Well it is from widget perspective. All the states currently visible. And of course it can run out of space cos the number of states is not limited.
Main purpose of widget is to get overview of state changes over time. Current state is actually partially out of display (fades out to right) thus the importance considered low.
But I think It can be done of course. (Show latest state). Takes couple of lines of coding
Well easy to promise but....
Clicking on legend shows summary of each state. Current state is not calculated in as it has no duration yet. If the configuration says that legend shows latest state, what to expect from stats to show? A bit of confusion.
I would say (if possible) just highlight the current state in the legend slightly so 100% for current state and slightly less opacity for rest of text...?
Well I did it as was requested and it actually still does the job nicely.
If latest state is not found anywhere else in timeline, the statistics will show zero time and it is correct value. I just never tough about it that way but really, statistics of state history should provide info about current state as much as possible. So it is done
Ability to graph more than one value (aka multiple gantt chart / swim lanes), using msg.topic as the graph id/key to determine where msg.payload goes. I'm also 100% OK if legend can't be shown at all when there are multiple graphs.
Ability to put label on LEFT instead of ABOVE. Especially important if feature request #1 above is implemented.
