Sonoff http команды

Sonoff http команды

Control Sonoff Devices from Home Assistant

Home Assistant custom component for control Sonoff devices with eWeLink (original) firmware over LAN and/or Cloud.

New features in version 3.0

  • support Integration UI, Devices and Zones
  • support new eWeLink API
  • support multiple eWeLink accounts and homes
  • support many sensors for each device (include RFBridge)
  • support thermostats for Sonoff TH ans NS Panel
  • support preventing DB size growth
  • support many new Hass features

Features from previous versions

  • can manage both local and cloud control at the same time!
  • support old devices wih 2.7 firmware (only cloud connection)
  • support new device types: color lights, sensors, covers
  • support eWeLink cameras with PTZ
  • support unavailable device state for both local and cloud connection
  • support sensors for Sonoff RF Bridge 433
  • support ZigBee Bridge and Devices
  • added new debug mode for troubleshooting


  • work with original eWeLink / Sonoff firmware, no need to flash devices
  • work over Local Network and/or Cloud Server
  • work with devices without DIY-mode
  • work with devices in DIY-mode
  • support single and multi-channel devices
  • support TH and Pow device sensors
  • support Sonoff RF Bridge 433 for receive and send commands
  • support Sonoff GK-200MP2-B Camera
  • instant device state update with local Multicast or cloud Websocket connection
  • load devices list from eWeLink Servers (with names and encryption keys) and save it locally
  • (optional) change device type from switch to light

Component review from DrZzs

There is another great component by @peterbuga, that works with cloud servers.

Thanks to @beveradb and @mattsaxon for researching the local Sonoff protocol.
Thanks to @michthom and @EpicLPer for researching the local Sonoff Camera protocol.

Almost any single or multi-channel Switch working in the eWeLink application will work with this Integration even if it is not on the list.

Tested (LAN and Cloud)

These devices work both on a local network and through the cloud.

Tested (only Cloud)

These devices only work through the cloud!

Tested ZigBee (only Cloud)

  • Sonoff ZigBee Bridge — turn on for pairing mode
  • SONOFF SNZB-01 — Zigbee Wireless Switch
  • SONOFF SNZB-02 — ZigBee Temperature and Humidity Sensor
  • SONOFF SNZB-03 — ZigBee Motion Sensor
  • SONOFF SNZB-04 — ZigBee Wireless door/window sensor

Tested Cameras (only LAN)

Maybe other eWeLink cameras also work, I don’t know.

HACS > Integrations > Plus > SonoffLAN

Or manually copy sonoff folder from latest release to custom_components folder in your config folder.

Configuration > Integrations > Add Integration > Sonoff

If the integration is not in the list, you need to clear the browser cache.

You can setup multiple integrations with different ewelink accounts.

Important. If you use the same account in different smart home systems, you will be constantly unlogged from everywhere. In this case, you need to create a second ewelink account and share your devices or home with it.

  • Problems: Hass + Hass, Hass + Homebridge, Hass + eWeLink app v3, etc.
  • No Problems: Hass + eWeLink app v4, Hass + eWeLink addon

Before posting new issue:

  1. Check the number of online devices on the System Health page
  2. Check warning and errors on the Logs page
  3. Check debug logs on the Debug page (must be enabled in integration options)
  4. Check open and closedissues
  5. Share integration diagnostics (supported from Hass v2022.2):
  • All devices: Configuration >Integrations >Sonoff > 3 dots > Download diagnostics
  • One device: Configuration >Devices > Device > Download diagnostics

There is no private data, but you can delete anything you think is private.

Configuration > Integrations > Sonoff > Configure

In auto mode component using both local and cloud connections to your devcies. If device could be reached via LAN — the local connection will be used. Otherwise the cloud connection will be used. This mode is recommended for most general user.

local mode or cloud mode will use only this type of connection.

Sometimes it can be difficult to get a local connection to work. You need a local network with working Multicast (mDNS/zeroconf) traffic between the Hass and your devices. Read about common problems.

Each time the integration starts, a list of user devices is loaded from cloud and saved locally ( /config/.storage/sonoff/ ).

auto mode and local mode can work without Internet connection. If the integration fails to connect to the cloud — the component will use the previously saved list of devices and continue to work only in local mode. auto mode will continue trying to connect to the cloud.

local mode can’t work without ewelink credentials because it needs devices encryption keys.

Devices in DIY mode can be used without ewelink credentials because their protocol unencrypted. But the average user does not need to use devices in this mode.

Enable debug page in integration options. Reload integrations page. Open: Integraion > Menu > Known issues.

Debug page shows only integration logs and removes some private data. You can filter log and enable auto refresh (in seconds).

By default component loads cloud devices only for current active Home in ewelink application. If there is only one Home in the account, it shouldn’t be a problem. Otherwise you can select one or multiple Homes to load devices from.

These settings are made via YAML.

Important. DeviceID is always 10 symbols string from entity_id or eWeLink app.

You can convert all switches into light by default:

You can convert specific switches into light , fan or binary_sensor :

You can convert multi-channel devices (e.g. Sonoff T1 2C):

You can convert multi-channel device (e.g. Sonoff T1 3C) into single light with brightness control:

You can control multiple light zones with single multi-channel device (e.g. Sonoff 4CH):

You can change device_class for Binary Sensor:

You can change device_class for Cover:

If you want some additional device attributes as sensors:

You can request actual device state and all its sensors manually at any time using homeassistant.update_entity service. Use it with any device entity except sensors. Use it with only one entity from each device.

As example, you can create an automation for forced temperature updates for Sonoff TH:

Preventing DB size growth

Pow devices may send a lot of data every second. You can reduce the amount of processed data.

For multi-channel devices use power_1 , current_2 , etc.

  • if new value came before min seconds — it will be «delayed»
  • if new value came between min and max seconds
    • if delta lower than delta value — it will be «delayed»
    • otherwise — it will be used
  • if new value came after max seconds — it will be used
  • any used value will erase «delayed» value
  • new «delayed» value will overwrite old one
  • «delayed» value will be checked for the above conditions every 30 seconds

Support power, current and voltage sensors via LAN and Cloud connections. Also support energy (consumption) sensor only with Cloud connection.

By default energy data loads from cloud every hour. You can change interval via YAML and add history data to sensor attributes (max size — 30 days, disable — 0). For multi-channel devices use energy_1 , energy_2 .

You can also setup a integration sensor, that will collect energy data locally by Hass:

Support optional Climate entity that controls Thermostat. You can control low and high temperature values and hvac modes:

  • heat — lower temp enable switch, higher temp disable switch
  • cool — lower temp disable switch, higher temp enable switch
  • dry — change control by humidity with previous low/high switch settings

In dry mode, the Thermostat controls and displays Humidity. But the units are displayed as temperature (Hass limitation).

Thermostat can be controlled only with Cloud connection. Main switch and TH sensors support LAN and Cloud connections.

Sonoff RF Bridge 433

RF Bridge support learning up to 64 signals (16 x 4 buttons).

Video HOWTO from @KPeyanski

Important. Integration v3 supports automatic creation of sensors for RF Bridge. All buttons will be created as Button entity. All alarms will be created as Binary sensor.

Both button and binary sensor has last_triggered attribute with the time of the last signal received. You can use it in automations.

Binary sensor will stay in on state during 120 seconds by default. Each new signal will reset the timer. Binary sensor support restore state between Hass restarts.

If you has door sensor with two states (for open and for closed state) like this one, you can config payload_off as in the example below. Also disable the timeout if you do not need it in this case (with timeout: 0 option).

You can use any device_class that is supported in Binary Sensor. With device_class: button you can convert sensor to button.

PIR Sensor

Single State Sensor

Dual State Sensor

You can read more about using this bridge in wiki.

Sonoff GK-200MP2-B Camera

Currently only PTZ commands are supported. Camera entity is not created now.

You can send left , right , up , down commands with sonoff.send_command service:

device — this is the number from the camera ID EWLK-012345-XXXXX , exactly 6 digits (leading zeros — it is important).

Common problems in only LAN mode

auto mode and cloud mode users don’t have these problems.

Devices are not displayed

  • not all devices supports local protocol
  • two routers
  • docker with port forwarding
    • you must use: —network host
    • hassio users are okay
  • virtual machine with port forwarding
    • you must use bridge virtual network mode (not NAT mode)
  • Oracle VM VirtualBox
  • linux firewall
  • linux network driver
  • incorrect network interface selected in Configuration >Settings > Global > Network

The devices publish their data through Multicast DNS (mDNS/zeroconf), read more.

Devices unavailable after reboot

All devices unavailable after each Home Assistant restart. Devices are automatically detected in the local network after each restart. Sometimes devices appear quickly. Sometimes after a few minutes. If this does not happen, there are some problems with the multicast / router.

The component adds the service sonoff.send_command to send low-level commands.

Example service params to single switch:

Example service params to multi-channel switch:

Example service params to dimmer:

Getting devicekey manually

The average user does not need to get the device key manually. The component does everything automatically, using the ewelink account.


Визуальное программирование для Sonoff Basic

Статья о том, как из дешёвого китайского устройства создать программируемый логический контроллер. Такое устройство найдёт своё применение как в домашней автоматизации, так и в качестве практических занятий по школьной информатике.

Для справки, по умолчанию программа Sonoff Basic работает с мобильным приложением через китайский облачный сервис, после предлагаемой переделки, всё дальнейшее взаимодействие с этим устройством станет возможным в браузере.

Раздел I. Подключение Sonoff к сервису MGT24

Шаг 1. Создание панели управления

Зарегистрируйтесь на сайте mgt24 (если ещё не зарегистрированы) и войдите в систему под своей учётной записью.

Чтобы создать панель управления для нового устройства нажмите на кнопку «+».

После того, как панель будет создана, она появится в списке ваших панелей.

Во вкладке «Установка», созданной панели, найдите поля «ID устройства» и «Ключ авторизации», в дальнейшем, эта информация потребуется при настройки Sonoff устройства.

Шаг 2. Перепрошивка устройства

С помощью утилиты XTCOM_UTIL загрузите прошивку ПЛК Sonoff Basic в устройство, для этого вам понадобиться USB-TTL конвертер. Здесь инструкция и видеоинструкция.

Шаг 3. Настройка устройства

Подайте на устройство питание, после того как загорится светодиод, нажмите на кнопку и удерживайте её в нажатом состоянии до тех пор, пока светодиод не начнёт периодически равномерно мигать.

В этот момент появится новая wi-fi сеть с названием «PLC Sonoff Basic», подключите свой компьютер к этой сети.

Светодиодная индикация Состояние устройства
периодическое двойное мигание нет связи с роутером
непрерывно светит установлена связь с роутером
периодическое равномерное мигание режим wi-fi точки доступа
потушен нет питания

Откройте интернет-браузер и введите в адресную строку текст «», перейдите на страницу настроек параметров сети устройства.

Заполните поля следующим образом:

  • «Имя сети» и «Пароль» (для привязки устройства к домашнему wi-fi роутеру).
  • «ID устройства» и «Ключ авторизации» (для авторизации устройства на сервисе MGT24).

Сохраните настройки и перезагрузите устройство.

Шаг 4. Подключение датчиков (опционально)

Текущая прошивка поддерживает до четырёх датчиков температуры ds18b20. Здесь видеоинструкция по монтажу датчиков. По всей видимости, это шаг будет самым непростым, так как потребует от вас прямых рук и паяльника.

Раздел II. Визуальное программирование

Шаг 1. Создание сценариев

В качестве среды программирования используется Blockly, среда проста в освоении, поэтому для создания простых сценариев не нужно быть программистом.

Я добавил специализированные блоки для записи и чтения параметров устройства. Доступ к любому параметру осуществляется по имени. Для параметров удалённых устройств используются составные имена: «параметр@устройство».

Пример сценария циклического включения и выключения нагрузки (1Гц):

Пример сценария синхронизирующего работу двух отдельных устройств. А именно, реле целевого устройства повторяет работу реле удалённого устройства.

Сценарий для термостата (без гистерезиса):

Чтобы создавать более сложные сценарии можно использовать переменные, циклы, функции (с аргументами) и прочие конструкции. Не буду здесь всё это расписывать подробно, в сети уже есть довольно много обучающего материала о Blockly.

Шаг 2. Порядок выполнения сценариев

Сценарий работает в непрерывном режиме, и как только он доходит до своего окончания он запускается вновь. При этом есть два блока, которые могут временно приостановить работу сценария, «delay» и «pause».

Блок «delay» используется для миллисекундных или микросекундных задержек. Этот блок строго выдерживает временной интервал, блокируя работу всего устройства.

Блок «pause» используется для секундных (можно и меньше) задержек, и он не блокирует выполнение других процессов в устройстве.

Если сценарий внутри себя содержит бесконечный цикл, в теле которого не стоит «pause», интерпретатор самостоятельно инициирует маленькую паузу.

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

Шаг 3. Отладка сценариев

Для отладки уже загруженного в устройство сценария, можно запустить трассировку программы по шагам. Это бывает крайне полезно, когда поведение сценария оказалось не таким, как задумывал автор. В этом случае, трассировка позволяет автору быстро найти источник проблемы и исправить ошибку в сценарии.

Сценарий вычисления факториала в отладочном режиме:

Инструмент отладки очень прост и состоит из трёх основных кнопок: «пуск», «один шаг вперёд» и «останов» (также не забудем про «вход» и «выход» из режима отладки). Кроме пошаговой трассировки можно установить точку останова на любом блоке (щелчком мыши над блоком).
Чтобы вывести в монитор текущие значения параметров (датчики, реле) используйте блок «print».
Здесь обзорный видеоролик об использовании отладчика.

Раздел для любознательных. А что же под капотом?

Для того чтобы сценарии работали на целевом устройстве был разработан интерпретатор байт-кода и ассемблер на 38 инструкций. В исходный код blockly был встроен специализированный генератор кода, который конвертирует визуальные блоки в ассемблерные инструкции. В дальнейшем эта ассемблерная программа преобразуется в байт-код и передаётся в устройство на исполнение.

Архитектура этой виртуальной машины довольно проста и описывать её особого смысла нет, в сети вы найдёте много статей о проектировании простейших виртуальных машин.

Под стек своей виртуальной машины я обычно выделяю 1000 байт, этого хватает с запасом. Конечно, глубокие рекурсии могут исчерпать любой стек, но вряд ли им найдётся практическое применение.

Итоговый байт-код получается довольно компактным. Как пример, байт-код вычисления того же факториала составляет всего 49 байт. Это его визуальная форма представления:

А это его ассемблерная программа:

Если ассемблерная форма представления не имеет какой-либо практической ценности, то вкладка «javascrit», напротив, даёт более привычный вид нежели визуальные блоки:

Что касается производительности. При запуске простейшего сценария мигалки, на экране осциллографа я получил меандр 47кГц (при тактовой частоте процессора 80МГц).

Считаю это неплохим результатом, по крайней мере, эта скорость почти в десять раз быстрее чем у Lua и Espruino.

Заключительная часть

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

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

На этом всё, буду рад услышать советы и конструктивную критику.