Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

S19 Stock Firmware does not respond to start / stop mining toggle switch. #424

Open
damanic opened this issue Nov 11, 2024 · 30 comments
Open

Comments

@damanic
Copy link

damanic commented Nov 11, 2024

First time trying this out on HA.

I am unable to start or stop mining using the toggle switch switch.antminer_s19_active . It has no effect either way.

Here is the debug log when trying to Resume mining when the miner is in 'sleep mode'

2024-11-11 20:08:50.311 DEBUG (MainThread) [custom_components.miner.switch] Antminer S19: Resume mining.
2024-11-11 20:08:53.858 DEBUG (MainThread) [custom_components.miner.coordinator] Found miner: S19 (Stock): 10.0.23.11
2024-11-11 20:08:54.151 DEBUG (MainThread) [custom_components.miner.coordinator] Got data: MinerData(ip='10.0.23.11', datetime='2024-11-11T20:08:53.859188+11:00', timestamp=1731316133, device_info=DeviceInfo(make=<MinerMake.ANTMINER: 'AntMiner'>, model=<AntminerModels.S19: 'S19'>, firmware=<MinerFirmware.STOCK: 'Stock'>, algo=SHA256Algo), make='AntMiner', model='S19', firmware='Stock', algo='SHA256', mac='PRIVATE', api_ver=None, fw_ver='Tue Dec  6 16:10:00 CST 2022', hostname='Antminer', hashrate=0.0 TH/s, expected_hashrate=95.0 TH/s, expected_hashboards=3, expected_chips=228, expected_fans=4, percent_expected_chips=100, percent_expected_hashrate=0, percent_expected_wattage=None, temperature_avg=19, env_temp=None, wattage=None, wattage_limit=None, voltage=None, fans=[Fan(speed=960), Fan(speed=960), Fan(speed=960), Fan(speed=960)], fan_psu=None, hashboards=[HashBoard(slot=0, hashrate=0.0 TH/s, temp=18.75, chip_temp=18.75, chips=76, expected_chips=76, serial_number='PRIVATE', missing=False, tuned=None, active=None, voltage=None), HashBoard(slot=1, hashrate=0.0 TH/s, temp=18.25, chip_temp=18.25, chips=76, expected_chips=76, serial_number='PRIVATE', missing=False, tuned=None, active=None, voltage=None), HashBoard(slot=2, hashrate=0.0 TH/s, temp=18.75, chip_temp=18.75, chips=76, expected_chips=76, serial_number='PRIVATE', missing=False, tuned=None, active=None, voltage=None)], total_chips=228, nominal=True, config=None, fault_light=None, errors=[], is_mining=False, uptime=None, efficiency=None, pools=[])
2024-11-11 20:08:54.151 DEBUG (MainThread) [custom_components.miner.coordinator] Finished fetching Antminer S19 data in 0.326 seconds (success: True)

Running the last available stock firmware
Antminer-S19-merge-release-20221227070716.bmu

I have confirmed that I am able to login via SSH and backend using same credentials passed to HA integration.

Any tricks to getting this working on stock firmware?

`

@b-rowan
Copy link
Collaborator

b-rowan commented Nov 11, 2024

Seems like the switch was toggling resume, but didn't log a shutdown?

It doesn't use the SSH credentials, it sends to the web UI /cgi-bin/set_miner_conf.cgi, but some versions of the firmware use an integer for the mode, and some use a string, and it seems like they don't do any conversion between them. Possible that's the issue, but not sure how to enable a flag for that.

@damanic
Copy link
Author

damanic commented Nov 11, 2024

@b-rowan
I started looking at posting to backend when I noticed it used auth digest, soon after I realised this is what pyasic does already.

Whilst looking at the post data I saw the values for mode are:

0 = Normal
1 = Sleep
3 = Low power

This is the latest/last firmware for the S19, so really the integer values should be submitted in favour of string. BUT considering this is such a basic issue that you are already aware of I suspect we are dealing with a set of mode constants that are reused across all 'antminers' , is that correct?

I really need to be able to switch between modes 0, 1, 3 for my automations in HA. Any ideas on how to resolve this would be great.

@b-rowan
Copy link
Collaborator

b-rowan commented Nov 11, 2024

I suspect we are dealing with a set of mode constants that are reused across all 'antminers' , is that correct?

Yeah pretty much. Here's a reference for the file that does this - https://github.com/UpstreamData/pyasic/blob/master/pyasic/config/mining/__init__.py

It also is defaulting to using an int, so not sure if that's the specific issue, but I've tested this lots (wayyy too much actually lol), so idk what could be going wrong.

@damanic
Copy link
Author

damanic commented Nov 11, 2024

@b-rowan
I will take another look to see what I can find.

How best for me to intercept/log the POST data being sent from HA/pyasic to my miner?

Also is there supposed to be an exposed control in HA for setting the low power mode? Apart from sensors I only havea one control exposed , and that's the active toggle switch

image

@b-rowan
Copy link
Collaborator

b-rowan commented Nov 11, 2024

There is no exposed item for low power mode. Honestly it's easiest if you just install BraiinsOS on the miner, they have much less stupid on/off design, and you can set a power limit in addition to on/off.

With regards to intercepting it, you pretty much need to use wireshark or something.

@damanic
Copy link
Author

damanic commented Nov 11, 2024

@b-rowan
Ok I will try and figure out an intercept for post data to see what is going on there.

The stock firmware with the three modes fits my use case, so hopefully I don't need to run BraiinsOS firmware with dev fee.

Pyasic has the s19 stock firmware as supported so this should work out. It is also aware of the low power mode, so I should be able to get a control for that in HA.

Any reason why a dropdown select is not offered for power mode?

@b-rowan
Copy link
Collaborator

b-rowan commented Nov 11, 2024

Any reason why a dropdown select is not offered for power mode?

Mainly because I'm too stupid to know how to do that in home assistant...

Pyasic has the s19 stock firmware as supported so this should work out. It is also aware of the low power mode, so I should be able to get a control for that in HA.

I'm very aware of that, considering I wrote the thing. X19 has been a consistent problem on stock firmware, seems like they change stuff every so often that is just completely incompatible.

@damanic
Copy link
Author

damanic commented Nov 11, 2024

@b-rowan
Excuse my ignorance. I can see now you are also a DEV on pyasic. I'm just trying to figure out how it all works and where the limits are.

You have a much broader perspective on this. I have a narrow focus on my S19 that is very unlikely to get any more firmware updates from antminer, it hasn't since 2022. So I think there is a solution here worth implementing, one that will stick.

I will keep looking. Thanks.

@b-rowan
Copy link
Collaborator

b-rowan commented Nov 11, 2024

So I think there is a solution here worth implementing, one that will stick.

I agree, I just need to figure out how to get it into HASS in a nice way.

@damanic
Copy link
Author

damanic commented Nov 12, 2024

Was hoping to inject a logger dump in pyasic directly to dump all POST data.

Unfortunately the HAOS SSH environment seems to be restricted , even hiding things from me. I cant find the pyasic lib used by hass-miner.

Do you know how to access it? Logging the HTTP coms between pyasic and miner should be easier than this right?

@b-rowan
Copy link
Collaborator

b-rowan commented Nov 12, 2024

Was hoping to inject a logger dump in pyasic directly to dump all POST data.

Unfortunately the HAOS SSH environment seems to be restricted , even hiding things from me. I cant find the pyasic lib used by hass-miner.

Do you know how to access it? Logging the HTTP coms between pyasic and miner should be easier than this right?

Should be able to edit it in ~/custom_components/miner/

Pyasic uses httpx, so if you up the loglevel for that it might be useful, but HASS uses it too...

@damanic
Copy link
Author

damanic commented Nov 12, 2024

Yeah I found the component, and can see it imports pyasic, but there is no trace of any python deps on the filesystem when I search. So cant get to httpx either.

Maybe things are hidden because I am accessing via the Terminal & SSH addon.....

I guess I will have to hook up a monitor and keyboard directly and try again, another day.

@damanic
Copy link
Author

damanic commented Nov 14, 2024

@b-rowan
Some progress. I have learnt that the py deps are in the homeassistant docker container. Once I got elevated access at command line I was able to edit the antminer.py in the container to dump debug logs around the HTTP requests.


2024-11-14 15:57:56.257 DEBUG (MainThread) [pyasic.antminer] Sending antiminer GET command to http://10.0.23.11:80/cgi-bin/get_miner_conf.cgi
2024-11-14 15:57:56.321 DEBUG (MainThread) [pyasic.antminer] Received response from http://10.0.23.11:80/cgi-bin/get_miner_conf.cgi with status: 200
2024-11-14 15:57:56.322 DEBUG (MainThread) [pyasic.antminer] Response content:

{
"pools" : [
**REDACTED**
]
,
"api-listen" : true,
"api-network" : true,
"api-groups" : "A:stats:pools:devs:summary:version",
"api-allow" : "A:0/0,W:*",
"bitmain-fan-ctrl" : false,
"bitmain-fan-pwm" : "100",
"bitmain-use-vil" : true,
"bitmain-freq" : "675",
"bitmain-voltage" : "1400",
"bitmain-ccdelay" : "0",
"bitmain-pwth" : "0",
"bitmain-work-mode" : "0",
"bitmain-freq-level" : "100"
}

2024-11-14 15:57:56.325 DEBUG (MainThread) [pyasic.antminer] Sending antiminer command to http://10.0.23.11:80/cgi-bin/set_miner_conf.cgi with parameters: {'bitmain-fan-ctrl': False, 'bitmain-fan-pwn': '100', 'freq-level': '100', 'miner-mode': 0, 'pools': [**REDACTED**]}
2024-11-14 15:58:01.345 ERROR (MainThread) [pyasic.antminer] HTTP error occurred while accessing http://10.0.23.11:80/cgi-bin/set_miner_conf.cgi:
2024-11-14 15:58:01.355 DEBUG (MainThread) [pyasic.antminer] Full exception details:
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/httpx/_transports/default.py", line 72, in map_httpcore_exceptions
    yield
  File "/usr/local/lib/python3.12/site-packages/httpx/_transports/default.py", line 377, in handle_async_request
    resp = await self._pool.handle_async_request(req)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/httpcore/_async/connection_pool.py", line 216, in handle_async_request
    raise exc from None
  File "/usr/local/lib/python3.12/site-packages/httpcore/_async/connection_pool.py", line 196, in handle_async_request
    response = await connection.handle_async_request(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/httpcore/_async/connection.py", line 101, in handle_async_request
    return await self._connection.handle_async_request(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/httpcore/_async/http11.py", line 143, in handle_async_request
    raise exc
  File "/usr/local/lib/python3.12/site-packages/httpcore/_async/http11.py", line 113, in handle_async_request
    ) = await self._receive_response_headers(**kwargs)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/httpcore/_async/http11.py", line 186, in _receive_response_headers
    event = await self._receive_event(timeout=timeout)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/httpcore/_async/http11.py", line 224, in _receive_event
    data = await self._network_stream.read(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/httpcore/_backends/anyio.py", line 32, in read
    with map_exceptions(exc_map):
  File "/usr/local/lib/python3.12/contextlib.py", line 158, in __exit__
    self.gen.throw(value)
  File "/usr/local/lib/python3.12/site-packages/httpcore/_exceptions.py", line 14, in map_exceptions
    raise to_exc(exc) from exc
httpcore.ReadTimeout

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/pyasic/web/antminer.py", line 82, in send_command
    data = await client.post(
           ^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/httpx/_client.py", line 1905, in post
    return await self.request(
           ^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/httpx/_client.py", line 1585, in request
    return await self.send(request, auth=auth, follow_redirects=follow_redirects)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/httpx/_client.py", line 1674, in send
    response = await self._send_handling_auth(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/httpx/_client.py", line 1702, in _send_handling_auth
    response = await self._send_handling_redirects(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/httpx/_client.py", line 1739, in _send_handling_redirects
    response = await self._send_single_request(request)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/httpx/_client.py", line 1776, in _send_single_request
    response = await transport.handle_async_request(request)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/httpx/_transports/default.py", line 376, in handle_async_request
    with map_httpcore_exceptions():
  File "/usr/local/lib/python3.12/contextlib.py", line 158, in __exit__
    self.gen.throw(value)
  File "/usr/local/lib/python3.12/site-packages/httpx/_transports/default.py", line 89, in map_httpcore_exceptions
    raise mapped_exc(message) from exc
httpx.ReadTimeout

So this confirms that GET requests for status are working as expected. And that the correct miner-mode is being sent when attempting to toggle the active state.

BUT we have a HTTP error when posting to set_miner_conf.cgi which is why the active state toggle is not working.

It appears to be a timeout issue.

Any idea what the problem is here?


For comparison, here is the JSON payload sent via Antminer backed UI to set_miner_conf.cgi

{"bitmain-fan-ctrl":false,"bitmain-fan-pwm":"100","miner-mode":0,"freq-level":"100","pools":[**REDACTED**]}

Taking about 13 seconds to respond with payload:

{"stats":"success","code":"M000","msg":"OK!"}

The only difference in POST payload is the order of params and that the boolean value for "bitmain-fan-ctrl" is lower case on backend UI post vs Capitalised on pyasic post.

@damanic
Copy link
Author

damanic commented Nov 14, 2024

@b-rowan
In firefox console I resent a successful request changing the payload to use Capital False instead of false

{"bitmain-fan-ctrl":False,"bitmain-fan-pwm":"100","miner-mode":0,"freq-level":"100","pools":[REDACTED]}

This results in response

{"stats":"error","code":"M001","msg":"Illegal request!"}

Changing back to lower case make the requests successful.

{"stats":"success","code":"M000","msg":"OK!"}

So it looks like pyasic antminer.py needs to be updated to send lower case boolean, at least for the S19.

EDIT: Scrap that. I was debug logging the parameters var that appeared to be json in log but I realise now that it is just the format debug outputs when it converts the obj to string. The client json=parameters almost certainly will convert all values to valid json (lowercase) . So this is not the issue.

Also tried order of params in the post payload - not the issue.

@b-rowan
Copy link
Collaborator

b-rowan commented Nov 14, 2024

EDIT: Scrap that. I was debug logging the parameters var that appeared to be json in log but I realise now that it is just the format debug outputs when it converts the obj to string. The client json=parameters almost certainly will convert all values to valid json (lowercase) . So this is not the issue.

I was gonna say, but good catch. This is a weird issue, it seriously seems like the miner is attempting to apply the change and failing, but usually it doesn't timeout like that. That being said, AFAIU on the web UI, it doesn't timeout take a while for the command to get sent and applied, so it's possible the timeout is just too short or something, but the miner settings should still update.

@b-rowan
Copy link
Collaborator

b-rowan commented Nov 14, 2024

You're doing enough work here inside a hass docker container, it might just be easier to run up Python on another machine, install pyasic, and test with that. The commands are pretty easy, basically get_miner into get_config into send_config. Can write a script if you need one.

@damanic
Copy link
Author

damanic commented Nov 14, 2024

@b-rowan
I increased the timeout on the client to 30 seconds and now I get a success response logged. BUT no change on the miner.

2024-11-14 17:23:35.768 DEBUG (MainThread) [pyasic.antminer] Sending antiminer command to http://10.0.23.11:80/cgi-bin/set_miner_conf.cgi with parameters: {'bitmain-fan-ctrl': False, 'bitmain-fan-pwn': '100', 'freq-level': '100', 'miner-mode': 1, 'pools': [**REDACTED**]}
2024-11-14 17:23:35.768 DEBUG (MainThread) [pyasic.antminer] Using username: root and password: root
2024-11-14 17:23:48.405 DEBUG (MainThread) [pyasic.antminer] Received response from http://10.0.23.11:80/cgi-bin/set_miner_conf.cgi with status: 200
2024-11-14 17:23:48.406 DEBUG (MainThread) [pyasic.antminer] Response content: {"stats":"success","code":"M000","msg":"OK!"}

Was hoping a simple debug log on the post data would point to the issue.... oh well. I might try and run pyasic and put the debug on httpx to see what the actual json payload looks like. Another day!

@damanic
Copy link
Author

damanic commented Nov 14, 2024

@b-rowan

I set up a command line script using effectively the same post method with Auth.Digest.

The script works.

import sys
import httpx
import logging
from httpx import RequestError, HTTPStatusError

# Set up logging for detailed debug output
logging.basicConfig(level=logging.DEBUG)

# Constants for miner configuration
IP_ADDRESS = "10.0.23.11"  # Replace with actual IP address
USERNAME = "root"
PASSWORD = "root"

# Set mode mappings
modes = {
    "on": 0,     # Normal
    "off": 1,    # Sleep
    "low": 3     # Low Power
}

async def set_miner_mode(mode):
    """Send a POST request to set the miner mode."""
    # Check if mode is valid
    if mode not in modes:
        print(f"Invalid mode. Choose one of: {', '.join(modes.keys())}")
        return

    # Prepare the payload and target URL
    payload = {"miner-mode": modes[mode]}
    url = f"http://{IP_ADDRESS}/cgi-bin/set_miner_conf.cgi"
    auth = httpx.DigestAuth(USERNAME, PASSWORD)

    try:
        async with httpx.AsyncClient(timeout=httpx.Timeout(30.0)) as client:
            # Send POST request with Digest authentication
            response = await client.post(url, auth=auth, json=payload)

            # Raise an error if the status code indicates failure
            response.raise_for_status()
            print("Mode set successfully:", response.json())

    except HTTPStatusError as e:
        # Capture HTTP-specific errors, such as 401 Unauthorized or 404 Not Found
        print(f"HTTP error occurred: {e.response.status_code} - {e.response.text}")
    except RequestError as e:
        # Capture all other request errors and show a more detailed error message
        print(f"Network error occurred: {e}")
        print(f"Cause of the network error: {e.__cause__}")
    except Exception as e:
        # Catch any other exceptions that may occur
        print(f"An unexpected error occurred: {str(e)}")

# Command-line interface for setting the miner mode
if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("Usage: python miner.py <on|off|low>")
    else:
        mode = sys.argv[1].lower()
        import asyncio
        asyncio.run(set_miner_mode(mode))

As you can see in this example, simply sending the miner-mode on its own in the payload is enough, there is no need to GET values from the ASIC to post it all back.

I'm not sure what is going on with the hass-miner->pyasic post request for it to effectively do nothing. I can only guess it is something to do with timeouts or perhaps there is more than one request being fired off at the same time or too many requests too close to each other. It is hard to pin down that's for sure.

Control of the miner through automation is the most valuable feature, so it's a shame it doesn't work with Antminer firmware. If this integration had a dropdown that could change mode and also serve as a readout for current active mode, it would be so perfect.

I will most likely add this simple HTTP post script as a service in HA, hook up some switches/buttons, tie it into some automation and be done with it.

Sorry I couldn't figure it out, I can only hope there is a clue in here somewhere that helps you find and fix the issue.

@b-rowan
Copy link
Collaborator

b-rowan commented Nov 14, 2024

Sorry I couldn't figure it out, I can only hope there is a clue in here somewhere that helps you find and fix the issue.

No worries man, you did a lot more than I expect for most people when troubleshooting stuff like this. Thanks for all the help.

Sadly I'm not really sure what the issue is here even after all that, but I will look into adding a dropdown, and maybe that will help.

@b-rowan
Copy link
Collaborator

b-rowan commented Nov 19, 2024

I found something really interesting while reworking some pyasic internals, namely that the values for the config were not initialized properly when setting sleep/normal mode. Not sure how I didn't catch this before, but should hopefully be out in the next major version once all my other changes get merged.

Here's the changes (the ones in antminer.py are the issue -
UpstreamData/pyasic@8aa95b3

@928driver
Copy link

@b-rowan does this mean it will be possible to control sleep/normal/low power mode for stock Antminer firmware? If that is the case, it sounds awesome!

@b-rowan
Copy link
Collaborator

b-rowan commented Nov 22, 2024

@b-rowan does this mean it will be possible to control sleep/normal/low power mode for stock Antminer firmware? If that is the case, it sounds awesome!

No, not that specifically, it just means that the device will actually be able to shut down now.

That being said however, I did sit down and spend some time today doing that part of the integration with a select dropdown, its on 1.1.19rc2 if anyone wants to try it out and lmk if it works 😉 ...

@damanic
Copy link
Author

damanic commented Nov 22, 2024

Dropdown would be amazing. Is there a way to run a RC/pre release in HACS?

Eager for this to replace my work around for setting miner mode using shell_command in (config yaml) and input buttons (helpers).

image

shell_command:
  miner_mode_on: >
    curl -X POST -u "root:root" --digest -H "Content-Type: application/json"
    -d '{"miner-mode": 0}' http://10.0.23.11/cgi-bin/set_miner_conf.cgi

  miner_mode_off: >
    curl -X POST -u "root:root" --digest -H "Content-Type: application/json"
    -d '{"miner-mode": 1}' http://10.0.23.11/cgi-bin/set_miner_conf.cgi

  miner_mode_low: >
    curl -X POST -u "root:root" --digest -H "Content-Type: application/json"
    -d '{"miner-mode": 3}' http://10.0.23.11/cgi-bin/set_miner_conf.cgi
    

Dropdown would be so much tidier and give feedback on which mode is currently active.

@b-rowan
Copy link
Collaborator

b-rowan commented Nov 22, 2024

I think you just redownload with the allow prereleases option? Mine just shows pre-releases, I might have changed a setting a while ago...

@damanic
Copy link
Author

damanic commented Nov 22, 2024

@b-rowan
Have RC2 installed... What is the entity ID I should be adding to dashboard to get the dropdown?

@b-rowan
Copy link
Collaborator

b-rowan commented Nov 22, 2024

You might have to reistall the device?

@damanic
Copy link
Author

damanic commented Nov 22, 2024

@b-rowan
I think I will wait for release proper and if reinstall device is required will do it on a day when I have more time - just in case it breaks my automations.

@b-rowan
Copy link
Collaborator

b-rowan commented Dec 23, 2024

Ok, I think I fixed it after some extensive testing, it should allow you to set power mode in 1.1.19.

@928driver
Copy link

@b-rowan I updated to the last release and the dropdown selection showed up for the power select for stock Antminer firmware, thank you! But the options are Normal, High and Low so it works to change between Normal which is also High and Low power mode, but seems that none of them are triggering the sleep mode. Is it possible to add a selection for sleep?

@b-rowan
Copy link
Collaborator

b-rowan commented Dec 25, 2024

@b-rowan I updated to the last release and the dropdown selection showed up for the power select for stock Antminer firmware, thank you! But the options are Normal, High and Low so it works to change between Normal which is also High and Low power mode, but seems that none of them are triggering the sleep mode. Is it possible to add a selection for sleep?

Sleep mode is the active trigger, they have to be separate because they are handled different for different miners in pyasic. You can turn off the miner with the active switch, then turn them back on with the mode selector.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants