TOG 0 27 марта, 2023 Опубликовано 27 марта, 2023 · Жалоба Спасибо, Товарищи. Данных у меня не много, ~500 байт. Но мне кажется, что через почту будет задержка в несколько секунд. То есть Человек нажал кнопочку отправить данные и ждёт секунд 10. У меня есть домен и хостинг. И мое устройство могло бы ломиться на этот домен. Осталось понять какой сервис надо запустить на домене, чтобы он был посредником между Устройством и домашним компом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 27 марта, 2023 Опубликовано 27 марта, 2023 · Жалоба 9 часов назад, TOG сказал: У меня есть домен и хостинг. И мое устройство могло бы ломиться на этот домен. Осталось понять какой сервис надо запустить на домене, чтобы он был посредником Так - любой удобный Вам. И если есть свой север, то даже и почтовый SMTP-сервер можете на нём запустить. И никаких "нескольких секунд" не будет. Будет ровно такое же время, как и при прямом соединении по TCP-сокету. Так как SMTP - это соединение через TCP-сокет, через который потом запускается простой протокол. А раз сервер ваш - можете даже на нём разрешить SMTP без шифрования. И сразу же получить письмо в ящике. И вполне возможно, что это будет гораздо быстрее MQTT. Так как нужно установить только одно единственное TCP-соединение. А для MQTT сколько соединений или UDP-кадров требуется? Могут ответить те, кто его рекламировал здесь? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimka76 62 27 марта, 2023 Опубликовано 27 марта, 2023 · Жалоба On 3/27/2023 at 3:25 PM, jcxz said: А для MQTT сколько соединений одно Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TOG 0 28 марта, 2023 Опубликовано 28 марта, 2023 · Жалоба On 3/27/2023 at 5:25 PM, jcxz said: Так - любой удобный Вам. И если есть свой север, то даже и почтовый SMTP-сервер можете на нём запустить. И никаких "нескольких секунд" не будет. Будет ровно такое же время, как и при прямом соединении по TCP-сокету. Так как SMTP - это соединение через TCP-сокет, через который потом запускается простой протокол. А раз сервер ваш - можете даже на нём разрешить SMTP без шифрования. И сразу же получить письмо в ящике. Отлично, jcxz ! Так и сделаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mitya1698 18 28 марта, 2023 Опубликовано 28 марта, 2023 · Жалоба только вопрос, как часто домашняя железка будет за почтой приходить, она же не узнает, что к ней почта пришла, не опрашивая постоянно ящик. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 28 марта, 2023 Опубликовано 28 марта, 2023 · Жалоба 34 минуты назад, mitya1698 сказал: как часто домашняя железка будет за почтой приходить Да хоть каждую секунду. В чём проблема? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
113 3 13 апреля, 2023 Опубликовано 13 апреля, 2023 · Жалоба Делал подобное через веб-сервер. Данные со стороннего сервиса кидаются в MySQL, а железяка опрашивает раз в две секунды. Столкнулся с одной проблемой - большинство бесплатных хостингов не принимали запросы без идентификатора клиента в http заголовке. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 16 апреля, 2023 Опубликовано 16 апреля, 2023 · Жалоба On 3/28/2023 at 1:01 AM, mitya1698 said: только вопрос, как часто домашняя железка будет за почтой приходить, она же не узнает, что к ней почта пришла, не опрашивая постоянно ящик. MQTT гораздо удобнее для такого устриойства. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 16 апреля, 2023 Опубликовано 16 апреля, 2023 · Жалоба 4 часа назад, Tarbal сказал: MQTT гораздо удобнее для такого устриойства. Чем? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 16 апреля, 2023 Опубликовано 16 апреля, 2023 · Жалоба On 3/24/2023 at 5:54 AM, jcxz said: Прошейте в ESP AT-командную прошивку и управляйте ею с STM-а AT-командами. Лучше вообще выбросить STM и написать прикладную программу для ESP в среде Ардуино. В крайнем случае, если от STM избавиться не получится, то хотя бы не связываться с AT командами для ESP, это тупиковый путь. Они криво реализованы. В разы проще и быстрее создать связное приложение для ESP в среде Ардуино. Тогда для реализации MQTT клиента можно взять готовую библиотеку PubSubClient. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 16 апреля, 2023 Опубликовано 16 апреля, 2023 · Жалоба 1 час назад, =AK= сказал: не связываться с AT командами для ESP, это тупиковый путь. Они криво реализованы. Конкретные факты приведите. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 16 апреля, 2023 Опубликовано 16 апреля, 2023 · Жалоба 25 minutes ago, jcxz said: Конкретные факты приведите. Китайцы написали АТ команды для человека, который сидит за терминалом, посылает команды и смотрит ответы. У них ответы не систематизированы, программно занимает много сил на то чтобы их обработать. Вдобавок ответы "дырявые", многие ситуации невозможно определить. Программно обрабатывать ответы китайских АТ команд - бессмысленная трата времени. То есть, ответы на АТ команды ESP представляют собой очень рыхлый псевдо-язык, а на создание интерпретатора этого языка требуется неоправданно много усилий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 16 апреля, 2023 Опубликовано 16 апреля, 2023 · Жалоба 58 минут назад, =AK= сказал: Вдобавок ответы "дырявые", многие ситуации невозможно определить. Приведите, пожалуйста, конкретный пример "дырявости". И - какую именно ситуацию "невозможно определить"? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 17 апреля, 2023 Опубликовано 17 апреля, 2023 · Жалоба 16 hours ago, jcxz said: Приведите, пожалуйста, конкретный пример "дырявости". И - какую именно ситуацию "невозможно определить"? Мне очень не хочется поднимать свои исходники 8-летней давности и перечитывать документацию на АТ команды. Просто примите к сведению. Впрочем, никто не мешает вам самому прочитать китайскую документацию, пропарсить ответы на АТ команды и выстроить машины состояний. PS: конкретный пример, берем ESP8266 AT Instruction Set, rev 0.60, стр 58, команда 7. AT+CIPBUFSTATUS – Check status of TCP-send-buffer В разделе Example: Single connection: AT+CIPBUFSTATUS returns 20,15,10,200,7 20 : means the latest segment ID is 19, next time we call AT+CIPSENDBUF, the segment ID returned will be 20; 15: means TCP segment of which ID is 15 is the latest segment that sent(may not succeed); 10: means TCP segment of which ID is 10 sent successfully; 200: TCP-send-buffer remain 200 bytes that available; 7: available TCP queue number, it’s not reliable; when queue number is 0, no more TCP data can be sent В разделе Response: <next segment ID>, < segment ID of which has sent >, < segment ID of which sent successfully>, <remain buffer size>, <queue number> OK If connection is not established, returns ERROR Как видите, Example как-то соотносится с Response, но нет обещанного ОК, когда этот ОК появится и появится ли вообще - неизвестно, а реакция "ненадежна" по собственному признанию авторов. Ну и через "китайский английский" продираться тоже удовольствия мало. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 17 апреля, 2023 Опубликовано 17 апреля, 2023 · Жалоба 5 часов назад, =AK= сказал: Просто примите к сведению. Впрочем, никто не мешает вам самому прочитать китайскую документацию, пропарсить ответы на АТ команды и выстроить машины состояний. Мне не нужно чего-то "принимать к сведению" или парсить. У меня есть работающий проект с ESP8266 с AT-командной прошивкой. Работает уже несколько лет. Работает нормально. 5 часов назад, =AK= сказал: PS: конкретный пример, берем ESP8266 AT Instruction Set, rev 0.60, стр 58, команда 7. AT+CIPBUFSTATUS – Check status of TCP-send-buffer Зачем брать такую древнюю версию AT-команд? В тех древних версиях было много багов - сырые были. Но уже несколько лет назад появились прошивки 1.7.4.0; 1.7.5.0 и более поздние. В которых уже всё работает нормально. Ну или по-крайней мере нормально работает как минимум - базовый функционал, необходимый для работы через TCP и/или UDP. 5 часов назад, =AK= сказал: Как видите, Example как-то соотносится с Response, но нет обещанного ОК, когда этот ОК появится и появится ли вообще - неизвестно, а реакция "ненадежна" по собственному признанию авторов. Ну и через "китайский английский" продираться тоже удовольствия мало. Не понятно - откуда это откопали??? Открываю даташит на AT-команды ESP8266 v3.0.1 от 2019г, читаю: раздел "Set command": Цитата 1. Single connection: (+CIPMUX=0) AT+CIPSENDBUF=<length> 2. Multiple connections: (+CIPMUX=1) AT+CIPSENDBUF=<link ID>,<length> раздел "Response": Цитата <current segment ID>,<segment ID of which sent successfully> OK > • Wrap return > begins receiving serial data; when the length of data defined by the parameter <length> is met, the data is sent; if the data length over the value of <length>, the data will be discarded, and the command returns busy. • If the connection cannot be established, or if it is not a TCP connection, or if the buffer is full, or some other error occurs, the command returns ERROR • If data is transmitted successfully, ‣ for single connection, the response is: <segment ID>,SEND OK ‣ for multiple connections, the response is: <link ID>,<segment ID>,SEND OK • If it failed, the system returns: SEND FAIL И "OK" имеется и описано вроде как вполне доступно и понятно. А "когда OK появится" - так вполне очевидно, что как только ESP8266 примет и успешно распарсит команду, то сразу ответит на неё = OK. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться