Умный Дом по Ethernet

Обсуждение статей, технологий домашней автоматизации, программных и аппаратных решений
Andrey_B
Администратор
Сообщения: 5327
Зарегистрирован: 18 мар 2011, 12:06

Re: Умный Дом по Ethernet

Сообщение Andrey_B » 19 май 2011, 12:53

THK писал(а): Сразу хочу задать несколько вопросов:
В какой среде шла разработка?
Как сконфигурированы фьюзы?
С каким уровнем оптимизации компилировалась прошивка? (В некоторых случаях это влияет на ее работоспособность)
Тактирование МК от кварца или от ENC28J60 ?
И немного странный вопрос. :) Не могли бы Вы выложить бинарник прошивки?
Среда разработки: текстовый редактор ;), компилятор gcc-avr
Фьюзы для atmega88 и atmega168
low fuse: 0x60
high fuse: 0xdf
ext. fuse: 0x01
В случае тактирования от ENC28J60. Но позже устройство было переделано на тактирование от кварца.
Все опции компилятора вы можете видеть в Makefile. По вашему вопросу, "-Os"
Бинарник прошивки

stanislav.l
Сообщения: 90
Зарегистрирован: 17 май 2011, 13:25
Откуда: СПб
Контактная информация:

Re: Умный Дом по Ethernet

Сообщение stanislav.l » 19 май 2011, 14:07

Andrey_B писал(а): С вашей психологией нужно воздержаться от управления современным автомобилем. Ведь в нем электронная педаль газа, электронный блок управления двигателем, напичканная электроникой тормозная система, роботизированная коробка передач.
Ага! :) Кроме шуток - именно так :)
Но интеллект в системе управления двигателем меня напрягает только одним: невозможностью починить при помощи отвертки и наждачной бумаги. "Надежной" эту систему делает наличие разветвленной сети автосервиса и телефонов через каждые 500м. ( ! Обратите внимание - значительный элемент обеспечения надежности вынесен из устройства НАРУЖУ, он как бы и "не виден", но без него нельзя) А где-нибудь в Сибири - я буду ОЧЕНЬ серьезно думать - не лучше ли будет дедовский карбюратор и контактный трамблер ?...
А что касается АБС - эту штуку я в натуре БОЮСЬ. Даже если без всякой электроники. А с электроникой - боюсь панически. И постараюсь чтоб ее у меня никогда не было. Я хочу САМ и ТОЛЬКО САМ принимать решения с какой силой мне тормозить, мысль о том что между мной и тормозной колодкой находится еще какой-то модератор, меня просто переворачивает.

(Если вдруг Вам интересно - я готов с т.з. автоматического регулирования ДОКАЗАТЬ следующий тезис: АБС облегчает жизнь НЕУМЕЛОГО водителя в НЕКРИТИЧЕСКИХ ситуациях, а для нормального водителя в критической ситуации управляемость автомобилем УХУДШАЕТ. Но это - если интрересно, просто так воду лить не буду)
Скажите, как в моем случае система может устроить потоп или пожар? Возможно, я чего-то не учитываю и мне нужно срочно принять какие-то меры. Я всегда рад выслушать конкретные предложения и обоснованные возражения.
Ну я же Вам сказал: вариантов "двойного сбоя" просто необозримое множество, соответственно "сценариев катастрофы" тоже необозримо. В каком-то журнальчике тыщу лет назад печатали "научно-популярный пример" на тему автоматизированной противоракетной обороны. В 2-х словах: вот сделали амы ХОРОШУЮ, ПРАВИЛЬНУЮ систему, БЕЗ ОШИБОК (что невозможно, но предположим). Мы сделали в ответ такую же, обе встали на боевое дежурство. И вот, допустим, произошла вспышка газа на каком-то месторождении в Сибири. Амовская система фиксирует эту вспышку "боковым зрением" сквозь облака и принимает решение, что с ма-а-аленькой вероятностью это может быть пуск межконтинентальной ракеты. И НА ВСЯКИЙ СЛУЧАЙ принимает решение на единичку увеличить боеготовность. Наша система фиксирует ажиотаж в амовской, и тоже НА ВСЯКИЙ СЛУЧАЙ решает повысить боеготовность на единичку. Амовская система засекает это и воспринимает это как подтверждение угрозы, и повышает боеготовность дальше...

Суть примера: 2 идеальные, правильные системы, работают безошибочно ПО ОТДЕЛЬНОСТИ, а неучтенный аспект взаимодействия между ними приводит к "саморазгону" и катастрофе.

Ну бог с ними, ракетами...

Вот представьте, что в 30-градусную жару прошла ошибочная команда включения отопления на полную мощность - просто глюк. Когда температура поднялась до 45, подох блок питания свича, и команды управления к котлу больше не проходят.

Таких примеров можно напридумывать тысячи.

Сорри, надо убегать. Чуть позже смогу продолжить, если интересно.

THK
Модератор
Сообщения: 588
Зарегистрирован: 18 мар 2011, 19:00
Откуда: Серпухов, МО

Re: Умный Дом по Ethernet

Сообщение THK » 19 май 2011, 14:37

Вот представьте, что в 30-градусную жару прошла ошибочная команда включения отопления на полную мощность - просто глюк. Когда температура поднялась до 45, подох блок питания свича, и команды управления к котлу больше не проходят.
А куда делись рабочая и аварийная автоматика котла? Даже на старинных "АОГВ" их 2 штуки... ;)

Andrey_B
Администратор
Сообщения: 5327
Зарегистрирован: 18 мар 2011, 12:06

Re: Умный Дом по Ethernet

Сообщение Andrey_B » 19 май 2011, 15:23

stanislav.l писал(а):Но интеллект в системе управления двигателем меня напрягает только одним: невозможностью починить при помощи отвертки и наждачной бумаги.
Заметьте, что в приведенном вами примере системой является связка человек-автомобиль-сервис. Среднестатистический автолюбитель не справится с ремонтом автомобиля в дороге будь то карбюратор или инжектор. Для осуществления ремонта необходимо что-то, а именно знания, инструмент. То, что вы лучше знаете, к примеру, карбюратор говорит лишь о ваших личных предпочтениях, но ничего не говорит о надежности инжекторных двигателей. Производитель, если, конечно, не брать в расчет маркетинговую составляющую все же применяет те решения, которые а) надежнее (хотя бы в рамках гарантийного периода) б) экономичнее в) экологичнее д) создают дополнительный комфорт пользователю.
stanislav.l писал(а):А где-нибудь в Сибири - я буду ОЧЕНЬ серьезно думать - не лучше ли будет дедовский карбюратор и контактный трамблер ?...
Учитывая устройство контактного трамблера, подготовленность современного водителя, а также опыт эксплуатации инжекторных двигателей можно сказать, что в пересчете на время/количество отказов, перевес будет не в пользу карбюратора. Теперь что касается вообще возможности осуществления ремонта, то есть наличие сервиса.
Сибирь - это внешние условия. Любое устройство хорошо работает в рамках какой-то задачи, внешних условиях и требований пользователя. Именно поэтому Ethernet. Почему? Потому что а) стандарт Ethernet хорошо изучен и документирован б) Поддерживается большим количеством устройств в) хорошо распространен г) Детально проработаны протоколы верхнего уровня д) Дешев е) Доступен в продаже
Именно поэтому HTTP. Почему? Потому что любой слесарь, державший хоть раз в руках мышь способен понять принципы работы устройства, перенастроить его, составить любые элементарные программы для управления устройством. Устройство максимально стандартно и воспроизводимо. Вся документация, схемы и ПО есть в Интернете.
А теперь возьмем какой-нибудь более узкий промышленный или не дай бог разработанный самостоятельно интерфейс, протокол, систему сообщений и т.д. Вместо стандарта, проверенного годами, вместо хорошо протестированного и знакомого и легко поддающегося дебагу TCP/IP-HTTP мы получаем что-то экзотическое в наших домашних условиях. Вот вам и Сибирь. Для ремонта такого устройства потребуется выписывать шамана с бубном из Тунгусских лесов.
stanislav.l писал(а): А что касается АБС - эту штуку я в натуре БОЮСЬ. Даже если без всякой электроники. А с электроникой - боюсь панически. И постараюсь чтоб ее у меня никогда не было. Я хочу САМ и ТОЛЬКО САМ принимать решения с какой силой мне тормозить, мысль о том что между мной и тормозной колодкой находится еще какой-то модератор, меня просто переворачивает. (Если вдруг Вам интересно - я готов с т.з. автоматического регулирования ДОКАЗАТЬ следующий тезис: АБС облегчает жизнь НЕУМЕЛОГО водителя в НЕКРИТИЧЕСКИХ ситуациях, а для нормального водителя в критической ситуации управляемость автомобилем УХУДШАЕТ. Но это - если интрересно, просто так воду лить не буду)
Во-первых, системы АБС постоянно развиваются и то, что было зафиксировано, скажем, на тестах в 2007 году, сегодня может оказаться по сути "оборотками" для черновиков. Во-вторых, среднестатистический водитель, а это и большая доля женщин, в критических условиях покажет больший тормозной путь, чем АБС. Выигрыш с автомобилем без АБС может показать только очень подготовленный водитель, знающий как правильно тормозить и фактически делающий тоже самое, что АБС. Мой водительский стаж более 12 лет и я ездил на автомобилях как с карбюратором, так и с инжектором, как с АБС, так и без него. АБС в моем автомобиле разрабатывался давно, но зимой он меня здорово выручает. Это, если хотите, мое личное мнение.
Теперь, что касается системы Умный Дом. Да, безусловно можно сделать более надежную систему, где пользователь будет дергать педальку тормоза 10 раз в секунду самостоятельно. Но я делаю систему Умный Дом совершенно не для этого.
stanislav.l писал(а):
Скажите, как в моем случае система может устроить потоп или пожар? Возможно, я чего-то не учитываю и мне нужно срочно принять какие-то меры. Я всегда рад выслушать конкретные предложения и обоснованные возражения.
Ну я же Вам сказал: вариантов "двойного сбоя" просто необозримое множество, соответственно "сценариев катастрофы" тоже необозримо.
Вдумайтесь в то, о чем вы говорите. Вариантов много. Сценариев развития ситуации много. Совершенно неизвестно, какая система даст в том или ином случае более приемлемый вариант - сложная или простая. Тем более, что сложность системы - характеристика сугубо субъективная. Может случиться и так, что сложная "выручит", а может наоборот. Так какой смысл теоретизировать на эту тему? Это форум не о философии, это форум о реальных задачах и реальных путях решения. А "если бы, да кабы", "двойной сбой", "тройной сбой" - это, извините, сочинения на тему как я провел лето.

Про ракеты интересно. В самом деле. Только при чему тут мой модуль?
stanislav.l писал(а):Вот представьте, что в 30-градусную жару прошла ошибочная команда включения отопления на полную мощность - просто глюк. Когда температура поднялась до 45, подох блок питания свича, и команды управления к котлу больше не проходят.
У меня используется система отопления с низкотемпературным газовым котлом и водой в качестве теплоносителя. Максимальная температура воды 83-85 градусов. Вот представим, что в +30 прошла ошибочная команда. Хотя в моей схеме это должно быть 1) Включить котел 2) Включить насос контура 3) Полностью открыть привод 3-х ходового (а это включить ключ на 120 с). Вероятность возникновения 3-х разных ошибочных команд невелика. Но, допустим. И что? Что произойдет? Учитывая, что температура отдачи радиатора зависит от температуры в помещении, температура стабилизируется где-нибудь на 40, ну 45 градусах, вряд ли больше. Котел имеет собственную автоматику и будет, работая на максимуме, держать температуру теплоносителя 83-85 градусов - не больше. А сдохнет сервер от перегрева, так все сразу выключится, так как питание ключей, которые обеспечивают работу насоса, берется из БП сервера. При 45 внутри помещения не произойдет ни потопа ни пожара. Пример неудачный.
stanislav.l писал(а):Таких примеров можно напридумывать тысячи.
Давайте еще попробуем.

stanislav.l
Сообщения: 90
Зарегистрирован: 17 май 2011, 13:25
Откуда: СПб
Контактная информация:

Re: Умный Дом по Ethernet

Сообщение stanislav.l » 19 май 2011, 22:36

Маленькая оговорка: я вообще-то поспорить люблю, стараюсь себя сдерживать, чтоб не уходить в спор ради спора, все-таки помнить о теме. Но не всегда получается :) Надеюсь на понимание :)
Andrey_B писал(а): Заметьте, что в приведенном вами примере системой является связка человек-автомобиль-сервис.
Разумеется. Но в ситуации "я+карбюратор" элемент "сервис" не является позарез необходимым.
Среднестатистический автолюбитель не справится с ремонтом автомобиля в дороге будь то карбюратор или инжектор.
Поправка: из водителей "старой закалки" с карбюратором справится минимум каждый десятый. (А если речь будет идти о выживании, то может и больше) С инжектором не справится никто. (Ну не видел я людей, которые в дальнюю дорогу берут паяльник и осциллограф...)

Но если говорить о моей жене, например, она не починит ни того, ни другого, так что ДЛЯ ЭТОГО СЛУЧАЯ действительны все Ваши доводы об экономичности и экологичности...
Любое устройство хорошо работает в рамках какой-то задачи, внешних условиях и требований пользователя. Именно поэтому Ethernet. Почему? Потому что а) стандарт Ethernet хорошо изучен и документирован б) Поддерживается большим количеством устройств в) хорошо распространен г) Детально проработаны протоколы верхнего уровня д) Дешев е) Доступен в продаже
Именно поэтому HTTP. Почему? Потому что любой слесарь, державший хоть раз в руках мышь способен понять принципы работы устройства, перенастроить его, составить любые элементарные программы для управления устройством. Устройство максимально стандартно и воспроизводимо. Вся документация, схемы и ПО есть в Интернете.
Если Вы держите в уме возможность делать такие штуки НА ПРОДАЖУ - тогда я снимаю все вопросы, и говорю что Вы правы! Тогда довод про "любого слесаря" становится очень весом. Но если Вы делаете это для себя и ТОЛЬКО ДЛЯ СЕБЯ - тогда при чем здесь "любой слесарь" ?!

Возможно, я не с того конца начал :) Попробую изложить "правильно":
Я совершенно убежден, что для задач автоматического управления, подобных Вашей, протокол UDP в принципе значительно лучше подходит!

Отступление: не знаю кто Вы по профессии. Вы скромно называете себя "человеком, незнакомым с", но мне кажется, что Ваши знания превосходят знания любого из 2-х десятков программистов, что сейчас сидят вокруг меня. Так что могу ошибиться в выборе правильного уровня детализации, не пинайте сильно...

Итак, UDP изначально заточен на передачу коротких сообщений, не требующих подтверждения (именно то, что требуется в большинстве Ваших случаев). Поэтому UDP быстрее, меньше грузит сеть и всю сетевую аппаратуру. Меньше объем кода для реализации. Я исхожу из того, что каждый килобайт содержит, условно, 0.23 бага :) :) :) (цифра вписана от балды, но думаю что порядок именно такой)

Недостаток TCP я покажу на таком примере. Допустим, Вы передаете каждые 10 секунд данные о температуре. И допустим, что на пути следования пакета роутер пошел на перезагрузку, которая длится 30 секунд. Что произойдет в случае UDP ? - вы просто потеряете 2-3 измерения. В большинстве случаев это не трагично. А что будет, если Вы их шлете по TCP ?...

1. Потеряются как несколько пакетов данных, так и встречные ACK/NAK. (Обе стороны должны будут это хозяйство хранить в буферах, чтобы передать как только появится возможность. Как там у AVRки с памятью под буфера ?) В результате возникнет таймаут до 2-3 минут (по опыту работы с ssh). Вы получите все переданные отсчеты, но - сперва Вы получите из очереди 3 неактуальных отсчета, посланных во время перезагрузки роутера, затем несколько значений, ставших неактуальными, пока TCP восстанавливал нормальную последовательность, и только после этого придет актуальное значение. (Т.е. - значительно позже, чем пришло бы по UDP)

2. Если связи не будет "слишком долго" (сколько точно - надо смотреть конкретные реализации), то TCP-соединение просто будет разорвано, и после восстановления связи надо будет заново проделать всю процедуру установления соединения. Причем, если Вы начнете устанавливать соединение до того как восстановилась сеть - получите громадный таймаут, так что "простое" решение восстанавливать соединение в цикле окажется просто скверным с т.з. оперативности. Чтоб этого избежать, надо еще усложнить алгоритм - например, пинговать в цикле, и только когда пришел ответ на пинг, открывать сокеты...

Ну а если мы шлем команды ? Представьте себе, что Вы (в смысле - Ваш сервер) несколько раз шлете устройству команды включить-выключить-включить-выключить. А связи нет - как в предыдущем случае. Все ваши команды аккуратно выстраиваются в очередь, и после восстановления связи устройство получит их все подряд, хотя они давно стали неактуальны...

Это - плата за "гарантированную доставку".

Правда, если Вы выбрали http, как протокол "верхнего уровня", проблемы с очередью Вы обошли. Каким образом ? Да просто-напросто Вы занимаетесь эмуляцией UDP over TCP. Открыть сокет, послать пакет, получить пакет, закрыть сокет - это разве не есть эмуляция UDP ? ;) Но только с двадцатикратным перерасходом ресурсов как машинных, так и собственных. В русском языке это зовется "из пушки по воробьям".

За что же платим ? - а за возможность раз в 2 года поуправлять устройством с неподготовленного компьютера.

Вопрос: стОит ли оно того ?

Как маркетинговый ход, ради облегчения внедрения - однозначно, стОит. А если делать "для себя, чтоб работало хорошо" - сомневаюсь... Если же хочется сделать так потому, что хочется поэкспериментрировать, наделать кирпичиков для будущего здания, которое целиком пока еще виднеется очень смутно - это третий вариант, отличный и от первого и от второго, совершенно другой мотив, и в этом случае я критиковать не возьмусь! Но для "боевой" системы, не для экспериментальной - я бы все-таки настаивал на UDP :)
А теперь возьмем какой-нибудь более узкий промышленный или не дай бог разработанный самостоятельно интерфейс, протокол, систему сообщений и т.д. Вместо стандарта, проверенного годами, вместо хорошо протестированного и знакомого и легко поддающегося дебагу TCP/IP-HTTP мы получаем что-то экзотическое в наших домашних условиях. Вот вам и Сибирь. Для ремонта такого устройства потребуется выписывать шамана с бубном из Тунгусских лесов.
Не увлекайтесь - over http у Вас все равно ходит СОБСТВЕННЫЙ протокол. Единственное его преимущество - его можно назвать "самодокументированным". Но трудозатраты на эту "самодокументированность" вообще-то больше, чем на написание нормальной документации к какому-нибудь VPupkin-BUS.
Вдумайтесь в то, о чем вы говорите. Вариантов много. Сценариев развития ситуации много. Совершенно неизвестно, какая система даст в том или ином случае более приемлемый вариант - сложная или простая. Тем более, что сложность системы - характеристика сугубо субъективная. Может случиться и так, что сложная "выручит", а может наоборот.
О! Согласимся пока на том, что эта тема ОЧЕНЬ сложная. Не первый год ломаю над этим голову, но до сих пор даже для себя не смог сформулировать критерии "надежности". Вернее, смог сформулировать один: в любой автоматизированной системе хочу иметь большую кнопку, вырубающую всю автоматику разом, чтоб человек мог перехватить управление, и никакие электронные жуки не смогли этому воспрепятствовать.

А ежели человек по условиям задачи вмешаться не может, то как ставить один автомат следить за другим автоматом - к этой задаче я даже подходов не нащупал :( Очевидные решения для частных случаев - не в счет. Хочется именно "общие принципы" выработать...
Так какой смысл теоретизировать на эту тему? Это форум не о философии, это форум о реальных задачах и реальных путях решения. А "если бы, да кабы", "двойной сбой", "тройной сбой" - это, извините, сочинения на тему как я провел лето.
Да я, вообще-то, с отверткой в руках себя чувствую уверенней, чем с книгой :)
Любая ненулевая вероятность рано или поздно реализуется. А с учетом общей склонности к недооценке каких-то факторов - гораздо больше "рано". Дурацкий пример: если вероятность ошибочного чтения байта с диска равна 10E-12 - это хорошо ? Вроде бы нормально! Встряхиваем головой и понимаем: это значит на терабайтном диске 1 файл гарантированно битый :) Другой дуракций пример: кошка роняет клавиатуру, при ее падении нажимаются последовательно F8, Enter (Norton Commander). Какова вероятность ? Ничтожно маленькая. Произошло на моих глазах.
Если вероятность неприятности =10E-9 - можем с чистой совестью ей пренебречь. Но если число таких "независимых" неприятностей =10Е7, то вероятность что какая-то одна из неприятностей реализуется оказывается чертовски высокой! И я не знаю другого пути повышения надежности кроме "перебора" на тему "а какая бяка еще может случиться, и как нам этого избежать"
1) Включить котел 2) Включить насос контура 3) Полностью открыть привод 3-х ходового (а это включить ключ на 120 с). Вероятность возникновения 3-х разных ошибочных команд невелика.
А какова вероятность, что программа получит температуру в доме = -255 градусов ? Там есть подпрограмма "сомнение в достоверности данных" ? ;)
Но, допустим. И что? Что произойдет? Учитывая, что температура отдачи радиатора зависит от температуры в помещении, температура стабилизируется где-нибудь на 40, ну 45 градусах, вряд ли больше.
Думаю - больше. (Точнее можно сказать, если Вы дадите данные о режиме отопления в самый сильный мороз) "Но, допустим" При такой температуре резко (в десятки раз) возрастает вероятность выхода из строя любой электроники, и значительно возрастает вероятность перерастания в пожар случайной искры. Хотя бы фокусировка солнечных лучей от неровностей стекла - при 20 градусах она еще "безопасна", а при 45 - заметно "опасней".

Девушку спрашивают:
- Какова вероятность встретить на улице динозавра ?
- 50% !
- ???!
- Либо встречу, либо нет !

Короче: я не говорил о гарантированном пожаре ! :) Здесь оперируем вероятностями. Если при 20 градусах вероятность была, скажем, 10Е-5, то при 45 она вырастает в 100, а то и в 1000 раз. Была "пренебрежимо мала", стала просто "мала", уже не "пренебрежимо". Такой подход возражений не вызывает ?
Котел имеет собственную автоматику и будет, работая на максимуме, держать температуру теплоносителя 83-85 градусов - не больше. А сдохнет сервер от перегрева, так все сразу выключится, так как питание ключей, которые обеспечивают работу насоса, берется из БП сервера.
Удачное решение! Кроме шуток. Можно сказать - "задарма" сделали такую дополнительную защиту. Но подыхание сервера может случиться и в процессоре (при 45, если кулер не пылесосили год - вероятность не подыхания, но зависона - я бы сказал повыше 50%!), а БП будет послушно питать мертвое железо.
stanislav.l писал(а):Таких примеров можно напридумывать тысячи.
Давайте еще попробуем.
Зачем? Можно и этот "добить" :)

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

Сорри за количество. Все-таки не уследил за собой :) Ну не стирать же теперь - так старался :mrgreen:

Andrey_B
Администратор
Сообщения: 5327
Зарегистрирован: 18 мар 2011, 12:06

Re: Умный Дом по Ethernet

Сообщение Andrey_B » 19 май 2011, 22:50

Добавил в прошивку поддержку АЦП.
Теперь можно видеть состояние АЦП в диапазоне от от 0 до 255.
Конвертация запускается в момент обращения к странице, поэтому нужно обращаться к ней дважды, чтобы увидеть текущее значение.
Думаю, как это лучше реализовать. Можно по таймеру запускать конвертацию, но случаи разные бывают, а таймер фиксированный. Или предусмотреть отдельную кнопку в интерфейсе. Или еще лучше, задержать на некоторое время выдачу страницы, пока идет преобразование. Задержка, думаю, будет очень невелика.
Виктор, как думаете?
ablog_eth_beta_adc.jpg
ablog_eth_beta_adc.jpg (18.7 КБ) 40808 просмотров

Andrey_B
Администратор
Сообщения: 5327
Зарегистрирован: 18 мар 2011, 12:06

Re: Умный Дом по Ethernet

Сообщение Andrey_B » 20 май 2011, 00:34

stanislav.l писал(а):Поправка: из водителей "старой закалки" с карбюратором справится минимум каждый десятый. (А если речь будет идти о выживании, то может и больше) С инжектором не справится никто. (Ну не видел я людей, которые в дальнюю дорогу берут паяльник и осциллограф...)
Лично не сталкивался от отказом блока ЭБУ. Сталкивался с отказом одного или нескольких датчиков: ДМРВ, дроссельной заслонки, лямбда-зонда. Разница лишь в том, что если накроется какой-нибудь жиклер, мы встанем и начнем ковырять "солекс" отверткой, а если накроется половина датчиков, мы поедем. Плохо, но поедем. В этом и смысл моего устройства. Предусмотреть сценарий по умолчанию, так сказать байпас.
stanislav.l писал(а): Если Вы держите в уме возможность делать такие штуки НА ПРОДАЖУ - тогда я снимаю все вопросы, и говорю что Вы правы! Тогда довод про "любого слесаря" становится очень весом. Но если Вы делаете это для себя и ТОЛЬКО ДЛЯ СЕБЯ - тогда при чем здесь "любой слесарь" ?!
Все мои домочадцы, включая детей, хорошо умеют обращаться с компьютером, во всяком случае что касается Интернета. И если вдруг, когда меня нет дома, случится выход из строя сервера (а такой случай реально имел место), я, даже не имея доступа к компьютеру могу сказать, зайди на адрес такой-то и кликни по ссылке такой-то, чтобы заработало то-то. А теперь представьте что мне надо будет сказать в каком-нибудь ином случае. SSH, рут, терминал? Это не основная возможность данного девайса, но с моей точки зрения нисколько не лишняя.

Все, что вы пишите про UDP совершенно неактуально в домашней локальной сети. HTTP поверх TCP я выбрал не только и не столько за гарантированную передачу данных, хотя ничего он на самом деле не гарантирует, сколько за гибкость, простоту и возможности. Мне надо чтобы быстро, просто и эффективно.
stanislav.l писал(а): Недостаток TCP я покажу на таком примере. Допустим, Вы передаете каждые 10 секунд данные о температуре. И допустим, что на пути следования пакета роутер пошел на перезагрузку, которая длится 30 секунд. Что произойдет в случае UDP ? - вы просто потеряете 2-3 измерения. В большинстве случаев это не трагично. А что будет, если Вы их шлете по TCP ?...
1. Потеряются как несколько пакетов данных, так и встречные ACK/NAK. (Обе стороны должны будут это хозяйство хранить в буферах, чтобы передать как только появится возможность. Как там у AVRки с памятью под буфера ?) В результате возникнет таймаут до 2-3 минут (по опыту работы с ssh). Вы получите все переданные отсчеты, но - сперва Вы получите из очереди 3 неактуальных отсчета, посланных во время перезагрузки роутера, затем несколько значений, ставших неактуальными, пока TCP восстанавливал нормальную последовательность, и только после этого придет актуальное значение. (Т.е. - значительно позже, чем пришло бы по UDP)
Реализация TCP/IP от tuxgraphics однопакетная. Буфер фиксированного объема. Новые пакеты фактически уничтожают старые. С точки зрения управления устройства вручную все это не имеет никакого практического значения. С точки зрения срабатывания сценария по умолчанию, устройство сформирует всего один пакет. Если коммутатор неисправен или отсутствует нет никакой разницы, будет это TCP или UDP.
stanislav.l писал(а): Правда, если Вы выбрали http, как протокол "верхнего уровня", проблемы с очередью Вы обошли. Каким образом ? Да просто-напросто Вы занимаетесь эмуляцией UDP over TCP. Открыть сокет, послать пакет, получить пакет, закрыть сокет - это разве не есть эмуляция UDP ? ;) Но только с двадцатикратным перерасходом ресурсов как машинных, так и собственных. В русском языке это зовется "из пушки по воробьям".
Я не понимаю к чему вся эта игра слов. С тем же успехом программист, скажем, на C++, Delphi или PHP бьет из пушки по воробьям, ведь ГОРАЗДО эффективнее писать на ассемблере.
О каких машинных ресурсах вы говорите? Простейшая Atmega справляется с поставленной задачей легко. Фактически 99.9% времени она ничем не занята. 20Мгц с лихвой хватает на реализацию всего задуманного. Обычно я покупаю вещь, чтобы использовать ее, а не бережно хранить в шкафчике. А та экономия, про которую вы говорите, выражается в русском языке так "экономия на спичках". И я, по-моему, перестал понимать смысл всех ваших рассуждений. Что вы предлагаете? Реализацией TCP/IP я не занимался, готовых стэков под Atmega по крайней мере три. Все, чем я занимался, это а) изучение C б) изучение возможностей и принципов устройства AVR в) реализация именно той логики, которая мне нужна. Исходя из этого я не вижу никакого перерасхода своих ресурсов. Построение системы Умный Дом я делаю с позиции архитектора, а не с позиции разнорабочего. Иногда, как в данном случае, я выступаю в роли исследователя, но основная мысль, собрать доступные мне кубики, пазл в единое целое. Видите ли, разрабатывать целиком свое решение, свой протокол, свою схемотехнику расточительная трата времени. Нельзя заниматься всем сразу. Но можно использовать все сразу. В технологиях Интернет, я, впрочем, как и все ведущие производители оборудования для систем Умного Дома видят механизм, позволяющий сцепить кубики воедино. Так что же вы от меня хотите?
stanislav.l писал(а):За что же платим ? - а за возможность раз в 2 года поуправлять устройством с неподготовленного компьютера.
Вы, по-моему не прочитали тот абзац, где я писал, почему в качестве основы взят HTTP. Мне так удобнее. Такой ответ устроит?
stanislav.l писал(а): Не увлекайтесь - over http у Вас все равно ходит СОБСТВЕННЫЙ протокол. Единственное его преимущество - его можно назвать "самодокументированным". Но трудозатраты на эту "самодокументированность" вообще-то больше, чем на написание нормальной документации к какому-нибудь VPupkin-BUS.
Все, что передается внутри HTTP можно назвать собственным протоколом. Это вопрос терминологии. О каких трудозатратах вы говорите? Мне, как человеку никогда раньше не писавшему для AVR, никогда не использовавшему C, потребовалось где-то 4-5 вечеров, чтобы реализовать основную массу задуманного. Я траву с граблями и лопатой сажал в огороде дольше. На чемпионат мира, где наши проиграли чехам потратил больше. Но это, извините, мое время.
stanislav.l писал(а):Любая ненулевая вероятность рано или поздно реализуется. А с учетом общей склонности к недооценке каких-то факторов - гораздо больше "рано". Дурацкий пример: если вероятность ошибочного чтения байта с диска равна 10E-12 - это хорошо ? Вроде бы нормально! Встряхиваем головой и понимаем: это значит на терабайтном диске 1 файл гарантированно битый :) Другой дуракций пример: кошка роняет клавиатуру, при ее падении нажимаются последовательно F8, Enter (Norton Commander). Какова вероятность ? Ничтожно маленькая. Произошло на моих глазах.
Если вероятность неприятности =10E-9 - можем с чистой совестью ей пренебречь. Но если число таких "независимых" неприятностей =10Е7, то вероятность что какая-то одна из неприятностей реализуется оказывается чертовски высокой! И я не знаю другого пути повышения надежности кроме "перебора" на тему "а какая бяка еще может случиться, и как нам этого избежать"
Сегодня в нашей местности было необыкновенно красивое небо. След от пролетающего самолета подсвечивался лучами заходящего солнца, от чего приобретал сказочный огненно пылающий цвет вишневого сиропа. А воздух сегодня был наполнен ароматами распускающейся сирени, липы, казался густым, сочным, свежим и постоянное преображался от легкого дуновения ветерка. Смотрю я на ваши 10E-9 и думаю, что вот это то время я точно трачу зря.
stanislav.l писал(а):
1) Включить котел 2) Включить насос контура 3) Полностью открыть привод 3-х ходового (а это включить ключ на 120 с). Вероятность возникновения 3-х разных ошибочных команд невелика.
А какова вероятность, что программа получит температуру в доме = -255 градусов ? Там есть подпрограмма "сомнение в достоверности данных" ? ;)
Программа управления отоплением работает с данными за последние 3 часа. Если в текущий момент было получено значение -255, что для 1-wire надо еще постараться сделать, то этого будет недостаточно, чтобы внести существенные коррективы в работу системы отопления. Впрочем, я неоднократно поднимал вопрос о том, что такой механизм, работающий в бэкграунде нужен. И дело даже не в очевидных ошибках (типа -255), а в сложных взаимосвязях. Например необычно долго работает насос системы водоснабжения в 5 утра или в отсутствие хозяев. Пики (еще нужно понять, пики ли это) в потреблении электроэнергии и т.д.
stanislav.l писал(а):
Но, допустим. И что? Что произойдет? Учитывая, что температура отдачи радиатора зависит от температуры в помещении, температура стабилизируется где-нибудь на 40, ну 45 градусах, вряд ли больше.
Думаю - больше. (Точнее можно сказать, если Вы дадите данные о режиме отопления в самый сильный мороз) "Но, допустим" При такой температуре резко (в десятки раз) возрастает вероятность выхода из строя любой электроники, и значительно возрастает вероятность перерастания в пожар случайной искры. Хотя бы фокусировка солнечных лучей от неровностей стекла - при 20 градусах она еще "безопасна", а при 45 - заметно "опасней".
А вы не думали, что более опасней - 5 минут за рулем автомобиля или 24 часа Умного Дома? Что вероятнее, кирпич на голову или критический сбой системы управления отоплением? Вероятности, вероятности, вероятности. Ну возрастет, и что? В жаркую погоду мои темные металлические отливы на деревянных окнах имеют температуру сильно выше 100 градусов. Тоже, наверное, вероятность... Страшно жить, правда?
stanislav.l писал(а):Короче: я не говорил о гарантированном пожаре ! :) Здесь оперируем вероятностями. Если при 20 градусах вероятность была, скажем, 10Е-5, то при 45 она вырастает в 100, а то и в 1000 раз. Была "пренебрежимо мала", стала просто "мала", уже не "пренебрежимо". Такой подход возражений не вызывает ?
Все ваше жонглирование цифрами не более чем калейдоскоп. Ключевое слово в ваших рассуждениях - "скажем".
stanislav.l писал(а): Вы автоматику котла проверяете каждый день ? Вот, котел не включался месяц - Вы готовы поклясться здоровьем своих близких, что эта автоматика в идеальном состоянии, и вероятность ее глюка "пренебрежимо мала" ?
Вы, кажется, изволили говорить о надежности компьютерного управления системами. Так вот автоматика котла вне системы Умного Дома. Она есть в любом случае, используется Умный Дом или не используется. Вы, кажется, изволили выразится, что система Умный Дом вполне конкретно может устроить пожар или потоп. Я попросил рассказать как. Внятных доводов я, как и предполагал, не услышал.
Если котел, пылесос, стиральная машина, чайник, микроволновка, посудомоечная машина неисправны и вот-вот устроят пожар и потоп, так это вовсе не значит, что причина в несчастном Ethernet-модуле, который мы тут пытаемся обсуждать.

THK
Модератор
Сообщения: 588
Зарегистрирован: 18 мар 2011, 19:00
Откуда: Серпухов, МО

Re: Умный Дом по Ethernet

Сообщение THK » 20 май 2011, 07:32

Andrey_B писал(а):Добавил в прошивку поддержку АЦП.
Теперь можно видеть состояние АЦП в диапазоне от от 0 до 255.
Конвертация запускается в момент обращения к странице, поэтому нужно обращаться к ней дважды, чтобы увидеть текущее значение.
Думаю, как это лучше реализовать. Можно по таймеру запускать конвертацию, но случаи разные бывают, а таймер фиксированный. Или предусмотреть отдельную кнопку в интерфейсе. Или еще лучше, задержать на некоторое время выдачу страницы, пока идет преобразование. Задержка, думаю, будет очень невелика.
Виктор, как думаете?
ablog_eth_beta_adc.jpg
Поражаюсь Вашей трудоспособности!
Я думаю, что лучше задержать страницу, тем более, что такую задержку будет трудно заметить.
В даташите написано: "13 µs - 260 µs Conversion Time", т.е. максимальное время преобразования 260 µs - меньше чем 0,0003 секунды! И это, как я понимаю, при максимальной разрядности преобразования.

stanislav.l
Сообщения: 90
Зарегистрирован: 17 май 2011, 13:25
Откуда: СПб
Контактная информация:

Re: Умный Дом по Ethernet

Сообщение stanislav.l » 20 май 2011, 11:01

Andrey_B писал(а):... Мне так удобнее. Такой ответ устроит?
Вполне устроит.
Нет у меня задачи Вас переспорить, переубедить, навязать Вам свои "вкусы" в отношении протоколов или языков (Кстати, мой "любимый" - таки да, ассемблер, ткнув "пальцем в небо", Вы попали в точку! :) ) Я поклонник "спартанского" стиля и в программизме, и в технике вообще, основной принцип - "ничего лишнего". Вы этот принцип не разделяете - ну так это не повод для огорчений. Ваше решение в любом случае интересно, в любом случае это опыт.

Если вдруг будет желание поспорить о принципах - может быть лучше дождаться возможности личной встречи за чаем/пивом/покрепче, а писать немножко устал. Мне есть что сказать и по поводу использования эзернета, и по поводу привлечения домашних к управлению устройствами, но "объем" обсуждения и временнЫе затраты на него уже слегка выходят за границы "рационального" :)

Или, если вдруг смогу отдельные утверждения сгруппировать в нечто стройное - откроем отдельную тему "споры о принципах построения" и там, при желании, будем оттягиваться.

Andrey_B
Администратор
Сообщения: 5327
Зарегистрирован: 18 мар 2011, 12:06

Re: Умный Дом по Ethernet

Сообщение Andrey_B » 20 май 2011, 23:59

Задал задержку около 100 микросекунд.
Одного _delay_loop_1(0); на 16Мгц от внешнего кварца было мало.
Теперь реальное значение с АЦП доступно сразу. Естественно, на глаз задержка незаметна.
Новые бинарник и исходники на сайте. В целом все готово для реального использования девайса. Думаю, совсем скоро это случится.

stanislav.l, подискутировать на философские темы всегда интересно, в отдельной теме. Но в данном случае как в анекдоте про обезьяну - "че думать, прыгать надо". Вот и прыгаем. ;)
А вообще я некоторое время назад понял, что на любую вещь можно посмотреть с разных сторон. Вроде бы очевидная штука, да не совсем. В этом смысле "лишний", "не лишний", "полезный", "бесполезный" все зависит от угла, под которым смотришь на предмет. А мировоззрение человека также подвержено развитию по спирали. От минимализма к классицизму, от классицизма к барокко, от барокко к индустриальному техно, от техно к неоклассицизму. Копья ломаются, а результаты творения рук человеческих остаются. Поэтому и прыгаем и будем прыгать, пока живы.

THK
Модератор
Сообщения: 588
Зарегистрирован: 18 мар 2011, 19:00
Откуда: Серпухов, МО

Re: Умный Дом по Ethernet

Сообщение THK » 21 май 2011, 08:35

Andrey_B писал(а):Задал задержку около 100 микросекунд.
Одного _delay_loop_1(0); на 16Мгц от внешнего кварца было мало.
Теперь реальное значение с АЦП доступно сразу. Естественно, на глаз задержка незаметна.
Новые бинарник и исходники на сайте. В целом все готово для реального использования девайса. Думаю, совсем скоро это случится.
Мне кажется, что 100 микросекунд маловато... Допускаю, что все будет работать и так, но на мой взгляд между запуском АЦП и считыванием данных с него должно пройти не менее 260 микросекунд.
160 микросекунд на запрос погоды не сделают, а надежность и достоверность преобразования повысят.
Новые бинарник и исходники на сайте.
:?:

Andrey_B
Администратор
Сообщения: 5327
Зарегистрирован: 18 мар 2011, 12:06

Re: Умный Дом по Ethernet

Сообщение Andrey_B » 25 май 2011, 23:41

Опубликовал статью на сайте. Фактически это копия того, что написано здесь, на форуме с небольшими уточнениями и дополнениями.
Может быть, пригодится не только мне.

THK
Модератор
Сообщения: 588
Зарегистрирован: 18 мар 2011, 19:00
Откуда: Серпухов, МО

Re: Умный Дом по Ethernet

Сообщение THK » 26 май 2011, 07:48

Отличная статья!
Для полноты картины не хватает описания как общаться со входом, настроенным как ADC.

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

Andrey_B
Администратор
Сообщения: 5327
Зарегистрирован: 18 мар 2011, 12:06

Re: Умный Дом по Ethernet

Сообщение Andrey_B » 27 май 2011, 23:46

THK писал(а):Для полноты картины не хватает описания как общаться со входом, настроенным как ADC.
Немного модифицировал исходники.
Теперь стало еще проще.

Код: Выделить всё

http://192.168.0.14/sec/?pt=7&cmd=get
Выдаст только состояние порта (ON, OFF, значение АЦП) без лишней информации.
На сервере можно написать только одну строчку на PHP

Код: Выделить всё

$adc = file_get_contents('http://192.168.0.14/sec/?pt=7&cmd=get');
И в переменной $adc у нас лежит состояние запрошенного порта.
Вот именно поэтому TCP/IP и HTTP, вместо всяких там... UDP, а не потому что это дает или не дает гарантию передачи. Универсализм и стандарт, как говорится, рулез форева.

THK
Модератор
Сообщения: 588
Зарегистрирован: 18 мар 2011, 19:00
Откуда: Серпухов, МО

Re: Умный Дом по Ethernet

Сообщение THK » 28 май 2011, 00:55

Выдаст только состояние порта (ON, OFF, значение АЦП) без лишней информации.
На сервере можно написать только одну строчку на PHP
Да, всё гениальное просто!

PS Сегодня на работе изготовил печатку, спаял, а прошить не успел... Жду понедельника.

sysand
Сообщения: 3
Зарегистрирован: 27 май 2011, 07:24

Re: Умный Дом по Ethernet

Сообщение sysand » 28 май 2011, 11:16

Здоровска! Золотые руки!

Я бы еще ну хотя бы для 1-2-3 ножек сделал счетный вход, было бы полезно для всяких там импульсных телеметрических датчиков, причем можно сделать сразу еще настройку делителя , ну там 640 импульсов - 1 киловатт*час или 1 кубометр чего-нить, а так же установку начального значения этого счетчика. считать можно по фронту или спаду импульса или по тому и другому, в зависимости от датчика.

Andrey_B
Администратор
Сообщения: 5327
Зарегистрирован: 18 мар 2011, 12:06

Re: Умный Дом по Ethernet

Сообщение Andrey_B » 28 май 2011, 16:14

sysand писал(а): Я бы еще ну хотя бы для 1-2-3 ножек сделал счетный вход, было бы полезно для всяких там импульсных телеметрических датчиков
Мысль здравая и такое развитие напрашивалось. Я изучу эту тему.

THK
Модератор
Сообщения: 588
Зарегистрирован: 18 мар 2011, 19:00
Откуда: Серпухов, МО

Re: Умный Дом по Ethernet

Сообщение THK » 29 май 2011, 21:17

Посетила меня такая мысль:
Хорошо-бы, чтобы один из выходов можно было настроить как Watchdog.
Допустим, каждую минуту сервер дает устройству запрос

Код: Выделить всё

http://192.168.0.14/sec/?pt=7&cmd=WD
если в течении ~5 минут (тут можно сделать настройку времени) запроса нет, на выходе появляется 1.
Ну а дальше только фантазия... Можно автоматом включать ручное управление, можно запускать резервный сервер или перезагружать имеющийся, а можно не привязываться к конкретному выводу, а выполнять сценарий типа "1:2;3:0;4:0;6:1".

Andrey_B
Администратор
Сообщения: 5327
Зарегистрирован: 18 мар 2011, 12:06

Re: Умный Дом по Ethernet

Сообщение Andrey_B » 30 май 2011, 11:05

THK писал(а):Хорошо-бы, чтобы один из выходов можно было настроить как Watchdog.
Мысль интересная. Идея понятна, но я бы попросил привести несколько примеров использования этой штуки, чтобы четко понимать как это дело можно использовать.
Если со счетчиком все понятно, то тут, наверное, следует на пальцах порассуждать.

THK
Модератор
Сообщения: 588
Зарегистрирован: 18 мар 2011, 19:00
Откуда: Серпухов, МО

Re: Умный Дом по Ethernet

Сообщение THK » 30 май 2011, 17:16

Andrey_B писал(а):Мысль интересная. Идея понятна, но я бы попросил привести несколько примеров использования этой штуки, чтобы четко понимать как это дело можно использовать.
Если со счетчиком все понятно, то тут, наверное, следует на пальцах порассуждать.
Первый вариант, который навел меня на эту мысль, включение резервного сервера. Но тут вылезают проблемы с переключением 1-Wire сети.
Второй вариант, это включение ручного управления. Вы писали, что для запуска отопления необходимо переключить несколько тумблеров, а почему-бы не доверить это автомату?
Третий, наверное самый разумный, включение зумера. Типа, посмотри хозяин, что-то с сервером...
Вообще, мне, эта функция ненужна. Просто пришла мысль, решил поделиться. Авось кому пригодится...

PS Небольшой отчет о проделанной работе... :D
Устройство "прошил". В процессе его оживления вылезло несколько багов.
1. Накосячил с питанием. В качестве стабилизатора 3,3 В применил МС IRU1010-33, в даташите указано, что у нее максимальное входное напряжение 7 В. Недолго думая, развел на плате второй стабилизатор на 5 В.
В результате питаю плату от 12 В (мне надо от 12) 78L05 понижает напряжение до 5 В, от которых питаю IRU1010-33.
Косяк в том, что максимальный выходной ток 78L05 - 100 мА, а ENC28J60 хочет 180 мА (!) в итоге у 78L05 срабатывает защита! Перепаял на 7805, греется как печка, но работает. Надо думать на тему LM2576...
2. По прошивке (от 27.05.2011) прошивал Ваш бинарник. То, что бросилось в глаза.
2.1. Функцию АЦП можно назначить пинам, на которых ее нет.
2.2. Состояние входов почему то инверсное (сейчас в этом не вполне уверен, пишу по памяти из дома, мог запутаться из-за следующего косячка). ;)
2.3. Какой то касяк с управлением выходами (мой или прошивки)... В WEB-интерфейсе нажимаю ссылку ON - светодиод (который на плате) не горит, OFF - загорелся, ну думаю и здесь инверсия. Но не тут-то было! ON - светодиод остается гореть OFF - потух.
Выяснил, что устройство меняет состояние выхода при сочетании команд

Код: Выделить всё

_http://192.168.0.14/sec/?pt=1&cmd=1:1
_http://192.168.0.14/sec/?pt=1&cmd=1:0
или при подаче команды _http://192.168.0.14/sec/?pt=1&cmd=1:2 два раза подряд.

Больше позаниматься с девайсом сегодня не удалось, завтра надо попробовать ф-ю АЦП...

Ответить