[Announce] node-red-contrib-ui-state-trail [Features]

Thank you @BartButenaers

For examples, yes I can make and add them. I just thought that infopage covers the needs

If you want to use the widget to show historical data, you need to pass in every state together with its timestamp. msg.payload = {state:true,timestamp:1579362774639}

For clickable intervals, I think there will be another widget (or maybe option for state-trail to behave in clickable manner which I think I dont like as it makes it kind of messy). Mainly because of performance reasons. To achieve best performance, currently there is only one element, colored with gradient. That gradient is calculated at server side, html gets only values to generate that gradient. It will be way too complicated thing (for me at least) to figure out what to send out with the click.
So for clickable, there will be multiple elements and they can carry some id-s and then the click option is easy enough to provide.

And I'd like to hear about is there more possible use cases or or bright ideas what kind of features such kind of widget should provide

Ah, didn't knew that. That is a clever solution...
Then my request indeed becomes hard to implement :frowning_face:

Will need to think about that. Hopefully other community members overwhelm you now with great ideas, to get you started implementing yet another cool UI node :wink:

1 Like

For you @BartButenaers is given the hardest thing in the new ui-widget development journey.
The thing needs a name :smiley:

1 Like



Hey @hotNipi,
a new (desperate) attempt to find some extra use cases :roll_eyes:

I see that other systems (like Openhab, Home Assistant, ...) not only use their timeline charts for showing 'history', but also to setup their system 'now' or even the 'future'...

  • Setup 'now': Suppose you show the history of a light (on/off):
    Currently (= 1:00 PM) the light is OFF. But perhaps if you could click on that last interval, you could switch it to ON ...

  • Setup the 'future': For example in Openhab they use the timeline to setup a heating profile:
    Suppose you could click on an interval, we could show my node-red-contrib-ui-contextmenu node (at least when your output message should also contain the click coordinates) to show a popup menu with following options:

    • 'add new sub-interval'
    • 'delete interval'
    • 'change interval'
    • ...

    Or - instead of a context menu - we could also fill some fields in the dashboard, based on your output message data:


  • About the 'history' example I gave above (for my video recordings). If I could click on a recording interval, I could also display a popup menu with:

    • 'delete video'
    • 'play video'

for setting my heating profiles I use a different approach using what is already in the dashboard toolbox (slider, chart, buttons, drop down, text):

You choose a room and a time period you can find the flow for configuring time periods here. The room drop-down is filled by the homematic ccu automatically but there is a configuration tab too to add or edit rooms and set default values.
Then you can add (divide the current period into two) or delete (current segment) points, move the cursor (magenta line) left an right and change the x (time) and y (temperature) values by using the sliders (these are sometimes a little bit sticky ... have to investigate)

For every room I have this panel:

(Before you ask there is still a bug updating ui-heater)
It uses the ui-heater node and updates the settings by sending the (not documented) setCalendar topic (sometimes a quick look into the source helps ;).
The actual temperature is then drawn above the set temperature curve. The 4 buttons give quick access to switch to manual mode, switch on comfort (warm) or lowering (cold) mode or activate the boost mode (valve 100% for a period of time 20min or so configured inside the thermostat).

The project isn't finished because I was moved to other projects (developing the homie node and other things) and had limited time. Still a lot of things to do but already in use. Beside bug fixes mainly program the thermostats with the edited schedule to get them running independently is on my to do list. But exactly this feature is not documented!

Hi Chris,
nice project ! I have bookmarked it :wink:
But there are multiple ways to Rome ...
And having a clickable timeline would be another way to go ...

1 Like

Sure and I will use the timeline to program my sprinkler system because it has to deal with boolean values over time. And the clickable feature would be great here too. Especially when it comes to Ui design there are may ways to Rome as you said.

My goals here where

  • visual representation of the values.
  • able to modify the values on a touch screen
  • periods in groups (for example all working days)
  • reusable nodes (I updated all function nodes to subflows and using the settings panel to be able to configure the subflow-node without going deeper into the source and make them reusable to many purposes)
  • ability to modify the layout by re-wiring or rearranging.
  • using mainly the topic/payload scheme to pass data
  • all data is configured over the dashboard and not in the flow.
  • use build in nodes wherever possible and suitable

Instead of rolling out a custom node (which would be easier if I only had more html css knowledge) there are many ways to tweak the panel to your needs. A custom node on the other hand could get rid of the sliders and do everything by taping and dragging on the curve or right click to add or delete points or even input precise values.
Finally I wanted to test how far I could get with the default dashboard and investigate the pros and cons (before I perhaps switch over to ui builder). In conclusion I decided to stay on the default dashboard mainly because it is not a monolithic block and integrates perfectly in the Node-RED concept of putting basic nodes together to build something that fits your needs.

Only an Idea: instead of building in functionality into this node perhaps there is a way of implementing callbacks to make this possible.
I recently made a PR to expose the callbacks of tabulator sitting behind the ui-table node to make this functionality available inside Node-RED.


  1. Single line vs. multi-line.
  2. Support overlaps (if yes, then how)
  3. Input data format:
  • {type:"data_type", start:1580754181, end:1580754546}
  • {type:"data_type", start:1580754181, duration:8954}
  • {type:"data_type", time:1580754181} (forces to use some kind of empty data type for gaps )
  1. Name of the widget. I like the "timeline" but there will be not that many functionality as timeline charts around the world provide, is it fair to steal the name?

Well this is what I think of when I hear timeline - http://simile.mit.edu/timeline/
(which is very clickable :wink:

Very good example. :slight_smile: Makes my question 4 statement solid as rock.

Hey @hotNipi,
Your questions sound like music in my ears :wink:

Personally I would make such a widget single line, and if somebody want overlaps then he can always combine multiple of such single line widgets? Although such flows might become much more complex for people that need overlaps... Have you seen already (IOT?) use cases for overlaps?

About the data formats. Perhaps the end/duration should be optional. If no end/duration supplied:

  • If no next time slice is available, then the current time slice runs until eternity.
  • If a next time slice is available, then the current time slice stops where the next time slice starts.

If the data is collected as live stream of events, no need for endings. It can managed as state-trail does for states. New state ends previous. Simple enough. But if you need to present some time related events created and stored as individual data chunks but having start and end time, you then miss the gap recording between them. So for such data the gap calculation should somehow be possible. And without end time or duration there is no way.

By supporting the start/end or start/duration format the overlap may just happen. But should the situation then be graphically covered nicely (having no bright idea how to do it) or it should be treated as not supported case.

Only some ideas... :face_with_hand_over_mouth: please take what you think is useful or doable:

  1. Multi line
  2. Perhaps like this
  • as the Dashboard isn‘t responsive in the size of a widget the available hight could be divided by the max. amounts of overlapping lines.
  • And if a line name is sent like msg.line=“Monday” as equally divided sections with some kind of separations.
  • vertical scroll - but not preferred because the intention should be to visualize all data and compare.
  1. all of them and
  • single events as „milestones“ or bullets
  1. Timeline is fine and functionality can evolve over time :wink:
  2. Zoom and scroll/drag on the x-axes (interactive and by sending ui_control messages)
  3. Build in or callback functions for
  • mause clicks
  • formatters for periods, legends, lines, ...
  • tooltip popups showing extra data about the event.

And many more, sorry you asked :hugs:

1 Like

I love challenges. But I really don't have couple of next years free :smiley:

1 Like

As I have little or no knowledge of html/css and such things I would warp something around what is already existing

But it is certainly less fun.

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 :rofl:

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 :smiley:

But OK, I'v got something to think about. (which I tend to spend more time than coding the stuff)

1 Like

Meanwhile the state-trail got some updates

  • Legend (with option to toggle between state names and aggregated time per state)
  • Improved configuration page (to indicate configuration errors more clearly)