Здравствуйте.
Использую eWeLink MCP Server для управления 4-канальным реле через собственный сервер на Ubuntu.
Схема простая: мой VPS читает расписание полива и только в момент полива обращается к eWeLink MCP. В текущей версии никакого постоянного опроса устройств нет.
Проблема: eWeLink MCP возвращает ошибку:
Request limit reached. You've hit the daily limit of 500 calls
Вчера лимит уже был достигнут. Сегодня утром ситуация осталась такой же — даже один одиночный вызов getBasicInformation сразу возвращает ту же ошибку.
Я проверил сервер:
- запущен только один процесс, который использует eWeLink MCP;
- других сервисов, cron-задач или таймеров, обращающихся к eWeLink, нет;
- в режиме ожидания мой сервис делает 0 запросов к eWeLink;
- обычный цикл управления требует примерно 5 MCP-вызовов: проверка состояния, включение, проверка, выключение, финальная проверка.
Ранее во время разработки действительно была версия, которая часто опрашивала устройство и могла израсходовать 500 запросов. Сейчас этот опрос полностью удалён.
Хотелось бы понять:
- Когда именно сбрасывается daily limit 500 calls?
*
в 00:00 UTC;
*
в 00:00 локального времени;
*
через 24 часа после достижения лимита;
*
используется скользящее 24-часовое окно? - К чему относится лимит 500 вызовов:
*
к конкретному MCP URL/token;
*
к eWeLink-аккаунту;
*
к устройству;
*
к IP-адресу;
*
ко всем MCP-клиентам одного пользователя? - Если отозвать текущий MCP URL и создать новый, сбросится ли лимит или он останется на уровне аккаунта?
- Есть ли способ в eWeLink посмотреть текущее количество использованных MCP-вызовов и время следующего сброса лимита?
- Какой способ eWeLink рекомендует для серверной автоматизации, где нужно надёжно управлять реле несколько десятков раз в сутки?
Для моего сценария 500 запросов в сутки более чем достаточно, если лимит действительно регулярно сбрасывается. Основная проблема сейчас в том, что после достижения лимита непонятно, когда сервис снова станет доступен.
Буду благодарен за официальное пояснение механизма MCP rate limit и рекомендации по правильной архитектуре.
Hello,
I am using the eWeLink MCP Server to control a 4-channel relay from my own Ubuntu VPS.
The architecture is simple: my server reads an irrigation schedule and contacts the eWeLink MCP Server only when an irrigation event needs to start. The current version does not poll the device continuously.
The problem is that the MCP Server returns:
Request limit reached. You've hit the daily limit of 500 calls
The limit was already reached yesterday. This morning the situation is still the same: even a single getBasicInformation request immediately returns the same error.
I checked my server:
- only one active process uses the eWeLink MCP Server;
- there are no other cron jobs, systemd timers, or services calling eWeLink;
- while waiting for the scheduled irrigation time, my service makes 0 eWeLink requests;
- one normal irrigation cycle requires approximately 5 MCP calls: state check, turn on, verification, turn off, final verification.
During development I previously had a version that polled the device frequently, and this may have consumed the 500-call quota. That polling has now been completely removed.
Could you please clarify the following:
- When exactly does the 500-call daily limit reset?
*
at 00:00 UTC;
*
at 00:00 local time;
*
24 hours after the limit is reached;
*
or is it a rolling 24-hour window? - What is the 500-call limit applied to?
*
a specific MCP URL/token;
*
the eWeLink account;
*
the device;
*
the IP address;
*
or all MCP clients connected to the same user account? - If I revoke the current MCP URL and generate a new one, does the quota reset, or does the same account-level limit remain?
- Is there any way to see the current number of MCP calls used and the exact time when the quota will reset?
- What architecture does eWeLink recommend for server-side automation where relays need to be controlled reliably several dozen times per day?
For my use case, 500 calls per day would be more than enough if the quota resets predictably. The main problem is that after the limit is reached, it is unclear when the MCP Server becomes available again.
I would appreciate an official explanation of the MCP rate-limit mechanism and recommendations for reliable automation.