-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Updated for monitoring multiple coins simultaneously and other improvements #77
Conversation
Let me continue to test in my local and merge when it is confident this is working. |
Codecov Report
@@ Coverage Diff @@
## master #77 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 40 47 +7
Lines 819 994 +175
Branches 86 115 +29
==========================================
+ Hits 819 994 +175
Continue to review full report at Codecov.
|
Testing it now.... will let you know if I find something wrong... |
Testing with 24 symbols... the only thing I've found so far is that when I add a new symbol in Global Settings it takes a while for it to show up in the GUI... I guess that's OK and works that way since new binance server component was added. It seems to be working fine... will wait until a couple of orders get executed... I am a little concerned with reaching API limits when using many symbols... can you please clarify how many API calls is the bot doing in case you have for instance, 10 different symbols configured? |
I see this is also implementing #59 |
OK, I've added more symbols. |
Buy orders are a no go... they likely have some bug related to the fact that updates are now made every second for all symbols... something is getting really messed with that. |
Good point. I will update it. |
Hmmmm, ok I think I know what to do. It could be placing an order taking more than 1 second, and the next tick process the same action. Besides this, I also currently have a strange issue that the last buy price is not saved, which should be. :(
I agree, since monitoring multiple coins, it is so unpredictable. Thank you for testing, let me update some code and get back to you. |
I have implemented a locking symbol mechanism to prevent duplicated processes. If the symbol is locked, then the process will not perform any action. I hope this can fix the issue with making multiple transactions. To update, run following commands
|
Nice, already updated here... testing to see how it works... |
With this change, it will never be over API limits unless 24 symbols suddenly buy/sell all together. Here are Binance API limits:
These are detailed API calls:
Hence the
Minimum is 420 weights, plus the number of orders with cancellation * 13 weights (or if cancel failed 7 weights, but let's assume cancelling an order is always working) So summing up, 420 base weights + 60 orders * 13 weights = 1200 weights. So basically, unless the bot is making 60 orders within a minute, it won't be exceeding the 1200 request limit. Hope I made it clear to you. |
@chopeta NPXS transferd to PUNDIX |
To run
|
@garyng Wow thanks for the tip. Could you add to wiki please? https://github.com/chrisleekr/binance-trading-bot/wiki/Troubleshooting |
@chrisleekr: I created a powershell script so that others would not need to tinker with npm config: #175. Can you take a look and maybe merge it if it's okay? |
@garyng So good. I will merge in. |
* Add powershell scripts for docker build on windows * Use switch instead
@garyng Merged! |
It seems that was not the issue, it was just a coincidence, after restarting containers, even with these 2 config lines or not, the bot doesn't display anything on frontend and has the same errors as before
As I said , bot was deployed on brand new VM with Ubuntu 20.04.02 LTS 64bit, with NO other software installed, just docker, docker-compose and npm for building the image. I even deleted ALL volumes and images, redeployed again and the same issue is happening. Any thoughts on how to debug what the bot receives from Binance ? The only difference i see from the master branch is that the jobs are handled differently, on this branch you have and extra "server-binance.js" which handles the candles and websocket, and master branch doesn't have this file and handles the operations in a different manner Also, WS logs from Chrome: |
Let's open a new issue and start from there. |
With the latest commit, the bot will disable action for 20 seconds after confirming an order per coin.
It also fixed the issue of not selling the coin like ALHPABTC. ALPHABTC's step size was Also, you will be able to see current API usage in the slack message. You know what to do for updating.
|
Ok, looks like the latest change made the bot more stable. I tested with an aggressive strategy and lost money, but I happily confirmed there was no missing last buy price and the order was placed correctly. I even experienced the failure in cancelling the order, which is handled well with the bot. I will run for few days and see how it goes. I think it's time to merge in. |
Failing for me with |
Are these 20 seconds hardcoded in the code? It could be cool to allow users to tune them. Sometimes 20 seconds are too many to wait for. |
Works great on test, but can't get it to work with Binance.US. |
@Naramsim Oh hmm, interesting. Customising that value can cause the failure of placing the order. Hmm, I may add to the environment parameter to customise it instead of in the UI since that is a configuration for running the system. |
I have added a new environment parameter to control disable action seconds after confirming the order. You can open your
And then you know what to do
|
Cool, thanks for the addition. Why do you think setting a timeout of 5 (or even 1) seconds would break the bot? I'm asking this question since the market is often very volatile and stop-limit orders can be filled pretty quickly. So I was expecting that the frequency of API calls when there is a stop-limit order in place should be the highest. Well, anyways, thanks a lot for addressing my request. PS: I'd change the description from -> to -Set the second for disabling the action after confirming the order. Note that decreasing this value can cause the issue with the bot acting wrong.
+Set the seconds for disabling any actions after confirming an order. Note that decreasing this value can cause issues with the bot acting in a wrong way (maybe specify the risks and what are the wrong ways). |
Oh thanks, man. I just updated the config description with why it may not work well if reduces the second (and typo).
When the market is volatile, Binance API became busy and slow response. Sometimes it does not return the response of the open orders immediately (or sometimes more than 5-30 secs). It's because of too many requests to process. The bot is checking the order in the open order API request every second to make sure the order is showing in Binance after placing the order. However, the bot is also trying to figure out what to do whether to buy/sell/remove the last buy price as well. Unexpectedly the bot seems too fast to check before confirming the order. The solution was to give the bot some time to disable any actions until the order is definitely confirmed in the open order. Hope it answered your question. |
Ok, guys. I am merging in. |
Description
The change is focused to reduce the Binance API call weight.
trailingTradeIndicator
has been added.binance
has been added.trailingTrade
has been updatedtrailingTradeIndicator
job andbinance
WebSocket.With this change, the bot can monitor many coins every second.
This change does not expect to lose existing data.
If anyone would like to test it, please checkout the branch
feature-monitoring-simultaneously
and build the docker image, then relaunch the bot with docker-compose.Related Issue
#52 #59 #90 #104 #93 #85 #99
Motivation and Context
Currently, the bot is monitoring coins one at each second. If you have many coins to monitoring, there will be many gaps between each tick per coin. To avoid that kind of issue, it was necessary to monitor the coin's current value simultaneously.
The suggestion was from @ienthach
How Has This Been Tested?
The test coverage is 100% and I have been running for a few days now.
Screenshots (if appropriate):