v0.5.8

Fixed

Gen2 dual-cover devices controlled the wrong channel (#3)

On Gen2 dual-cover devices (e.g. Shelly Pro Dual Cover PM, SPSH-002PE16EU) both Home Assistant cover entities drove cover 0 — moving one entity moved the wrong shutter.

The command path used a legacy cloud roller endpoint that predates Gen1 single-cover devices and has no per-channel selector, so every command landed on cover 0. Gen2 covers now route through the modern v2 cloud endpoint (/v2/devices/api/set/cover), which addresses each cover by a real channel. Open/close/stop and set-position now target the correct physical cover. Gen1 devices are unchanged.

Confirmed working on real hardware by @superarturo15 — thank you!

---

This release was validated as v0.5.8-beta1 before promotion.

v0.5.8-beta1 (beta)

Beta — fixes #3: on Gen2 multi-cover devices (e.g. Shelly Pro Dual Cover PM, SPSH-002PE16EU) both cover entities controlled only the first physical cover.

What changed

• Gen2 covers are now controlled through the v2 cloud endpoint /v2/devices/api/set/cover, which honors a real channel field. Each cover entity now drives its own physical cover.
• Gen1 rollers are unchanged (no regression).
• Fixed cover position control, which previously did not work.

How to test

1. In HACS, open Shelly Cloud DIY → three-dot menu → enable Show beta versions.
2. Update to 0.5.8-beta1, then restart Home Assistant.
3. Confirm each of your two cover entities moves its own cover independently (open/close/stop and set-position).

Please report back on #3 — once confirmed I will promote this to a stable release.

v0.5.7

Docs + packaging only — no functional change to the integration.

• docs: corrected the "Help the project" section. Home Assistant no longer lists newly-added custom integrations in its public per-integration analytics (brands-registry policy change in HA 2026.3), so the earlier promise that this integration would appear there by name was inaccurate. The section now gives an honest picture (a ⭐ is the clearest signal). EN + DE.
• packaging: releases now ship a HACS-installable shelly_cloud_diy.zip asset, enabling a cumulative download counter. No action needed on your side — HACS keeps working as before.

v0.5.6 — Updating guidance (docs)

Docs-only release (no code changes vs v0.5.5).

Adds an Updating section to the README (English + German): after a HACS update, redownload → restart Home Assistant, because new release entities only appear after the restart. A missing entity right after an update is almost always "updated in HACS, but HA not restarted yet" rather than a bug.

Shipped as its own release so the guidance shows up in the HACS-rendered README of the installed tag.

v0.5.5 — BLU Motion + Plus Uni voltmeter

Two new sensor mappings for previously unsupported readings.

Added

• Shelly BLU Motion (SBMO-003Z, gateway-bridged): the gateway-reported motion:0 key now creates a motion binary_sensor (device_class: motion). Validated against 21 live BLU Motion devices. (#1)
• Shelly Plus Uni / Plus Add-on analog input: the Gen2 RPC voltmeter:<id> component now creates a voltage sensor from its voltage field (device_class: voltage, V). (#2)

Illuminance and battery on BLU Motion, and the Add-on's DS18B20 temperature channels, were already supported and are unchanged.

Notes

Both changes are purely additive — a device that reports none of these components gets no new entity, so existing setups are unaffected. After updating, reload the integration if the new entities don't appear immediately.

v0.5.4 — transparent brand icon

Fixes the integration brand icon so it renders cleanly (no white box) on Home Assistant's dark theme.

What changed

• brand/icon.png (256²) and brand/icon@2x.png (512²) are now RGBA with a transparent background (the previous icons were RGB with a baked-in white background). The README icon was refreshed too.
• These local brand/ images are the supported path since Home Assistant 2026.3 (served via /api/brands/integration/shelly_cloud_diy/…); the old home-assistant/brands repo no longer accepts custom-integration icons.

To see it: update to v0.5.4 in HACS, then hard-refresh the browser (Ctrl+Shift+R) to clear the cached brand image. The icon appears on the integration's page under Settings → Devices & Services.

No functional code changes.

v0.5.3 — roadmap: upstream HA Core PR submitted

Docs-only release.

The native device-replacement repair (Phase 2 "giving back") has been submitted upstream to Home Assistant Core: home-assistant/core#174581 — an ESPHome-style device_conflict repair that lets you replace a dead Shelly with a new unit (different MAC) while preserving entity IDs, history and every automation/dashboard reference.

The READMEs (EN + DE) and docs/FEATURE-HIGHLIGHTS roadmap now reflect this (submitted-for-review, with link); the Phase 2 marker moved to in progress.

No code changes; integration behaviour is identical to v0.5.2.

v0.5.2 — shared weather-station screenshot

Docs release. Adds the privacy-redacted ECOWITT WS90 dashboard screenshot to the "concrete example: a shared weather station" section of both READMEs (EN + DE).

This illustrates the integration's shared-device USP: a weather station paired to someone else's Shelly account, shared into yours, surfaced as native Home Assistant sensor entities via the self-service Cloud Control API — something a LAN-only integration structurally cannot reach.

No code changes; integration behaviour is identical to v0.5.1.

v0.5.1 — self-service, no gatekeeping

Docs-only release. No code changes vs v0.5.0.

Foregrounds a key advantage of this integration: self-service authentication. You set it up yourself in about two minutes with an auth_key you generate in the Shelly app (OAuth is the Milestone 2 path) — no application, no approval queue, no waiting on a vendor's "yes".

The README (EN + DE) now explains why that matters versus the gated Integrator API route, where private users must apply and depend on Shelly's goodwill ("licenses for personal use are not provided") and may simply be refused. Stated factually; the engesin project is fine, it just uses a gated auth path that isn't open to private users.

🤖 Generated with Claude Code

v0.5.0 — Fleet-Map device overlay

First stable release of the device-swap overlay. A read-only layer that connects your Shelly Cloud devices to their local Home Assistant twins.

✨ Fleet-Map

A new action Shelly Cloud DIY: Fleet map (read-only by default) that, for every device in your Shelly account:

• Matches it to its local HA twin by MAC — both Wi-Fi Shellys (native shelly integration) and Bluetooth/BLU sensors (e.g. bthome). BLU devices are matched by decoding the cloud's XB id back to the BLE MAC.
• Includes offline devices and marks them [OFFLINE] — important, since a device you want to replace is usually offline.
• Suggests names (cloud alias → local device) you can optionally apply. The apply touches only the device's technical name, never name_by_user, never entity IDs — so automations and Node-RED are unaffected.
• Flags control-path risks — devices controllable only via the cloud, or where an automation drives the cloud entity despite a local twin existing.
• Plus machine-readable diagnostics (MACs fingerprinted, names redacted).

🔧 Replace device (opt-in, preview first)

Shelly Cloud DIY: Replace device transplants a dead Shelly's Home Assistant identity (entity IDs, device, name, area, history, automation references) onto a new unit of the same model, so you don't reconfigure HA after a hardware swap. Cloud devices supported now; native local Shelly + an upstream HA Core contribution are planned. Run it with Dry run on first.

🧭 Local-first

The cloud is never in the control path — this is an overlay over your fast, offline-resilient native shelly integration. Validated on a live 60+ device fleet.

See the README for details and the roadmap (Milestone 2: OAuth + WebSocket realtime).

🤖 Generated with Claude Code