v0.2.0 — services and view ID

Reaches the parts of the recovered BLE protocol that no entity could express.

What is new

Two services. The entity platforms could not carry everything the protocol
supports, so rather than invent an entity per token there are now two services,
both targeting a specific window so a household with several is unambiguous.

• atmoph_window.send_command sends any one of the 15 implemented control
  tokens. This is how double_tap and search are reached — they have no
  button, because a double tap and a jump to the search screen depend on what
  the window is already showing, and search leads to a text field this
  integration deliberately cannot fill.
• atmoph_window.set_setting writes any one of the nine quick-menu settings,
  including SoundscapeLayer and CurrentDecoration, which have no entity
  because they are catalogue indexes rather than magnitudes and a slider would
  misrepresent them.

Both validate against the protocol module rather than trusting the service
schema, so a YAML automation cannot push an unverified token or key at the
window; either raises a readable error instead. set_setting checks a level
against the bounds the window itself reported, never a hardcoded range.

A view-ID sensor. A diagnostic sensor carrying the Atmoph catalogue id of
the view on screen, with the render revision as an attribute. View titles repeat
across the catalogue and change with the app's language, so they are unreliable
to match on in an automation; the id is not.

What is verified and what is not

This project labels every protocol claim by evidence tier, and these two
features sit in different tiers.

Capability	Evidence
send_command tokens	App-verified. Every token comes from the ControlCommand enum in our own decompilation of Atmoph app 2.3.4. S, FW, BW, and C are additionally confirmed from live BLE traffic on Atmoph hardware.
set_setting keys and the bare-value write format	App-verified. Both come from QuickMenuSetting and the app's own write path.
Per-device bounds on a level	Reported. That real bounds run wider than 0–10 is a third-party hardware observation, which is exactly why the integration reads them from the device instead of assuming.
The view-ID sensor	Unverified third-party observation. It may not work on your window.

On that last row, plainly: the characteristic 03cffbfe-… is declared in the
app but the app never binds it, so our decompilation says nothing about how a
window responds to a read. The claims that a window answers at all, and that
the value is <view-id>/<revision>, come from a third party working on a
Window Yo — not a Window 2, and not confirmed by us.

So it is built to cost nothing when wrong. The subscription may be refused, the
read may fail, and the first failure stops the client asking again for that
connection. A window that does not implement it simply gets no view-ID sensor
rather than one stuck unavailable, and setup, polling, and the existing
current_view sensor are unaffected either way. If the entity does not appear
after upgrading, your window does not expose the characteristic.

Nothing in this release has been checked against an Atmoph Window 2 (AW102) by
this project. See #5 for the hardware validation checklist and #14 for what
specifically needs measuring on the view-ID characteristic.

Also worth knowing

set_setting refuses a key the window has not reported yet, because the write
format gives no way to tell a boolean from a level and writing the wrong type
to this device is worse than declining. In practice the window reports all nine
on connect. Tracked in #15.

Not implemented and deliberately so: text entry, which needs an AES key
hardcoded in the Atmoph APK that this repository will not publish; and zoom,
which maps poorly onto any Home Assistant entity.

Install: HACS installs from the atmoph_window.zip asset below.

Full protocol notes: docs/PROTOCOL.md