Отображение данных "умного дома" на дисплее - что выбрать?

Цель: на "центральной консоли" (назовём это так) умного дома отображать данные.
Динных немного: дата/время, температура/давление/влажность, некие информационные сообщения.
Расположение - на стеллаже/стене в центральной комнате (всегда на виду).
Дисплей хотелось бы "интеллектуальный" - ночью притухает/выключается (датчик освещенности), включается от датчика движения и т.д. и т.п.
Ну и "приемлемый" внешний вид, раз он всегда на виду.

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

Потом был один из вариантов - матрица из RGB-светодиодов размером 16x64 с "бегущей строкой" и опять же мк. Поняв что и это неподходит - достаточно дорого (такая матрица это 1024 светодиода и ценник выше 100 у.е.) стал размышлять над другими вариантами.

Сейчас в голове их 2:
1. Дешевый (50-60 у.е.) китайский планшет на индроид (7"). Поскольку по квартире wifi и "центральный сервер" уже давно есть (с него можно передавать накопленные данные через wifi) решение почти готовое.
Как вариант №1 - открыть на планшете страницу с веб-сервером, на которой уже динамически отображать/менять информацию.
Как вариант №2 - написать свое приложение под индроид.
И то и другое достаточно просто.

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

Что смущает - качество устройства в целом и дисплея в частности (вживую не видел), не знаю как оно будет выглядеть с 3-5 метров (различимо или нет и т.п.).
Нужно чтобы было видно. ))
Также всякими выключениями и т.п. придется тоже как-то озаботиться, чтобы ночью не работал ненужным "светильником".

2. Дешевый микрокомпьютер, типа Raspberry PI (25 у.е.) + недорогой монитор.
На распберри ставится линух, там делается всё что хочешь, хоть 3d-графику крути.

Что смущает - raspberry pi все раскуплены по июнь включительно и неясно когда появятся в наличии.
Непонятно сколько потянет приемлемый по качеству/внешнему виду монитор.
С передачей отображением в линуксе проблем нет - хочешь своё приложение, хочешь - опять же через web-сервер.

Я это к чему - у меня иногда "глаз замыливается" и я упираюсь в простую проблему лбом. Поискав по форуму и не найдя достойных альтернатив решил спросить - вдруг у кого идея получше придёт в голову - как лучше такое дело организовать/отобразить?

В готовых "продаваемых" решениях предлагается использовать либо телевизор (у меня стоит и плазма и даже к ней подключен простейший htpc на intel atom, но не хотелось бы держать комп/телевизор постоянно включенным, чтобы увидеть время/температуру), либо там сразу идет дисплей. Но обычно дисплеи опять же достаточно мелкие (4-5"), а мне бы хотелось еще и часы и метеостанцию иметь, а это значит что эта информация должна быть легко различима с ~3 метров, что накладывает ограничения на минимальный размер такого дисплея...

Сообщение от sym Да как можно обидеть критикой софта. Это норвежские программисты могут обидется :)

Хех, если бы люди не отождествляли себя с софтом и прочими любимыми вещами, мир был бы скучен, без холиваров-то. :)

http://www.ebay.som/itm/3-5-TF... 3cc6f7f2c3 прикрутите такую радость.

0

Туда бы еще тачскрин прилепить. И генерировать PAL сигнал микроконтроллером лишняя морока, зато дешево ))

0

http://www.ebay.som/sch/i.html?_nkw=at043tn24 как вариант

0

Имхо все, что ТС расписал умещается в
- детальные данные с планшета или телефона с сервера
- критические оповещения делать делать в виде аудио информирования, натыкав в каждой комнате по динамику.

0

Сообщение от ssr Вы таки будете смеяться, но с совместимостью приложений тоже не всё так радужно, по крайней мере для Андроида.

Я смеяться не буду, т.к. участвую в этом празднике жизни. Кроме того, это высказывание приведено без понимания причин несовместимости.

Сообщение от ssr По поводу несовместимости HTML5/JS....

Несовместимость реализаций браузеров - это только одна сторона медали. Некоторые вещи просто не реализовать на HTML. Удобные вещи.

Сообщение от ssr Тут ещё выше было про преимущества нативного клиента перед браузерным, заключающиеся в доступе к железу. Если из JS что-то недоступно, то на крайний случай можно поднять локальное приложение на устройстве, которое JSON-ом будет отдавать данные в веб-клиент на том же устройстве. Единственный оправданный сценарий здесь, что я вижу - использование API для распознавания лиц/голоса на планшете/телефоне, не факт, что для веб-приложений они недоступны, не смотрел. Update: вот есть ещё такие вещи, как PhoneGap, посмотрите на список фич: http://ru.wikipedia.org/wiki/PhoneGap, где-то встречал упоминание про Bluetooth плагин к нему, очевидно, платформозависимый.

Даже не урезаю, но это исключительно теоретические умозаключения без понимания работы платформы. Что Andoid, что iOS. Без обид. Написать можно на разных языках программирования, с использованием разных библиотек, в том числе совместно. Тем не менее полностью и ВСЁ написать так всё равно не выйдет. В определённых аспектах всё равно встанет вопрос работы на другом уровне, нежели с UI. Приложение только для просмотра данных с сервера - аж бегом. Но сделать по-настоящему полезное приложение, да ещё и энергоэффективное, так не выйдет.

Сообщение от ssr Плюс веб-приложения - отделение интерфейса от бизнес-логики, вы можете сделать версию странички для простого древнего телефона с WAP браузером, с грамотно урезанным функционалом, а также красивую, со свистелками и перделками под iPad, Android и PC. Выбираться оно будет автоматически на основании юзерагента, заявляемого браузером.

Т.е. "показометр". Имхо пользы немного. Мне было бы полезнее, чтобы даже при заблокированном экране выдавались предупреждения. Это уже немного другой уровень. Как минимум push-извещений, которые могут и не прийти.

Сообщение от ssr Веб-сервер, кстати, может крутиться как на домашнем компьютере, так и на NAS, роутере, да хоть на самом планшете.

Ага. Только главное - обеспечить безопасность доступа. В идеале - ещё и без уязвимостей.

Всё это красивые слова. Только задуматься надо для начала немного над другим: какой будет планируемый срок службы системы. И что за это время может поменяться. Соответственно из этого решить, какие технологии и решения использовать. Так, за ближайшие десять-двадцать лет вряд ли изменится TCP/IP. Тот же IPv6 - появился уже очень давно. И изменений вроде не планируется. Точно так же вряд ли поменяется USORT.
А ещё мне, например, лень было бы раз, пусть даже, в 10 лет переписывать кучу всего. А это придётся делать, если размещать всю логику на веб-сервере или на конечном устройстве. В то же время надо обеспечить простой удалённый доступ к информации и управлению.

0

Сообщение от Vid_kh Т.е. "показометр". Имхо пользы немного. Мне было бы полезнее...

Гляньте на название темы.

Сообщение от Vid_kh ...чтобы даже при заблокированном экране выдавались предупреждения. Это уже немного другой уровень. Как минимум push-извещений, которые могут и не прийти.

Сообщение от Vid_kh Но сделать по-настоящему полезное приложение, да ещё и энергоэффективное, так не выйдет.

Коллега, это устройство будет висеть на стене воткнутым в розетку и показывать разное 24/7, какая блокировка экрана? IMHO, тут достаточно браузера на полный экран и всё. Пуши пусть приходят на телефон, где на счету каждый миллиампер, а здесь, опять же IMHO, достаточно пулить домашний сервер раз в какое-то время для обновления информации. Попробуйте посмотреть на проблему не только с позиции разработчика под носимые устройства (понимаю, что наболело). У нас тут немного другой юзкейс - устройство получается, фактически, стационарное.

Если я, допустим, захочу парсить webcal с такслистом, выдаваемый Remember the Milk, на предмет фильтрации домашних задач, которые я хотел бы видеть на этом устройстве, при Вашем подходе мне придётся писать парсинг для каждого устройства (Java, Objective-C, C#, что там ещё), а потом этот зоопарк поддерживать вместо того, чтобы возложить это на серверную часть. То же с почтой, погодой, картой пятен на солнце и т.п. Ну или писать ещё серверную прослойку в дополнение к нативному клиенту.

Сообщение от Vid_kh Кроме того, это высказывание приведено без понимания причин несовместимости.

Сообщение от Vid_kh ...это исключительно теоретические умозаключения без понимания работы платформы

Эка Вы меня припечатали... :) Меряться пиписьками в плане понимания принципов работы платформ и нюансов совместимости Андроида не буду - без обид, ;) тем более, что разработчиком давно не являюсь, так, сочувствующий. Я ведь не спорю, что нативные приложения имеют преимущества практически во всём, кроме переносимости на другие платформы. И недавний пример Фейсбука, отказавшегося от большей части HTML5 функционала в своём мобильном клиенте это подтверждает. Просто хотел донести мысль, что если речь идёт о распространении больше чем на одну платформу, имеет смысл крепко задуматься, что важнее - фичи или трудозатраты.

Да, мобильные устройства пока не созрели для SaaS, наверное, во многом из-за пресловутой фрагментированности, но через годик-полтора подтянутся, никуда не денутся. Мы не говорим здесь про iOS с его анальным огораживанием разработчика/пользователя от всего, чего только можно. Но создатели мобильных браузеров/движков будут вынуждены стандартизировать/расширять функционал по доступу к мобильному железу, местоположение, вон, уже практически все умеют определять.

Vid_kh писал(а):

Ага. Только главное - обеспечить безопасность доступа. В идеале - ещё и без уязвимостей.

По поводу безопасности не совсем понял - если планируется светить фейсом наружу - то не всё ли равно, что ломать? Если не планируется - закрыть доступ извне на домашнем роутере или настроить VPN - и дело с концом.

Vid_kh писал(а):

мне, например, лень было бы раз, пусть даже, в 10 лет переписывать кучу всего. А это придётся делать, если размещать всю логику на веб-сервере или на конечном устройстве

Ну это уж совсем не аргумент - можно подумать, нативное приложение для мобильной платформы будет запускаться на новом железе спустя десять лет. По десять лет без переписывания работают, например, приложения в банковской сфере, вон, дос/полуось там обычное дело. В SOHO сегменте всё десять раз поменяется. Однако есть надежда, что валидный HTML и горстка JS, отдаваемые стареньким, надсадно жужжащим домашним сервером будет более-менее адекватно отображаться в браузерах мобильных устройств и через десять лет тоже. ;) Особенно если JS переносимый, через jQuery Mobile или аналоги.

Сообщение от ssr ...

Не хочу выделять по пунктам, лень, некогда, да и банально невыспался.
Что, впрочем, и хорошо в какой-то мере.
Мне вообще этот, да и не только, топик напоминает ощупывание слона четырьмя слепцами.
Поэтому наверное лучше так и сделать, расписать, кто что нащупал и что из нащупанного понравилось :D

В общем, моё решение:
- в каждой комнате стоит общий модуль, к которому витой парой подключена куча датчиков и исполнительных устройств. Силовая часть проходит через него же для аварийного отключения. К этому модулю также подключён RF-модуль 2.4ГГц, который связывается с центральным модулем. Таким образом получаем разумную автономность с централизованным управлением, а также экономию на длинных линиях связи. RF-трансивер стоит дешевле, чем 4 метра витой пары.
- в произвольном месте стоит центральный модуль, который управляет всеми прочими модулями, ведёт протоколирование событий и пр. Также имеет RF-трансивер, USORT, к которому подключается Bluetooth-модуль для связи с планшетом, который играет роль панели управления. Также имеет выход в инет для удалённого управления, т.к. в моём случае это необходимо. Формат передачи данных - JSON.
- планшет для управления в доме.
- приложение на телефоне для удалённого доступа.

Вся система спроектирована так, чтобы интерфейс к ней и удалённое управление можно было переписать/изменить в течение недели. В текущий момент система ещё до конца не доведена. Банально нет времени. Часть работает, часть в процессе. Большинство модулей (кроме источников питания и покупных частей) стараюсь сделать максимально долговечными.

0