Это только концепт, или устройство уже выпускается «в железе»? На сайте компании olf-action о нём ни слова, нормальных фотографий в сети нет, только тот 3D-рендер, что является иллюстрацией к данной статье.
Если их 1-2 на всю систему, и установлены они в радиусе 5 м от сервера, тогда экономия оправдана. А если тянуть далеко, то просто сравните цены на витую пару и качественный USB-кабель, и еще добавьте стоимость USB-хабов/усилителей через каждый десяток метров. Не говоря уже о том, что USB-камеру в уличном исполнении вы вряд ли найдете.
Если хочется совсем дешево — ставим аналоговые камеры и многоканальную плату видеозахвата.
Прятать, и желательно в сейф. Не столько будет жалко самого системника, сколько лежащих на нем видеозаписей, потенциально облегчающих расследование кражи. Как вариант можно сразу выкладывать видео на внешний сервер, но связь может неожиданно исчезнуть в самый неподходящий момент. Да и не добавляет комфорта мысль, что все происходящее в квартире куда-то транслируется.
Представляю заголовки новостей:
«В интернет утекли записи с камер внутреннего наблюдения 14000 пользователей»
«Хакер убил человека голодом, заблокировав холодильник»
«Ведется расследование по делу о „туалетных спамерах“»
Если серьезно, в системе обязательно должна быть Большая Красная Кнопка, разом превращающая «умный дом» в «глупый».
Да, гуглодвижок для распознавания голоса — это по меньшей мере странно. Но автор и сам признается, что так сделано «не от хорошей жизни», оффлайновые распознавалки якобы не устраивают по качеству. <telepatmode> A может, просто микрофоны плохие? </telepatmode>
Грамотно спроектированная система не должна терять основной функциональности, даже распадаясь на отдельные компоненты. То есть кофеварка должна быть способна варить кофе и без интернета, и без подключения к «центральному мозгу» умного дома.
Отключение электричества — уже более серьезная проблема, но тут все равны: и обычный утюг, и интеллектуальная система. У последней даже преимущество в виде возможности подключить ИБП (или дизель — для желающих) и назначить устройствам приоритеты в получении аварийного питания.
Система на беспроводных звонках — квадратноколесный велосипед. Стандартом в бытовых беспроводных интерфейсах считается ZigBee, но оборудование пока дорогое. X10, фактически, тоже дает свободу перемещения: в какую хочешь розетку воткни — будет работать.
То, что 1-wire позволяет тянуть длинные линии связи — миф. Да, в стандарте говорится «до 300 метров», но это скорее в лабораторных условиях, а на практике смело уменьшайте предельную длину вдвое, а то и вчетверо. Расскажу почему:
1) Устройства 1-wire питаются от той же линии, по которой передают данные. Тонкий длинный провод + много устройств на нем + закон Ома => питающее напряжение падает, устройства работают нестабильно. Для шины протяженностью больше десятка метров настоятельно рекомендуется отказаться от фантомного питания и вести +5 вольт отдельным проводом.
2) 1-wire — несимметричная линия, а значит, сильно подвержена помехам. С этой точки зрения гораздо лучше себя ведут RS-485 или CAN.
3) Единица отличается от нуля только длительностью импульса. Длинный кабель, ведущий себя как RC-фильтр, будет размазывать импульсы, нарушая работу сети. В какой-то степени проблему решает ведущее устройство с т.н. активной подтяжкой линии (то есть высокий уровень задается не резистором, а транзисторным ключом).
4) Сеть 1-wire большой длины чувствительна к топологии. Идеальный вариант — единая шина, на которой «сидят» все устройства, ведущее — на конце. Дерево, и, тем более, звезда работают хуже из-за переотражения сигнала. При большом числе устройств рекомендуется делить сеть на сегменты при помощи управляемых ветвителей.
Немного информации к размышлению — здесь.
Вполне корректен, не считая некоторой громоздкости кода, но для учебных целей это даже хорошо.
Сейчас еще такая идея в голову пришла: если выводим бегущую строку, и отображаемая область значительно меньше полной картинки, то эффективнее не сдвигать весь буфер экрана, а менять координаты «окна» вывода. Примерно так:
unsigned char screen_buffer [256];
unsigned int position, endpos, column;
// здесь забиваем в screen_buffer всю строку
for (position = 0; position < 256; position++) // сдвиг окна
{
endpos = position + 8; // определяем правую границу окна
// вывод столбцов,
// попавших в окно
for (column=position; column<endpos; column++)
{
delay (1);
if (column > 255) continue; // проверка границ
PORTB = (1 << column); // включили столбец
PORTC = screen_buffer [column]; // зажгли нужные пиксели столбца
}
delay (1000);
}
На будущее: вместо циклов с задержками правильнее использовать таймеры и прерывания.
Это для буквы A. Возможно значения придется инвертировать (смотря какие применяются ключи) или изменить порядок (смотря как скоммутированы выводы).
По-хорошему нужно один раз объявить набор констант с матрицами для всех символов, а потом просто копировать в screen_buffer / менять указатель. Бегущая строка организуется путем сдвига элементов в массиве screen_buffer:
Пусть матрица 8x8 и управляется 16 выводами (8 столбцов — PORTB, 8 строк — PORTC) через ключи, чтобы решить проблему мощности, но без всяких сдвиг. регистров.
Состояние экрана хранить в виде массива из восьми байт, причем каждый байт соответствует столбцу.
Вывод:
Если хочется совсем дешево — ставим аналоговые камеры и многоканальную плату видеозахвата.
«В интернет утекли записи с камер внутреннего наблюдения 14000 пользователей»
«Хакер убил человека голодом, заблокировав холодильник»
«Ведется расследование по делу о „туалетных спамерах“»
Если серьезно, в системе обязательно должна быть Большая Красная Кнопка, разом превращающая «умный дом» в «глупый».
<telepatmode> A может, просто микрофоны плохие? </telepatmode>
Отключение электричества — уже более серьезная проблема, но тут все равны: и обычный утюг, и интеллектуальная система. У последней даже преимущество в виде возможности подключить ИБП (или дизель — для желающих) и назначить устройствам приоритеты в получении аварийного питания.
Система на беспроводных звонках — квадратноколесный велосипед. Стандартом в бытовых беспроводных интерфейсах считается ZigBee, но оборудование пока дорогое. X10, фактически, тоже дает свободу перемещения: в какую хочешь розетку воткни — будет работать.
1) Устройства 1-wire питаются от той же линии, по которой передают данные. Тонкий длинный провод + много устройств на нем + закон Ома => питающее напряжение падает, устройства работают нестабильно. Для шины протяженностью больше десятка метров настоятельно рекомендуется отказаться от фантомного питания и вести +5 вольт отдельным проводом.
2) 1-wire — несимметричная линия, а значит, сильно подвержена помехам. С этой точки зрения гораздо лучше себя ведут RS-485 или CAN.
3) Единица отличается от нуля только длительностью импульса. Длинный кабель, ведущий себя как RC-фильтр, будет размазывать импульсы, нарушая работу сети. В какой-то степени проблему решает ведущее устройство с т.н. активной подтяжкой линии (то есть высокий уровень задается не резистором, а транзисторным ключом).
4) Сеть 1-wire большой длины чувствительна к топологии. Идеальный вариант — единая шина, на которой «сидят» все устройства, ведущее — на конце. Дерево, и, тем более, звезда работают хуже из-за переотражения сигнала. При большом числе устройств рекомендуется делить сеть на сегменты при помощи управляемых ветвителей.
Немного информации к размышлению — здесь.
>через ключи, чтобы решить проблему мощности
нужно написать:
Всё, спать пора!
Сейчас еще такая идея в голову пришла: если выводим бегущую строку, и отображаемая область значительно меньше полной картинки, то эффективнее не сдвигать весь буфер экрана, а менять координаты «окна» вывода. Примерно так:
На будущее: вместо циклов с задержками правильнее использовать таймеры и прерывания.
Это для буквы A. Возможно значения придется инвертировать (смотря какие применяются ключи) или изменить порядок (смотря как скоммутированы выводы).
По-хорошему нужно один раз объявить набор констант с матрицами для всех символов, а потом просто копировать в screen_buffer / менять указатель. Бегущая строка организуется путем сдвига элементов в массиве screen_buffer:
Состояние экрана хранить в виде массива из восьми байт, причем каждый байт соответствует столбцу.
Вывод: