Disabled profitability.py

[mj-xmr]

@endorxmr

The profitability.py module appears to be broken, reporting connection errors from supportxmr.com, so I disabled it

It also needs to have an alternative source of information, as a fallback, in case the same thing happens again, as well as be able to react on the following options of the CLI:

• --offline-force - to avoid the web-API calls completely and deliver a dummy response without crashing the application
• --offline-try - to try calling the web-APIs, including all the fallbacks and deliver a dummy if it all fails, producing a warning
• default behavior - to try calling the web-APIs, including all the fallbacks and crash if it all fails.

[endorxmr]

The module is fine, code doesn't magically break out of nowhere. Supportxmr's public node has been down for months, hence the connection errors. Just need to set a different node in the configuration. I can also add the option to set multiple nodes.

Not sure what the point would be for two different offline flags - just make one the default and leave the other as an option. The only scenario where I see any point in it though is if the user only wants to run the software for energy management, without caring about profitability. As for testing, I'd keep that separate.

I'll add it to my task list.

[mj-xmr]

The module is fine, code doesn't magically break out of nowhere.

From a User's perspective it's broken. The only person who looks at it from other perspective is currently you.

Not sure what the point would be for two different offline flags

I believe I described it well enough. Some Users will expect it to work because they care about the profitability, while some will be OK with it being not delivered. You cannot enforce a policy on them. The test suite should expect the default setting or any fallbacks not to crash.

[endorxmr]

I've added support for multiple nodes, to provide at least some redundancy: endorxmr@fcd0581 (and also fixed a small bug in the next commit). I have left supportxmr's node in the config (assuming that it will come back at some point), and have added cake wallet's public node (which I assume should be reasonably stable and trustworthy for testing purposes).
Next up: properly handling the case when none of the configured nodes are available. For the --offline-try case (which I will call differently, because I find that name to be confusing relative to the actual behaviour), I'm thinking of including a few "trustworthy" public nodes as backups if the user-configured ones fail (and an option to strictly enforce only user-configured nodes, for maximum control).

Some Users will expect it to work because they care about the profitability, while some will be OK with it being not delivered. You cannot enforce a policy on them.

The issue here is how to set up the power usage simulation in the case where we can't fetch the mining difficulty from nodes (and thus have no difficulty prediction).

If you don't care about fiat profitability, then you can (will be able to) just set it to ignore the price stuff. But even from a pure energy management point of view, you still care about maximising the XMR/hash mined.
Technically one could just purely care about the energy management alone (i.e. control battery charge/discharge) and not about the XMR/hash, but at that point one might as well use other automation software that can already do that and forget about SolOptXMR anyway.

Also, since you can't mine without an internet connection anyway, fetching difficulty data to optimise XMR/hash is a free performance boost with basically no penalty.

I can implement the option for strict no api calls, but its only realistic purpose would be purely for testing the software. There are other features with higher priority.