Умный дом с проводами

Логотип Mirta Framework Пройдя от самых основ и вникая в каждую строчку конфигураций, по материалам прошлых статей мы получили шаблон для комфортной разработки правил wb-rules на TypeScript: Очевидно, что подобный процесс хорош с позиции обучения. Тем не менее, сейчас в проекте много вспомогательного кода, который используется только на этапе разработки. Да и вместо программирования правил приходится интенсивно разбираться с многочисленными настройками. Можно ли это упростить? Безусловно. Подготовка к работе Установка Node.js Если Node.js у вас ещё не установлен, понадобится зайти на его официальный сайт и скачать актуальную версию LTS (24.12.0): В процессе установки будет предложен выбор компонентов - отметьте опции «Node.js runtime», «corepack manager» и «Add to PATH». Остальное не понадобится. Выбор компонентов при установке Node.js На следующем экране будет предложено автоматически установить «необходимые» инструменты - мы обойдёмся без них, пропускаем. Предложение установить доп

Дальнейшее развитие проекта на TypeScript привело к появлению фреймворка под названием «Мирта» - постепенно добавляются различные модули, расширяющие стандартные возможности wb-rules. Здесь и симулятор запуска на контроллере для юнит-тестов, и расширение устройств готовыми плагинами, и вспомогательные механизмы вроде debounce и throttle для предотвращения избыточных вызовов функций. Использование проверенных паттернов и подходов улучшает качество кода и облегчает сопровождение. Поскольку базовая функциональность уже реализована, можно быстрее создавать новые проекты. Сегодня рассмотрим один из таких элементов фреймворка - хранилище состояний. В целях обучения, базовая реализация модуля встроена в шаблон проекта (в Мирте хранилище представлено отдельным NPM-пакетом). Источником вдохновения послужила Vue Pinia, с той лишь разницей, что воспроизвести на wb-rules 2.0 реактивность не представляется возможным в компактных объёмах кода и с сохранением высокой производительности - требуется по

Создавать правила можно разными способами. Поначалу кажется, что самое простое решение — поместить всё в один файл внутри папки wb-rules. Код перед глазами, всё чётко и последовательно. Казалось бы, что может пойти не так? Сложности возникают по мере добавления функционала. Сначала это defineRule, затем объявления виртуальных устройств и подписка на топики MQTT, а позже появляется объёмная логика сценарного взаимодействия. Код становится трудным для восприятия, ведь чтобы сложить полную картину происходящего, требуется вникнуть в каждую деталь. Распутать клубок кода позволяет деление на модули. Нет смысла каждый раз «изобретать» работу с устройством заново, будь то многоканальный счётчик электроэнергии, термостат или же обычный сценарный пульт Zigbee на четыре кнопки. Мы ведь не пытаемся создать с нуля микроволновку перед тем, как разогреть себе еду? Это справедливо и по отношению к модулями правил wb-rules. Один раз настроили, покрыли юнит-тестами для уверенности в отсутствии ошибок и

Однажды познакомившись с программированием, требуется постоянно следить за изменениями, чтобы оставаться в теме происходящего - множество людей по всему миру без устали вносят корректировки в общедоступные инструменты. Меняются конфигурации, устаревают руководства, обновляются подходы к разработке. При подготовке статьи с примерами правил wb-rules, пришлось бороться с Prettier - он упрямо переносил тело инструкций if, else, while и for в одну линию: if (index !== -1) callbacks.splice(index, 1) Разработчикам, не привыкшим к такой записи, будет сложно воспринимать коды. В мире без Prettier существует несколько правил, решающих ту же самую проблему иначе - от обязательного соблюдения отступов, до автоматического добавления фигурных скобок: if (index !== -1) { callbacks.splice(index, 1) } Было решено задействовать альтернативы. И так совпало, что в этот момент вышла статья о ESLint Stylistic на Хабре: Сегодня мы перезапустим процесс статического анализа кода - оптимизируем конфигурацию и

Первое улучшение, предложенное и внедрённое участником сообщества Github. Ваш вклад в этот открытый проект помогает другим разработчикам создавать удивительные вещи, спасибо за это! Хитрость заключается в более тонкой настройке тандема TypeScrtipt и Rollup, приводящего итоговый код к формату, который понимает движок правил wb-rules на контроллере Wirenboard. Если вы пропустили прошлый выпуск, в нём подробно рассказывалось об использовании переменных окружения dotenv: Новые установки открывают возможность для проведения дальнейших оптимизаций, что уже сказалось на ветке проекта latest, получившей значительно переработанную конфигурацию ESLint. В существующих примерах и тех, что готовятся для статьи о программировании правил wb-rules с применением реальных устройств, проблем пока не возникло. В корне проекта найдём файл tsconfig.json и перенастроим работу компилятора TypeScript: "compilerOptions": { "target": "es5", "module": "es2015", "moduleResolution": "node", "outDir": "./dist", "pat

Переменные окружения - это все те строковые константы, которые раньше были зашиты прямо в код. Сегодня мы вынесем их в отдельный текстовый файл и оформим построчно в виде пар «ключ-значение». Чтобы стало ещё интереснее, научимся собирать проект в вариантах development и production. Первый используется для отладки и экспериментов, а второй - серьёзный, компактный и максимально эффективный. Разумеется, разные варианты сборки потребуют переключения между разными наборами строковых значений. И обновлённая система умеет делать это буквально по щелчку пальцев. Прежде чем открыть очередную тайну профессиональной разработки, следует сделать небольшую оговорку - переменные окружения работают только совместно со сборщиком модулей. Если вы пропустили недавний рассказ о работе с Rollup, придётся наверстать: После успешного освоения юнит-тестов, мы и дальше будем налегать на их применение. В частности, сегодня напишем пару-тройку тестов для того, чтобы посмотреть, как функционируют переменные окруж