MySolar and MyElectric 'today' button

I was wondering if it had been considered adding a ‘today’ button to the apps displaying electricity/solar usage? MySolar, MyElectric, Octopus Agile etc.

ie, just show 00:00 to now.

We have 1h, 8h, D, M, Y. But D shows the previous full 24 hours.

Having a single today view would also allow the summary figures at the bottom only show only today’s totals too.

You can see this sort of display in action on PVOutput, which I think works well… the graph compresses to fill the space as the day (and data) goes along.

Final piece of feedback. When connecting to emoncms.org, there is no favicon icon. So Chrome for example shows the default world logo.

1 Like

Suggestion…
To avoid confusion with “the previous full 24 hours,” call it “today so far.”
(that’s the approach Grafana takes)

1 Like

I’d suggest adding in 24h - 1h, 8h, 24h, D, M, Y

2 Likes

I’ll second that. I modded the code (until I switched to Grafana) so that it would display 24h
(as well as 12h) and found it very useful.

2 Likes

@Gwil, could this be added as a feature request in the appropriate Repo? I suspect it may be a global change as all the visualizations look very similar

2 Likes

Added here, thanks View: 1h, 8h, 24h, D, M, Y · Issue #133 · emoncms/app · GitHub

1 Like

My suggestion would be that 1h, 8h, 24h shows that period as elapsed time, while D, M, Y as current day, month and year.

Using < and > for navigating whole periods as last selected. So if M is selected and showing the current month, selecting < will show previous month.

2 Likes

I’ve been looking at this very problem today (haha).

In my other system and the app I’m building in EmonCMS I’ve created a

tdy

button as a compact representation of “since midnight”. I’ve been using “24h” to mean 24 hours and I don’t have a “D” button.

<div class="powergraph-navigation">
    <span class="bluenav" id="right" >></span>
    <span class="bluenav" id="left" ><</span>
    <span class="bluenav" id="zoomout" >-</span>
    <span class="bluenav" id="zoomin" >+</span>
    <span class="bluenav time dmy" time='720'>m</span>
    <span class="bluenav time dmy" time='168'>w</span>
    <span class="bluenav time" time='24'>24h</span>
    <span class="bluenav time" time='tdy'>tdy</span>
    <span class="bluenav time" time='3'>3h</span>
    <span class="bluenav time" time='1'>1h</span>
    <span class="bluenav time" time='0.166'>10m</span>
</div>

As with Michiel, I’d like the “<” and “>” buttons to move by the selected chunk size. I haven’t looked into what they do at the moment, but it’s in my list of things to fix later because I can’t work out what it is doing at the moment. It calls “panleft” and “panright” on the view.

FWIW I have this scrap of dodgy code to get midnight:

function midnight(){
    const midnight =new Date();
    midnight.setHours(0);
    midnight.setMinutes(0);
    midnight.setSeconds(0);
    return midnight;
}

Seeing as I run everything in UTC I’m obviously fine with this, but I’m assuming you’d want timezone-specific midnight which this may not be doing. The fact that I’m not sure is partly why I run everything in UTC :slight_smile:

Thanks

David Bowen

1 Like

I’ve just submitted a pull request to resolve this issue as it was annoying me!

Thanks a lot @stuart I’ve tested and merged your pull request, looks great, cheers!

That was quick!

As I’ve expanded the options bar quite a lot it looks a bit of a mess on small screens/mobile phones.

Yes noticed that as well, I wonder if it needs to switch to a dropdown menu somehow on mobile?

Don’t know why we did not just add 24H.

Oh and while you are at it it is not Last Half Hour is is Current Half Hour.

Probably, there are a lot of options now, if would be good to get these consistent across all the apps - perhaps a seperate javascript module that can be included in the others?

I also noticed that emoncms has a lot of script tags - these are not great for performant web pages - the jquery ones in particular can be wrapped into a single call.

In what way @borpin?

The original options are a rolling X hours - these options are still there (12h/1d/7d/30d/60d) but the new options show midnight to midnight today etc.

The electric billing part isn’t based on a rolling period, its on a day by day calculation so this makes more sense (to me at least!)

@TrystanLea - this should have had more discussion.

@stuart, the current view

image

which I agree is not enough, but your proposal is just too verbose - as you point out Mobile does not work and plenty of folk use it on a tablet!

What problem are you solving? Matching the output to billing periods? Will 30d make any real difference over M? What if your billing period starts mid month?

The original proposal was to add 24h (12h make no sense to me) as the previous 24h and day is since midnight (TZ adjusted or UTC?).

The extra ‘days’ setting, doesn’t really make any difference over week, month etc unless this means week to date rather than 7d (which then needs some explanation).

To be consistent you need a 2 Month entry as well.

To me these additional periods are just noise and in any case it needs to be more concise.

I’d suggest ** 24h, D, D-1, 7D, 30D, 60D **
I’d suggest ** 24h, D, D-1, M, M-1, 7D, 30D, 60D **
I’d suggest ** 24h, d, 7d, 30d, 60d, D-1, M, M-1**

  • 24 Hr period
  • Day since midnight (TZ adjusted or UTC?)
  • previous 7 days use from now (i.e. 7*24H)
  • previous 30 days use from now (i.e. 30*24H)
  • previous 60 days use from now (i.e. 60*24H)
  • Yesterday midnight to midnight (TZ adjusted or UTC?)
  • Current month midnight on 1st to now (TZ adjusted or UTC?)
  • Last month midnight first day to 23:59 last day (TZ adjusted or UTC?)

[edit] - added in month options
[edit2] - d = since mignight, D = midnight-midnight. Changed grouping.

My opinion is that a fixed period (yesterday, today, last month) should be visibly different to a rolling period - either by grouping or post/pre fix in the description.

Either way, 30D or 60D don’t really do anything for me (as I don’t use them) but what I do want to know is how much electric did I use in Feb as an example.

Fair enough, but how does ‘Month’ do that? ‘Month’ to me would be the current month, not the last month (that would be M-1).

I suspect a tooltip could be added to explain the different periods.

As ever, the need is to be unambiguous and not make the assumption others will understand what you perceive (the bain of any UI).

I’ll edit my suggestion.

There is - I added that with yesterdays code release.