vnStat [Release] vnStat-on-Merlin - UI, CLI and email - data use and data limit monitoring - R1 and R2

[L&LD]

Are you setting your browser full screen?

What resolution is the monitor set to?

 

[Stephen Harrington]

Are you setting your browser full screen?

@L&LD

No, but it's set to a very large "window", and making the window wider does not change the horizontal size of the graph or fix the problem, if that's what you mean?
For the heck of it I DID set the app to be "full screen" but it also made no difference ...
Also tried it in Firefox and Safari to see if it worked differently to my default Chrome.
I even got really down and dirty and resorted to trying Microsoft Edge - no difference with any of them.

What resolution is the monitor set to?

It's an older 27" iMac (Late 2013, pre-5K displays) so it's running at its default "native" resolution of 2560 X 1440.

So I take it you're not seeing the same issue on your setup?

 

[dev_null]

@dev_null
Just playing around with the various graphing options and I think I may have encountered a bug /display error in R2 on my RT-AX86U?

For the "Compare Usage" graph, if I set the Options to Days (and GB and Logarithmic but that doesn't make a difference) I get the following display:


The bar graphs for "Current 7 days - Received" and "Previous 7 days - Sent" overlap and obscure each other.
I presume that all 4 bars are meant to be side by side and not overlap each other?

Is anyone else seeing this?
I've tried a few different Browsers with the same result.

This is more or less by design. This uses the JY charting function common to many of the @Jack Yaz scripts, and when we were speccing out these new interactive charts initially, there was no column overlap.

The issue was that with the number of data columns I wanted to show - and the width of the columns -, there was no space between the columns from the various days on the X-axis, making it difficult to parse. So we ended up with the view you see, with overlap, though the colors should be transparent enough that you should be able to eyeball all the column values.

It seems most obvious on larger monitors, and I can confirm what you see. A key driver is also the width of the Asus UI, which isn't scalable (IIRC there's only 760 pixels in width for the charts).

 

[joe scian]

Hi dev_null
I had my rollover date set at 14 month. Today ( 15th ) I still see this message
You have used 46.95% (234.74GB) of your 500.00GB cycle allowance; the next cycle starts on day 14 of the month. After I went in and manually updated stats - i get You have used 2.35% (11.73GB) of your 500.00GB cycle allowance; the next cycle starts on day 14 of the month. ( The correct stats).
Might have been some cron jobs missing i think. I think they are there now though- thanks

 

[Stephen Harrington]

This is more or less by design.

Hmmm ... OK.
Sure, you CAN decipher the info under the overlapped items but I find it unclear and visually confusing.
Looks like a "mistake" to my eyes, but maybe I'm weird ...


So do I gather there is no possibility (because of JY limitations) to make the 4 columns much, much thinner and have no overlap and still leave space between the days to delineate them?

 

[Jack Yaz]

Hmmm ... OK.

Sure, you CAN decipher the info under the overlapped items but I find it unclear and visually confusing.
Looks like a "mistake" to my eyes, but maybe I'm weird ...


So do I gather there is no possibility (because of JY limitations) to make the 4 columns much, much thinner and have no overlap and still leave space between the days to delineate them?

what's weird is that they display fine here:

the fact they're overlapping suggests that something is probably off in my timezone/date code - which TZ is your router set to? i'll see if i can reproduce

 

[Stephen Harrington]

the fact they're overlapping suggests that something is probably off in my timezone/date code - which TZ is your router set to? i'll see if i can reproduce

Appreciate you looking at it @Jack Yaz.
Yes, your screen shot is exactly how I was thinking it should be!
I may not be the only one so afflicted then …

My TZ is set to “GMT+10:00 Canberra, Melbourne, Sydney”
If it makes a difference, we are NOT currently in DST here in Sydney, that starts October 3.

 

[Jack Yaz]

Appreciate you looking at it @Jack Yaz.
Yes, your screen shot is exactly how I was thinking it should be!
I may not be the only one so afflicted then …

My TZ is set to “GMT+10:00 Canberra, Melbourne, Sydney”
If it makes a difference, we are NOT currently in DST here in Sydney, that starts October 3.

i'll try and take a look, but no promises on an ETA I'm afraid

 

[Stephen Harrington]

i'll try and take a look, but no promises on an ETA I'm afraid

I thought you were on a break anyway - so if/when it takes your fancy (or never as the mood dictates) is fine by me as always! Main thing was your confirmation something may be not right …

 

[festus77]

@Jack Yaz - Same issue as Stephen - my TZ is:

 

[dev_null]

After updating Diversion, I'm finding a vnStat-on-Merlin communication issue on my testbed router (AC66U_B1).

I updated Diversion, updated my password, tested Diversion communications (works fine). I disabled and tried to re-enable dn-vnstat comms but get the "dn-vnstat relies on Diversion to send email summaries, and email settings have not been configured - Navigate to amtm > 1 (Diversion) > c (communication) > 5 (edit email settings, test email) to set this up" error.

This is not a Diversion error, it's a dn-vnstat issue.

I've reached out to Jack to try to see if he has the same problem and what we might be able to do to fix it.

For now, if dn-vnstat comms are critical, you may wish to hold off updating Diversion until we have more information.

If anyone has already updated Diversion and your comms are working, please PM me so I can compare our setups.

 

[dev_null]

Appreciate you looking at it @Jack Yaz.
Yes, your screen shot is exactly how I was thinking it should be!
I may not be the only one so afflicted then …

My TZ is set to “GMT+10:00 Canberra, Melbourne, Sydney”
If it makes a difference, we are NOT currently in DST here in Sydney, that starts October 3.

@Jack Yaz - Same issue as Stephen - my TZ is:

View attachment 36341

Jack and I have been discussing this. At this point we'll add a fix to our tracking but since it's cosmetic not functional, it might be some time.

 

[visortgw]

After updating Diversion, I'm finding a vnStat-on-Merlin communication issue on my testbed router (AC66U_B1).

I updated Diversion, updated my password, tested Diversion communications (works fine). I disabled and tried to re-enable dn-vnstat comms but get the "dn-vnstat relies on Diversion to send email summaries, and email settings have not been configured - Navigate to amtm > 1 (Diversion) > c (communication) > 5 (edit email settings, test email) to set this up" error.

This is not a Diversion error, it's a dn-vnstat issue.

I've reached out to Jack to try to see if he has the same problem and what we might be able to do to fix it.

For now, if dn-vnstat comms are critical, you may wish to hold off updating Diversion until we have more information.

If anyone has already updated Diversion and your comms are working, please PM me so I can compare our setups.

I found a workaround. I updated Diversion, generated new app password/updated in Diversion, and verified Diversion e-mails worked. I tried to re-enable daily stats (HTML) in vnStat using CLI, but it failed. I successfully re-enabled daily stats (HTML) in vnStat via web UI (and I was able to verify via CLI).

EDIT: I forgot to mention that connmon e-mail worked without any changes after updating app password in Diversion.

 

[dev_null]

I found a workaround. I updated Diversion, generated new app password/updated in Diversion, and verified Diversion e-mails worked. I tried to re-enable daily stats (HTML) in vnStat using CLI, but it failed. I successfully re-enabled daily stats (HTML) in vnStat via web UI (and I was able to verify via CLI).

EDIT: I forgot to mention that connmon e-mail worked without any changes after updating app password in Diversion.

I'm not sure that the UI does the same test as the CLI. I was able to do what you did but when I forced a daily update using the sh -x /jffs/scripts/dn-vnstat summary it showed the same error.

I'm already testing some changes that Jack has worked up. It looks like a symlink issue.

 

[Jack Yaz]

After updating Diversion, I'm finding a vnStat-on-Merlin communication issue on my testbed router (AC66U_B1).

I updated Diversion, updated my password, tested Diversion communications (works fine). I disabled and tried to re-enable dn-vnstat comms but get the "dn-vnstat relies on Diversion to send email summaries, and email settings have not been configured - Navigate to amtm > 1 (Diversion) > c (communication) > 5 (edit email settings, test email) to set this up" error.

This is not a Diversion error, it's a dn-vnstat issue.

I've reached out to Jack to try to see if he has the same problem and what we might be able to do to fix it.

For now, if dn-vnstat comms are critical, you may wish to hold off updating Diversion until we have more information.

If anyone has already updated Diversion and your comms are working, please PM me so I can compare our setups.

fwi

I'm not sure that the UI does the same test as the CLI. I was able to do what you did but when I forced a daily update using the sh -x /jffs/scripts/dn-vnstat summary it showed the same error.

I'm already testing some changes that Jack has worked up. It looks like a symlink issue.

symlink issue in that i wasn't anticipating diversion moving its email config so soon, so in connmon I symlinked diversion's email to the new location. fix for dn-vnstat should be out today

 

[thelonelycoder]

fwi

symlink issue in that i wasn't anticipating diversion moving its email config so soon, so in connmon I symlinked diversion's email to the new location. fix for dn-vnstat should be out today

Sorry, I had to make the decision to move it and remove symlinks. I'd have to do it anyway at some point and I did not want to deal with checking if it's a symlink or regular file.

amtm will follow with that promised email edit function within the next few weeks.
Right now I'm on a plane to the US to somewhere on Cape Cod for business.

 

[Jack Yaz]

Sorry, I had to make the decision to move it and remove symlinks. I'd have to do it anyway at some point and I did not want to deal with checking if it's a symlink or regular file.

amtm will follow with that promised email edit function within the next few weeks.
Right now I'm on a plane to the US to somewhere on Cape Cod for business.

no problem! fix is in a PR.
connmon should be OK regardless (haven't checked but no-one's reported anything)

 

[dev_null]

A minor update 2.0.2 has been published to address the Diversion email change. R2 only. We have not yet assessed this issue on MIPS-based hardware (R1) but will do so in the next week. My MIPS test router has been deployed in production remotely.

Please run a u update for vnStat-on-Merlin if you are using R2.

Note: if you haven't done so, please check the functionality of the email settings under Diversion once you've updated Diversion, prior to updating vnStat-on-Merlin.

To test on vnStat-on-Merlin, run sh /jffs/scripts/dn-vnstat summary from the command line. You should get an early "daily" summary. If you don't get an email, run sh -x /jffs/scripts/dn-vnstat summary and report any error messages.

 

[Khadanja]

How often are the stats updated and where is it specified? Is it a script that runs to update the stats?(out of curiosity). Just trying to understand how scripts work?

 

[dev_null]

How often are the stats updated and where is it specified? Is it a script that runs to update the stats?(out of curiosity). Just trying to understand how scripts work?

If you read through the vnStat-on-Merlin landing page here, you'll see some explanation on how I original designed the script (pre-R1). The R1 and R2 releases were built with Jack Yaz's assistance and automate (and in R2, significantly enhance) the stats presented.

To answer your specific question: every 5 minutes for regular usage and at 23:59 for daily stats, both via cron jobs (also described on the landing page; see the non-UI configuration steps here).