Indicating left or right x-axis in the graph legends

Looking a the graph below as an example, The yellow “heat_power” trace peaks at 3kW (righthand scale) where as the red “Rm1-light_power” is only around 0.55kW and the green “Com-light_power” barely breaks 100watts.

It is unclear what value any traces are when there is 2 scales and none of the traces can be identified as using the left or right scale. This is apparent on both the multigraph and the newer Graphs module

Any thoughts as to how we could make it clear 2 scales are being used and which traces use which?

The obvious suggestion is to have 2 legends, one on the left and one on the right, although that would currently clash with the graph navigation in the multigraphs, the navigation could be made to centre in the graph area perhaps? and splitting the legend into 2 might have the benefit of,avoiding longer legend lists reaching too far into the graphing area.

Another thought is to add a little arrow within the legend but I think that might be too discrete and even when spotted, not obvious what it means.

Any thoughts???

other idea ?
Even if we get some floating pallet showing the arrow point data … still hard to point when we have such extreme difference with or without scales …
why not automagically propose the viewer to multiply the small values (so there are more detailed on view) and adapt it’s scale accordingly … and show clearly the multiplication factor (maybe even let user change it on screen ?) This could become a dynamic feature (not only when you create a graph) …

2 cents … with some dust

So you are suggesting the legend could say

vent_power X6
Rm1-light_power X6
Com-light_power X6

and then just the one scaled axis is needed 0 - 3500 (on the left)

Not an entirely bad idea, but I think it will possibly join my 2 above in the “not bad, but not ideal” bin.

However, there probably wouldn’t be much need for 2 scales if we could zoom in on the x-axis much like we can on the y-axis.

For example if this was the initial graph zoom (same graph with all plots using left hand scale, max 3600)

and we could zoom in to see the lower consumption plots effectively like so (edited same graph for max x-axis of 600)

For my specific application this could work well if there was just a selectable “Max x-axix” value added to the graph navigation toolbar, even better if I could pre-define those levels in the settings eg in this instance, only give the user a choice of 600 or 3600.

But this assumes a common minimum of 0 which might not work for everyone, so maybe we need to offer both the Min and the Max to adjust, or maybe we could play clever and provide a setting for “Min options” and “Max options” and if these are not populated the graph works as it currently does, so for example in my example I could define 600 and 3600 in the Max options leaving the Min options blank, which would only add the “Max x-axis” setting to the graph tool bar, and that would offer the user just 2 options 600 or 3600, the Min would remain pinned to 0 as it is now.

(Setting these settings to “auto” could result in a “free text” value box being added to the graph toolbar instead perhaps?)

I think we might be on to something here!

Just thinking out loud here!

If we could just add a vertical scaling factor (as suggested by @bidouilleur) to the graph toolbar and be able to scroll up and down that could work, IF the x-axis scale values could move/change as the graph scrolls.

I think a 3 button approach would be needed, scale factor, "scroll upandscroll down` to avoid accidentally zooming in on the y-axis when dragging with the mouse, but I could be wrong, I have never worked with flot, I do not even know how easy it would be for dynamic (scrolling?) x-axis labels, I assume it is possible because if you leave the x-axis max as “auto” and zoom into a part of the day that has lower consumption, the vertical scales adapt automatically.

2 cents … with some dirt.

I like the two legends idea. To me that seems to be the most intuitive.


I’d suggest placing the Nav above the graph. For many of my graphs the data I want is under the Nav. And to see the tooltip I need to click > to slide the graph to the left.

But after a couple of seconds the graph navbar fades and you can see the plots, when the buttons are over the top of the box that leaves less room for the graph and when the graph is embedded and 9 times out of 10 showing the right interval, they are effectively redundant buttons hogging space. Perhaps a “permanent external” verses"internal hover-over" toggle option in the settings would be the way to go. This is one of 2 main reasons I use multigraph over the Graph module.

Seeing your mock up with the handed legends I think that might work well with a centre aligned graph navbar too,

Maybe when the axis are left as “auto” there should be a little extra headroom included, when setting the max manually it’s easy to leave a little extra room.

Since most of my graphs show the most likely viewed data by default, the buttons are rarely used, usually for scrolling back or checking last month/week etc, but when embedded or running in kiosk mode the buttons etc are better hidden, but there if you need them IMO.

I can see the plots OK but I cannot get the Tooltip to work at the red dots (under the Nav).


For my graphs, the Nav being above the graph is not an issue since I have a Title on the far left side.


Centering the Nav is a nice idea. And leaving more headroom would be great! Or having a choice (if possible) would be great also. Nav might be Inside Right, Inside Center, Outside Right, etc.

(I’m saying “great” too many times. I almost sound presidential!)

This screen grab highlights the need for fixed scales on the y-axis. The top graph is a multigraph with fixed scales of 500 and 4000, the lower “graphs” graph has “auto” y-axis scaling. The data displayed is from the exact same feeds, but the lower graph is magnifying the <0.12 watts of noise and making the graph busy and confusing.

Unfortunately the graphs module only lets you set one y-axis scale min and max so you effectively cannot use fixed scales and 2 y-axis scales at the same time. I’ve added this observation to the issue raised on the Graphs repo.

Interestingly, I hadn’t previously noticed the graphs module graph background is transparent, I quite like that but unfortunately it doesn’t outweigh the other functional benefits of the multigraph.

See Misleading Y-Axis for for a related discussion.

also see Looking for a "dashboard" solution - #15 by GeorgeB for an example of alternative solution using the trace colors for the y-scale text, probably not the best idea to use this specifically but it’s food for thought eg colour the left and right axis red and blue and use those same colours for the legend text so that each entry is either blue or red text to indicate left or right.

Seems a pretty clear solution and you will notice it has 4 feeds, each with their own axis. There would need to be a feed limit of say 4 to prevent confusion.

Another solution is to split the y - axis in four and give a quarter of the axis to each of four feeds.

Mmh, I not so sure, your example graph on the linked thread has 6 traces (2 active and 4 disabled) it isn’t possible to colour 2 x y-axis scales (1x left and 1x right) in 6 different colours and having 6 y-axis wouldn’t be clear at all (I have over a dozen traces on some graphs) which is why I suggest abstracting the axis colours from the trace colours, not mention the trace colours can be quite light and hard to distinguish.

indeed, but how would you map 6 (or more) traces to even 4 y-axis? you couldn’t use trace colors which is why I think the example isn’t ideal. I guess I’m suggesting a max of 2 initially to keep it simple.

bLue for Left and Red for Right is easy to recall as is red legend entries for the right axis (as in “warning you are looking at the wrong axis it’s the right one not the left”) :slight_smile:

As a first step having the left y-axis and the labels in the legend for the traces that use the left axis and red for right, would fix the immediate problems and perhaps pave the way for additional left or right scales at a later time to follow the same convention eg the 3rd y-axis could be green and legend entries for traces using that 3rd scale are green text.

I do not know how capable flot is for any of these ideas though, I’m just throwing idea’s out there at this point.

not ideal as it decreases resolution by 4x for the same screen area and overlaying the traces often makes it easier to compare events across traces on different value ranges.

That’s not to say there might be a desire for a graphing tool that plots multiple separate graphs using the same nav tools and settings, but that’s a different topic.

1 active and 5 disabled that’s why the left axis should have no values at all.

That’s probably never going to be a clear graph then is it?

Seems too minimal.

Obviously but that particular system does allow you to select proportions, so one feed could have 50% etc.

Oops! I must be overdue an eyetest :slight_smile: but my point stands 6 trace colours still doesn’t go into 4 axis scales

Currently the only issue is knowing if the trace belongs to the left or right axis, I have to memorize or stick to a rule eg minor loads (<3kW max) on the left and major loads (>3kW max) on the right, these are graphs are generally the best debugging tool I have to hand and the main reason I started this very thread.

But more likely achievable, by making it too complex it sometimes discourages development. 2 colors fixes the issue raised here. job done! Then it could indeed possibly be extended.

I get what you say but which ever way it works 4 graphs stacked take up 4x as much space with the same resolution or give 4x less resolution using the same space and not really a factor in this context, that would be a different visualization it wouldn’t replace this of be concidered a fix for this no matter how useful for something else.

Therefore 1 y-axis, not 2, simple.

Ok George we’ll have to agree to disagree, if you read my comments in the original thread, the scale disappearing if only one trace is selected doesn’t fix the issue, it might be nice to have and work sometimes, but it isn’t a fix.

This thread is specifically about identifying which traces use which axis scale, removing a scale when only one trace is active does nothing to help that, I thought being able to see which axis the only enabled trace was using would be helpful, perhaps I was wrong.

I read the thread, this is the thread.

Showing any sort of scale for something that doesn’t exist seems bizarre to me and I don’t have a clue how it was coded with no data, ergo don’t provide a scale.

If one of those other five traces wasn’t disabled and was tracing a value around zero, you would still see the exact same 2 y-axis scales as the graph you posted… ergo you could still make the same mistake that urged you to propose removing the unused scale… ergo you still need to identify which trace is using which scale.

This is why I say identifying what is what is essential and dropping an unused scale is just nice to have.

but they are disabled.

I don’t really understand what point you are making, are you saying you can’t or won’t consider another scenario?

I’ve agreed with you, a disappearing axis might be nice to have, but it simply doesn’t fix anything, it only helps when only one axis is in use, in which case you could just create graphs with just the one axis, job done! I don’t know what else to say.

I don’t think I can be any clearer. No feed, no axis.

It fixes the “bug” of showing an axis for something that doesn’t exist and I would have thought it can’t be difficult to show a blank axis.

But the whole idea is that you can deselect feeds in the graph and sometimes 15, 12, 9, 3 or 2 feeds will be cut to 1 for clarity, without creating multiple graphs.