Earnings calculator (Update 2022-12-08: v12.3.0 - Now compatible with node version 1.62+ - Detailed earnings info and health status of your node, including vetting progress)

The docker container for v1.12.3 is available at storjlabs/storagenode:6f6b9b10-v1.12.3-go1.14.7

Looking forward to the update!

https://hub.docker.com/r/storjlabs/storagenode/tags?page=1&name=v1.12

This issue has now been fixed with todays release. I apologize for the inconvenience and the delay for those who got this node update earlier than I did. It sucks to have to wait for a fix. But to make up for it I implemented some new goodies. We now have uptime as recorded by the satellites with the new uptime tracking system. With more verbose warnings for different scenarios that may cause issues. I’ve also reshuffled the layout a little bit to make sure the longer status line doesn’t get in the way of the important stuff.

image
Please note that the warning for stefan-benten is likely because that satellite wasn’t updated and doesn’t report back uptime as it’s about to be phased out. You can safely ignore this for now. That’s the downside of reporting stats that haven’t been officially exposed to end users yet. :slight_smile:

Here’s a few examples of the more detailed warning messages.

Enjoy the new version!

Changelog

v9.4.0 - Uptime is back

  • Fix for changes to databases with node release v1.12
  • Uptime scores are now included
  • Status display for uptime suspension and under review
  • More verbose warnings display what should be looked at
  • Layout changes for readability
13 Likes

Please note, there is currently a bug that prevents the uptime to be updated in the first 30 days. This is on the storagenode end. So I don’t expect this will show correct information in the first month.

Additionally this new update requires node version v1.12 or later. The database changes made to the node were not backwards compatible.

5 Likes

Big THANK YOU for the update!

3 Likes

Node Version: v1.12.3
script version = “9.4.0”

python earnings.py
Traceback (most recent call last):
File “earnings.py”, line 229, in
con.execute(‘ATTACH DATABASE ? AS su;’,tSU)
sqlite3.OperationalError: attempt to write a readonly database

After stop,rm,start node script working, 2 hours and error.
If script run as SU working :face_with_raised_eyebrow:

I wouldn’t expect that error to begin with, as the script only reads from the databases. I just tried making them read only and the script ran fine for me.

Nice update. Good addition with the uptime scores. Also good to see that it’s showing to be expected results for the current month on Stefan-Benten satellite. Looks like it’s not communicating with the nodes anymore as my uptime is showing 0%

I see this on 2 of 3 nodes I have. All the other satellites are 100%…?

Status: WARNING: Uptime low >Audit[0.0% DQ|0.0% Susp] >Up[0.0%]

This was included in the update post.

OH - thanks @BrightSilence - I missed that. :grimacing:

Runing the last versión of the script on an 1.12.3v storj node…

python earnings.py /path/to/storj/data 2020-09
File “earnings.py”, line 6

^
SyntaxError: invalid syntax

Looks like something went wrong in the download. I just added these to the top post to help prevent that.

Direct link (right click > save as):

https://raw.githubusercontent.com/ReneSmeekes/storj_earnings/master/earnings.py

From CLI:

wget https://raw.githubusercontent.com/ReneSmeekes/storj_earnings/master/earnings.py

Try either of those options.

2 Likes

I’ve downloaded the earnings.py file to my storj folder but when I run it I get the message:-

ERROR: bandwidth.db not found at: “/home/dwr/storj/storage” or “/home/dwr/storj”

Is your node brand new? If not, is /home/dwr/storj where you store actual data for the network or is that where you placed your identity files? In my case, I have /opt/storj/identity for where my identity is stored and /opt/storj/data for the actual data hosting and all I type is “python earnings.py /opt/storj/data” (minus the quotes) and it works fine. If you’ve got your run command saved, post it here (you can redact the values for anything other than the bind points and I recommend that you do redact the other values).

Many thanks for the reply. My node is about 2 months old, has about 600GB on it.

I have

/home/dwr/storj/storage/bandwidth.db

but it’s only accessible by root.

sudo python earnings.py /home/dwr/storj/storage/

does work. Should I be content with that or do I need to change folder and file permissions? Currently I have :-
dwr@r710:~/storj$ ls -l
total 84
-rw------- 1 root root 8209 Jul 29 10:54 config.yaml
-rwxr-x–x 1 dwr dwr 17871 Sep 28 21:03 earnings.py
drwx------ 2 root root 16384 Jul 27 15:22 lost+found
drwx------ 4 root root 4096 Sep 10 12:56 orders
-rw------- 1 root root 32768 Sep 21 13:11 revocations.db
drwx------ 6 root root 4096 Sep 29 09:35 storage
-rw------- 1 root root 1430 Sep 29 05:39 trust-cache.json
dwr@r710:~/storj$ sudo ls -l storage
total 307984
-rw------- 1 root root 4157440 Sep 29 09:31 bandwidth.db
-rw------- 1 root root 32768 Sep 29 09:35 bandwidth.db-shm
-rw------- 1 root root 2624472 Sep 29 09:35 bandwidth.db-wal
…etc

In case it’s still needed :-

dwr@r710:~/storj$ docker run -d --restart unless-stopped --stop-timeout 300 -p 28967:28967 -p 127.0.0.1:14002:14002 -e WALLET=“xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx” -e EMAIL="xxxxxxx@gmail.com" -e ADDRESS=“eeeee.dd.ccc:66666” -e STORAGE=“9TB” --mount type=bind,source="/home/dwr/.local/share/storj/identity/storagenode/",destination=/app/identity --mount type=bind,source="/home/dwr/storj/",destination=/app/config --name storagenode storjlabs/storagenode:latest

so the reason why the script (without sudo) can’t run is because the “other” permission set is blank (meaning you have no permissions because you’re neither the root user nor in the root group, though group perms are blank too.) Honestly, while running any old script as root is generally bad practice, you’re probably better off using sudo to run this particular script. I must’ve tweaked my permissions at some point because I know my node isn’t accessible except from my network in terms of SSH and other means of access that would allow for messing with the file structure.

1 Like

Well this is awkward… I built in uptime before it was active and missed an inadvertent rounding down. Suddenly my node showed 99.0% uptime on 2 satellites, which surprised me a bit. Turns out it was rounded down from 99.99% and 99.97%. This minor release fixes the issue and adds an extra decimal point to align with how the numbers are shown on the web dashboard.

Changelog

v9.4.1 - Uptime rounding fix

  • Fixes an issue where uptime percentages were rounded down to a whole percentage
7 Likes

An update is due in time for the new satellite :slight_smile:
New us2.tardigrade.io Satellite!

Yes, I will update once the satellite starts pushing data to the node. I would need to know the hex of the satellite ID. Can only get that once my node has received some data back from the satellite.