Перейти к содержимому

← Web, MQTT & HTTP | Содержание | Далее: Справочник →

Расширенные возможности — Нативный драйвер DimmerLink для Tasmota

Кривые диммирования

Кривая диммирования определяет, как процент яркости соответствует фактическому углу открытия TRIAC и, следовательно, мощности, подаваемой на нагрузку. Доступны три кривые, каждая из которых подходит для различных типов нагрузок.

LINEAR (значение 0)

Угол фазы пропорционален запрашиваемому уровню яркости. Зависимость между значением команды и электрической мощностью является линейной.

plaintext
Power delivered
100% |                    /
     |                  /
 50% |              /
     |           /
  0% |        /
     +------------------
     0%     50%     100%
          Level set

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

Не рекомендуется для: LED-ламп или ламп накаливания, где важна воспринимаемая яркость.

RMS (значение 1)

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

plaintext
Perceived brightness (incandescent)
100% |                    /
     |                  /
 50% |              /
     |           /
  0% |        /
     +------------------
     0%     50%     100%
          Level set

Применение: Лампы накаливания и галогенные лампы. При кривой RMS значение 50 даёт примерно половину воспринимаемой яркости от значения 100.

Не рекомендуется для: LED-ламп — диммируемые LED-драйверы регулируют ток внутренне, и зависимость между углом фазы и световым выходом более сложная.

LOG (значение 2)

Угол фазы следует логарифмической кривой, предназначенной для обеспечения перцептивно равномерных ступеней яркости. Человеческий глаз воспринимает интенсивность света логарифмически (закон Вебера-Фехнера), поэтому равные приращения дают примерно равные перцептивные изменения.

plaintext
Perceived brightness (LED)
100% |                         /
     |                    /
 50% |               /
     |         /
  0% |  /
     +------------------
     0%     50%     100%
          Level set

Применение: Диммируемые LED-лампы, декоративное освещение, любое приложение, где важно плавное диммирование на низких уровнях. Устраняет распространённую проблему, когда LED переходят от «едва горит» до «очень ярко» в небольшом диапазоне.

Не рекомендуется для: Резистивных или индуктивных нагрузок, где важен контроль мощности (а не воспринимаемая яркость).

Выбор подходящей кривой

Нагрузка Рекомендуемая кривая Команда
Диммируемые LED LOG DlCurve 2
Лампа накаливания RMS DlCurve 1
Галогенная лампа RMS DlCurve 1
Резистивный нагреватель LINEAR DlCurve 0
Коллекторный двигатель (вентилятор, миксер) LINEAR DlCurve 0
Неизвестная Попробуйте все три --

Кривую можно изменить в любое время без влияния на текущий уровень яркости. Новая кривая применяется начиная со следующей команды изменения яркости.


Управление затуханием (Fade)

Принцип работы

Время затухания определяет, сколько времени MCU тратит на переход от текущего уровня яркости к новому заданному уровню. Затухание реализовано полностью в прошивке MCU — после записи нового уровня по I2C устройство плавно изменяет его внутренне без дополнительного взаимодействия с Tasmota.

Расчёт времени

plaintext
Fade time (seconds) = value * 0.1
Значение Время затухания
0 Мгновенно (без затухания)
1 100 мс
5 500 мс
10 1,0 секунда
20 2,0 секунды
50 5,0 секунд
100 10,0 секунд
255 25,5 секунд (максимум)

Затухание задаётся для устройства, а не для канала

Все каналы одного устройства используют одинаковое время затухания. Для разных скоростей затухания на разных каналах они должны быть на отдельных устройствах.

Использование затухания со слайдерами веб-интерфейса

Настройка затухания влияет на все команды изменения уровня, включая команды от слайдеров веб-интерфейса. При ненулевом значении затухания перемещение слайдера задаёт новый целевой уровень, и устройство плавно переходит к нему. Повторное перемещение слайдера до завершения затухания начинает новый переход с текущей позиции.

Установка и запрос значения затухания

plaintext
DlFade 10       # Set device 1 fade to 1.0 second
DlFade2 0       # Set device 2 fade to instant
DlFade          # Query device 1 current fade value

Мониторинг температуры

Наличие функции

Мониторинг температуры доступен, когда прошивка MCU скомпилирована с FEATURE_TEMPERATURE. Драйвер автоматически определяет это при загрузке, считывая регистр TEMP_CURRENT (0x40). Если регистр возвращает 0xFF, датчик температуры отсутствует и все поля температуры скрываются.

Считывание температуры

Необработанное значение температуры хранится в регистре 0x40 со смещением 50:

plaintext
Temperature (Celsius) = register_value - 50

Это позволяет охватить диапазон от -50 °C (значение регистра 0) до +205 °C (значение регистра 255). Нормальный рабочий диапазон: от 20 °C до 100 °C.

Тепловые состояния

Прошивка MCU управляет тепловой защитой автономно. Определены шесть состояний:

Состояние Значение Описание Действие драйвера
NORMAL 0 Температура ниже порога предупреждения Нет
WARNING 1 Температура выше порога предупреждения Запись на уровне DEBUG
DERATE 2 Активное снижение выходной мощности для понижения температуры Нет — оборудование управляет выходом
CRITICAL 3 Агрессивное снижение выходной мощности Запись на уровне ERROR
SHUTDOWN 4 Все выходы отключены в целях безопасности Запись на уровне ERROR
FAULT 5 Неисправность датчика температуры Запись на уровне ERROR

Состояния CRITICAL, SHUTDOWN и FAULT вызывают запись в журнал на уровне ERROR:

plaintext
DLK: Dev 0x50 thermal CRITICAL

Тепловая защита управляется аппаратно

MCU управляет снижением мощности и отключением автономно. Tasmota не может переопределить тепловую защиту — если устройство находится в состоянии SHUTDOWN, запись значения яркости не даёт эффекта до тех пор, пока устройство не остынет и не выйдет из состояния отключения.

Мониторинг через MQTT

При включённом мониторинге температуры каждое сообщение SENSOR содержит текущую температуру и состояние:

json
{
  "DimmerLink1": {
    "Addr": "0x50",
    "ACFreq": 50,
    "Fade": 0,
    "Ch1": {"Level": 75, "Curve": "LOG"},
    "Temp": 42,
    "Thermal": "NORMAL"
  }
}

Используйте правила Tasmota или внешнюю систему для реагирования на изменения теплового состояния.


Адресация нескольких устройств

Драйвер поддерживает до четырёх устройств DimmerLink на одной шине I2C (или распределённых по двум шинам). Устройства нумеруются от 1 до 4 в порядке обнаружения при сканировании во время загрузки — по возрастанию адреса (от 0x08 до 0x77).

Нумерация устройств

I2C-адрес Порядок обнаружения Номер устройства
0x50 1-е найдено Устройство 1 (суффикс 1 или без суффикса)
0x51 2-е найдено Устройство 2 (суффикс 2)
0x52 3-е найдено Устройство 3 (суффикс 3)

Назначение уникальных адресов

Все устройства DimmerLink поставляются с I2C-адресом 0x50. Для использования нескольких устройств каждому необходимо назначить уникальный адрес по одному перед их совместным подключением.

Пошаговая инструкция для трёх устройств:

plaintext
Step 1: Connect Device A only (boots at 0x50)
        Console: DlAddress 0x51
        Result: Device A is now at 0x51
Step 2: Power off. Connect Device B only (boots at 0x50)
        Console: DlAddress 0x52
        Result: Device B is now at 0x52
Step 3: Power off. Connect Device C (keep at 0x50)
        Power on all three together.
        Three devices detected: 0x50, 0x51, 0x52

Проверка адреса

Драйвер проверяет изменение адреса, повторно считывая регистр VERSION с нового адреса:

c
if (DL_ValidRead8(&ver, new_addr, DL_REG_VERSION, dev->bus) && ver == DL_FW_VERSION) {
    dev->addr = new_addr;
    // success
}

Если проверка не удаётся, команда возвращает ошибку. Физическое устройство могло уже изменить адрес — выполните DlStatus для подтверждения.

Допустимый диапазон адресов

Адреса должны быть в диапазоне от 0x08 до 0x77 включительно. Зарезервированные адреса 0x00–0x07 и 0x78–0x7F отклоняются.

Примечания о конфликтах I2C-адресов

Адрес по умолчанию 0x50 конфликтует с распространёнными устройствами EEPROM/FRAM (FM24CXX, AT24Cxx, 24C256, 24LC256). Драйвер идентифицирует устройства DimmerLink именно по байту версии прошивки в регистре 0x03, поэтому устройства сторонних производителей на адресе 0x50 молча пропускаются. Однако, чтобы избежать нежелательных транзакций на шине, смените адрес DimmerLink, если на шине присутствуют устройства EEPROM.

Порядок сканирования по шинам

Если активны две шины I2C, сканирование обрабатывает сначала шину 0, затем шину 1. Устройство на шине 0 с адресом 0x51 будет найдено раньше устройства на шине 1 с адресом 0x50.


Миграция с Berry-драйвера

Если вы использовали Berry-драйвер DimmerLink.be и переходите на нативный драйвер, обратите внимание на следующие отличия.

Что изменяется

Аспект Berry-драйвер Нативный драйвер
Префикс команды DimmerLink, DimmerLink_Kitchen и т. д. Dl
Выбор устройства По метке (имени) По порядку обнаружения (числовой суффикс)
Адресация каналов Завершающая цифра: DimmerLink_Kitchen2 Синтаксис ch,level: DlDim 2,50
Команда кривой DimmerLink_KitchenCurve 2 DlCurve 2
Команда затухания DimmerLink_KitchenFade 10 DlFade 10
Виртуальное реле Да — Power ON/OFF Не предусмотрено
Пресеты DimmerLinkPreset night Не предусмотрено
Сканер шины DimmerLink.scan() в консоли Berry Не предусмотрено; используйте I2CScan
Именованные экземпляры Да — метки в dimmerlink.json Не предусмотрено — устройства пронумерованы
Конфигурация /dimmerlink.json на файловой системе user_config_override.h во время компиляции
Ключ MQTT-телеметрии Метка устройства (например, "Kitchen") DimmerLink1, DimmerLink2 и т. д.

Шаги миграции

  1. Прошейте новую прошивку, включающую USE_DIMMERLINK.
  2. Удалите файлы Berry-драйвера с файловой системы (DimmerLink.be, dimmerlink_loader.be) или удалите строку load('dimmerlink_loader.be') из autoexec.be. Berry-драйвер и нативный драйвер могут сосуществовать, но оба будут реагировать на одно и то же устройство и генерировать дублирующуюся телеметрию.
  3. Обновите MQTT-автоматизации — замените имена команд DimmerLink_ на DlDim, DlCurve, DlFade.
  4. Обновите MQTT-подписки — замените ключи именованных устройств (например, "Kitchen") на нумерованные ключи ("DimmerLink1", "DimmerLink2").
  5. Обновите HTTP API-вызовы — замените DimmerLink_Kitchen%2075 на DlDim%2075 (или DlDim2%2075 для второго устройства).
  6. Виртуальные реле — если вы использовали Power для переключения устройств, реализуйте эквивалентную логику с помощью правил Tasmota и команд DlDim.
  7. Пресеты — если вы использовали DimmerLinkPreset, создайте эквивалентные правила Tasmota или Berry-скрипты, выдающие команды DlDim.