refine miner status derivation logic and improve logging

[GitGab19]

This PR improves the way the status is derived from hashrate and power consumption when pyasic returns UNKNOWN.

Tested with my Bitaxe Gamma:

[markoceri]

Hi @GitGab19, I think the bug is in the _derive_miner_status() function and how state_map maps the function output to the miner state.

The _derive_miner_status() should return a boolean result so it can be mapped to the miner state from state_map but returns a MinerStatus type, which is always mapped with UNKNOWN.

Changing the function return type from MinerStatus to boolean, I think, solves the problem.

Assuming that the miner is mining because it is producing hashrate is not correct because even when the miner is turned off and is not consuming energy (within a minimum consumption threshold given, for example, by the fans), the hashrate could have values other than 0.

Try leaving the handling with the variable IDLE_WATTAGE_THRESHOLD = 100 and considering the miner turned on with the double condition; if it is producing hashrate and consuming power, then it is ON. Just change the function return type from MinerStatus to boolean and let me know if that works.

[GitGab19]

Ok, I just changed the _derive_miner_status() to return a Optional[bool] as you requested.

About the IDLE_WATTAGE_THRESHOLD = 100, I had to change it to 1, otherwise it won't detect active small miners (e.g Bitaxe consumes around 14W only).

[markoceri]

We could create a list of low-power devices, get the device type, compare it to the list and set IDLE_WATTAGE_THRESHOLD accordingly.

[GitGab19]

It doesn't make sense to reinvent the wheel IMO, we are calling _derive_miner_status() only when pyasic APIs are not able to detect the status. But this is happening only with bitaxes, where all the other miners supported by pyasic should work properly.

About the specific code inside _derive_miner_status(), if we see some hashrate there, it means the miner is working, and the check on the IDLE_WATTAGE_THRESHOLD is just an additional secondary check IMO.

[markoceri]

In our tests, we observed that in some cases, Pyasic wasn't correctly reporting the miner status, and even though it was turned off, the miner still produced a hashrate higher than 0 (issue on Pyasic: UpstreamData/pyasic#328 (comment)).

But I agree with you; let's leave it as it is, and if there are any issues with edge mining, we'll fix it later.

[GitGab19]

So you would leave the unknown status as it is now?

[markoceri]

Yes, in undetermined cases I would leave it unknown. What do you propose?

[GitGab19]

It's fine, I personally don't want to spend too much time on a minor thing like this one.