I’ve mentioned in another post regarding false value in demand zone. Have you checked it? in demand zone values are being displayed such as 0.5, 0.1, 1 when price is higher than 200+ prices. It is not usable values as in every options these price will have higher exit orders of sellers. there should be a window like within 100 RS price higher demand is at 110, 125 etc.
@MohitGolecha
I am ok either way, just please keep supporting 2000/3000 symbols in websockets, I think people finding it difficult to generate candles from LTP, if you just add this functionality in their SDKs(python etc.) where they have to just call your function/method to get the candles they should be ok right what is the role of having previous candle I do not understand, if your connection is not recovered within 1-2 min you will be in the same situation as with live candles, so your only way is to call rest api get the updated candles this functionality also you can add in the SDKs then I don’t think people will have any reason to complain. I do not want previous candles at the expense of loss of symbols if people are keen and you went ahead with this with reduced symbols then please allow more websockets connection to compensate for 2000/3000 symbols.
In case you are considering schemas for candlestick
Request:-
{
“type”: “subscribe”,
“payload”: {
“channels”: [
{
“name”: “candlestick_1m”,
“symbols”: [
“SBIN”,
“BHEL”,
…,
…
]
"name": "candlestick_5m",
"symbols": [
"SBIN",
"BHEL",
..,
..
]
},
Response:-
{
“candle_start_time”: 1596015240000000,
“close”: 830,
“high”: 845,
“low”: 820,
“open”: 825,
“resolution”: “1m”,
“symbol”: “SBIN”,
“timestamp”: 1596015289339699,
“type”: “candlestick_1m”,
“volume”: 12000
}
Those candles are not 100% percent accurate if you compare it with GUI only talking about 1-min candle…
currently getting previous 1 min candles from websocket V2 (older version) and it is fully accurate.
1 Like
As i am working on a orderflow algo trading system, LTQ is important on every live tick and again appreciate you for accepting our request but please also give LTQ information on FULL mode in V3. As it helps in deciding, if Last trade was a initiated by a aggressive buyer, seller or by a passive buyer or seller(comparing LTP and LTQ with best bid and ask prices) FULL mode gives live market depth numbers with LTQ helps in making robust trading decision. Please provide LTQ information in FULL mode as well just like V2.
@MohitGolecha have you explored way of sharing 1 min candles over server side events where you send data to user for subscribed tokens.
This would save bandwidth usage (1 tick per minute vs 60 ticks per minute per token) and also be cost effective way, if not SSE , please see if you could explore some ways to send 1 min candle data.
Lot of users end up needed only 1 min candle while they can still use websocket for live tick data.
You could have users share their needs and see if this is something you want to put into your tech pipeline.
1 Like
@MohitGolecha
websocket code works if it doesn’t have connection issues, I have tested the fail scenario if it does have connection issues I think retrieving intraday candles to fix it will not work without the previous candle(Well correct thing to say is it will be more computationally expensive) , so it becomes important hence I changed my vote, only thing needed for complete setup is LTP and previous candle not current candle. Whatever you do please keep supporting 2000 symbols.
1 Like
yes @athma_prathisti The best approach is to provide both Live 1-Min and Previous 1-Min OHLCV.
Previous 1-Min OHLCV ensures accurate indicator calculations and reliable trade signals since it provides finalized OHLC and volume without missing any ticks due to WebSocket disconnects. This is essential for maintaining strategy consistency.
AND Live 1-Min OHLCV allows for real-time indicator updates on every tick, helping execute strategies as early as possible, reducing reaction time to price movements.
Both have their own advantages, and the combination would be ideal. However, if Upstox can provide only one, then the Previous 1-Min Candle is non-negotiable for strategy execution accuracy and data integrity.
4 Likes
{
"type": "live_feed",
"feeds": {
"NSE_FO|51239": {
"fullFeed": {
"marketFF": {
"ltpc": {
"ltp": 169.5,
"ltt": "1738825336000",
"ltq": "75",
"cp": 207
},
"marketLevel": {
"bidAskQuote": [
{
"bidQ": "975",
"bidP": 169.35,
"askQ": "75",
"askP": 169.7
},
{
"bidQ": "750",
"bidP": 169.3,
"askQ": "1125",
"askP": 169.75
},
{
"bidQ": "2250",
"bidP": 169.25,
"askQ": "1050",
"askP": 169.8
},
{
"bidQ": "1275",
"bidP": 169.2,
"askQ": "525",
"askP": 169.85
},
{
"bidQ": "375",
"bidP": 169.15,
"askQ": "675",
"askP": 169.9
}
]
},
"optionGreeks": {
"delta": 0.4544,
"theta": -13.9607,
"gamma": 0.0008,
"vega": 13.0873,
"rho": 2.0628
},
"marketOHLC": {
"ohlc": [
{
"interval": "1d",
"open": 224.8,
"high": 231.85,
"low": 161.85,
"close": 169.5,
"vol": "8517225",
"ts": "1738780200000"
},
{
"interval": "I1",
"open": 170.2,
"high": 170.2,
"low": 167.9,
"close": 169.85,
"vol": "57300",
"ts": "1738825260000"
}
]
},
"atp": 187.62,
"vtt": "8517225",
"oi": 3144225,
"iv": 0.1519775390625,
"tbq": 156000,
"tsq": 394800
}
},
"requestMode": "full_d5"
}
},
"currentTs": "1738825338241"
}
Simply answer:
- Yes
- No
0
voters
4 Likes
LTQ in LTPC mode as well?
Yep, LTPC mode will have LTQ!
1 Like
When it will go live?
We’re trying to ship this next week if tests & QA are all green!
3 Likes
{
“interval”: “I1”,
“open”: 170.2,
“high”: 170.2,
“low”: 167.9,
“close”: 169.85,
“vol”: “57300”,
“ts”: “1738825260000”
}
In this part vol indicate traded quantity in this 1 min . Am i right?
1 Like
Yes @Nirav_vora
The volume here is for the specified 1m candle
3 Likes
Thank you @MohitGolecha for your speedy reply and great focus on user requirements. Love to interact with you. Thank you again
1 Like
ya a BIG THANK YOU TO @MohitGolecha and Upstox team, for listening to the community… Your commitment to providing high-quality service and continuously improving the platform is truly appreciated. A special thanks to the developers for their hard work in making algo more seamless and reliable… APPRECIATED
4 Likes
Thank you for the updates.
if you can make OHLC response like below
“ohlc”: {
“1d”: {
“interval”: “1d”,
“open”: 224.8,
“high”: 231.85,
“low”: 161.85,
“close”: 169.5,
“vol”: “8517225”,
“ts”: “1738780200000”
},
“i1”: {
“interval”: “I1”,
“open”: 170.2,
“high”: 170.2,
“low”: 167.9,
“close”: 169.85,
“vol”: “57300”,
“ts”: “1738825260000”
}
}
},
As there will be only 2 json object. this will be easy to access. If possible
We’re already on the edge of balance between providing good number of sockets & TBT data stream.
Optimizing the response to add anything more will cause the instrument limits to come down. I don’t feel that the current response that we have finalized should be of any major hindrance to run your tasks.
1 Like
No issue. Thanks for your efforts.
I have one suggestion to introduce new websocket for Intraday OHLC data which will produce ohlc every minute for the subscribed instruments. as I have noticed in current websocket same OHLC is repeated for each tick. Hence if there is separate websocket only made for 1minute OHLC every user can subscribe to it and get single or all intraday ohlc once in minute.