Прошу консультации по связке Arduino + GPRS
- Войдите на сайт для отправки комментариев
Втр, 26/08/2014 - 17:22
Всем добрый день.
Не ищу испольнителя или халявы, нужна именно консультация по возможности\не возможности реализации следующей задачи:
Есть 3 сухих контакта
есть 3 светодиода
Arduino + GPRS шилд
+ все что понадобиться
Задача:
При нажатии любого СК зажигать соответствующий диод и отправлять на сервер (используя GPRS) данные о нажатой кнопке и если возможно времени, когда это произошло.
Что потом с этими данными будет делать сервер - не важно. Это уже другая головная боль.
Спасибо
Контакты заменить на мокрые и все будет работать.
возможно)
jeka_tm
Возьметесь за такое проект? само собой не безвоздмезно.
я не. я такое не потяну, да и свой проект надо доделать
Тут всё элементарно, можно было бы сделать, только я в Украние.
Тут всё элементарно, можно было бы сделать, только я в Украние.
Ты нам весь бизнес ломаешь. Тут все очень сложно! Минимум 3 месяца работы.
3 месяца мочить контакт? )
а если серьезно, то как нефиг может в такой срок и выльется. если какой нибудь оператор с глючным инетом, то статистику надо будет хранить локально, потом передавать с синронизацией... можно и на год проблем придумать.
Контакты мочить это не терористов в сортире. Тут нужно правильный рассол, температура, угол падения лунного света... :) очень серьезный процесс.
Не ищу испольнителя или халявы, нужна именно консультация по возможности\не возможности реализации следующей задачи:
Да - возможно.
а если серьезно, то как нефиг может в такой срок и выльется. если какой нибудь оператор с глючным инетом, то статистику надо будет хранить локально, потом передавать с синронизацией... можно и на год проблем придумать.
Согласен. C чем-то подобным сейчас и вожусь и сроки, вот примерно такие и выходят. На первый вгляд "все тупо до горя", а в реальности...
"Основная логика" - это даже не 3% работы.
То у самой дуины оказывается сгоревший/выгоревший пин, то выясняется что на самом модуле не хватает кондеров (проблемы с питанием, помехи на карту и т.п.), то сам модуль теряет сим карту, в зависимости от того на какой частоте базовую станцию нашел (и попробуй еще найти-догадаться о взаимосвязи между частотой и потерей сим-карты...), то одни карты видит, другие не видит, то оператор обрывает gprs сессию, то grps модуль может не с первого раза реагировать на powe_on пин, то он могут помехи вылезать на state пине, то проблемы с кард-холдером и микросимками (даже с адаптером). А это все "дни/недели", и только для того что-бы "запустится"....
И ничего этого нет, в статейках "как запустить gprs шилд". Там типа "ой как все просто, парочка AT комманд, и у нас отправилась sms, или http запрос". Круто... а как только реальность. И нужно отправить запрос к реальному REST сервису, то... ой. А поддерживаются только GET/POST запросы. Все PUT/UPDATE/DELETE/OPTIONS и т.п. феншуй - идут лесом (ну или работай на уровне TCP и забуть что у модуля заявленна поддержка Http/https , хотя ты на это расчитывал когда эстимейты давал). Сервис поддерживает "basic authentication"? Забудь. Модуль не позволяет работать с заголовками запросов (ну или сам, бери TCP и реализуй http стек). Кстати, по этой же причине, передать серверу желаемый "accept-encoding" - тоже не выйдет. И посмотреть заголовки ответа - опять облом. Только http статус, и body ответа.
SMS-ски. Операторы есть разные... и энкодинги SMS-сок.... в примерах-то везде "ну вот просто ascii", а в реальности там такой заопарк кодировок. И никто не обещает что оператор придерживается стандартов. И если ты ему сказал, что "я хочу sms получать в виде простого текста", то он тебя послушается.... и не прийдется разгадывать шифрограмы..
Потом... вот кроме основной логики, то что в стартовом посте осталось "за кадром": всякие аудинтефикации, авторизации. Привязки к аккаунтам, пересбросы паролей, первоначальная настройка apn и проч. мдени. Скорее всего еще и за балансом карты поглядывать нужно, и предусмотреть вероятность что обезяна до кнопки дорвется и начнет долбить ее выюзывая баланс карточки (ну или кнопка, физически поломается). А что делать если сервер не отвечает? А как сообщить пользователю что сигнал плохой или вообще в подвале не видно вышек и не наша железка виновата?
А потом "то что пользователю не видно". Всякие механизмы логгирования. На этапе разработки, нужны же инструменты для нормально отслеживания "что происходит?" (потом и службе поддержки они пригодятся). Туда же и всякие "эмуляторы" (опять-таки, при разработке нам же нужно как-то имитировать все эти "обрывы, отказы" и т.п.), тесты и т.п.
А потом выяснится что все это должно питаться от акума и нужно экономить энергию. А, сдругой стороны, хитропопый оператор все GPRS сессии округляет до 200kb, и часто их обрывать/засыпать - дополнительные расходы....(не говоря уже про то, что каждая регистрация в сети - тоже удар по акуму). Сплошные компромисы и балансирование на грани...
Ну это я уже не говорю, про то сколько времени уходит на выяснение деталей ТЗ, общение и т.п.
Так что.. мочить три месяца контакт - не такая уж и фантастика.
Вот так, в потоке грустных мыслей, уважаемый leshak продемонстрировал разницу между "хотелкой" и ТЗ :D
Вот так, в потоке грустных мыслей, уважаемый leshak продемонстрировал разницу между "хотелкой" и ТЗ :D
Почему грустных? :)
Как говорил Арамис: " Это довольно трудно, но главное достоинство всякой вещи состоит именно в ее трудности."
Тем больше фана, когда "оно блин, все-таки заработало".
Ну и, было-бы это просто, то... что-бы мы, программеры кушали? Если бы каждый мог просто взять парочку готовых библиотек, слепил... и любая, как вы выразились, хотелка - заработала.
Работа программера, это и есть, на 95% борьба со сложностью. Попытки управлять хаосом.
То есть - это и есть суть професии. Почему же грустить при столкновении с этим?
ТЗ - это конечно "хорошо". Только:
1. А стоимость разработки ТЗ? А если учесть, что оно, в реальности устаревает чуть быстрее чем пишется код?
2. ТЗ - это конечно идеал. Все мечтают о нем (и конечно стремится к нему - нужно), но желание полного/детального и проч. ТЗ, опасно близко к водопадной модели разработки. Которая, как показала практика, работает чуть хуже чем хреново. По крайней мере если вы не транснациональная корпорация и у вас нет немерянных бюджетов. Или вы не занимаетесь чем-то вроде написания софта для запуска шатлов и во главе угла у вас не стоит "надежность", а все остальные факторы расплаты - плевать.
Дык ниодног-ж смайлика нету! :)
1 - стоимость разработки ТЗ - не проблема разработчика
2 - 99,9% в проектах без ТЗ имеем хотелку как у ТС (это просто пример! к ТС никаких вопросов, это не "ищу исполнителя"), а имеем то что Вы написали в своем посте, но по цене хотелки.
На вопрос "сколько стоит сделать сайт?" я привык отвечать вопросом "сколько стоит автомобиль?". При заказе софта/сайта я предупреждаю что интепретирую задачи из деловой переписки(! именно так, никаких телефонных переговоров по делу) так как Я их понимаю. Все дополнительное будет расчитываться/оплачиваться отдельно, причем в некоторых случаях "допил фичи" может выходить в сумму эквивалентную стоимости всего проекта, речь конечно не идет о "а можно шрифт поменть?". И еще раз предлагаю составить грамотное ТЗ, при желании с моей помощью (естественно оплачивается отдельно, самое дорогое ТЗ вышло 25% от стоимости проекта). Те кто обращаются впервые этому не верят и получают "хорошие" счета. Со второй попытки дело уже идет лучше :)
Дык ниодног-ж смайлика нету! :)
1 - стоимость разработки ТЗ - не проблема разработчика
Ну это - филосовский вопрос. Очень часто "разработчик" и "менеджер" - одно лицо. Да даже, когда разные, IMHO подход "я тупо кодю и меня ничего не волнует" - довольно стремный. Ты тогда "кодер", а не разработчик. IMHO нормальный работник всегда должен в уме держать то, что, в конечном итоге он пишет не ради кода, а ради того что-бы "клиент был счастлив". Получится ли это - другой вопрос, но держать на подсознании это - нужно.
Ну и, не забывать, что в конечном итоге получать зарплату возможно только в одном случае: если результаты твоего труда ВЫГОДНО использовать. Если нет, то... у клиента рано или поздно закончатся деньги :) И следующего заказа - не будет.
Можно конечно спрятаться за "не мое это дело", но ... как-то это очень "совково". Мне кажется, тут просто играет роль что больше тебя интересует "краткосрочные цели" или долгосрочные. Что тебе важней, твоя зарплата за этот месяц, или твой доход в ближайшие 3-5 лет.
2 - 99,9% в проектах без ТЗ имеем хотелку как у ТС (это просто пример! к ТС никаких вопросов, это не "ищу исполнителя"), а имеем то что Вы написали в своем посте, но по цене хотелки.
Сами же говорите "99.9%". Значит "такова реальность", и как-то с этим жить нужно.
случаях "допил фичи" может выходить в сумму эквивалентную стоимости всего проекта, речь конечно не идет о "а можно шрифт поменть?".
А почему "не идет"? А если вдруг захотели шрифт, который есть только в виде .js файлов (да... и такое бывает, уже имеющихся .ttf, .eof, .woff, .svg и .swf, каждому из которых тоже нужно было настроить mime-type верный на сервере - не хватило). И нужно еще прикрутить движок его рендеринга... да еще грузить его динамически с другого домена (привет CORS и проч. мозголомки). Кстати это не "абстрактная придумка", а буквально "опыт этой недели" :) Когда захотелось диких трасформаций и эффектов. Причем векторно. Каждый элемент буквы харапуцать как пожелается. Да еще что-бы это все на разных браузерах (в том числе и мобильных...). А потом это все экспортнуть в виде .svg. А что-бы мало не показалось то и поддержка pdf экспорта не должна поломаться :) И фишка "печати" нормально работала. И старые данные, которые пользователи сохраняли до введения фичи .js шрифтов тоже нормально рендерились. А еще нужно, что-бы остальные 15-ть проектов, которые используют тот же движок и которым эта приблуда "нафиг упала" (по крайней мере "пока"), не потребовали переделок и не рухнули после твоих коммитов (делать отдельных форк движка - тоже не вариант). Да админку допилить, что-бы для шрифтов можно было задавать "что можно что нельзя" (например какие символы в нем отсутсвуют).
Говорите "да тут же просто другой шрифт поменять? вот как на том сайтике? Да?". Хе-хе... ;)
Кодер вс разработчик
Был у меня когда-то авто -митцубиси Sapporo а в магазин завезли "широкие лапти" вроде 205. Я говорю мастеру - ставь. Он мне нельзя, по аркам не подходит, цеплять будут. А я хотел. В результате он поставил, я получил звуковую сигнализаци работы амортизаторов и через месяц эксплуатации новую подходящую резину. Должен ли был мастер отказаться продавать и ставить резину?
У меня нет заказчиков со стороны, и всегда и долго пытаюсь переубедить и выбрать "правильный" путь. Но если клиент очень уж настаивает, то он соглашается на моих условиях или уходит искать другого испонителя. Поэтому кто остается, и даже если без ТЗ и с бОльшим бюджетом - заказывают еще.
Я не случайно взял фразу про "шрифт" в кавычки ;)
Кодер вс разработчик
Был у меня когда-то авто -митцубиси Sapporo а в магазин завезли "широкие лапти" вроде 205. Я говорю мастеру - ставь. Он мне нельзя, по аркам не подходит, цеплять будут. А я хотел. В результате он поставил, я получил звуковую сигнализаци работы амортизаторов и через месяц эксплуатации новую подходящую резину. Должен ли был мастер отказаться продавать и ставить резину?
Я бы - продал :) Как мастер, свой совет-консультацию - он дал. А вот решение - принимает не он. Свою задачу "честного спеца" - он выполнил. Предоставил максимально объективную инфу для принятия решения. Вот если бы это был "начальник гаража". Который отвечает за ваш автопарк, то тут, конечно уже "либо вы принимаете мои советы, либо я не несу отвественности. Но.. тогда какой я "начальник", нафиг?" :)
У меня нет заказчиков со стороны, и всегда и долго пытаюсь переубедить и выбрать "правильный" путь. Но если клиент очень уж настаивает, то он соглашается на моих условиях или уходит искать другого испонителя. Поэтому кто остается, и даже если без ТЗ и с бОльшим бюджетом - заказывают еще.
Ну вот видите.... вы научились сосущестовать с этой объективной реальностью :)