vnStat vnStat-on-Merlin v2.0.9 [2025-Aug-14] - Data Usage and Data Limit Monitoring using vnStat

[Martinski]

Release Notes for vnStat-on-Merlin v2.0.8 production version now available
[2025-Jul-05]

1) IMPROVED: Modified all SQLite3 calls to capture and log errors in the system log.

2) IMPROVED: Modified SQLite3 configuration parameters to improve the processing of database records.

3) IMPROVED: Added code to create a separate logfile to capture the SQLite3 errors with more verbosity.

Debug logfile default location: /opt/share/tmp/​

4) IMPROVED: Added error-handling code when an SQLite3 database operation fails to create a file.

5) IMPROVED: When an SQLite3 operation returns error messages indicating a corrupted binary, the error-handling code will now log a separate message to the system logger and to its own debug logfile to let users know of the corrupted SQLite3 and the need to remove and reinstall its Entware package.

6) IMPROVED: New code to remove duplicate parameter key names found in the configuration file. Getting duplicate key values can cause "bad number" or "arithmetic syntax" errors.

7) IMPROVED: Modified the startup call made in the 'post-mount' script to check if the USB-attached disk partition passed as an argument has indeed Entware installed.

8) IMPROVED: Modified the call made in the 'service-event' script to check if the parameter contains the script name.

9) IMPROVED: Show the current database file size information on the WebUI page.

10) IMPROVED: Show the "JFFS Available" space information for the "Data Storage Location" option on the WebUI page.

11) FIXED: Minor cosmetic glitch related to the "Data Usage Warning" message on the WebUI page, where the "Warning Bell" image had what appeared to be a "dot" underneath it. [Reported by @Tarek Yag]

12) Miscellaneous code improvements.


The fork from @dev_null's vnStat-on-Merlin add-on is now hosted on the AMTM-OSR GitHub repo:

GitHub - AMTM-OSR/vnstat-on-merlin: vnstat-on-merlin

vnstat-on-merlin. Contribute to AMTM-OSR/vnstat-on-merlin development by creating an account on GitHub.

github.com

For some important notes about vnStat-on-Merlin, see the following post by @dev_null:

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

vnStat-on-Merlin - Release versions - R1 and R2 Update 18 July 2021: Upgrade! For ARM and AARCH-based routers, we've got some great news: vnStat-on-Merlin Release 2 (R2) is now available for non-MIPS devices. This version is based on vnStat 2.7, recently included as an Entware package. More...

www.snbforums.com

 

[Tarek Yag]

I'm very glad that I'm contributing to the great Merlin communities! Looking forward more contributions to vnStat very soon.
Good luck everyone, and congratulations on the first release under the AMTM-OSR repository! I'll update in a few minutes.

 

[Martinski]

Release Notes for vnStat-on-Merlin v2.0.9 production version now available
[2025-Aug-14]

1) IMPROVED: Added code to double-check and make sure that the correct custom service script installed by vnStat-on-Merlin (for vnstatd) is found and executed, and to verify that it has not been overwritten or modified (e.g. via Entware package updates). These checks are performed at startup following a reboot, every time the vnstatd service is restarted, and every 5 minutes via the pre-existing cron job that generates stats.

2) Miscellaneous code improvements.


NOTE: This release prevents a possible scenario where an Entware update of the vnstat2 package installs its own service script, which may launch a separate vnstatd process outside of the control of vnStat-on-Merlin.



The fork from @dev_null's vnStat-for-Merlin add-on is now hosted on the AMTM-OSR GitHub repo:

GitHub - AMTM-OSR/vnstat-on-merlin: vnstat-on-merlin

vnstat-on-merlin. Contribute to AMTM-OSR/vnstat-on-merlin development by creating an account on GitHub.

github.com

 

[aru]

Thanks for developing vnStat! It’s been a very reliable and lightweight tool for long-term network traffic monitoring.

Currently vnStat shows RX/TX/Total traffic, which is great for historical usage tracking.

However, for users who want to understand whether their subscribed bandwidth is being fully utilized, the raw traffic numbers are not very intuitive.

For example, if a user subscribes to a 300M/300M connection, they may want to know not only how many GB were transferred, but also what percentage of their maximum capacity was used each day.

### Benefits
- Provides a more intuitive view of how efficiently the subscribed bandwidth is used.
- Helps with capacity planning (e.g., knowing when to upgrade or downgrade).
- Could also be useful for alerts or for visualization in vnStat frontends.

I’m not sure about the feasibility of adding this directly into vnStat, or if there are already similar tools that provide this feature.

Thanks for considering this suggestion!

 

[Martinski]

Thanks for developing vnStat! It’s been a very reliable and lightweight tool for long-term network traffic monitoring.

Currently vnStat shows RX/TX/Total traffic, which is great for historical usage tracking.

However, for users who want to understand whether their subscribed bandwidth is being fully utilized, the raw traffic numbers are not very intuitive.

For example, if a user subscribes to a 300M/300M connection, they may want to know not only how many GB were transferred, but also what percentage of their maximum capacity was used each day.

### Benefits
- Provides a more intuitive view of how efficiently the subscribed bandwidth is used.
- Helps with capacity planning (e.g., knowing when to upgrade or downgrade).
- Could also be useful for alerts or for visualization in vnStat frontends.

I’m not sure about the feasibility of adding this directly into vnStat, or if there are already similar tools that provide this feature.

Thanks for considering this suggestion!

I can take a look to see if it's something feasible (when time allows), but likely not within the next month or so due to workload and other priorities. Also, there are a couple of things I'd like to finish before the end of this month, and then one little feature I may add to YazDHCP (more on that on the YazDHCP thread).

 

[Tarek Yag]

A couple of months ago, I kept some features in mind to suggest to be added to vnStat script, which would be a great addition. However, I have other priorities right now that should keep these suggestions for later.

Anyhow, after I recently started experimenting with Dual WAN in failover/failback and load-balance modes, as a result of changes on my internet setup at home. I found out that the script cannot just monitor two interfaces since I need to monitor my two WAN interfaces (now named vlan2 and vlan3 instead of eth0).

This is a missing feature that I believe should be present in the script, and it's something that we might need to give some immediate attention, although -I'm unsure, but- it could be an easy modification/fix to get it to work as it should.

For reference, in Linux, the command vnstat actually supports merging multiple interface data internally using the "+" operator as described in the command's man page. Refer to this page for complete information

-i, --iface interface
Select one specific interface and apply actions to only it. For database queries, it is possible to merge the information of two or more interfaces using the interface1+interface2+... syntax. All provided interfaces must be unique and must exist in the database when the merge syntax is used. Optionally, depending on the InterfaceMatchMethod configuration setting, interface can be replaced with alias previously set using --setalias. Merge syntax isn't supported when alias is used. The -i, --iface option is optional and interface can be used as parameter on the command line for selecting the used interface even without the option being explicitly used.

Doing some troubleshooting as usual, I made a no-brainer try to get dn-vnstat to monitor both interfaces, but I faced errors where the script didn't allow me to do so:
1- The first try when I tried to input both interfaces for monitoring "vlan2+vlan3" at script install process where it rejected it because it doesn't match the required interface name format (for dn-vnstat script itself)

Input is not a valid interface or interface not up, please try again.

2- The second try when I edited the vnstat config file from the dn-vnstat script's CLI interface to input both interfaces (again, "vlan2+vlan3"), although it somehow started merging data and displaying it correctly, but it kept outputting an error every update:

**ERROR**: Unable to get vnStat Interface ID [gnr1].

In the end, I'm open for any workarounds/suggestions to get this to work accordingly with Dual WAN in my new network setup, before/without even making this needed script fix. And since I'm specialized in Software Engineering, I'm not very good at networking terminology, so any guidance to (maybe?) merging these two interfaces into one (for stats only?) that I can input to dn-vnstat script, would be much appreciated.

Kindly,