forex-scalping.com

MT5 push notifications from an EA: 2 per second, 10 per minute, 255 characters

SendNotification(text) sends a push message to the phone through the MetaQuotes ID you set under Tools, Options, Notifications. The documented limits are 2 calls per second, 10 per minute, and 255 characters per message. It returns false if the send fails, and it does nothing in the strategy tester.

An EA that alerts on every EMA cross on M1 runs into the limit quickly. In a choppy minute there can be 15 crosses. The first 10 go through at most, the rest fail with error 4518, which is ERR_NOTIFICATION_TOO_FREQUENT. If a violation keeps recurring, the terminal can disable the sending.

A minimal guard:
datetime lastSent = 0;
void Notify(string msg)
{
if(MQLInfoInteger(MQL_TESTER)) return;
if(TimeCurrent() - lastSent < 6) return; // at most 10 a minute
if(StringLen(msg) > 255) msg = StringSubstr(msg, 0, 255);
if(SendNotification(msg)) lastSent = TimeCurrent();
else PrintFormat("push failed, error %d", GetLastError());
}

It drops anything that arrives inside 6 seconds of the last one. That is the right behaviour for alerts where only the latest state matters.

The limits are easy to hit. A simple fix is to queue messages and combine them into one summary sent at most every 10 seconds. That keeps alerts useful and avoids error 4518. Filtering alerts by importance also helps.

If every message matters, queue them instead of dropping. Keep an array of strings, push each new message onto it, call EventSetTimer(6) in OnInit, and in OnTimer send the first message and remove it. At that rate 15 signals in a minute take 90 seconds to deliver, so the fifteenth arrives 84 seconds after it happened, which for a scalping signal is stale. Two ways round it: expire queued messages after 30 seconds, or replace a burst by a summary such as EURUSD: 15 crosses in the last minute, now above. For trade events like fills and closes, a queue is right. For signals on a fast chart, a summary is more useful than a late message.

Before blaming the code, check the three obvious things. In the terminal, Tools, Options, Notifications must have the push box ticked and the MetaQuotes ID typed exactly as the mobile app shows it. On the phone, the app needs notification permission in the system settings. And the call has to come from an EA or script that is actually running. Error 4517 points at settings: no ID configured or permissions off. Error 4515 means the send itself failed. In code, TerminalInfoInteger(TERMINAL_NOTIFICATIONS_ENABLED) tells you whether the terminal side is switched on, so you can print a warning in OnInit instead of discovering it a week later.

Compose the text for a glance at the phone. A message such as EURUSD BUY 0.25 @1.0852 SL 1.0832 TP 1.0892 risk 0.5% is 56 characters, well inside 255, and carries everything needed to decide if you care. Put the symbol and the action first, since lock screen previews cut off the end. Include the price the order filled at, not the price you requested. If the server and your phone are in different time zones, leave time out or add UTC explicitly, because a bare 14:32 will be read in the wrong zone about half the time. Keep the same format for every message type so you can scan a column of them.

Think about volume before turning notifications on for everything. An EA that sends a message for each of 20 trades a day, plus signals, plus errors, makes 60 or more buzzes. After a week most people stop reading them, and the one that matters, a stop out warning or a disconnection, is lost among them. Choose a few classes: stop out and margin warnings, connection loss, daily limit reached, and maybe trade opened and closed. Everything else goes to the Experts log or a daily summary at the end of the session. The point of the phone is that you act on what it says, and each extra category lowers the chance you will.

A short case that has floated around a few forum threads. A trader runs a tick-based scalping routine on a demo and a live account at the same broker. Same entries, same rules. Demo looks healthy. Live bleeds small losses, many of them stops hit a pip or so before price turned around.

The first guess was slippage. The second was a bad broker. Neither held up, since the average slippage was small and symmetrical.

The twist showed up when the logged ticks from both accounts were lined up. The live feed was delivering fewer updates per second than the demo. Quotes were being sampled or throttled, so the live chart skipped moves the demo had drawn in full. Entry signals fired on stale prices, which looked fine until the fill came back at the real level, and brief spikes that would have been visible on the faster feed simply never appeared.

Some brokers do limit how often prices are pushed to retail terminals, especially in busy sessions, sometimes to protect their servers, sometimes as a form of latency control. It is not always disclosed, and it varies a lot by broker and by platform.

The practical lesson was less about the broker and more about the test. Any tick-driven logic should be validated on the live feed for its actual update rate, not assumed from a demo or from historical data. Count ticks per minute during quiet and busy periods, and compare against another source.

If entries depend on a micro move, a throttled feed can quietly turn an edge into a coin flip with a cost attached.

Has anyone counted ticks per minute across different brokers, and how big were the gaps between them?