Arduino Mega Server

[Alex]

Так, тут нужно пояснить. Ещё в первой статье про АМС

http://geektimes.ru/post/259248/

я написал, цитирую

«Необходимое пояснение. В названии присутствует слово «сервер» и речь в первой части статьи идёт о серверных функциях системы. Это может ввести вас в заблуждение и создать впечатление, что основным назначением системы является хостинг файлов и сайтов и раздача контента. Это не совсем так... ...заменить микроконтроллером настоящий веб-сервер конечно не удастся.

Смысл системы несколько в другом. Вместе с Arduino Mega Server вы получаете возможность удобного управления своим устройством при помощи веб-интерфейса и просто роскошного (в визуальном смысле) выведения результатов его работы при помощи всей мощи современных технологий (HTML5, CSS3, THREE.js и т.п.). Будь то система управления умным домом, теплицей, автоматом по продаже напитков, метеостанцией или чем угодно, на что у вас хватит фантазии.»

Конец цитаты

Два клиента это уже неплохо, с оптимизацией или на более мощной Due будет 4-5 (активных!, пассивных могут быть десятки). Большего из микроконтроллера выжать очень трудно, но то, что есть уже очень неплохо.

По поводу технических вопросов. Страничка собирается совместными усилиями контроллера и браузерных скриптов, поэтому создать её на стороне контроллера скорее всего не удастся. Если кто-то думает иначе — интересно было бы послушать.

И вопрос к вам — на сайтах партнёров с обилием графики теряются ли картинки (на главных страницах)?

[nikita]

Есть ли в планах API, с помощью которого стороннее веб приложение или любой другой сервер сможет получить данные в удобном виде для дальнейшего использования?

В односокетном режиме прогружается 2-3 картинки на странице, изредка не прогружается CSS файл, среднее время загрузки одного изображения - 300-330 мс
В двухсокетном режиме ситуация несколько лучше: 6-7 картинок, среднее время загрузки одного изображения - 170-190 мс
В многосокетном режиме соединение нестабильно - достаточно часто "Страница недоступна". Грузится 1-2 изображения, а иногда и nil изображений

[Alex]

Есть ли в планах API, с помощью которого стороннее веб приложение или любой другой сервер сможет получить данные в удобном виде для дальнейшего использования?

Идея интересная и здравая. Я планировал нечто подобное но в ручном режиме — что-то нужно — для каждого случая программируем отдельное взаимодействие. Идея организовать системное API мне нравится. Надо поставить в планы.

В односокетном режиме прогружается 2-3 картинки на странице, изредка не прогружается CSS файл, среднее время загрузки одного изображения - 300-330 мс
В двухсокетном режиме ситуация несколько лучше: 6-7 картинок, среднее время загрузки одного изображения - 170-190 мс
В многосокетном режиме соединение нестабильно - достаточно часто "Страница недоступна". Грузится 1-2 изображения, а иногда и nil изображений

Если вы имеете в виду эти режимы

FREE_SOCKETS_ZERO = 0;
FREE_SOCKETS_ONE = 1;
FREE_SOCKETS_TWO = 2;

то у меня картина другая

при FREE_SOCKETS_ZERO = 0; грузится всё и всегда

при FREE_SOCKETS_ONE = 1; грузится всё, кроме 1 графического файла на страницах партнёров где много графики

с родной немодифицированной библиотекой — просто кошмар — не грузится 3 — 4 картинки на страницу.

И это странно — получается родная библиотека ведёт себя самым неадекватным образом.

С первой библиотекой для 5100 таких проблем не наблюдается вообще. Это наводит на мысль, что они некорректно сделали библиотеку для 5500 из библиотеки для 5100. Остаётся только определить, где они накосячили.

[alex946]

3. Доработка библиотеки dallastemperature, либо отказ от неё, т.к. она использует Delay - тем самым подвешивая систему по 1 секунде с каждого датчика.

В этой библиотеке есть асинхронный режим, пользуйтесь им и не будет проблем с задержками. См. примеры.

[Alex]

В этой библиотеке есть асинхронный режим, пользуйтесь им и не будет проблем с задержками. См. примеры.

Ещё, кажется, есть разница во времени измерения в зависимости от точности (которую можно выставить), хотя не уверен, давно это было.

[alex946]

Вопрос в количестве одновременных пользователей. Начиная с 2-х клиентов, система тормозит, некоторые элементы перестают прогружаться.

Просьба к разработчику и подопытным. Прочтите уже, пожалуйста, спецификации HTTP 1.0 хотя бы.
0. Сделайте дамп запросов к АМС, посмотрите на параллельность и общее их количество при каждом соединении.
1. Отдавайте правильные заголовки Last-Modified и Cache-control при отдаче статики. Это снизит нагрузки в десяток раз.
2. Настройте свои браузеры в соответствии с возможностями контроллера, (в Firefox это параметр network.http.max-connections-per-server в about:config и родственные ему.) Попробуйте работать при одном-двух коннектах.

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

По библиотеке Ethernet2 - там есть затыки с обработкой внешних событий и таймаутами. Пока непонятно, что с этим делать кроме как переписать её полностью, выкинув половину функционала, как это было сделано многими с предыдущей версией. Ссылку на исходники пришлю попозже.

[Alex]

1. Отдавайте правильные заголовки Last-Modified и Cache-control при отдаче статики. Это снизит нагрузки в десяток раз.

Если вы хотите помочь проекту, то оформите правильное решение в комментированный кусок кода. Покажите как надо на деле.

2. Настройте свои браузеры в соответствии с возможностями контроллера, (в Firefox это параметр network.http.max-connections-per-server в about:config и родственные ему.) Попробуйте работать при одном-двух коннектах.

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

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

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

[alex946]

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

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

Браузеры нужно настраивать, чтобы точно определить место сбоя и понять, возможно ли вообще обеспечить работу при текущей архитектуре. Если вы не хотите учиться и полностью понимать, что именно вы делаете - это ваш выбор. Если вы хотите подвергать своих подопытных риску преждевременной смерти из-за отсутствия гальванических развязок в интерфейсах - это ваш выбор. Если вы не читаете ПУЭ и при этом собираетесь управлять силовыми цепями - это ваш выбор. Если вы надеетесь развести специалистов на слабо и заставить их поработать на вас бесплатно - это ваш выбор. Все последствия - на вашей совести.

Переписывать за вас весь код АМС не планирую, там не в коде проблема а в изначальных идеях проекта, извините. Не хочу быть даже минимально причастным к возможным последствиям.

[pastry777]

библиотека DallasTemperature использует delay,да,вы правильно помните,задержка зависит от выставленной точности..если использовать точность 12бит,то время конвертации будет 750мс,если нам достаточно точности 9бит,это до 0.1*С,то время конвертации там всего около 150мс,точно не помню...SPBDima ошибался,когда сказал,что задержка 1с на каждый датчик в системе...команда на конвертацию дается широковещательная,сразу для всех устройств на шине,поэтому конвертация пройдет во всех датчиках одновременно..отказавшись от библиотеки Dallas оставив только OneWire,можно вообще уйти от задержки...к примеру если мы опрашиваем датчики раз в пять сек,то алгоритм будет такой:в 0 сек мы бросаем команду на конвертацию,пока они себе так конвертируются мы занимаемся своими делами,через пять сек забираем значения и снова даем команду на конвертацию...суть вы поняли,никаких задержек...

[Alex]

Браузеры нужно настраивать, чтобы точно определить место сбоя и понять, возможно ли вообще обеспечить работу при текущей архитектуре. Если вы не хотите учиться и полностью понимать, что именно вы делаете - это ваш выбор. Если вы хотите подвергать своих подопытных риску преждевременной смерти из-за отсутствия гальванических развязок в интерфейсах - это ваш выбор. Если вы не читаете ПУЭ и при этом собираетесь управлять силовыми цепями - это ваш выбор. Если вы надеетесь развести специалистов на слабо и заставить их поработать на вас бесплатно - это ваш выбор. Все последствия - на вашей совести.

Переписывать за вас весь код АМС не планирую, там не в коде проблема а в изначальных идеях проекта, извините. Не хочу быть даже минимально причастным к возможным последствиям.

В отличие от других участников форума, я от вас не видел ни одной строчки кода и ни одного дельного предложения, одни «понтовые» заявления. Соответственно, ценность ваших заявлений для меня и сообщества ровна нулю.