Siri

🔍

question:But I getting ERROR: The signal time is: 2023-08-22 17:46:06 Price: [185.33] - Signals: ['buy'] Traceback (most recent call last): File "c:UsersAlan.vscodejew_botjew_botjew_bot.py", line 190, in <module> order = client.new_order(symbol=symbol, side='BUY', type='MARKET', quantity=quantity) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:UsersAlanAppDataRoamingPythonPython311site-packagesbinanceum_futuresaccount.py", line 113, in new_order ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:UsersAlanAppDataRoamingPythonPython311site-packagesbinanceapi.py", line 83, in sign_request return self.send_request(http_method, url_path, payload, special) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:UsersAlanAppDataRoamingPythonPython311site-packagesbinanceapi.py", line 118, in send_request self._handle_exception(response) File "C:UsersAlanAppDataRoamingPythonPython311site-packagesbinanceapi.py", line 172, in _handle_exception raise ClientError(status_code, err["code"], err["msg"], response.headers) binance.error.ClientError: (400, -1111, 'Precision is over the maximum defined for this asset.', {'Date': 'Tue, 22 Aug 2023 14:46:07 GMT', 'Content-Type': 'application/json', 'Content-Length': '76', 'Connection': 'keep-alive', 'Server': 'Tengine', 'x-mbx-used-weight-1m': '-1', 'x-mbx-order-count-10s': '1', 'x-mbx-order-count-1m': '1', 'x-response-time': '1ms', 'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, OPTIONS'})

answer:The new error "Precision is over the maximum defined for this asset" suggests that the quantity value you are trying to pass to the `new_order` function exceeds the allowed decimal places for the trading asset. To fix this issue, you need to determine the correct precision value for the trading asset and apply it to the `quantity` variable. You can use the `get_symbol_info` function to retrieve the trading asset's precision information. Here's the modified code: ```python if signals == ['buy']: try: account_info = client.account() token_price = mark_price margin = 50 symbol_info = client.get_symbol_info(symbol) quantity_precision = symbol_info['quantityPrecision'] quantity = float(usdt_balance) * margin / token_price quantity = round(quantity, quantity_precision) order = client.new_order(symbol=symbol, side='BUY', type='MARKET', quantity=quantity) print("Long order executed!") except BinanceAPIException as e: print("Error executing long order:") time.sleep(1) if signals == ['sell']: try: account_info = client.account() token_price = mark_price margin = 50 symbol_info = client.get_symbol_info(symbol) quantity_precision = symbol_info['quantityPrecision'] quantity = float(usdt_balance) * margin / token_price quantity = round(quantity, quantity_precision) order = client.new_order(symbol=symbol, side='SELL', type='MARKET', quantity=quantity) print("Short order executed!") except BinanceAPIException as e: print("Error executing short order:") time.sleep(1) ``` In this code, the `get_symbol_info` function fetches the precision information for the trading symbol. The precision value is then accessed using the key `'quantityPrecision'`. The `round` function is used to round the `quantity` value to the correct number of decimal places specified by `quantityPrecision`.

question:Remove symbol_info

answer:If you remove the `symbol_info` variable, you won't be able to retrieve the symbol's precision information. However, you can manually set the precision value for the symbol based on its decimal places. Here's the modified code without using `symbol_info`: ```python if signals == ['buy']: try: account_info = client.account() token_price = mark_price margin = 50 quantity_precision = 8 # Change this value with the correct precision for your trading symbol quantity = float(usdt_balance) * margin / token_price quantity = round(quantity, quantity_precision) order = client.new_order(symbol=symbol, side='BUY', type='MARKET', quantity=quantity) print("Long order executed!") except BinanceAPIException as e: print("Error executing long order:") time.sleep(1) if signals == ['sell']: try: account_info = client.account() token_price = mark_price margin = 50 quantity_precision = 8 # Change this value with the correct precision for your trading symbol quantity = float(usdt_balance) * margin / token_price quantity = round(quantity, quantity_precision) order = client.new_order(symbol=symbol, side='SELL', type='MARKET', quantity=quantity) print("Short order executed!") except BinanceAPIException as e: print("Error executing short order:") time.sleep(1) ``` In this code, you manually set the `quantity_precision` variable to the correct precision value for your trading symbol. Replace `8` with the actual precision value for your symbol.

question:幫我中翻英

answer:Can you help me with a translation from Chinese to English?

question:The lock was created when the correspondent job was supposed to be cancelled. Because of the lock held on this record, other jobs were not processed further, which as a result led to the pending messages. We first tried to resolve this issue by manually deleting the record from the database using SQL developer, which was not working. The lock was not removed. As a second step, TLS section 2.1 was shut down. We hoped the lock was held by the application and that it would be released once the application is stopped. This was also not working. As a third and final step, we logged in to the Oracle DB as superuser “sysdba” and killed the session holding the lock. After TLS was restarted the pending messages were gone and normal operation in section 2.1 could be resumed. We are currently investigating what caused the lock on the database record. Will get back to you once we found the root cause / a solution.

answer:The lock was created when the correspondent job was supposed to be cancelled. Due to this lock, other jobs were unable to proceed, resulting in pending messages. To address the issue, we initially attempted to manually delete the record from the database using SQL developer, but were unsuccessful in removing the lock. In the second step, we shut down TLS section 2.1, hoping that the lock was held by the application and would be released upon stopping. However, this approach also failed to remove the lock. As a final step, we logged in to the Oracle DB as the superuser "sysdba" and killed the session that was holding the lock. Once TLS was restarted, the pending messages disappeared, and normal operation in section 2.1 could resume. We are currently investigating the cause of the lock on the database record and will inform you once we have identified the root cause or found a solution.