Skip to content

Releases: mj-xmr/SolOptXMR

Security fixes after a review (hashes)

24 Nov 10:45
@mj-xmr mj-xmr
v0.4.1
1bab693
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
Security fixes after a review (hashes) Latest
Latest

This release only replaces fixed versions (tags) of the 3rd party software (monero-core, xmrig & p2pool) with hashes of the same versions for security reasons.

What's Changed

  • Doc: Star history by @mj-xmr in #145
  • Using hashes of 3rd party software, rather than tags by @mj-xmr in #146

Full Changelog: v0.4.0...v0.4.1

Contributors

mj-xmr
Assets 2
Loading

First public release

18 Nov 06:34
@mj-xmr mj-xmr
v0.4.0
cf123e5
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
First public release 
v0.4.0

Disable donation (#144)
Assets 2
Loading

v0.4-rc2 Full automation (Milestone 4 of 4)

09 Nov 12:26
@mj-xmr mj-xmr
v0.4-rc2
c64f70c
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.4-rc2 Full automation (Milestone 4 of 4) Pre-release
Pre-release

Full automation (Milestone 4 of 4)

Brief

This version brings full automation (after an initial setup investment) and a lot of stability via fast corner case testing, that allowed me to fix prevailing bugs and enables further, risky experiments.

Major changes:

Change log

Full Changelog: v0.2-beta...v0.4-rc2

Contributors

endorxmr and mj-xmr
Assets 2
Loading

v0.4-rc1 Full automation (Milestone 4 of 4)

09 Nov 12:10
@mj-xmr mj-xmr
v0.4-rc1
16217e0
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.4-rc1 Full automation (Milestone 4 of 4) Pre-release
Pre-release

Full automation (Milestone 4 of 4)

Brief

This version brings full automation (after an initial setup investment) and a lot of stability via fast corner case testing, that allowed me to fix prevailing bugs and enables further, risky experiments.

Major changes:

Change log

Full Changelog: v0.2-beta...v0.4-rc1

Contributors

endorxmr and mj-xmr
Assets 2
Loading

Stability fix - no solutions during initial overvoltage & early stop limited

24 Jul 20:39
@mj-xmr mj-xmr
v0.3-beta
b4a07eb
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
Stability fix - no solutions during initial overvoltage & early stop limited Pre-release
Pre-release

What's Changed

  • Opti: No early stop until 1st solution is found by @mj-xmr in #84
  • Bugfix: no solution at initial overvoltage by @mj-xmr in #85

Full Changelog: v0.2-beta...v0.3-beta

Contributors

mj-xmr
Assets 2
Loading

v0.2-beta Measurements; OCR; Stability fixes

22 Jul 14:36
@mj-xmr mj-xmr
v0.2-beta
3f4f1f0
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.2-beta Measurements; OCR; Stability fixes Pre-release
Pre-release

Intro

This pre-release is one step before being able to automate the act of switching the mining on and off. It deals with supplying all the necessary measurements, yet still without the "Home Assistant" hardware, but rather the bare metal ones. It automates the part of acquiring the initial battery state - the only part that had to be supplied by hand to perform the simulation. Moreover, by adding a few more parameters to the battery.json, described in the configuration documentation, the required conversions from voltage to charge percentage are being performed.

Major changes

Charging and discharging voltage modelling

Thanks to the voltage modelling, we can now translate the voltage readouts to battery charge in percent, yielding a linear calculation, ultimately being able to translate voltage to Ah (Ampere-hours): a unit of energy capacity, that's much simpler for calculations.
As described in the main documentation, the voltage input can be triggered with:

./soloptxmr.py --battery-charge-v 12.3 # Set the voltage of your battery to be converted to its current charge

OCR

Thanks to an incorporation of GasPumpOCR project, it's possible to reuse the existing examples of OCR modules or to write your individual ones. The right parameters of such a module can be learned with an interactive script called playground.py of the GasPumpOCR project (example). See the new documentation. The OCR module can be generalized to just recognize certain rectangles, that could represent the battery charge in % already, rather than the raw voltages, like here . There's an example that does it as well.
Using the OCR module is done via:

./soloptxmr.py --battery-charge-ocr # Use image recognition to read the current battery voltage

Image capture

Closely related to OCR (and documented there) is a similarly interfaced image capture system, allowing you to write your own image capture models.

Temperature readouts

These will come very handy whenever there's a suspicion, that a given rig is overheating. In such an event the controlling PC will reduce the mining effort of the mining rig to let it cool down.

Optimization algorithm stability fixes

I noticed, that the algorithm behaved in an unstable way for a few reasons not worth mentioning. This part is simply being left in a working ad-hoc state for now, while I focus on the integration of many individual systems, like the ones mentioned above. There will come a time soon, when I'll focus on making the optimization algorithm work much better.

Full changes

What's Changed

New Contributors

Full Changelog: v0.1-beta...v0.2-beta

Contributors

dependabot and mj-xmr
Assets 2
Loading

MVP: Optimization, weather, habits & hashrates

29 May 05:13
@mj-xmr mj-xmr
v0.1-beta
909cc9d
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
MVP: Optimization, weather, habits & hashrates Pre-release
Pre-release

First release and an MVP

The 1st release concludes the 1st milestone described in the original description, plus a few very important features from the @endorxmr 's 2nd milestone, that also nears completition.

This together means, that except for the stub of the hashrate's seasonality, all the major components, that deal with physical properties of the system are being simulated and optimized. Additionally, the system helps in further leveraging the current hashrate situation, using Mean Reversion strategy, to further boost the collected hashes per unit of energy used for mining. The hashrate bonuses are a result of @endorxmr 's work, and my post-processing of what his module delivers. The post-processing is being done by tsqsim. Many further improvements can be still done on this front and this is what tsqsim is about: squeezing more from the publicly available data, that still is able to give you advantage over the careless type of competitors :)
Collectively, scooping the hashes this way also improves and stabilizes the network's security.

As far as the 1st milestone deals with optimization of collecting hashes while preventing battery's over-/undervoltage, the 2nd milestone will deal with profitability of the same act, measured in FIAT currency terms. Please note however, that this will be only a derivative of the collected hashes, and can thus be treated just as an additional layer for a User, who is dedicated to mine Monero and assumes being rewarded in FIAT later, at a higher price anyway.

Major achievements

As a starter, please see the Screenshots section. The individual achievements will be explained below. Here are the quickstart instructions, if you'd like to play around with the release.

Weather predictions

The output of a PV system is greatly influenced by weather conditions. The simulation takes this into account and whenever a cloudy weather is predicted, the system behaves much more conservatively.

Optimization

The optimizer is able to deliver multiple solutions and presents the User the one, which achieves the best score, measured by the sum of collected hashes. Whenever in a given solution the battery would be over-/undervolted, such solution becomes penalized and will thus not be taken into account. The horizon of such optimization is set to 4 by default but can be increased up to 8 days.
Obviously the longer the horizon, the poorer the weather predictions shall become. However, nothing prevents you from rerunning the simulation again with a state (battery charge) achieved in future, in order to correct any mistakes done earlier.

Extra documentation

I felt like I needed to let it all out, what I exactly think about safety and economy of the operation we're dealing with. Please see this section, if you like a quick blog-like read.

Habits

As explained in the economy article, many times it will make sense to rather use the electricity for domestic purposes, as the reward is immediate and without any competition. This is especially valid, if your PV system is of a tiny size. The habits configuration allows you to declare your predictable habits and mine when only these higher-priority needs (as defined by you), are satisfied and there's still enough power stored for mining.

Mining rig definition

Very related to habits are the mining rig definitions, with the difference, that they are assumed to be able to be started and switched off by the system on demand. More information can be obtained in this section.

Modeling solar arrays

Before even spending a dime, you might want to make a good plan how many panels to buy and where to place them. You might want to resist the mainstream idea of placing every panel with the same azimuth of 180° (exactly south) and tilt of 45°, for more diversification stabilizes your output across the day or even the whole year. The following section explains how to perform such experiments.

Console UI (almost done)

There's a console UI in works, whose prototype you may already execute with the src/ui_curses_menu.py script. In the future we'll present a GUI version of the UI, using exactly the same menu definitions, to avoid duplication, which are stored here.

What's Changed

New Contributors

Full Changelog: https://github.com/mj-xmr/SolOptXMR/commits/v0.1-beta

Contributors

endorxmr and mj-xmr
Assets 2
Loading