syoma

Сорри, но пока вы здесь обсуждаете дизайн пиктограмм моего устройства, другие спокойно продают свои устройства на ESP32 и плевать они хотели на эти ваши эстетики и прочую мишуру. Если что, UХ дизайнер у меня есть и он готов работать, но я не собираюсь его подключать, пока у меня не будет хоть какой-то рабочей железяки на руках.

Не только требованиями, но и рисками. Если требование было сложным, дорогим в исполнении или вы не были уверены в том, что исполнитель его правильно понял и имеет нужную компетенцию, вы обязаны были сделать derisking - то есть уменьшить свои риски удорожания или срыва проекта из-за невыполнения этого требования. И я уверен, что все эти «рисковые» требования вы вычислили изначально, но не захотели ими заниматься, а скинули все на неграмотного (или алчного) исполнителя. А риски уменьшаются теми способами, что я указал выше - результаты НИ, разработка демонстраторов, проработка архтектуры, концепции с последующей защитой и т.д.

Выше обновил мой подход. Я тестировал настенные выключатели Sonoff Touch в реальных местах установки в течении пары лет. Задержки мониторились по тому, как быстро загорался свет (в том числе в критичном к этому явлению туалете :-) ) после нажатия выключателя. По результатам тестирования образовался этот проект.

У меня есть на примете конкретные устройства на ESP, которые я тестировал и которые работают и уживаются в моей сетке. Зависаний, отказов, разрывов связи и прочих пауз при их использовании я не наблюдал, поэтому думаю, что все возможно. Ну а вообще насчет «годится решение или выкрасить и выбросить» по аналогии с темой про сложные системы и невыполнение ТЗ я поэтому и организую почасовую оплату - сначала соберем прототип из существующих железяк и проверим в том числе и качество связи. Если будут проблемы, будем смотреть есть ли выход. Если нет - пойдем по другому пути дальше.

Тоже это не понимаю. Если были четкие требования и исполнитель все их выполнил, получив свои деньги, то в том, что в итоге получился хлам, виновен тот, кто заказывал, а не исполнитель. Т.е. грубо говоря, вы просили сделать вам автомобиль с квадратными колесами. Это абсолютно понятное требование и даже я под него подпишусь и реализую. Но если такой автомобиль не едет - это ваша проблема.

Это хорошие вопросы, но я не могу обновлять начальное сообщение. На данном этапе - (это прототип) чем проще, тем лучше. Как варианты: - Через встроенный веб-сервер - заливаем файл, он прошивается - это то, что я видел. - Или заливаем прошивку на SD карту - при включении он прошивается - Вариант поиска прошивок на опеределнном сервере - возможно на будущее. Пока к локальному без защит. Wi-fi защита стандартная. Если MQTT библиотека будет поддерживать что-то более навороченное, проверим. Варианты: - при включении питания, если удерживать нажатым на Тач-скрин, устройство входит в режим настройки. Там можно будет ввести параметры Wi-Fi, MQTT брокера и т.д. - После этого веб-сервер или FTP для доступа к SD карте. - Или файл конфигурации на SD карте. Редактируем, включаем. Нет, но в будущем может быть. Нет Нет. По идее все конфигурационные параметры должны быть на ней. Пользователь наверняка захочет хранить их копии где-то у себя в SVN чтобы синхронизировать изменения или переносить их на другие устройства.

Ну это смотря как на это посмотреть. Большинство народу здесь никогда научными исследованиями не занимались и для них это отсутствие результата. Хотя иногда даже одна формула и есть этот результат, как и доказательство возможности или невозможности построения системы на том или ином принципе. Например, мы потратили примерно 6 месяцев и 1 человеко-год на доказательство того, что мы можем использовать PCIe для обмена данными в реальном времени между платами с периодом 5мкс и нужным джиттером. Результатом стали всего лишь пара еволюционных ПЛИС плат на столе, подключенных к осциллографу, да десяток страниц отчета в Ворде. Для кого-то это давно известная истина, но для нас, которые о PCIe знали только по книжками - нет. И все это легло в основу будущей системы управления. А не получилось бы тогда - неважно или изза ограничений, или из-за нашей компетенции - система могла бы выглядеть совсем по другому. Так что ответственность и результат есть и у НИ. Модели сегодня - это тоже частый результат НИ. А требования надо чем-то обосновывать, иначе это не требования. А для обоснования тоже часто нужны НИ.

Еще один пример, что хочу получить в плане финального результата: Но тут ESP8266 и Nextion дисплей - можно упростить.

Вы поняли, что я написал про этапы НИОКР? Невозможно точно оценить сроки и стоимость для "через год нормально работающая система уже была на "объекте"", если вы еще не прошли этап НИ. Никак. Любая нормальная фирма, посмотрев на ваше ТЗ, сразу бы сказала - "Через год и за 500k$ обещаю вам эскизный проект и демонстратор по этим и этим пунктам. И если все получится и заработает, поговорим о продолжении проекта - ОКР и прототипах." Вот так надо. И это не исполнитель делит проект, а вы должны делить вместе с исполнителем. И желаете вы "систему под ключ" или не желаете, вы должны либо принять данный подход, либо выкидывать по 1-2млн$ каждый раз за неработающее барахло. Потому что они не следуют принципам R&D проект-менеджмента. Но вы не волнуйтесь, судя по метаниям "Роскосмоса" и его дочек, эти принципы отсутствуют уже везде. ПС подумал - а может и были такие фирмы, что предлагали вам сперва пройти этап НИ? Только вы их сами отвергли, не понимая зачем платить деньги за отчеты на бумаге и в итоге выбирая тех, что готовы "под ключ"? Признавайтесь.

Мне так удобней в плане оплаты и договоров. Обычно исполнитель оформляется как ФЛП и платит фиксированный или 5% налог - а я ему спокойно перечисляю с украинского на украинский счет. Т.е. получается все по белому. А как работать из Украины с заграницей по белому мне неведомо. Переводить деньги можно разве что paypalом.

Вы можете сделать работу за 2 часа, а сами записать 6 и я не буду ничего иметь против, если работа сделана.

@DeadCadDance - прочитав это ваше сообщение, я, кажется понял, в чем ваша (и возможно ваших исполнителей) проблема. Дело, скорей всего, в том, что у вас отсутствует культура R&D проект-менеджмента сложных проектов. Т.е. нельзя вот так взять и с нуля разработать сложную систему, если есть риски, если есть сложные проблемы, если есть непонятки с технологиями. Для этого разработка делится на этапы НИОКР. Вы о них забыли? Т.е. сначала делаются и оплачиваются прикладные исследования в нужном направлении, делаются демонстраторы, проверяются технологии. Определяются основные технологические и конструкторские риски в системе, и они прорабатываются. Затем создается ТЗ на ОКР. Все суммарно - примерно 2-3 этапа. На этапе ОКР создается архитектура (один этап), детальная разработка (второй этап), валидация и верификация (третий этап), индустриализация (четвертый этап). И только потом изготавливаются шкафы. Каждый этап должен заказываться и оплачиваться отдельно и переход к следующему этапу должен осуществляться только после завершения предыдущего. При этом в конце каждого этапа делается Gate Review на котором помимо обсуждения готовности этапа и всего прочего определяются и корректируются примерные стоимости последующих этапов - настолько, насколько можно. Чтобы менеджмент или заказчик мог принять решение - продолжать работы или прекратить их. Так вы рискуете и меньшими деньгами и сроками и держите все под контролем. Т.е по итогу вы вместо одного большого тендера с бюджетом на 2млн$ сначала проводите первый этап, который может стоить всего 20тыс$, потом второй на 100тыс$, третий и т.д и из этого всего и формируется весь бюджет проекта. Как правило, каждый следующий этап дороже предыдущего, но в этом и есть смысл - ведь риски с каждым этапом тоже уменьшаются. А вот про эти все «под ключ» в R&D можно забыть. Можно дом построить под ключ. Можно ремонт сделать под ключ. Можно спроектировать противопожарную систему под ключ - т.е создать системы и обьекты, которые повторены уже сотни раз, под которые есть стандарты И нормативы, полностью известны этапы и сроки. Но не в случае большой и сложной системы, которая создается в первый раз.

Если он влезет в подрозетник, то пожалуйста. Но мне кажется,что в таком типоразмере ESP32 будет лучше.

Кстати, как вариант - поставить RPi, на нем NodeRED, подконнектиться к CloudMQTT. Там есть дашборды, логи и визуализация тоже.

Ну так создайте! Записей нет, потому что нет тем для обсуждения.