WebSockets API Documentation describes a field called "price change" - Price change (If mode is quote, the packet ends here).
The com.zerodhatech.models.Tick class does not capture this field. The KiteTicker class only allows OnTicks listener. There is no LtpQuote or Quote Listener. And the OnTicks listener is called when a Binary message arrives. So, for LTP & Quote modes too, it will be the OnTicks listener, and the Tick class.
In effect this is a mismatch between the actual KiteConnect code and the API documentation. I have not seen the Python Client code and do not know if it is treated differently in Python.
Is this by design? Does this mean I have to roll my own implementation of KiteTicker to make this reflect the actual Binary Structure as described in the API Documentation? Is that API Documentation accurate and up to date?
On further study, I understand that the current design of KiteConnect Java API uses a single Tick class for all subscription modes. The LTP & Quote classes are not used in the context of the WebSocket but as return values of the LTP & Quote APIs. The WebSocket API only uses the Tick class.
This of course means that the values in a Tick instance will depend on the mode. Only in the case of "full" mode will all the values be populated.
ticker.SetMode(Tokens: tokens.ToArray(), Mode: Constants.MODE_FULL) I'm using to fetch ticks data, however, I'm observing Open, High Low, and close coming same value for each tick. Could you please suggest which mode need to use?
I'm filtering & ordering tick data by timestamp and storing in the collection (variable r) for 5-minute intervals.
Then using the C#.Net LINQ query, I'm trying to prepare 5min OHLC Vol candle data through the mentioned code...
decimal open = r.First().Open; [First ticker open value] decimal close = r.Last().Close; [last ticker of 5min duration data, close value] decimal high = r.Max(x => x.High); [In 5min duration highest value] decimal low = r.Min(x => x.Low); [In 5min duration lowest value] long lastVol = r.Last().Volume; [Last tick data volume in 5min duration data] long iniVol = r.First().Volume; [First tick data volume in 5min duration data] long volume = lastVol - iniVol; [Volume is cumulative so subtracting from last - first ticker]
Please suggest to me what is wrong with this approach.
Open, High Low, and close coming same value for each tick
Open, High, Low, Close values in a WebSocket Tick will remain the same for the entire Trading Session (Day) as they are the OHLC values of the previous Trading Session (Day). You must use the Last traded price (LTP), Last traded quantity and Last traded timestamp to build your candles (any time frame).
Process to build 1-minute candles from Ticks (or any higher time frame)
Step 1:Tick 1 -> Start a new Live Candle. Set the Candle's Open, High, Low and Close to the Last traded price (LTP). Set the new Candle's Volume to Last traded quantity (LTQ). That is, Open = High = Low = Close = LTP and Volume = LTQ
Step 2:Tick 2 ... N -> Set Candle Close to LTP. Check if LTP is greater Candle High and replace Candle High with LTP if true. Check if LTP is less than Candle Low and replace Low with LTP if true. Add LTQ to Candle Volume (Candle Volume = Candle Volume + Last Traded Quantity)
Step 2:Tick (N + 1) -> Check Last traded timestamp to see if 1-minute if complete. If so, close the current candle and create a new Live Candle as in Step 1. Continue processing Ticks as above for new 1-minute candle.
I use Ticks to build 1-minute candles stored in-memory cache and persisted to DB. Then I use these 1-minute candles to form higher time frame candles using the same logic as above. Higher time frame candles like 5-minute, 15-minute, etc., can also be formed directly from Tick data as above.
My question wasn't clear I suppose.
On further study, I understand that the current design of KiteConnect Java API uses a single Tick class for all subscription modes. The LTP & Quote classes are not used in the context of the WebSocket but as return values of the LTP & Quote APIs. The WebSocket API only uses the Tick class.
This of course means that the values in a Tick instance will depend on the mode. Only in the case of "full" mode will all the values be populated.
I'm filtering & ordering tick data by timestamp and storing in the collection (variable r) for 5-minute intervals.
Then using the C#.Net LINQ query, I'm trying to prepare 5min OHLC Vol candle data through the mentioned code...
decimal open = r.First().Open; [First ticker open value]
decimal close = r.Last().Close; [last ticker of 5min duration data, close value]
decimal high = r.Max(x => x.High); [In 5min duration highest value]
decimal low = r.Min(x => x.Low); [In 5min duration lowest value]
long lastVol = r.Last().Volume; [Last tick data volume in 5min duration data]
long iniVol = r.First().Volume; [First tick data volume in 5min duration data]
long volume = lastVol - iniVol; [Volume is cumulative so subtracting from last - first ticker]
Please suggest to me what is wrong with this approach.
Open, High Low, and close coming same value for each tick
Open, High, Low, Close values in a WebSocket Tick will remain the same for the entire Trading Session (Day) as they are the OHLC values of the previous Trading Session (Day). You must use the Last traded price (LTP), Last traded quantity and Last traded timestamp to build your candles (any time frame).
Process to build 1-minute candles from Ticks (or any higher time frame)
Hope this helps.