Скрыть объявление
Управляйте вашими ESP8266 и другими устройствами прямо с телефона из любой точки мира, где есть интернет!
Подробности и обсуждение IoT Manager в этой теме. Официальный сайт приложения и документация IoTmanager.ru
Скрыть объявление
На нашем форуме недоступен просмотр изображений для неавторизованных пользователей. Если Вы уже зарегистрированы на нашем форуме, то можете войти. Если у Вас еще нет аккаунта, мы будем рады, если Вы к нам присоединитесь. Зарегистрироваться Вы можете здесь.

Делюсь опытом Мониторинг и управление. ESP8266 и WebSocket.

Тема в разделе "Скетчи для Arduino IDE", создана пользователем view24, 22 фев 2017.

  1. view24

    view24 Новичок

    Сообщения:
    31
    Симпатии:
    0
    Мои 20 копеек в тему IOT - интернета вещей. Простой скетч для мигания, он же для отправки и приема числовых данных, он же для сохранения и отображения последних 10 000 точек измерений. На другом конце - ПАНЕЛЬ, т.е. картинка в любом браузере с графиками и кнопками управления.

    Начиналось это на научном предприятии и работает с лабораторным оборудованием до сих пор. Живой пример работы в реальном времени http://view24.ru/test24
     
  2. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    5.811
    Симпатии:
    1.005
    Почему написано 10000 точек, а отображает меньше?
    Виснет что-ли периодически :)
     
  3. view24

    view24 Новичок

    Сообщения:
    31
    Симпатии:
    0
    Уважаемый pvvx, внизу панели есть кнопочки, которыми устанавливается количество точек для просмотра - от 15 до 10000. Про зависания могу сказать, что используется websocket, (кстати, с частотой передачи 1 точка/сек) и зависания могут быть либо по причине слабого интернета либо скорости компа. Вы бы очень помогли, если бы рассказали о параметрах быстродействия интернета у Вас.
     
  4. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    5.811
    Симпатии:
    1.005
    В низу панели, если двигать указатель "влево", то он упирался в 9400 и происходил отсчет далее (прибавление кол-ва замеров раз в секунду). При следующей загрузке, или если подождать, то он доходил до 10001 и это был максимум. Далее всё циклически сдвигалось.
    Т.е. имело место, что в буфере было всего 9400 отсчетов.
    Вы сами не знаете что даете? :) Я дождался ночью, чтобы он дошел до 10001 и заскриншотил:
    Снимок1312.gif
    У меня интернет в предел 100MB/s и фиксированный IP, особенно ночью, т.к. не мешают телеканалы для детей :) В таком состоянии уже не помню сколько лет, оптику на 1GB/s в Питере не хотят ко мне тащить. :mad:

    Событие, когда было менее 9400 точек наверно увидите по времени на скриншоте, если оно устанавливается правильно...
     
    Последнее редактирование: 22 фев 2017
  5. view24

    view24 Новичок

    Сообщения:
    31
    Симпатии:
    0
    Вот теперь все сделано правильно. Отражаются события между 9341 точкой и последней 10001 точкой. И Вы совершенно правы, что правая последняя точка не будет иметь номера больше 10001. Это потому, что точки начала начала графика с течением времени удаляются из панели. Каждую секунду одна точка поступает в панель, одна - самая ранняя - удаляется. В противном случае - час работы компьютера или смартфона приводил бы к увеличению точек в буфере на 3600 единиц. И вот тут уже реально начались бы замедления. А в действительности график-то ползет себе, напоминая ленту регистратора.
     
  6. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    5.811
    Симпатии:
    1.005
    Про то и говорю - по началу было 9400 в пределе - последняя точка (если весь график сжать кнопкой "."). Затем, в течении 600 сек он дорос до 1001 и безусловно закольцевался - начало удалялось, а новое появлялось. Далее, через какое-то время, при следующем заходе, там было 9600 точек всего(!). Ждать не стал, но кол-во их росло.
    Исправляйте :)
    Возможная причина:
    При работе ESP8266 всегда (!) происходят дыры в передаче более 1 сек, связанные с его софтом WiFi драйвера. При этом он ругается в лог, какими-то цифрами из потрохов драйвера WiFi. Так-же, при появлении короткого импульса сильной помехи, у него сносит АРУ (может что-то другое), но это вызывает длительную паузу в передаче данных с него + идут пакеты реконнекта стека TCP (у вас же web-soscket!). Т.е. имеем дырки, а сервер принимает по часам - ставит принятым точкам метки по времени приема пакетов. Итого, если были пробелы, то пачка точек придет в одну и ту-же единицу времени отсчета сервера и он их поместит в одну точку. Дальше сообразите сами - вы же научное предприятие, которое считает трафик передачи перемножая кол-во бит данных, забывая о маркерах времени для каждой точки и атрибутов пакетов, если они малых размеров, да о арбитраже диктуемом в WiFi AP станцией... :)
     
    Последнее редактирование: 22 фев 2017
  7. view24

    view24 Новичок

    Сообщения:
    31
    Симпатии:
    0
    Я "забыл" не только о маркерах времени, но еще и накладных расходах, связанных с tcp/ip. Но я был первым, кто путем умножения доказал, что пропускная способность канала в 1000 раз превышает потребности, так стоит ли говорить о мелочах? :):):)
     
  8. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    5.811
    Симпатии:
    1.005
    Считайте заново, с учетом сказанного. :) Получите почти предел и любой чих или внешний WiFi всё опустит...
    Отсылка 1000 шт пакетов (и прием 1000 шт пакетов ACK если TCP) одним устройством в секунду. Прием АСК при TCP можно сократить в 2 раза. Т.е. 1500 пакетов.
    С UDP хуже в том случае - будет очень много потерь (почему - вам не укажу - должны сами знать :)).
    На обработку 1500 пакетов ESP при штатной частоте не тянет, а у вас ещё прием по SPI - жрет процессорное время наверно на 1/5 (пока вы там ковыряетесь в сотне регистров через тормозную шину на 26MHz, чтобы выудить всего 32 бита :) )
    1500*1560 = 2340000 байт при 1500 пакетах на полный MTU. Как видите ему не требуется обрабатывать более 1200 пакетов, чтобы упереться в предел HT20. Ему почти всё равно, есть данные в пакете или нет.
    Всё это говорит, что нам, домушникам, далеко до научных предприятий :) У нас выходит минус, а у вас в 1000 раз. Научите так жить :)
    И в научных предприятиях используют Arduino, где при приеме каждого пакета и других процедурах стоят ожидания в 1 ms для отдачи тиков системе... Тогда, да - действительно в 1000 раз :)

    PS: Блин, напомнили про Разработка параллельного детектора для Open Source CT 2 - совсем некогда заняться и сделать лучше и дешевле... но только 3D спектроскоп на рассеивании, как тама его - Рамана или тоже на Р...
     
    Последнее редактирование: 22 фев 2017
  9. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    5.811
    Симпатии:
    1.005
    На сайте view24 не расписано полного формата работы websocket. :(
    Надо ковырять какие-то "вимос" "скетчи" от устаревшего модуля, чтобы узнать протокол? (например на посылку "data=1234" какой ответ?)

    Получил такой "пинг"
    Код (Text):
    1. Connect ws://view24.ru ...
    2. >>>>>>>>>>>>>>>Connected to websocket server<<<<<<<<<<<<<<<<<<
    3. ws: connected, state = OPEN
    4. ws: send text msg
    5. ws: rx txtmsg[8]: 'ping=ok;'
    6. ping 47 ms
    7. ws: send text msg
    8. ws: rx txtmsg[8]: 'ping=ok;'
    9. ping 51 ms
    10. ws: send text msg
    11. ws: rx txtmsg[8]: 'ping=ok;'
    12. ping 48 ms
    13. ws: send text msg
    14. ws: rx txtmsg[8]: 'ping=ok;'
    15. ping 47 ms
    16. ws: send text msg
    17. ws: rx txtmsg[8]: 'ping=ok;'
    18. ping 50 ms
    19. >>>>>>>>>>>>>>>Closing the Connection with websocket server<<<<<<<<<<<<<<<<<<
    ~50 ms на сообщение туда и прием.
    Модуль RTL8710AF.
    На SSL:
    Код (Text):
    1. Connect wss://echo.websocket.org ...
    2. >>>>>>>>>>>>>>>Connected to websocket server<<<<<<<<<<<<<<<<<<
    3. ws: connected, state = OPEN
    4. ws: send text msg
    5. ws: rx txtmsg[6]: 'ping='
    6. ping 138 ms
    7. ws: send text msg
    8. ws: rx txtmsg[6]: 'ping='
    9. ping 136 ms
    10. ws: send text msg
    11. ws: rx txtmsg[6]: 'ping='
    12. ping 135 ms
    13. ws: send text msg
    14. ws: rx txtmsg[6]: 'ping='
    15. ping 135 ms
    16. ws: send text msg
    17. ws: rx txtmsg[6]: 'ping='
    18. ping 138 ms
    19. ws: send binary
    20. >>>>>>>>>>>>>>>Closing the Connection with websocket server<<<<<<<<<<<<<<<<<<
    Но wss://echo.websocket.org по жизни тормоз...
     
    Последнее редактирование: 5 мар 2017
  10. view24

    view24 Новичок

    Сообщения:
    31
    Симпатии:
    0
    Спасибо за эксперимент, 50ms - это я думаю неплохо для недорогого VPS.
     
    Последнее редактирование: 5 мар 2017
  11. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    5.811
    Симпатии:
    1.005
    Ужасно, но даже не в этом дело.
    Как и писалось, ваш сервер имеет ошибки. Если передавать чаще 1 сек, то показывает последнюю точку. График смешно прыгает :) при получении новых значений пока не истекла секунда, но выставляет при переходе на следующую секунду прямую, соединяющую предпоследнюю стробированную точку данного отрезка с прошлым. :)
    Но и это не всё - если передавать точки с паузой менее 120 ms, то ваш websocket глючит и вдобавок не воспринимает ни какие точки, пока пауза передачи между ними не будет больше.
    Всё это говорит о том, что его использовать, кроме как посмеяться - нельзя.
    Дельта "пинга" (передача соо - ответ) за пару тысяч точек достигла 500 ms. Часто выпадает при нажатии кнопки передачи чего устройству (помигать LED) на графике. Говорит о том, что сервак уже перегружен.
    50 ms - это пинг сервака на другой стороне шарика... имея в виду расстояние :)
    Приучаете народ к задержкам на "пинг" с серверами на Марсе? ;)
    В общем всё, что писалось, что ночью он терял точки с вашего тестового устройства - подтвердилось на 100 %. Любой сбой (тормоз) в сети до вашего сервака и точка с графика выпала - передать её повторно нельзя, не выждав паузы после прием ответа на прием прошлой точки от сервера ...
    Нет смысла в таком websocket, если за его время приема точки можно открыть и закрыть десяток HTTP соединений на ESP8266 - Кол-во и скорость открытия множественных Web соединений (JMeter) (это является доказательством, что проблема не в оборудовании, а в сотрудниках "научного предприятия" - британские учёные... :) )
    Но заодно нашел ущербности websocket входящего в либу Realtek к SDK RTL871xAx... Надо переписывать...
     
    Последнее редактирование: 5 мар 2017
  12. view24

    view24 Новичок

    Сообщения:
    31
    Симпатии:
    0
    Спасибо большое за Ваше внимание к моей работе. Наверное, столько постов к моей работе по WebSocket для ESP8266 от выдающегося метра IT дорогого стоят. Кстати, не против продолжения экспериментов по исследованию надежности нашего WebSocket сервера на предмет живучести. В связи с чем, разрешаю испытать наш сервер на максимальной нагрузке. Мы сами делали это много раз, но последняя версия работает надежно даже при наличии тысячи клиентов. Просьба сообщить, когда 'положите WebSocket сервер View24 ' по email - view24.ru@mail.ru Спасибо. А пока все работает, в чем можно убедиться, зайдя на http://view24.ru/test24
     
  13. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    5.811
    Симпатии:
    1.005
    Я не занимаюсь "укладыванием" серверов :)
    Могу произвести всего-то тест на возможность применения с простыми устройствами IoT, которые построены на популярных чипсетах с данного сайта. Он и был проведен, с вердиктом - глючковый сервак. :)
     
  14. view24

    view24 Новичок

    Сообщения:
    31
    Симпатии:
    0
    'глючковый сервак' - это что-то новое, не ожидал от 'корифеяIT'.
     
  15. Сергей_Ф

    Сергей_Ф Moderator Команда форума

    Сообщения:
    999
    Симпатии:
    111
    @view24 политкорректность никогда не была сильной стороной @pvvx. Вы суть смотрите. Обидно? Возможно. Но он дал Вам шанс и направление сделать лучше. Разве не так?
     
  16. view24

    view24 Новичок

    Сообщения:
    31
    Симпатии:
    0
    Сергей, абсолютно согласен. Если у читателей возникают вопросы, то не надо парировать эти вопросы, надо сделать так, чтобы вопросов не возникало. Это мне объяснили давно. Поэтому я благодарен @pvvx.
     
  17. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    5.811
    Симпатии:
    1.005
    Вы с потерей точек разобрались? Или нет? Они же будут теряться, даже если передавать реже 1-го раза в секунду. В сети пакеты приходят как попало и имеют разные задержки, а ваш сервак не ест точки, если между ними нет его любимой паузы. Самое интересное в этом - как умудрились сделать это(?). Если писать в лоб, то так не получиться. :)
    Посылаем сообщение новой точки на графике, предположим оно где-то застряло по пути и пришло через 1.01 секунд на ваш сервер. Он его съел, поместил в график и отправил подтверждение. Мы приняли подтверждение, а по счетчику времени у нас пора передавать следующую точку. Мы её и передаем... она приходт на глюк-сервер, пусть через 10 ms. Тут глюк-сервер обиделся - не прошла его специально программно вставленная любимая пауза, и кушать точку не хочет и занимается неизвестно чем. Усё - протокол нарушен, точка пропала...
    Если серверу не сожрать несколько точек из-за проблем в графиках, то самое простое решение - отказаться от протокола запрос-ответ. Посылаем хоть 100 сообщений точек, не дожидаясь ответа. У нас вроде не UDP :) Сервер их съест и выведет на график среднее за свой любимый промежуток. При этом ему не обязательно передавать ответы на прием каждой точки.
    Но это тоже решение глупой проблемы, связанной с невозможностью подписи времени точки точнее 1 сек для данных графика. Более нормальное решение для отображения(!) - выводить мин и мах за промежуток. Но оно не позволяет рассчитывать среднее значение за период.
    "Глючковатый" сервер и назван, по причине невозможности обработки данных с него ни для каких расчетов. И нафига для таких данных какая-то стабильность сервера? :) Ну рисует картинки - может и падать - картинки будут веселее... :)
    Так-же очень сильно перегружен интерфейс ответов. Зачем тупому IoT устройству знать куда и как сервер поместил отосланную точку? Он его посылку с временем в его формате в жизнь не разберет - ресурсов не хватит, а вот время и память для приема этой длинющей аброкадабры необходимо на устройстве выделить, чтобы понять в вашем запросно-ответном протоколе, что точка дошла, и только после этого, выждав паузу, можно передавать другую. Вот зачем это всё? Писал любитель-фрик? Мало гарантированной доставки в TCP, надо обязательно ввести поверх свой протокол подтверждения доставки? :) Наверно сеть мало нагружена и надо было её забить отсылкой простыней о самочувствии сервера с его дня рождения :) А почему он не отсылает dmesg на любое сообщение в websocket? Программист-фрик постеснялся?
     
    Последнее редактирование: 7 мар 2017
  18. view24

    view24 Новичок

    Сообщения:
    31
    Симпатии:
    0
    Вы пытаетесь измерить точность атомных часов школьным секундомером, после чего делаете сомнительный вывод о 'глючковатости' атомных часов. С чем Вас и поздравляю.
     

Поделиться этой страницей