[TOG 0]

Спасибо, Товарищи. 
Данных у меня не много, ~500 байт. 
Но мне кажется, что через почту будет задержка в несколько секунд. 
То есть Человек нажал кнопочку отправить данные и ждёт секунд 10. 
У меня есть домен и хостинг. И мое устройство могло бы ломиться на этот домен.
Осталось понять какой сервис надо запустить на домене, чтобы он был посредником

между Устройством и домашним компом. 

[jcxz 215]

9 часов назад, TOG сказал:

У меня есть домен и хостинг. И мое устройство могло бы ломиться на этот домен.
Осталось понять какой сервис надо запустить на домене, чтобы он был посредником

Так - любой удобный Вам.

И если есть свой север, то даже и почтовый SMTP-сервер можете на нём запустить. И никаких "нескольких секунд" не будет. Будет ровно такое же время, как и при прямом соединении по TCP-сокету. Так как SMTP - это соединение через TCP-сокет, через который потом запускается простой протокол. А раз сервер ваш - можете даже на нём разрешить SMTP без шифрования. И сразу же получить письмо в ящике.

И вполне возможно, что это будет гораздо быстрее MQTT. Так как нужно установить только одно единственное TCP-соединение. А для MQTT сколько соединений или UDP-кадров требуется? Могут ответить те, кто его рекламировал здесь?

[dimka76 52]

On 3/27/2023 at 3:25 PM, jcxz said:

А для MQTT сколько соединений

одно

[TOG 0]

On 3/27/2023 at 5:25 PM, jcxz said:

Так - любой удобный Вам.

И если есть свой север, то даже и почтовый SMTP-сервер можете на нём запустить. И никаких "нескольких секунд" не будет. Будет ровно такое же время, как и при прямом соединении по TCP-сокету. Так как SMTP - это соединение через TCP-сокет, через который потом запускается простой протокол. А раз сервер ваш - можете даже на нём разрешить SMTP без шифрования. И сразу же получить письмо в ящике.

Отлично, jcxz !

Так и сделаю.

[mitya1698 18]

только вопрос, как часто домашняя железка будет за почтой приходить, она же не узнает, что к ней почта пришла, не опрашивая постоянно ящик.

[jcxz 215]

34 минуты назад, mitya1698 сказал:

как часто домашняя железка будет за почтой приходить

Да хоть каждую секунду. В чём проблема?

[113 3]

Делал подобное через веб-сервер. Данные со стороннего сервиса кидаются в MySQL, а железяка опрашивает раз в две секунды. Столкнулся с одной проблемой - большинство бесплатных хостингов не принимали запросы без идентификатора клиента в http заголовке.

[Tarbal 4]

On 3/28/2023 at 1:01 AM, mitya1698 said:

только вопрос, как часто домашняя железка будет за почтой приходить, она же не узнает, что к ней почта пришла, не опрашивая постоянно ящик.

MQTT гораздо удобнее для такого устриойства.

 

[jcxz 215]

4 часа назад, Tarbal сказал:

MQTT гораздо удобнее для такого устриойства.

Чем?

[=AK= 12]

On 3/24/2023 at 5:54 AM, jcxz said:

Прошейте в ESP AT-командную прошивку и управляйте ею с STM-а AT-командами.

Лучше вообще выбросить STM и написать прикладную программу для ESP в среде Ардуино.

В крайнем случае, если от STM избавиться не получится, то хотя бы не связываться с AT командами для ESP, это тупиковый путь. Они криво реализованы.

В разы проще и быстрее создать связное приложение для ESP в среде Ардуино. Тогда для реализации MQTT клиента можно взять готовую библиотеку PubSubClient.

[jcxz 215]

1 час назад, =AK= сказал:

не связываться с AT командами для ESP, это тупиковый путь. Они криво реализованы.

Конкретные факты приведите.

[=AK= 12]

25 minutes ago, jcxz said:

Конкретные факты приведите.

Китайцы написали АТ команды для человека, который сидит за терминалом, посылает команды и смотрит ответы. У них ответы не систематизированы, программно занимает много сил на то чтобы их обработать. Вдобавок ответы "дырявые", многие ситуации невозможно определить. Программно обрабатывать ответы китайских АТ команд - бессмысленная трата времени.

То есть, ответы на АТ команды ESP представляют собой очень рыхлый псевдо-язык, а на создание интерпретатора этого языка требуется неоправданно много усилий.

[jcxz 215]

58 минут назад, =AK= сказал:

Вдобавок ответы "дырявые", многие ситуации невозможно определить.

Приведите, пожалуйста, конкретный пример "дырявости". И - какую именно ситуацию "невозможно определить"?

[=AK= 12]

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 215]

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.