• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Постоянная загрузка данных.

ART_HA

Member
После загрузки страницы включается скрипт в котором даже не один запрос, а два
Но я то для получения данных никаких запросов не шлю, верно?
А ведь именно это мне это и требовалось - получение данных с ESP8266 чаще, чем раз в секунду.
 

Ildarmustafin86

Active member
Физически вы ничего не нажимаете, запрос делает сам браузер функцией setInterval
 

Ildarmustafin86

Active member
Сколько поставите в setInterval, с такой частотой и будет спрашивать. Я бы не делал get запросы чаще секунды, а то и двух
 

Ildarmustafin86

Active member
Вы шлете первый запрос и не получив ответа на будете слать следующий запрос. А в коде нет обработки ответа на запросы
 

ART_HA

Member
ОК.
Я подключил ESP, зашел в браузер, набрал его IP, браузер загрузил с ESP страничку, отправил запрос данных, и я увидел страничку с загруженными данными.
Скрипт в браузере запрашивает данные с ESP каждые, к примеру, 0,1 сек и получает их, что и отображается на экране.
Теперь я отключаю питание ESP, страничка в браузере остается загруженной, но данные не обновляются, т.к. на посланные браузером запросы ответа нет.
Сравним ситуацию с наличием связи с ESP и с её отсутствием.
Насколько я понимаю, в обоих случаях со стороны браузера идет периодический запрос ESP, разница только в том, что при отсутствии связи со стороны ESP нет ответа.
Какая разница в этом случае, как часто делаются get запросы?
 
спустя некоторое время после запуска сеанса наблюдается прекращение передачи данных с ESP8266 в браузер
Так что было?

У меня тоже иногда залипает. Как в варианте с вебсокетом, так и при get запросах. Как я понял, в прерывании от датчика перестает обновляться переменная-флаг. Тут в соседней ветке обсуждали вроде схожую проблему, но потом ушли в сторону...
Сам по себе датчик может молотить бесконечно(моргая лампочкой на esp), но как только в код подключается WebSocketsServer или ESP8266WebServer лампочка иногда перестает моргать.



C:
int led_state =LOW;
volatile int curRange=0;
volatile bool newData = false;

void ICACHE_RAM_ATTR  handleInterrupt(){
    ETS_GPIO_INTR_DISABLE();
    newData = true;
    led_state=!led_state;
    ETS_GPIO_INTR_ENABLE();
}

...
void setup() {
  attachInterrupt(pinGPIO1, handleInterrupt, FALLING);
  ....
}

void loop() {
  int i=digitalRead(pinGPIO1); // прерывание датчика
  if(i==LOW && !newData)
  {
     // тут и возникает затык, датчик выставил LOW , а прерывание не отработало
     // помогает заглушка
     // newData = true;
  }
  digitalWrite(LED_BUILTIN,led_state);
  if(newData)
  {
     curRange=loxRead(); // читаем датчик
     String s = String(curRange);
     webSocket.broadcastTXT(s);
  }
  webSocket.loop();
  http.handleClient();
   
}
ps: На выводах SDA, SDL, D6, D5 обязательно нужны подтягивающие резисторы? А то у меня с этим есть некоторые проблемы, просто спаял датчик и esp проводами на монтажке.
sshot-2.jpg
 
Какая разница в этом случае, как часто делаются get запросы?
Насколько я понимаю расклад(возможно неверно), вы не удаляете созданные запросы и они продолжают "накапливаться" как в браузере, так и в esp. Браузер это в принципе легко переживет, а вот у esp и память и кол-во открытых одновременных запросов ограничено.
 

ART_HA

Member
Насколько я понимаю расклад(возможно неверно), вы не удаляете созданные запросы и они продолжают "накапливаться" как в браузере, так и в esp. Браузер это в принципе легко переживет, а вот у esp и память и кол-во открытых одновременных запросов ограничено.
Попытался представить такую ситуацию, и у меня не получилось.
Ибо если связь есть, то есть запрос и ответ на него, а если связи нет, то нет ответа, но нет и запроса.
 
Попытался представить такую ситуацию, и у меня не получилось.
Помогу. Говоря утрированно, каждый вызов запроса по Timeout примерно эквивалентен созданию новой страницы браузера обращающейся к esp. Причем запросы в браузере создаются вне зависимости от того есть связь или нет. в том коде нет никаких проверок. На предыдущей страничке pvvx приводил логи на которых после 4 поставленного в очередь (но по всей видимости не обработанного) запроса esp-шка отваливалась от сети.
 

ART_HA

Member
Помогу. Говоря утрированно, каждый вызов запроса по Timeout примерно эквивалентен созданию новой страницы браузера обращающейся к esp. Причем запросы в браузере создаются вне зависимости от того есть связь или нет. в том коде нет никаких проверок. На предыдущей страничке pvvx приводил логи на которых после 4 поставленного в очередь (но по всей видимости не обработанного) запроса esp-шка отваливалась от сети.
Не понимаю.
Запрос по Timeout браузер посылает вне зависимости от того есть связь или нет.
Если связь есть, то запрос достигает ЕСП, и тот дает ответ.
А если связи нет, то запрос не достигает ЕСП, и никаких необработанных запросов в ЕСП не возникает.
 
А если связи нет, то запрос не достигает ЕСП, и никаких необработанных запросов в ЕСП не возникает.
Зато возникает в браузере где это запрос ставится в очередь на некоторое время.

Говоря образно, ситуация похожа на очередь в поликлинику, где запрос это "пациент", а esp - "врач". "Регистратура" timeout генерирует поток пациентов которые записываются к единственному врачу, и садятся в коридоре перед его кабинетом где всего 4 стула. Если врач работает медленнее регистратуры, то перед его кабинетом случается затык и пятого пациента посылают в пешее эротическое путешествие. Не попавшие на прием пациенты уходят слоняться по поликлиннике, иногда заходят обратно и пытаются занять стулья перед кабинетом, влезая между вновь прибывшими из регистратуры. А регистратура все гонит и гонит новых пациентов. Так понятно? :)

В правильно написанном коде следует дождаться приема пациента(или отказа в приеме), а только потом посылать туда следующего. В моем текущем коде на websockets я вызываю timeout из обработчика закрытия текущего сокета.

C:
function initWebSocket() {
    console.log('Trying to open a WebSocket connection...');
    Socket = new WebSocket('ws://' + host + ':81');
    Socket.onopen = function(event) {
      console.log("OnOpen");
    };
    Socket.onclose = function(event) {
      console.log("OnClose");
      setTimeout(initWebSocket, 100);
    };
    Socket.onerror = function(evt){console.log("Error"+evt);}
    Socket.onmessage = function(event) { processReceivedCommand(event);};
  }
 

ART_HA

Member
Зато возникает в браузере где это запрос ставится в очередь на некоторое время.
Говоря образно, ситуация похожа на очередь в поликлинику, где запрос это "пациент", а esp - "врач". "Регистратура" timeout генерирует поток пациентов которые записываются к единственному врачу, и садятся в коридоре перед его кабинетом где всего 4 стула. Если врач работает медленнее регистратуры, то перед его кабинетом случается затык и пятого пациента посылают в пешее эротическое путешествие. Не попавшие на прием пациенты уходят слоняться по поликлиннике, иногда заходят обратно и пытаются занять стулья перед кабинетом, влезая между вновь прибывшими из регистратуры. А регистратура все гонит и гонит новых пациентов. Так понятно?
Нет, потому что:
Во-первых, Вы описали проблемы коридора (браузера), а не врача (ЕСП). Врач как сидел за дверью в кабинете, так и сидит, ему плевать на очередь в коридоре.
А во-вторых, с чего Вы взяли, что врач (ЕСП) работает медленнее, чем указано в графике регистратуры (браузера)?
 

pvvx

Активный участник сообщества
В правильно написанном коде следует дождаться приема пациента(или отказа в приеме), а только потом посылать туда следующего. В моем текущем коде на websockets я вызываю timeout из обработчика закрытия текущего сокета.
Это никак не избавляет от одновременно открытых соединений на ESP. Откройте пять-шесть страниц обращающихся к ESP, можно и на разных устройствах.
А во-вторых, с чего Вы взяли, что врач (ЕСП) работает медленнее, чем указано в графике регистратуры (браузера)?
По тому что даже канал к нему медленнее, чем обрабатывает браузер.
Это схоже с DDOS атакой. Но типовой сервер выдерживает сотни запросов с открытием сотен портов одновременно, а ваша ESP всего 4-ре.
А дальше просто валиться в "протектед", т.к. кто-то неверно написал код.
 
Нет, потому что:
В этом примере "коридор" - это "предбанник" сетевого стека esp. А браузер это сама "поликлиника".
Врач esp работает медленне потому, что помимо лечения пациента(вашего кода) ему еще надо кучу бумажек оформить(обработка всех входящих запросов, отсыл ответа етс) о которых вы, как пациент, и не подозреваете.

Это никак не избавляет от одновременно открытых соединений на ESP.
Я заметил, сокет постоянно закрывается, и переоткрывается моим обработчиком (пишет об этом в лог браузера).
Может быть в этом причина поведения описанного в этом сообщении на предыдущей странице?
 

ART_HA

Member
По тому что даже канал к нему медленнее, чем обрабатывает браузер.
ИМХО тут одно из двух.
Либо канал ЕСП достаточен, и мы видим на экране компа данные от ЕСП. Либо канал недостаточен, и мы видим сообщение "Не удалось получить доступ к сайту".
 
Сверху Снизу