At - my graphs default to 1-week - no matter what I save as?

HI guys
been using the hardware and hosting for years - love it.

Not sure what I’m doing wrong -but after some graph changes I noticed some time range problems.

The public dashboard - my two graphs

  • show a 24 hour range
  • but the menu bar says ’ 1 week’.
  • and Clicking it - does NOT change the graph to 1 week. To get to a week view - have to double click - first on eg 12 hours, then on 1-week.

I’m not sure, but I think it’s always been like that. The drop-down list doesn’t necessarily show the saved state of the graph when it’s first opened.

I suspect you’d previously saved your graph with the default time scale of the drop-down list (1 week) and hadn’t noticed. Notwithstanding that, it’s not ideal (and really, it should show ‘choose’ or something like that as soon as you change the scale with ‘+’ or ‘-’).

It’s like that on my local emonCMS too.

Hi Robert - thanks for the super fast reply - you’re a star here on the forum.

As you get the same - then this is perhaps a UI tweak that would be helpful to fix?

If I create fresh Graphs I observe this:

  • first time I click graph menu - the default is an empty graph, set to show ‘1 week’.
  • I select an existing graph - it shows it with the correct time frame (from last save I made earlier in the week - 24 hours) - BUT the menu still says 1 week.
  • in fact -when you move between existing graphs in the edit - the Menu will NOT change between graphs. Even tho each may show a different time-line in the graph itself.
  • if you change the menu - it then ‘sticks’ with that, as you again move between saved Graphs.

So two code tweaks - does this sound right?
A) when displaying the Dashboard - set the menu for each graph to the same time-range as the graph already knows about and displays
B when editing Graphs - when move to another pre-saved graph - change the menu to match what the graph already knows about and displays.

II) I have another tiny UI tweak (no code to change): - in when adding graphs to dashboard -the setting for /width/height can be changed between ‘pixels’ and ‘percent’ - with ‘pixel’ as default.
It would be more logical to default to ‘percent’ for the width - to make it responsive on both mobile phone narrow screens and on desktop screens.
And maybe add some text on that config page to explain that).

III) And ANOTHER UI tweak for emonCMS -that does need code

  • as above when a graph has width as ‘percentage’ - the calculations are somehow wrong: if in editing you pull the graph to be nearly full width - when you save and look at the live dashboard - on some screen widths the graph overlaps the end -so you miss-off the Y axis.
    Maybe some CSS is not understanding maybe there’s not 100% of the page width, available to the graph object.
  • maybe this applies to any objects that can be set to be ‘width= percentage’?

As you can tell - I am very observant of UI friction. ! A curse as well as a help. If ever you want a Wiki page proof-read: I can always make it much easier for reader - by various ‘message clarity’ tips tricks. None of this is my day job.

I’m not a coder:: but maybe the JS that already exists, (that runs when you click the menu to change the visible word) needs to be initialised - ie Run as the graph is first opened. But isn’t.

looking at the live page in F12 mode

Each graph comes as a widget - served over the network like


and INSIDE that, is HTML that is hard-coded to ‘1 week’

<div id="navigation" style="padding-bottom:2px;">
    <div class="input-prepend input-append" style="margin-bottom:0 !important; margin-left:2px;">
        <button class="btn graph_time_refresh" title="Refresh"><i class="icon-repeat"></i></button>
        <select class="btn graph_time" style="width:90px; padding-left:5px">
            <option value="1">1 hour</option>
            <option value="6">6 hours</option>
            <option value="12">12 hours</option>
            <option value="24">24 hours</option>
            <option value="168" selected="">1 Week</option>
            <option value="336">2 Weeks</option>        
            <option value="720">Month</option>
            <option value="8760">Year</option>

and the javascript that builds that widget - DOES KNOW what the graph width is on initialising: from the line below: view.interval = result.interval;

        url: path+"/graph/get?id="+graphid,
        async: true,
        dataType: "json",
        success: function(result) {
            if (result.mode==undefined) result.mode = 'interval';
            view.start = result.start;
            view.end = result.end;
            view.mode = result.mode;
            view.interval = result.interval;
            view.limitinterval = result.limitinterval;
1 Like

Hello @JustPlaying thank you for the suggestions, I’ve created an issue on the emoncms github repository to note your suggestions Review UI improvements suggested by DJ Jones · Issue #1799 · emoncms/emoncms · GitHub, so that I can come back to this when Im next working on these parts of emoncms.

fast response Trsytan - amazing!
Hopefully my analysis above, points to it being an easy code fix? No new code, just run it at end of initialisation of widget?

( I’m not a coder - but I can dive in and get the gist.)

1 Like

Thanks @JustPlaying you may well be right, I will take a look, thanks!

This annoyed me as well, so I added the following snippet of code into embed.php (the one for putting graphs into dashboards). This mostly works, though isn’t completely fool-proof as there’s no checking if hours is a legitimate option.

index 7ef219b..54d233f 100644
--- a/embed.php
+++ b/embed.php
@@ -139,6 +139,10 @@
             yaxismax2 = result.yaxismax2;
             feedlist = result.feedlist;
+            // update time selector to match
+            var hours = Math.round((view.end - view.start) / 3600 / 1000);
+            $('.graph_time').val(hours);
             // show settings
             showmissing = result.showmissing;
             showtag = result.showtag;

(I’ve also got a patch to automatically refresh it every minute, but that’s not relevant to this discussion)