Sonoff

As I promised in #1585 this pull request adds initial support for the Power-On state feature. For now, it works on DUALR3 and TX Ultimate devices. I have refrained from adding more devices as I cannot test them. I would appreciate support on the following: - Code conventions/Variable names: This PR needed support for select entities, thus the select.py file should be reviewed. I tried to make it as bare-bones as possible - send_bulk functions: I avoided modifying the original send_bulk function, a better option would be to generalize it. - Fetching the power-on state periodically from …

Excerpt saved from GitHub on 2026-10-23.

This PR adds support for the Sonoff IW101 The IW101 has power monitoring and the IW100 does not. Support for the 100 can be added I just don't have one so I do not know the uiid.

Excerpt saved from GitHub on 2026-10-23.

Hey! I've been using the MINI-DIM (UIID 277) with an adaptive lighting automation and noticed it was the only dimmer class without transition support. Thought I'd have a go at adding it. ## What I found The MINI-DIM firmware (tested on 1.1.2) supports a `transitionTime` parameter in milliseconds, the device does smooth hardware fading when it receives it alongside a brightness command. The catch is it only works through the cloud API. The local `/zeroconf` endpoint either ignores it or returns a `text/html` error and times out. ## What this does - Adds `LightEntityFeature.TRANSITION` to …

Excerpt saved from GitHub on 2026-10-23.

The problem MINIR4M (uiid 138) on firmware 1.3.1 discards any zeroconf command whose decrypted JSON payload contains whitespace. The device still decrypts the request and still answers `{"error":0}` with a normal sequence, the relay simply does not move. Nothing surfaces as an error, so the entity looks perfectly healthy in Home Assistant while local control does nothing. `json.dumps()` defaults to `separators=(", ", ": ")`, so every command `encrypt()` builds carries spaces. eWeLink's own hub builds the same payload with JavaScript's `JSON.stringify()`, which is compact, which appears to …

Excerpt saved from GitHub on 2026-10-23.

Environment Home Assistant: 2026.3.3 (OS) SonoffLAN: 3.11.0 RF Bridge model: RFBridge433, firmware 3.6.2, hardware 28 Sensor: Sonoff DW2-RF on rfChl 8 Description The RF Bridge binary_sensor (binary_sensor.1001f6cd6c_8) does not update its state when an alarm is triggered in auto or local mode. The sensor remains permanently "off" despite the trigger data arriving correctly. Switching to cloud mode fixes the issue, the binary_sensor updates as expected. Evidence from debug logs Auto mode, trigger received but binary_sensor stays off: 1001f6cd6c Local4 | 192.168.0.237:8081 | getState {} <= …

Excerpt saved from GitHub on 2026-10-23.

You no longer have to flash the S31s. There's the SonoffLAN Integration that offers local control over LAN and/or Cloud from Home Assistant. Mine are stock firmware and have been tested and confirmed to be 100% local with no calling out.

Excerpt saved from the Arctic Shift Reddit archive on 2026-10-23.

tested with Mode: local Home: on/off both worked. All entities where auto-discovered and added

Excerpt saved from GitHub on 2026-10-23.

Description Adds support for the Sonoff SNZB-09P Zigbee indoor siren, which isn't currently recognized by this integration. New entities: - button, trigger the siren (sends `alarmSetting.test = true`). Tested and confirmed working on a real device, the siren sounds and `alarmType` goes from `none` → `manual` → back to `none` once the configured Alarm Duration elapses. - switch, Alarm Sound enable, Alarm Light enable - number, Alarm Duration (seconds), Alarm Volume - sensor, Alarm Sound Type (read-only), Alarm Status - binary_sensor, External Power connected ### How the values were …

Excerpt saved from GitHub on 2026-10-23.

Fixes #1819. Adds support for CoolKit `CK-BL602-TC-01` (uiid 216), the eWeLink-based Wi-Fi module found in VEVOR MD370 / MD750 and other rebranded sliding-gate motors. Reported at #1819 (with device dump). Exposed as a `cover` with `device_class: gate`.

Excerpt saved from GitHub on 2026-10-23.

After updating Sonoff devices to new FW, Local stopped working. Only TH device not updated, still working. 2025-03-05 14:27:59.987 ERROR (MainThread) [custom_components.sonoff.core.ewelink.cloud] You logged in from another place, read more https://github.com/AlexxIT/SonoffLAN#configuration 2025-03-05 14:28:15.482 ERROR (MainThread) [custom_components.sonoff.core.ewelink.cloud] You logged in from another place, read more https://github.com/AlexxIT/SonoffLAN#configuration 2025-03-05 14:28:45.707 ERROR (MainThread) [custom_components.sonoff.core.ewelink.cloud] You logged in from another place, …

Excerpt saved from GitHub on 2026-10-23.

Summary SonoffLAN 3.13.0 can lose local acquisition after a Home Assistant restart or config-entry reload. Affected devices remain cloud-online but show host=null and local=null, so local telemetry stops until an advertisement is accepted or an external command reactivates polling. While acquisition is missing, Home Assistant also generates sustained mDNS traffic for unresolved Sonoff hostnames. I am requesting a supported recovery path that can reuse a known/configured host and device key, with bounded mDNS retries, rather than depending indefinitely on fresh zeroconf discovery. Environment …

Excerpt saved from GitHub on 2026-10-23.

After updating the Sonoff TRVZB thermostat to firmware 1.4.0, the SonoffLAN integration started producing repeated cloud errors in Home Assistant logs: [code] This error repeats frequently, indicating that TRVZB cloud communication is broken after the firmware upgrade. Steps to reproduce - Pair TRVZB with eWeLink account and Home Assistant via SonoffLAN. - Update TRVZB firmware to version 1.4.0. - Observe HA logs – repeated Cloud ERROR 400 messages appear. Expected behavior TRVZB should be handled correctly by the SonoffLAN integration without cloud errors after firmware update. Additional …

Excerpt saved from GitHub on 2026-10-23.