В данном контексте «коммерческое» подразумевает использование с целью предоставления услуг, а не в тестовом режиме. См. выводы в конце: если вы предоставляете сервисы, то применять IPv6 можно и нужно. Если вы предоставляете доступ в Интернет конечным пользователям, то внедрение IPv6 принесет пока только дополнительные проблемы для техподдержки пользователей.
1. Для Вашего котла, судя по документации, существует штатный комнатный терморегулятор, работающий по принципу «цепь разорвана — ничего не греем, цепь замкнута — греем до параметров, заданных на консоли котла». Этот вариант у меня схемотехнически предусмотрен (т.е. есть реле, которым можно управлять программно). В этом случае (в отличии от управления по eBus) температурой будет управлять сам контроллер, основываясь на показаниях своих датчиков. А на консоли котла выставляется максимальное значение температуры обогрева.
2. За три месяца эксплуатации проблем с потерей давления пока не было, но за идею спасибо.
3. Стресс-тесты пока были такого плана:
— устройство вырубили/сдохло/оторвали_кабель. Отопление должно продолжать работать в каком-то из аварийных вариантов (т.е. в любом случае мы не должны остаться без тепла);
— устройство многократно выключают в произвольный момент времени. После включения работоспособность должна сохраняться;
— при попытке зависания устройство должно самостоятельно делать аппаратный сброс и восстанавливать свою работоспособность;
— отсутствует связь через Интернет. С устройством можно общаться (запросить состояние или дать команду на изменение режима) посредством SMS;
— связь через Интернет нестабильная (покрытие «прыгает» от EDGE до LTE). Устройство само пытается выбрать диапазон, в котором в настоящее время покрытие наилучшее. Если все-таки связаться с сервером никак не получилось, то накопленные данные будут отложены до следующего сеанса связи.
Питать котел с ИБП смысла особого пока не вижу. Отключение обогрева на несколько часов дом охлаждает не очень сильно. При восстановлении питания можно задать быстрый прогрев на более сильном режиме. А для автономного питания порядка суток и более к ИБП придется цеплять аккумуряторы большой емкости, что и дорого и занимает место. Да и цены на ИБП с чистым синусом не относятся к разряду гуманных.
В статье имелся ввиду низковольтный ИБП для питания самого устройства. Чтобы продолжать собирать телеметрию и, в случае необходимости, все-таки успеть послать сообщение хозяину об аварии.
Ардуинка для меня слабовата была. Хотелось быстро собрать систему, управляемую через Интернет. А это означает linux на борту. Из-за этого и взял банану в качестве платформы.
Не рискнули подключаться к котлу по eBus, или в Вашей модели он отсутствует? У меня этот вариант был в качестве запасного, если не удастся расколоть цифровой протокол обмена. Так что в схемотехнике вариант с реле предусмотрен, но реально не используется.
А от чего у вас кормятся уличные беспроводные датчики температуры? Сам хотел их добавить, но с дополнительным датчиком влажности и с питанием от солнечных батарей.
Я тоже сначала хотел купить готовую систему. Но управление через SMS меня не устроило из-за больших эксплуатационных расходов при желаемых объемах передаваемой телеметрии. Т.е. только в качестве аварийного варианта. Адекватных решений для работы через Интернет найти не удалось. Вот и пришлось самому заняться разработкой.
Пока поставил первый попавшийся на глаза Teplocom ST-555. Прыгающее напряжение он выравнивает, ну и ладно. А по результатам мониторинга за прошедшие 3 холодных месяца полное отключение электропитания было 4 раза на 5-60 минут. За это время дом остыть не успевает. Сам котел вполне способен запуститься самостоятельно. Ну или пнуть его можно удаленно, на крайний-то случай…
В оперативку (у бананы ее 1Gb). Раз в 15 минут сеанс связи с сервером. Если сервер подтвердил получение и корректную обработку данных, то из устройства они удаляются. В случае ошибки данные сохраняются до следующего сеанса. Пока что максимальный период отсутствия связи (из-за каких-то работ на сети оператора) был 3 суток. После восстановления связи потерь данных не обнаружено.
Спасибо, учту. Хотя дешевле сделать корпус с защелками, который снимать перед приходом контролеров и ставить обратно после их ухода. А текущая реализация — просто макет для отладки софта/железяки (описание железяки готовится в виде следующей статьи).
Дамы и господа, всех с прошедшими праздниками!
Наконец-то дошли руки сделать фотки крепления сенсора на газовый счетчик. Может быть кому-то пригодятся.
О, спасибо за идею, тоже подумаю, из чего можно сделать автономный счетчик. Единственное, что смущает — SS441A в режиме покоя от 5V кушает 5mA. Многовато будет для батарейки…
Так вроде больше о hardware статья. Ну да, не обзорная, скорее howto получился. По идее подключения сенсора, по созданию device tree конфигурации по физическим исходным разъемам. Если статья все-таки не по теме, то перенесу ее на хабр.
Не выберет, т.к. DHCP Relay Agent в запросе к серверу вполне может отправлять и dhcp option 82. А сервер может ограничить кол-во выдаваемых адресов по клиенту. Просто в моем конкретном случае это излишне (подразумевается наличие клиента с кривыми руками, способного воткнуть не то и не туда, а не злонамеренного хакера).
Каюсь, производительность не сравнивал. Возможно Вы и правы. Хотя что-то мне подсказывает, что дополнительная обработка пакета все-таки должна потреблять какое-то количество времени CPU.
Сейчас есть только 2 используемых IP: DHCP Server (он же default gateway для клиентов из всех VLAN) и DHCP Relay Agent. Если селить сервер на каждый VLAN, то имеем следующее:
— добавление/удаление клиента повлечет за собой операцию выделения/освобождения ip-адреса на интерфейсе (а какую маску ставить будем? На каждый VLAN выделять свою подсеть вместо ее динамического распределения?)
— при изменении общей размерности сети придется изменить параметры на всех интерфейсах;
— разрастание таблицы маршрутизации пропорционально кол-ву клиентов;
— уменьшение пропускной способности из-за увеличения нагрузки на CPU (вместо работы на L2 сначала разберем пакет до уровня L3, затем выполним фильтрацию/маршрутизацию, потом снова L3 соберем в L2).
Платформа не важна. Отладка вообще велась на десктопной машине, а целевая система собиралась при помощи buildroot. Но замечание о терминологии принимается, по-возможности внесу в статью исправления. И, возможно, стоит указать минимально необходимые опции сборки ядра для поддержки используемых фич. Хотя в современных generic ядрах все они присутствуют по умолчанию. Интересно, а есть здесь хаб для embedded programming?
Вообще-то в комментариях проскакивало, что это решение не для сервера, а для embedded-системы. Необслуживаемо — это верно, обслуживать просто нечего. Схема проста до невозможности и, практически, не использует ip-адресации.
Масштабируемо достаточно сильно: новый клиент добавляется одним шагом цикла в скрипте, который создает для него набор интерфейсов. Кол-во клиентов ограничено кол-вом поддерживаемых VLAN на обвязке. Вы ведь не думаете, что эта конфигурация создается вручную? Один маленький скрипт, получающий на входе требуемое кол-во клиентов и начальный номер VLAN для них (на самом деле еще и распределение VLAN-ов по физическим ethernet, но не суть).
Отлов проблем: зная VLAN с проблемным клиентом просто запустят на нем tcpdump.
2. За три месяца эксплуатации проблем с потерей давления пока не было, но за идею спасибо.
3. Стресс-тесты пока были такого плана:
— устройство вырубили/сдохло/оторвали_кабель. Отопление должно продолжать работать в каком-то из аварийных вариантов (т.е. в любом случае мы не должны остаться без тепла);
— устройство многократно выключают в произвольный момент времени. После включения работоспособность должна сохраняться;
— при попытке зависания устройство должно самостоятельно делать аппаратный сброс и восстанавливать свою работоспособность;
— отсутствует связь через Интернет. С устройством можно общаться (запросить состояние или дать команду на изменение режима) посредством SMS;
— связь через Интернет нестабильная (покрытие «прыгает» от EDGE до LTE). Устройство само пытается выбрать диапазон, в котором в настоящее время покрытие наилучшее. Если все-таки связаться с сервером никак не получилось, то накопленные данные будут отложены до следующего сеанса связи.
В статье имелся ввиду низковольтный ИБП для питания самого устройства. Чтобы продолжать собирать телеметрию и, в случае необходимости, все-таки успеть послать сообщение хозяину об аварии.
Не рискнули подключаться к котлу по eBus, или в Вашей модели он отсутствует? У меня этот вариант был в качестве запасного, если не удастся расколоть цифровой протокол обмена. Так что в схемотехнике вариант с реле предусмотрен, но реально не используется.
А от чего у вас кормятся уличные беспроводные датчики температуры? Сам хотел их добавить, но с дополнительным датчиком влажности и с питанием от солнечных батарей.
Наконец-то дошли руки сделать фотки крепления сенсора на газовый счетчик. Может быть кому-то пригодятся.
Каюсь, производительность не сравнивал. Возможно Вы и правы. Хотя что-то мне подсказывает, что дополнительная обработка пакета все-таки должна потреблять какое-то количество времени CPU.
— добавление/удаление клиента повлечет за собой операцию выделения/освобождения ip-адреса на интерфейсе (а какую маску ставить будем? На каждый VLAN выделять свою подсеть вместо ее динамического распределения?)
— при изменении общей размерности сети придется изменить параметры на всех интерфейсах;
— разрастание таблицы маршрутизации пропорционально кол-ву клиентов;
— уменьшение пропускной способности из-за увеличения нагрузки на CPU (вместо работы на L2 сначала разберем пакет до уровня L3, затем выполним фильтрацию/маршрутизацию, потом снова L3 соберем в L2).
Масштабируемо достаточно сильно: новый клиент добавляется одним шагом цикла в скрипте, который создает для него набор интерфейсов. Кол-во клиентов ограничено кол-вом поддерживаемых VLAN на обвязке. Вы ведь не думаете, что эта конфигурация создается вручную? Один маленький скрипт, получающий на входе требуемое кол-во клиентов и начальный номер VLAN для них (на самом деле еще и распределение VLAN-ов по физическим ethernet, но не суть).
Отлов проблем: зная VLAN с проблемным клиентом просто запустят на нем tcpdump.