The alarm and the light have separate executors

A connected morning involves two systems: iOS schedules the alarm while Home Assistant can execute a light session it has already received. The transmitted time connects them. The server does not independently know whether the iPhone has actually started ringing.

That matters when you postpone an alarm, skip an occurrence or lose connectivity. A change is effective for the light only after the server confirms it.

A ramp adapted to the light

Some lights implement native transitions. For brightness-capable lights without that feature, LorisIoT Schedule can use explicitly enabled steps. A session associates ramp start, wake time and a planned off time after the selected delay.

Component 0.3.2 includes the fixes in this series for adapters that round brightness to integer percentages and for identical state reports that could interrupt automatic off. The latest fix passes 51 local integration tests. This does not replace a complete test with each light model.

Automatic off needs consistent tracking

Successful on is not enough to confirm what follows. The server keeps a receipt and checks that it still owns the session. An explicit command, loss of tracking or restart during the session can prevent planned off. An identical passive report should not be mistaken for an intervention; that is the case fixed in 0.3.2.

Closing an app or interrupting a computer test does not cancel a schedule already accepted by Home Assistant. Cancellation must be confirmed by the server.

Set it up with clear expectations

The Home Assistant guide covers connection, the component, steps, alarm changes and troubleshooting. It documents compatible versions; check your Velya release notes before looking for an option.

Examples are fictional. Your addresses and tokens belong in your own configuration; this guide never needs access to your home.