Home Assistant custom component for control Sonoff devices with eWeLink (original) firmware over LAN and/or Cloud.
New features in version 3.0
Features from previous versions
Pros
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)
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.
Before posting new issue:
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.
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.
It is highly recommended that you use mode: auto
and do not use mode: local
or DIY mode. Because the local protocol is not always stable and you will get a bad experience. Devices may sometimes disappear from the network or fail to respond to local requests. Also some POW and TH devices cannot update their sensors without a cloud connection.
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).
http://192.168.1.123:8123/api/sonoff/c8503fee-88fb-4a18-84d9-abb782bf0aa7?q=1000xxxxxx&r=2
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:
sonoff:
default_class: light # (optional), default switch
You can convert specific switches into light
, fan
or binary_sensor
:
sonoff:
devices:
1000xxxxxx:
device_class: light
name: Sonoff Basic
1000yyyyyy:
device_class: fan
name: Sonoff Mini
You can convert multi-channel devices (e.g. Sonoff T1 2C):
sonoff:
devices:
1000xxxxxx:
device_class: [light, fan]
name: Sonoff T1 2C
1000yyyyyy:
device_class: [switch, light]
name: MiniTiger 2CH
You can convert multi-channel device (e.g. Sonoff T1 3C) into single light with brightness control:
sonoff:
devices:
1000xxxxxx:
device_class:
- light: [1, 2, 3]
name: Sonoff T1 3C
You can control multiple light zones with single multi-channel device (e.g. Sonoff 4CH):
sonoff:
devices:
1000xxxxxx:
device_class:
- switch: 1 # entity 1 (channel 1)
- light: [2, 3] # entity 2 (channels 2 and 3)
- fan: 4 # entity 3 (channel 4)
name: Sonoff 4CH
You can change device_class
for Binary Sensor:
sonoff:
devices:
1000xxxxxx:
device_class: window
You can change device_class
for Cover:
sonoff:
devices:
1000xxxxxx:
device_class: shutter
You can set the uiid
when running in DIY mode to enable the device features. More info here.
sonoff:
devices:
1000xxxxxx:
extra: { uiid: 136 } # Sonoff B05-BL
sonoff:
devices:
1000xxxxxx:
name: Device name from YAML # optional rewrite device name
host: 192.168.1.123 # optional force device IP-address
devicekey: xxx # optional encription key (downloaded automatically from the cloud)
If you want some additional device attributes as sensors:
sonoff:
sensors: [staMac, bssid, host]
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:
trigger:
- platform: time_pattern
minutes: '3'
action:
- service: homeassistant.update_entity
target:
entity_id: switch.sonoff_1000xxxxxx
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.
sonoff:
devices:
1000xxxxxx:
reporting:
power: [30, 3600, 1] # min seconds, max seconds, min delta value
current: [5, 3600, 0.1]
voltage: [60, 3600, 5]
min seconds
- it will be "delayed"min
and max seconds
delta value
- it will be "delayed"max seconds
- it will be usedSupport power
, current
and voltage
sensors via LAN and Cloud connections. Also support energy (consumption) sensor only with Cloud connection.
Many models of Sonoff power devices DON'T send power
, current
and voltage
by default. You need to ASK these devices to send this data. This can ONLY be done through a cloud-based request. The mobile app does it. And the integration does it (only in the auto
and cloud
modes).
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
.
sonoff:
devices:
1000xxxxxx:
reporting:
energy: [3600, 10] # update interval (seconds), history size (days)
template:
- sensor:
- name: "10 days consumpion"
unit_of_measurement: "kWh"
state: "{{ (state_attr('sensor.sonoff_1000xxxxxx_energy', 'history') or [])|sum }}"
You can also setup a integration sensor, that will collect energy data locally by Hass:
sensor:
- platform: integration
source: sensor.sonoff_1000xxxxxx_power
name: energy_spent
unit_prefix: k
round: 2
Support optional Climate entity that controls Thermostat. You can control low and high temperature values and hvac modes:
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.
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
sonoff:
rfbridge:
PIR Sensor 1: # button/alarm name in eWeLink application
device_class: motion
timeout: 60 # optional (default 120), timeout in seconds for auto turn off
Single State Sensor
sonoff:
rfbridge:
Door Sensor 1: # button/alarm name in eWeLink application
name: Door Sensor # optional, you can change sensor name
device_class: door # e.g. door, window
timeout: 5
Dual State Sensor
sonoff:
rfbridge:
Sensor1: # button/alarm name in eWeLink application (open signal)
name: Window Sensor # optional, you can change sensor name
device_class: window # e.g. door, window
timeout: 0 # disable auto close timeout
payload_off: Sensor2 # button/alarm name in eWeLink application (close signal)
You can read more about using this bridge in wiki.
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:
script:
left:
sequence:
- service: sonoff.send_command
data:
device: '012345' # use quotes, this is important
cmd: left
device
- this is the number from the camera ID EWLK-012345-XXXXX
, exactly 6 digits (leading zeros - it is important).
auto
mode and cloud
mode users don't have these problems.
Devices are not displayed
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:
device: 1000xxxxxx
switch: 'on'
Example service params to multi-channel switch:
device: 1000xxxxxx
switches: [{outlet: 0, switch: 'off'}]
Example service params to dimmer:
device: 1000123456
cmd: dimmable
switch: 'on'
brightness: 50
mode: 0
The average user does not need to get the device key manually. The component does everything automatically, using the ewelink account.
ITEAD-10000
, password12345678
http://10.10.7.1/device
deviceid
and apikey
(this is devicekey
)