Шаблон интерфейса - включение по температуре

[Wagan]

Уважаемый mebitek, большое спасибо за информацию и за терпение, которое вызывает уважение.

От себя добавлю в подтверждение Вашей позиции: существует огромное количество систем, осуществляющих цетрализованный опрос абонентских точек. Кроме того, такие интерфейсы, как RS485 и RS422 обычно используются с такими протоколами, как Modbus, ставшими промышленными стандартами де факто. В таких протоколах нет иного режима, как опрос (полинг). И никаких проблем в них нет, всё детерминировано: если нет отклика от абонента, значит либо он не получил запрос, либо не может его отправить. Такая ситуация в системе считается штатной и верхним уровнем отрабатывается однозначно: либо перезапрос либо фиксация проблемы связи с абонентом и исключение его из цикла опроса на заданное количество циклов.

[stD]

И Вам спасибо, за добрые слова.

Мне очень хочется поболтать и даже поспорить (для пользы дела) вот о чём:

Есть проблема, и есть несколько вариантов решения, но все они имеют недостатки.

Суть вот в чём. Все протоколы, типа RS485, Modbus и т.д. - это всё хорошо и здорово, и прикрутить их к исполнительным устройствам не проблема. Дело в том, что они решают только вопросы взаимодействия устройств расположенных на одной территории (квартиры, дома, дачного участка, завода), и какой из этих протоколов применить - зависит от самого места, то есть штробить ли стены под провода или использовать радио канал и т.д.

Например дача, вообще не нужно никаких протоколов, все исполнительные и управляющие устройства стоят в щитке (там же стоит ардуина мега и сервер), а от него рассходится веер проводов. В бане стоит ещё одна ардуина, которая общается с основной с помощью RXTX через RS485.

Основная проблема, для меня во всяком случае, это связь с внешним миром.

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

И вот вопрос в том, как с ним общаться (при условии что подключено несколько клиентов и они с высокой частотой (допустим раз в 3сек) запрашивают текущее состояние), так чтоб клиенты не мешали друг другу?

(Клиенты работают через веб. Написание своих клиентских программ не приемлемо, это утопия и вообще не кошерно.)

[Wagan]

Нужен сервер, на котором необходимо поднять openvpn server, чтобы обеспечить шифрованный канал доступа извне. Без такого канала удаленный доступ к серверу не считается безопасным. К серверу могут подключаться несколько клиентов одновременно, в зависимости от объема оперативной памяти и производительности сервера.

В чем проблема при одновременном подключении к вэб-интерфейсу? Не вижу здесь проблем, ведь вэб-интерфейс вчего лишь отображает состояние и несколько клиентов никак ему не мешают производить опрос оконечников

[stD]

С серверами, впнами и прочими видами соединения я вполне дружу )))

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

Дело в другом, не важно по какому каналу мы подключились к серверу.
В частности мне нравится nginx. Он принимает запросы от клиентов, сколько к нему подключится не важно - хоть тысяча одновременно ))), всех обслужит.
Но вопрос в том, как дальше пойдёт запрос, например к основной ардуине. То есть, как правильно соединить nginx <---> arduina?

[Wagan]

Понял, что Вы имели в виду, прошу прощения)))

В таких УД, кака MajorDoMo, Jeedom, OpenHAB используют традиционные средства: разграничение доступа. На вэб-интерфейс заходим не сквозняком из туннеля, а логинимся. Это отсекает тысячи жаждущих внести противоречивые изменения. Однако и админов в системе может быть несколько, тогда оборудование отработает запросы от каждого последовательно. Чтобы не было заморочек, не нужно позволять через вэб отправлять микро-операции, тогда через вэб можно выполнить только какие-то сложные команды, состоящие из несколких мелких. То есть каждая команда через вэб занимает какое-то конечное время и есть очередь таких команд. Например команда "Никого нет дома" разбивается на микро-операции: выключить везде свет, закрыть жалюзи, выключить оргтехнику, включить систему безопасности, отправить подтверждение о выполнении. Это точно займет пару секунд. И даже если админов в системе несколько, противоречивые команды "Никого нет дома" и "У нас гости" выполнятся последовательно, но при этом полноценно и без конфликтов на оборудовании.

Может я опять чего-то не понял))) лучше приведите пример в какой-нибудь жизненной ситуации с УД

[stD]

Может я опять чего-то не понял)))

Вы всё правильно поняли. Сейчас соберусь с мыслями (проснулся только) и разложу задачу на составляющие.
Заодно, Вы не подскажите, где можно прочитать подробно про алгоритм обмена данными на сервере (например MajorDoMo и OpenHAB).

[stD]

Опишу на примере обычной квартиры.

Щиток:

В прихожей стоит щиток в котором стоят куча контакторов, которые отвечают за розетки, маленькие реле - отвечают за свет. От контакторов и реле уходят провода (220v), то есть схема "звездой". Контакторы и реле управляются ардуиной, так же к ардуине подключены не фиксируемые включатели (кнопки), они через ардуину вкл/откл реле (свет). И ещё к ардуине подключены датчики температуры, влажности и т.д.



...

Девайсы для управления:

В прихожей, к стене прибит ipad. В комнате валяется ещё один ipad. В кармане у меня и у жены телефоны.
Все эти четыре девайса подключены к серверу по вифи и раз в две секунды запрашивают у ардуины статус.

...

Агоритм:

Планшет раз в две секунды отправляет серверу символ/запрос, в ответ на который, ардуина отправляет статусы всех котакторов и реле + температуру и т.д.

Запрос влетает в сервер, сервер передаёт его php-скрипту, скрипт передаёт его ser2net'у, ser2net передаёт его ардуине, ардуина обрабатывает символ и отвечает.
Ответ отдаётся ser2net'у, который ждёт ответ, ser2net передаёт ответ php-скрипту, который тоже ждёт и отдаёт его серверу, сервер отдаёт клиенту.

...

В какой-то момент, получается так, что все планшеты (или не все, а например три из них) начинают запрашивать статус одновременно.
Серверу (nginx) это не страшно, он их мгновенно обработал по очереди.
Но вот когда все эти запросы передаются в php-скрипт, то он конечно не может обработать их одновременно. Он ведь в данное мгновение ждёт ответ от ардуины на первый запрос.
И вот здесь происходит затык.

А если ещё в этот момент, я с другого устройства пытаюсь включить свет, то естественно мой запрос "становится в очередь" и создаётся впечатление, что система повисла. То есть нет мгновенной реакции.
Вот это мне и не нравится.

Из-за этих затыков, непонятно как грамотно сделать так, чтоб отличить этот кратковременный затык от реальной потери соединения (железный или програмный отвал ардуины, php, ser2net, сервера).

У меня есть некоторые мысли (правда ещё не совсем сформировавшиеся) по решению этой проблемы, но очень бы хотелось послушать других людей и подискутировать на эту тему.

Убрав эти затыки, можно смело поднимать скорость обновления до 500мс. и почивать на лаврах ))).

[Prana]

>А если ещё в этот момент, я с другого устройства пытаюсь включить свет, то естественно мой запрос "становится в очередь" и создаётся впечатление, что система повисла. То есть нет мгновенной реакции.
Вот это мне и не нравится.

у себя в модуле я уходил от ежесекундного опроса состояния каждым из клиентов, реализовав эмуляцию "постоянного соединения": с клиента отправляется ajax-запрос с информацией о состоянии, хранящемся в клиенте. И cgi-скрипт подвешивает "на паузу" обработку запроса, если состояние не менялось. Если происходит изменение - сервер присылает ответ, если нет - отвечает только ближе ко времени таймаута.

[Mike]

mebitek, большое спасибо за цикл статей, для начинающих весьма ценный и понятный.
Сейчас стал разбираться с тем как подключать роутер(3020) к ардуине и возникли трудности, надеюсь подскажите куда копать.
На роутере зашит CyberWRT в связи с тем, что обещаны некоторые плюшки и удобство "из коробки", возможно в этом и проблема .
Удалось соединить и проверить связь по UART, светодиодом на ардуине моргать получается.
А вот заставить сервер получать данные, как описано URL="http://cyber-place.ru/showpost.php?p=24014&postcount=2"]здесь[/URL] не удалось. Лого остается красного цвета.
Предполагаю, что чего-то не хватает в предустановленном на CyberWRT uhttpd и он не может кроме статичной странички ничего вывести.
Если это так, то что нужно доставить?
Было бы здорово не переносить систему на флешку, а уместиться в свободной памяти роутера, вроде 1,2мб нам оставили
Чисто из соображений простоты и надежности, чтобы ничего не торчало, хватало питания, и не перестало включаться из-за потерявшейся/вытащенной кем-то флешки.


Вообще стоит задача снимать телеметрию(порядка 2 десятков параметров) с Атмеги и выводить ее через wi-fi на мобильные устройства (смартфон/планшет/ноутбук). На текущем этапе для проработки взята ардуина и всякие тестовые датчики вроде температуры/света/енкодера..., как с этим будет отлажено, функционал переместится на чистую атмегу.
С вероятностью 99% одновременно будет подключаться только 1 устройство и конфликтов быть не должно.
Частота обновления показания - 1 раз в секунду. Если будет 2-3 раза в сек. то вообще замечательно.

Буду рад каким-то подсказкам по реализации и по архитектуре. Пока думаю, что в моем случае лучше обойтись без запроса со стороны сервера в сторону контроллера, и просто ждать пока контроллер сам не отправит данные. На стороне сервера соответственно ждать данных с конроллера и регулярно обновлять их. Если будет какой-то пропуск "кадра" для отображения, то это не страшно, а вот если зависнет контроллер то это уже беда, поэтому не хочется его дополнительно нагружать. Или может я не прав?

[stD]

что чего-то не хватает в

А пхп установлен?
...

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

Вариантов обмена полно и все по своему хороши (или плохи, всё зависит от философских взглядов ) вопрос лишь в том где и как делать проверки.

вот если зависнет контроллер

Контроллер - это последнее, что может зависнуть. Тем более, ничто не мешает прикрутить "сторожевую собачку", которая в общем-то обязана присутствовать в наших поделках.