2023 full task description

[mj-xmr]

As mentioned in the main issue, this particular issue deals with the individual tasks themselves and the ability for you to vote for or against them individually.

If you wish to donate, please visit this page.

If you have an idea, that's not mentioned here, please discuss it first in the brainstorming thread.

[mj-xmr]

Distribution and CI

There are several ways one could improve the delivery mechanisms, as opposed to the currently only available way – installing everything into the current environment – has obvious disadvantages of polluting your environment. There are many other solutions, which include:

• Docker images
• Anaconda environment
• virtualenv

[mj-xmr]

Ports

The following ports are possible to be prepared and kept under Continuous Integration (CI)

• Windows port
• OSX fixes
• Rpi CI

Also I may use gitian, or similar software to cross compile the software across other platforms
And last but not least, it would make sense to minimize Python dependencies, based on User choices

[mj-xmr]

Search algorithm

The search algorithm should not be completely random (as in "brute force") and needs some guidance. My best candidates so far are:

• Monte Carlo search, that I already implemented in tsqsim
• Genetic algorithm
• decision tree

All these algos shall be interchangeable, using the same interface, that not only allows them to be directly comparable, but also allows you to write your own alternatives, for example for research purposes.

[mj-xmr]

Modularization and enabling future work

Generally speaking, I'd like every dependency, that the project uses, to be replaceable by anybody, without having to dig in the code, but rather by providing own modules that are simply being called. The list follows:

• interface for custom energy sources like wind
• Crypto exchange – for Fiat prices and hashrates
• Weather source
• solar position source
• type hints – making the code more readable for other Devs

It will also be very beneficial, if each of the alternatives were able to be called in case the preferred one fails, and lastly, an "offline" version should be called, that, even though its results are inferior, will always be guaranteed to be functional.

[mj-xmr]

Electrical modeling improvement

• Model voltage loss resulting from attaching consumers, depending on the cable lengths and how it affects the available resulting power at a given time – add an according penalty if it does.
• Full support of different voltage systems, other than 12V.
• Model voltage conversion losses.

[mj-xmr]

Documentation

Stuff that I'd like to document, but in order to keep it factually correct, like the already existing documentation is, I need to perform the due diligence on the topics.

• doc: fuses on battery, cables (industrial), MPPT's radiator, that can overheat and inverter's grounding. Mention synthetic load
• doc: measure and document battery voltage vs. temperature, esp. across the night.
• doc: grounding https://www.solaris-shop.com/blog/grounding-techniques-to-prevent-inverter-damage/

Gather info from:

• https://footprinthero.com/lifepo4-battery-voltage-charts
• https://pushevs.com/2018/01/29/2018-nissan-leaf-battery-real-specs/
• https://batteryuniversity.com/article/bu-808-how-to-prolong-lithium-based-batteries
• https://www.rebel-cell.com/knowledge-base/the-discharge-and-capacity-of-batteries/

[mj-xmr]

Minor

• increase the console plots resolution by arbitrary number of line plots by stacking N blocks on top of one another. Most of the code for this is already written, just needs to be refactored & tested
• automatically scramble the geo location – to hide the physical location of your farm, in case your PC gets compromised.
• present multiple solutions in a HTML file (Partly done: using console)
• scheduling for further days requires setting these days for the at command as well (+ tests of course)
• distributing the simulation results onto a website

[mj-xmr]

Compare historical results

Compare historical results against each other across time, to measure the discrepancy – this would allow to detect faster where effort needs to be made in order to improve the quality of the simulation

[mj-xmr]

Scheduled energy production

Scheduled energy production with generators, in a format similar to habits.

Imagine, that you realize that there's currently not enough solar power available, but you would like to model an actual manual addition of the charge to your batteries, using either a diesel generator, a generator bike or a portable hand crank generator. You could also define these "addition habits" so, that you'd use them only when the currently available battery charge falls below a certain threshold, also defined by yourself.

[mj-xmr]

Detailed cloud forecast

The cloud forecast can be made much more elegantly and precisely, using information gathered at least in the following sources:

• https://github.com/pvlib/pvlib-python/blob/v0.9.0/pvlib/forecast.py
• https://pvlib-python.readthedocs.io/en/stable/user_guide/forecasts.html#cloud-cover-and-radiation
• https://solarforecastarbiter-core.readthedocs.io/en/stable/reference-forecasts.html

This will greatly improve the quality of the simulation.

[mj-xmr]

Leverage Boost Units 

Use Boost Units library to avoid potential conversion errors.
Boost Unit offers a great way to handle various SI units, protecting you from mistakes that classify as mathematical operations on incompatible units, like: adding power to charge, or accumulating charge, which was already accumulated, because you thought that you were accumulating power to end up with charge.

[mj-xmr]

Synthetically increasing the load

During days of rapidly alternating clouded/sunny sky helps reducing the shock on the inverter
This unpleasant effect is described in the safety documentation

Whenever the cloud/sun alteration occurs, artificially increasing the load protects your inverter from getting too high a voltage due to slow MPPT controller's reaction time, which would otherwise cease the inverter's operation.

[mj-xmr]

Hashrate predictions

Incorporate Hashrate predictions into model – it's possible to use tsqsim to not only give you the objective value of current state of the hashrate's relative profitability, but a finer grained prediction could be performed, that would further boost your collected hashes.

Focusing on this subject will undoubtedly pave the road for further research into Monero itself, whose blockchain can be equally treated as a Time Series, as the very same tool: tsqsim has been approved by the MAGIC Panel, as the tool of choice for really fast and dynamic parameter adjustments on the fly.

[mj-xmr]

UIs: console + curses + Qt

There's a WIP demo, that can be executed with src/ui_curses_menu.py , which displays pictures like below:

https://user-images.githubusercontent.com/63722585/163773221-52705e53-167b-4468-ad7e-2038c2f822a8.png

https://user-images.githubusercontent.com/63722585/163773424-64711673-ce88-4a49-a1fc-0c16526e623d.png

https://user-images.githubusercontent.com/63722585/163773989-c00c180a-43ab-408d-be97-5624c099d148.png

but I was never able to get to this point. The idea is to use just one data model and schema (already prepared here ) to deliver several types of UI – from putty-friendly console ones, to desktop-friendly Qt.

[mj-xmr]

Habits dynamic UI

• choose habits via console and their text ID: It would be great, if the pre-defined habits were able to be selected by the User upon running the simulation, in case the User knows that the given habit will be executed right now, in order to see its impact on the overall situation. Perhaps it will make the User to alter the decision, upon seeing the unacceptable battery drainage.
• habits need to be able to be declared as optional, and ran only when there's enough power: Some habits are simply "nice to have", or "can be done later". The User should be able to decide about them.

[mj-xmr]

Enabling crypto currencies other than XMR

This is a tongue-in-cheek feature, but I need to ask you about it. Especially if the only reason for you to donate to the project would be, that you may switch the currencies, when you need it, like those which use GPUs.

Going in this direction will require a lot of additional work, as for example: a given computer might have a possibility to mine XMR and some GPU coin at the same time, but it has to be taken into account when making the decision, if mining the GPU one currently makes sense in a scenario, that its hashrate already went through the roof. This extends the current "all or nothing" model.

Also, I couldn't use the hashrates as a decision criterion only, as I do now, because I'd have to resort to the USD prices of each of the coins, to be able to compare them under a common denominator. This complicates the system, which had however already been prepared for this extension at the same time.

Due to this task's controversial nature, it will be treated differently: I will only do it at the end of queue of other tasks, unless they're not funded at all. In such case, I'd however expect an adequate weight to be put on this particular donation address, beyond its maximal declared value. Then the remaining funds from this tasks shall be used for other tasks.

[mj-xmr]

Business model introduction

Another tongue-in-cheek one. I have the possibility of enabling automated mining donations ("dev fee") to collect something like ~2% from every End User. I sincerely don't expect a lot of income this way, but I have to give you freedom of choice on this one. Perhaps I won't need to announce further fundraisers, if it does work OTOH.

Enabling this could however open up an interesting future research topic, that, based on the time of collected anonymous fees alone, could help identifying how the current weather (or climate) affects the usage of the software. OTOH, you might be against it exactly because you DON'T WANT to have this potentially fingerprintable data getting "leaked".

There might be even such Users/Donators, who could vote for this feature, in order to be able to install a tailored version of this software at their Customer's farm, which redirects the dev fee towards their own servers. The GPL license, that this software uses, doesn't prohibit you from making profits on Free Software. I'm happy from every supportive User.

Exactly in the same way as with the "other crypto currencies" task, I will only do it at the end of queue of other tasks.