News Filter trong EA #11

Trả lời ngắn: News Filter trong EA là cổng thời gian đọc lịch kinh tế, xác định sự kiện nào liên quan tới mã đang xét, rồi tạo khoảng chặn trước và sau sự kiện. Nó trả PASS, BLOCK hoặc UNKNOWN kèm bằng chứng; nó không đoán tin tốt/xấu và không tự gửi giao dịch.

Đọc xong, bạn sẽ hiểu:

• Vì sao “không đọc được lịch” khác hẳn “không có sự kiện”.
• Cách ghép giờ máy chủ, dữ liệu lịch, mức liên quan và policy.
• Vì sao mức quan trọng của sự kiện khác tác động sau khi công bố.
• Cách xử lý sự kiện chưa có giờ chính xác và snapshot quá cũ.

Lưu ý giáo dục: Mọi currency, thời điểm và khoảng đệm trong bài là dữ liệu demo để học thiết kế phần mềm. Chúng không phải lịch live, tín hiệu hoặc lời khuyên về thời điểm giao dịch.

1. News Filter là cổng thời gian, không phải máy đọc tin

a. Đầu vào và đầu ra

Một cửa sổ sự kiện (event window) là khoảng do policy tạo quanh một sự kiện lịch. Ví dụ, policy demo chặn từ 15 phút trước đến 10 phút sau giờ công bố; không có bộ đệm đúng cho mọi hệ thống.

News Filter nhận bốn nhóm dữ liệu:

• ảnh chụp thời gian (clock snapshot) gồm giờ, nguồn và độ mới;
• ảnh chụp lịch (calendar snapshot) gồm các bản ghi sự kiện đã lấy được;
• bảng liên quan (relevance map) nối mã sản phẩm với currency hoặc nhóm event cần xét;
• bộ quy tắc (policy) gồm mức quan trọng, buffer trước/sau, quy tắc biên và phiên bản.

Đầu ra có quyết định, lý do, bằng chứng và mốc chuyển trạng thái:

• PASS: truy vấn đã hoàn tất, dữ liệu còn mới và không có event window liên quan đang phủ thời điểm hiện tại;
• BLOCK: có event window liên quan đã biết đang phủ thời điểm hiện tại;
• UNKNOWN: lịch, metadata, clock hoặc phạm vi truy vấn chưa đủ để kết luận.

b. Ranh giới phải nói rõ

News Filter không dự báo số liệu, không đánh giá tin tốt/xấu, không đo biến động và không gửi giao dịch. PASS chỉ nghĩa ứng viên đã qua cổng lịch; cổng phiên, biến động, rủi ro và thực thi vẫn có thể từ chối.

Hãy hình dung bảng thông báo sửa đường. Bảng tải xong và không có tuyến liên quan là một bằng chứng. Màn hình mất mạng cũng trống, nhưng không ai nên kết luận đường đang thông chỉ vì vậy.

2. Bốn dữ liệu phải cùng đúng

a. Lịch kinh tế dùng giờ máy chủ giao dịch

Các hàm Economic Calendar của MQL5 dùng giờ máy chủ giao dịch (trade-server time). News Filter phải so event time với clock cùng cơ sở, đồng thời ghi nguồn và độ mới. CalendarValueHistory

So 14:30 từ calendar với 14:30 trên laptop ở múi giờ khác là sai gốc. News Filter chỉ dùng clock snapshot đã chuẩn hóa.

b. Bản ghi lịch khác mô tả sự kiện

Bản ghi lịch (calendar value) chứa event_id, thời điểm, kỳ dữ liệu và các giá trị actual, forecast, previous. Mô tả sự kiện (event metadata) chứa tên, loại, mức quan trọng và chế độ thời gian.

CalendarValueHistory() lấy values theo khoảng thời gian, country hoặc currency. Thành công trả số record; lỗi trả -1. Timeout là 5401; mảng chưa đủ chỗ nhận hết dữ liệu là 5400. CalendarValueHistory

CalendarEventById() lấy MqlCalendarEvent từ event_id. false chỉ nói không lấy được mô tả, không chứng minh “không có event”. CalendarEventById

c. Mức quan trọng không phải loại tác động

Mức quan trọng (importance) nằm trong MqlCalendarEvent. Đây là nhãn lịch như LOW, MODERATE, HIGH.

Loại tác động (impact type) nằm trong MqlCalendarValue, mô tả tác động sau công bố so với kỳ vọng. Nó không phải importance dùng để lọc trước event. Economic Calendar structures

d. Mã sản phẩm cần bảng liên quan có chủ đích

Trong demo, EURUSD → {EUR, USD}. Tên thật có thể có prefix, suffix hoặc là CFD, index, kim loại. Cắt chuỗi tên như quy tắc chung rất dễ sai.

Relevance map nên đến từ metadata hoặc policy rõ ràng. CalendarCountryById() cung cấp country code và currency để đối chiếu. CalendarCountryById

3. Từ bản ghi lịch đến cửa sổ sự kiện

a. Tám bước xử lý

1. Chụp serverNow, nguồn clock, sampledAt và kiểm độ mới.
2. Xác định khoảng query cùng currency/country cần lấy.
3. Gọi calendar API, kiểm mã trả về (return code) và độ phủ (coverage) của kết quả.
4. Với từng value, lấy event metadata và mapping liên quan.
5. Lọc theo currency, importance và policy version.
6. Kiểm chế độ thời gian (time mode) của event.
7. Tạo window [eventTime - beforeBuffer, eventTime + afterBuffer).
8. Sắp xếp, chỉ gộp các window thật sự chồng/chạm theo policy, rồi đánh giá serverNow.

Quy tắc biên (endpoint) trong ví dụ là đầu có tính, cuối không tính. Bởi vậy 14:15 thuộc window nhưng đúng 14:40 thì không. Hệ thống khác có thể chọn quy ước khác, miễn ghi rõ và kiểm thử nhất quán.

b. count=0 chỉ có nghĩa khi query hoàn tất

Lời gọi thành công trả 0, đúng phạm vi/tiền tệ và snapshot đầy đủ mới hỗ trợ kết luận “không thấy event liên quan”.

Ngược lại:

• -1 là lỗi;
• 5401 là timeout;
• 5400 báo cần thêm chỗ để nhận đủ dữ liệu;
• metadata lookup thất bại làm thiếu importance hoặc time mode;
• snapshot quá cũ không đại diện cho hiện tại.

Các tình huống này về UNKNOWN / CALENDAR_DATA_INCOMPLETE / RELOAD, không gom thành mảng rỗng rồi PASS.

c. Event chưa có giờ chính xác

MqlCalendarEvent.time_mode có các dạng thời gian chính xác, theo ngày, không có thời gian hoặc dự kiến. Một chuyến bay ghi “14:30” khác thông báo “dự kiến buổi chiều”. Không thể lấy cùng buffer 15 phút cho cả hai.

Bộ quy tắc phải quy định DATE, NOTIME, TENTATIVE: chặn cả ngày, giữ UNKNOWN hoặc dùng nguồn xác nhận. Nếu chưa quy định, hệ thống đóng an toàn (fail-closed) về UNKNOWN.

Hình 1 — News Filter chỉ được PASS khi dữ liệu lịch đã hoàn tất và không có event window liên quan đang phủ.

4. Demo hai sự kiện và khoảng trống năm phút

a. Bộ quy tắc và hai sự kiện giả

Toàn bộ dữ liệu dưới đây là demo:

• mapping: EURUSD → EUR, USD;
• importance: chỉ xét HIGH;
• buffer trước: 15 phút;
• buffer sau: 10 phút;
• endpoint: [start, end).

Sự kiện E1 là EUR HIGH lúc 14:30, nên W1 là [14:15, 14:40). Sự kiện E2 là USD HIGH lúc 15:00, nên W2 là [14:45, 15:10).

W1 và W2 không chồng hoặc chạm; gap 14:40–14:45 phải được giữ. Merge qua gap sẽ xóa trạng thái PASS của policy demo.

Hình 2 — Hai cửa sổ demo có gap năm phút nên không được nối thành một khoảng chặn duy nhất.

b. Bốn phiếu quyết định

Tình huống B PASS vì truy vấn hoàn tất và 14:42 nằm trong gap. Snapshot quá cũ hoặc thiếu coverage sẽ đổi kết quả thành UNKNOWN.

Phiếu quyết định (decision card) log now, policyVersion, eventId, window, decision, reason, nextTransition và độ mới.

Hình 3 — Decision Card luôn giữ thời điểm, bằng chứng, lý do và mốc chuyển tiếp để có thể kiểm tra lại.

5. Bảy lỗi và giới hạn cần nhớ

1. Dùng giờ máy cá nhân: calendar dùng trade-server time, nên phép so khác nguồn có thể lệch.
2. Cắt tên symbol để đoán currency: prefix, suffix và instrument đặc biệt làm rule này hỏng.
3. Nhầm importance với impact type: một field phục vụ lọc trước event, field kia mô tả kết quả sau công bố.
4. Gom mọi kết quả rỗng: success 0, lỗi -1, timeout và more-data không cùng nghĩa.
5. Ép tentative thành giờ chính xác: event chưa có mốc cố định cần policy riêng.
6. Gộp qua gap: hai window gần nhau vẫn có thể để lại khoảng PASS.
7. Dùng snapshot quá cũ: lịch từng đúng không chứng minh nó vẫn đầy đủ ở thời điểm quyết định.

Các trường actual/forecast có thể dùng LONG_MIN khi thiếu; hàm truy cập trả NaN. Bộ tiếp nhận dữ liệu (adapter) phải kiểm trạng thái thay vì coi số thô là dữ liệu thật. Economic Calendar structures

News Filter chỉ biết event trong nguồn lịch. Nó không bảo vệ khỏi tin bất ngờ, lỗi kết nối, spread, trượt giá hoặc mọi biến động. PASS không nói thị trường an toàn.

6. Checklist và bảng bài tập cửa sổ tin 15 phút

a. Mười hai câu kiểm

1. serverNow đến từ đâu?
2. Clock sampled lúc nào và còn mới không?
3. Query range bắt đầu/kết thúc ở đâu?
4. Mã trả về là count, -1, 5401 hay 5400?
5. Coverage đã đủ currency và thời gian chưa?
6. event_id nào đang được xét?
7. Currency liên quan theo mapping nào?
8. Importance lấy từ event metadata chưa?
9. Time mode có đủ chính xác không?
10. Buffer và endpoint policy là gì?
11. Window có bị merge qua gap không?
12. Decision có reason, evidence và next transition không?

Điểm dừng: thiếu độ mới của clock, độ phủ truy vấn, mô tả event hoặc policy cho time mode thì trả UNKNOWN. Không dùng bộ nhớ tạm (cache) cũ cho qua và không tự đổi lỗi thành “không có tin”.

b. Bài tập miễn phí

Dùng giấy hoặc Google Sheets 10–15 phút. Dựng W1/W2 rồi điền decision, reason, next transition cho bốn case. Chưa mở MT5 hoặc dùng tiền thật.

c. Mẫu đối chiếu đã điền

Giữ lại timeline và bốn decision cards. Đây là bài tập về contract dữ liệu, không phải cấu hình giao dịch.

7. Tổng kết: lịch đủ bằng chứng rồi mới quyết định

a. Năm ý chính

• News Filter tạo event windows; nó không dự báo tin tốt/xấu.
• Calendar API dùng trade-server time.
• Importance và impact type là hai field khác vai trò.
• count=0 thành công khác lỗi, timeout hoặc more-data.
• PASS chỉ qua cổng lịch; thiếu bằng chứng phải UNKNOWN.

Bài trước là Session Engine trong EA. Bài tiếp theo là Volatility Filter trong EA #12.

b. Câu hỏi tự kiểm tra

• Vì sao mảng rỗng chưa chắc nghĩa là không có event?
• Importance nằm ở cấu trúc nào?
• Event TENTATIVE nên được xử lý ra sao khi policy chưa quy định?
• Vì sao hai window trong demo không được merge?

c. Gợi ý đáp án

Xem gợi ý câu 1

Mảng có thể rỗng do success 0, nhưng cũng có thể do code nuốt lỗi, timeout hoặc chưa cấp đủ chỗ; phải giữ return code và coverage. → xem mục 3.

Xem gợi ý câu 2

Importance nằm trong `MqlCalendarEvent`, không nằm ở `MqlCalendarValue.impact_type`. → xem mục 2.

Xem gợi ý câu 3

Khi policy chưa có cách xử lý tentative, giữ UNKNOWN thay vì tự gán một giờ chính xác. → xem mục 3.

Xem gợi ý câu 4

W1 kết thúc `14:40`, W2 bắt đầu `14:45`, nên có gap năm phút thật. → xem mục 4.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• MQL5 CalendarValueHistory
• MQL5 Economic Calendar structures
• MQL5 CalendarEventById
• MQL5 CalendarCountryById
• MQL5 CalendarValueHistoryByEvent
• MQL5 Runtime errors

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. News Filter không thể loại bỏ rủi ro thị trường, dữ liệu hoặc thực thi.