Releases: mike-goldfinger/ha-warema-wms
Release list
v1.8.0
Added
- Valance control. A motor's valance is now a
coverentity of its own (Valance 1 / Valance 2) on the same device, with open, close, stop and set-position, alongside the read-only sensors added in 1.6.x. Auto-detected from observed data — no new entities on hardware without a valance. (Resolves the remaining part of #4.)
See CHANGELOG.md for full details.
v1.7.1-beta.1 - Pair Wandsender-bound devices (test build)
Test build for issue #8: adds an options-flow step ("Pair a Wandsender-bound device")
for actuators that never join the WMS network on their own and are only ever paired
to a handheld Wandsender (observed on a Lamaxa slat-roof's integrated lighting).
This is a pre-release for testing only - not recommended for general use.
It does not appear as an update for existing installations unless you explicitly
select it.
How to test:
- In HACS, open the Warema WMS integration -> "..." -> Redownload
- Pick this release (v1.7.1-beta.1) from the version dropdown
- Restart Home Assistant
- Settings -> Devices & Services -> Warema WMS -> Configure -> "Pair a Wandsender-bound device"
- Follow the on-screen steps (put the Wandsender in pairing mode, then trigger the
device you want to add from the Wandsender)
Please report back in issue #8 whether the device is captured and appears in the
device list afterwards.
v1.7.0
Added
- Light entities for WMS dimming actuators. Dimmers (device types 26, 28
and 31) are now discovered and exposed as dimmable lights with brightness
(0–100 %) and on/off. A WMS light is always a stand-alone actuator with its
own serial number — it is never a sub-channel of a motor — and it answers
the same scan as any other device; the integration simply filtered it out
and had no light platform. Brightness only: the protocol carries no colour
information. Existing configurations are unchanged — run Configure → Add
new devices to pick up dimmers. (Fixes #8; resolves the LED part of #4.) - Product type diagnostic sensor. Every device now shows the product type
it reports (e.g.28 SlatRoofL70) under Diagnostics, with the raw
device/product type fields as attributes. This is the field that decides how
a device is driven, and the one to quote in a support request. Startup also
logs one identifying line per device at INFO, and the position poll logs the
raw state bytes at DEBUG.
Fixed
- Firmware parameter editor guarded against differing block-38 layouts.
The block-38 addresses the editor reads and writes are correct for the
actuators driving blinds, shutters and awnings, but slat roofs and dimmers
lay that block out differently — a write would have silently changed
unrelated parameters (on a slat roof, run times would land on the louvre
angle limits). Reading and writing motor parameters is now refused for
those products, and they no longer appear in the editor's device picker.
Note on slat roofs (issue #7)
This release does not yet fix stepwise slat-roof control. It ships the
diagnostics needed to finish that fix: the Product type sensor identifies
which slat-roof variant a system reports, and the debug log now shows the raw
angle values at the physical end positions. If you own a slat roof, please
report those values on issue #7 — the tilt fix lands in the next release.
v1.6.1
Valance position sensors never updated in Home Assistant. The read-only valance sensors added in 1.6.0 always stayed Unknown: the WMS position frame decodes valance_1/valance_2 correctly, but the stick dropped them when building the position-update payload, so the coordinator only ever saw None. The values are now carried on BlindPosition and forwarded in the payload, and are part of the position equality check so moving a valance while the awning stays put actually emits an update. (Fixes #4.)
v1.6.0: Position inversion, 2A sync, and valance sensors
✨ Features
Per-device position inversion (fixes #5)
New Display: position direction option in the options flow. For awnings (Markisen), invert the open/closed direction in Home Assistant display + commands. Default off.
Device type 0x2A sync (fixes #3)
Lamaxa slat-roof motor (0x2A) now properly recognized; no longer shows as 'unknown'.
Read-only valance position sensors (partial fix for #4)
Valance 1 and Valance 2 sensors now exposed as diagnostic read-only values (0–100%).
v1.5.0 — Lamellendach (slat-roof) support
Adds support for Warema Lamellendach (slat-roof) systems
(SlatRoofL60 / L70 / L70Tilting).
These use a dedicated radio motor (device type 2A / RADIO_MOTOR_L60_L70)
that was previously filtered out of device discovery, so the roof never
appeared as a selectable device. It is now recognised, mapped to the
awning cover device class with slat-tilt enabled.
v1.4.0 — Full motor-parameter configuration & diagnostics
v1.4.0 — Full motor-parameter configuration & diagnostics
✨ Added
- Full motor-parameter configuration. The Configure motor firmware parameters options flow now exposes all 17 writable block-38 parameters instead of the original 5 — comfort automatics, position/angle for the "Away" status, run times up/down, calibration up/down, tilting time, min/max slat angle, tilting steps, and motor-rotation reversal. Each field is pre-filled with the value currently stored in the motor; only changed fields are written.
- Firmware/hardware diagnostic sensors. Two read-only diagnostic entities are now created per blind: Software version and Device type (read from block 81), marked as
diagnostic. - Full English & German translations for all options-flow strings (labels + concise field descriptions, ZHA style).
- Copy parameters from another blind. Optional Load values from dropdown in the device picker — pre-fills the form with another configured blind's values. Handy for replicating a tuned setup across identical blinds.
🔧 Changed
- Redesigned the parameter form: input boxes instead of sliders (with %/s/° units), the 17 fields grouped into collapsible sections, and the redundant current-value table removed.
- Parameters are read up front with a loading indicator. After selecting the device, a short progress step reads the values over the radio network before the form opens. Submit now only writes — the old two-step copy flow is gone.
- Minimum Home Assistant version raised to 2024.6.0 (
hacs.json), required for the collapsible form sections.
🐛 Fixed
- Motor-parameter writes can no longer corrupt unrelated settings. Previously a full 496-byte snapshot of block 38 was committed atomically; a partial commit could overwrite unrelated bytes — most critically
motorRotation(block 38, addr 475), which inverts a blind's up/down direction. Writes are now targeted single-byte writes to the exact address of each changed field, with retry, no-op skipping, and read-back verification.
Full Changelog: v1.3.0...v1.4.0
v1.3.0
Per-device product-type detection (Block 37) and read/write of the persistent on-device motor parameters (Block 38). Maps each device to the right Home Assistant cover device class and enables slat tilt where applicable. See CHANGELOG.md for details.
v1.0.2
Fixed
Sensors and the moving binary_sensor now appear on first setup, not only after a later rescan. If no device is explicitly ticked in the setup wizard, all discovered blinds are added, so CONF_DEVICES is always populated and every platform creates its entities consistently.
Changed
Tilt controls are now only exposed for actuator types 20 (Actuator UP) and 2E (Actuator 230V UP), which drive slatted blinds (Raffstoren). Awnings and roller shutters on plug receivers (21) or radio motors (25) no longer show a meaningless tilt control.
v1.0.1
Fixed
- Background position queries (pos-update / watch-moving) now skip motors that already have a
pendingblindGetPosrequest (dedup guard). - An unreachable motor now costs ~1 s instead of ~3 s per cycle, so the 5 s poll cycle
stays ahead of the backlog even with one or two flaky motors. Working blinds keep
updating reliably. Explicit user commands (stop/move follow-ups) keep full retries.
Full Changelog: v1.0.0...v1.0.1