У нас (страховая компания) до сих пор большая часть кода на COBOL, хотя все новое пишется преимущественно на Java. Несмотря на поставленную цель отказаться от старых программ, поддерживать нам их придётся ещё немало лет.
А ещё у нас до недавнего времени был математический модуль на APL...
Речь шла не о отдельном мк, а о целой системе умного дома. Nodered совершенно не предназначено решать задачи в пределах одного устройства - это инструмент интеграции устройств в "умную" систему - и здесь mqtt и Nodered отлично справляются.
Ещё раз - низкоуровневые вещи естественно нужны, но не на уровне интеграции, а на уровне устройства - наружу должен быть виден сервис (открыть ворота, считать температуру), а не "считай пятый бит порта X".
HA очень неудобен при написании сценариев. Написанные сценарии очень не наглядны. А хорошо сделанные графики Nodered вполне можно (в общих чертах) объяснить даже ребёнку.
С помощью mqtt можно очень просто объединить несколько различных сервисов - у меня например есть инстанция fhem (где мне проще подключить некоторое оборудование), HA и Nodered - все прекрасно общается между собой одинаковым образом через mqtt. Это чрезвычайно удобно. И много проще заменяемо - не только в границах esphome.
Шлагбаум это не умный дом, это более менее одно изолированное устройство, тут вполне оправдано поднять сервер на esp. А если у вас система доступа с десятком-другим точек? На каждой независимый сервер поднимать? Или лучше сделать центральный сервис с проверкой прав доступа, логированием, контролем нештатных ситуаций?
Mqtt для этого не предназначено, тут совсем другой уровень абстракции. MQTT это командный интерфейс, имплементация комманд, естественно, пишится на том же С в самих устройствах.
Тоже самое с Nodered - я не вижу никакого смысла читать здесь ADC. Тут должно передаваться конкретное значение, температура, давление, неважно что, а как это реализуется, находится на более низком уровне, в в устройстве. Это гарантирует взаимозаменяемость - я могу заменить тот же датчик температуры на совершенно другой без изменений на уровне mqtt и Nodered. Nodered задаёт логику умного дома и не заботится о low level реализации. В этом весь смысл.
Кстати, в чем проблема с управлением со смартфона? Вполне есть клиенты mqtt. А если уж поднимать на esp вебсервер, то это уже не серверлес. Проще поднять центральный сервер, который раздаёт команды на отдельные устройства через MQTT.
Разговаривать с каждым esp отдельно IMHO чаще всего плохая идея. А если вы через пару лет заменить захотите систему (поддержки больше нет, вышли из строя и замена недоступна, появились более лучшие варианты,..) ? Я пару лет назад выбросил все самоделки на основе MySensors и заменил их готовыми устройствами zeegbe и shelly и немного самодельный на esphome. В Nodered логике изменений не потребовалось вообще, только топики mqtt и формат (на json перешёл).
MQTT более универсален. Я пользуюсь Homeassistant только в качестве вебморды, а писать сценарии мне намного больше нравится на Nodered. MQTT это клей, что все это связывает.
Такой преобразователь и так стоит в каждом телефоне (ну естественно не трансформатор, там импульсные преобразователи). Стандартная батарея всегда получает свои четыре с копейками вольт по определённому профилю заряда (вообще-то заряд идёт током, а не напряжением, но в данном случае не будем усложнять).
Еще бы начать с корня всей проблемы - ошибки в "адресе" получателя. В ЕС это вполне неплохо реализовано - переводы по всему ЕС осуществляются через IBAN - это такой номер с двумя проверочными цифрами. Ошибиться в наборе практически невозможно - система неверный номер просто не примет.
То, что все изменения протоколлируются - это понятно, но это мало поможет, если сделать грамотно.
Такие вещи естественно делаются в рамках поставленных задач - новая feature, bugfix... В идеале размазываются на несколько коммитов и выглядят как неявный побочный эффект. Ошибка, каких много, бывает... К тому же мы говорим не о программе игры в крестики-нолики - закладка делается так, что между внесением и первым проявлением проходят месяцы. За это время в больших и важных системах накапливаются тысячи коммитов. Определить "день X" будет очень сложно. И доказать намеренную диверсию практически невозможно. Разработчику высокого уровня такое вредительство вполне по плечу.
Ну например итальянская забастовка - все очень правильно и по уставу, что не подкапаешся, но очень-очень не эффективно.
Закладки в коде, как вы описываете - слишком грубо. Это делается намного более субтильно. Например ухудшение перформанса, немного, чтобы все работало каждый день, но какой нибудь месячный batch job (в тех же банках их много) переодически вылезал за рамки и создавал проблемы. Или намеренное неправильное округление результата, но для редких случаев. Не сойдётся годовой баланс на пару рублей - искать будет весь отдел пару недель - ну ошибся, ну бывает. Ну и много других вариантов.Я давно работаю в этой сфере, вполне смогу сделать так, что и тесты все пройдёт и ни одно ревью не найдёт.
Про язык тоже хотел написать. Работаю тут уде 20 лет (финансовая сфера). Банки, страховые - абсолютно все только на немецком. Не то чтобы английский не знают - но язык документации и вся переписка - немецкий.
Solidaritätszuschlag (помощь восточным землям) с января прошлого года уже не актуален для 90%. До 73000 годового дохода (151000 для семьи) этот налог больше не взимается.
— На счет орать — не знаю, мои меня в общем-то и так нормально понимают, разве что очень шумно в комнате.
— Поиск пока что не фонтан, да. Но заметно время от времени, что амазон над ней работает. Так что наверное будет лучше, смотря, что искать. Для сложных тем она и не задумывалась, для ответа на вопросы вроде кто? где? когда? — вполне.
— Музыка слушается подключением алексы к нормальному усилителю через Bluetooth или проводом. Будет Вам отличное качество. Для кухни большой алексы и так достаточно.
Когда идешь в темноте и руки заняты, такой голосовой выключатель очень даже кстати (ну или когда лень с дивана вставать :)
Еще удобно:
— будильник
— время спросить (ночью, когда темно)
— таймер (на кухне, чай заварить)
— погода
— календарь
Может оно так и было в начале, не знаю. Сейчас проблем с пониманием очень мало. У меня стоят несколько штук «Echo Dot», управляю светом и электроставнями без проблем. Хотя основное применение пожалуй проигрывание музыки. Лучшего плейера я пока не встречал. Ну и еще новости и прогноз погоды.
Пользуюсь DirtyPCBs / DangerousPrototypes. Из нескольких сотен изготовленных плат была только одна с ошибкой. При том они часто доставляют пару-тройку больше чем заказано.
Действительно финиш.
Вы не знаете разницы между ESP (WLAN) и nRF24L01 (создает легковесную радиосеть). Совершенно разния свойства и области применения.
У нас (страховая компания) до сих пор большая часть кода на COBOL, хотя все новое пишется преимущественно на Java. Несмотря на поставленную цель отказаться от старых программ, поддерживать нам их придётся ещё немало лет.
А ещё у нас до недавнего времени был математический модуль на APL...
Речь шла не о отдельном мк, а о целой системе умного дома. Nodered совершенно не предназначено решать задачи в пределах одного устройства - это инструмент интеграции устройств в "умную" систему - и здесь mqtt и Nodered отлично справляются.
Ещё раз - низкоуровневые вещи естественно нужны, но не на уровне интеграции, а на уровне устройства - наружу должен быть виден сервис (открыть ворота, считать температуру), а не "считай пятый бит порта X".
HA очень неудобен при написании сценариев. Написанные сценарии очень не наглядны. А хорошо сделанные графики Nodered вполне можно (в общих чертах) объяснить даже ребёнку.
С помощью mqtt можно очень просто объединить несколько различных сервисов - у меня например есть инстанция fhem (где мне проще подключить некоторое оборудование), HA и Nodered - все прекрасно общается между собой одинаковым образом через mqtt. Это чрезвычайно удобно. И много проще заменяемо - не только в границах esphome.
Шлагбаум это не умный дом, это более менее одно изолированное устройство, тут вполне оправдано поднять сервер на esp. А если у вас система доступа с десятком-другим точек? На каждой независимый сервер поднимать? Или лучше сделать центральный сервис с проверкой прав доступа, логированием, контролем нештатных ситуаций?
Мы просто о разных вещах говорим.
Mqtt для этого не предназначено, тут совсем другой уровень абстракции. MQTT это командный интерфейс, имплементация комманд, естественно, пишится на том же С в самих устройствах.
Тоже самое с Nodered - я не вижу никакого смысла читать здесь ADC. Тут должно передаваться конкретное значение, температура, давление, неважно что, а как это реализуется, находится на более низком уровне, в в устройстве. Это гарантирует взаимозаменяемость - я могу заменить тот же датчик температуры на совершенно другой без изменений на уровне mqtt и Nodered. Nodered задаёт логику умного дома и не заботится о low level реализации. В этом весь смысл.
Кстати, в чем проблема с управлением со смартфона? Вполне есть клиенты mqtt. А если уж поднимать на esp вебсервер, то это уже не серверлес. Проще поднять центральный сервер, который раздаёт команды на отдельные устройства через MQTT.
Разговаривать с каждым esp отдельно IMHO чаще всего плохая идея. А если вы через пару лет заменить захотите систему (поддержки больше нет, вышли из строя и замена недоступна, появились более лучшие варианты,..) ? Я пару лет назад выбросил все самоделки на основе MySensors и заменил их готовыми устройствами zeegbe и shelly и немного самодельный на esphome. В Nodered логике изменений не потребовалось вообще, только топики mqtt и формат (на json перешёл).
Esphome?
MQTT более универсален. Я пользуюсь Homeassistant только в качестве вебморды, а писать сценарии мне намного больше нравится на Nodered. MQTT это клей, что все это связывает.
Такой преобразователь и так стоит в каждом телефоне (ну естественно не трансформатор, там импульсные преобразователи). Стандартная батарея всегда получает свои четыре с копейками вольт по определённому профилю заряда (вообще-то заряд идёт током, а не напряжением, но в данном случае не будем усложнять).
Это еще влияет на энергопотребление и быстродействие. Так что разница естьи большая.
Еще бы начать с корня всей проблемы - ошибки в "адресе" получателя. В ЕС это вполне неплохо реализовано - переводы по всему ЕС осуществляются через IBAN - это такой номер с двумя проверочными цифрами. Ошибиться в наборе практически невозможно - система неверный номер просто не примет.
Если успеют. Шансов на следующих выборах у них (по результатам опросов) уже практически нет.
То, что все изменения протоколлируются - это понятно, но это мало поможет, если сделать грамотно.
Такие вещи естественно делаются в рамках поставленных задач - новая feature, bugfix... В идеале размазываются на несколько коммитов и выглядят как неявный побочный эффект. Ошибка, каких много, бывает... К тому же мы говорим не о программе игры в крестики-нолики - закладка делается так, что между внесением и первым проявлением проходят месяцы. За это время в больших и важных системах накапливаются тысячи коммитов. Определить "день X" будет очень сложно. И доказать намеренную диверсию практически невозможно. Разработчику высокого уровня такое вредительство вполне по плечу.
Ну например итальянская забастовка - все очень правильно и по уставу, что не подкапаешся, но очень-очень не эффективно.
Закладки в коде, как вы описываете - слишком грубо. Это делается намного более субтильно. Например ухудшение перформанса, немного, чтобы все работало каждый день, но какой нибудь месячный batch job (в тех же банках их много) переодически вылезал за рамки и создавал проблемы. Или намеренное неправильное округление результата, но для редких случаев. Не сойдётся годовой баланс на пару рублей - искать будет весь отдел пару недель - ну ошибся, ну бывает. Ну и много других вариантов.Я давно работаю в этой сфере, вполне смогу сделать так, что и тесты все пройдёт и ни одно ревью не найдёт.
Про язык тоже хотел написать. Работаю тут уде 20 лет (финансовая сфера). Банки, страховые - абсолютно все только на немецком. Не то чтобы английский не знают - но язык документации и вся переписка - немецкий.
Solidaritätszuschlag (помощь восточным землям) с января прошлого года уже не актуален для 90%. До 73000 годового дохода (151000 для семьи) этот налог больше не взимается.
— Поиск пока что не фонтан, да. Но заметно время от времени, что амазон над ней работает. Так что наверное будет лучше, смотря, что искать. Для сложных тем она и не задумывалась, для ответа на вопросы вроде кто? где? когда? — вполне.
— Музыка слушается подключением алексы к нормальному усилителю через Bluetooth или проводом. Будет Вам отличное качество. Для кухни большой алексы и так достаточно.
Когда идешь в темноте и руки заняты, такой голосовой выключатель очень даже кстати (ну или когда лень с дивана вставать :)
Еще удобно:
— будильник
— время спросить (ночью, когда темно)
— таймер (на кухне, чай заварить)
— погода
— календарь
Пользуюсь DirtyPCBs / DangerousPrototypes. Из нескольких сотен изготовленных плат была только одна с ошибкой. При том они часто доставляют пару-тройку больше чем заказано.
Ну и о профессионализме — не с вами говорить. Веселых вам поделок ;)
Вы не знаете разницы между ESP (WLAN) и nRF24L01 (создает легковесную радиосеть). Совершенно разния свойства и области применения.
Я вполне себе использую и ESP и Ардуинки для различных назначений, но не в качестве костылей.
Например вот: s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/139-onewire-wlan-bridge-auf-basis-esp8266
и вот: s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/138-mysensors-wlan-gateway-milight-bridge