Sensor on off

[3ldcm]

Describe the bug

I have 3 diffusers connected with AromaLink: 2 × A7 and 1 × A5.

When I turn a diffuser Off from Home Assistant, the diffuser correctly powers off.

However, after approximately 60 seconds, the On/Off sensor changes back to On, even though the diffuser itself is still powered off.

This happens with the latest versions of Home Assistant and ha_aromalink.

Steps to reproduce

1. Turn a diffuser On.
2. Turn it Off from Home Assistant.
3. Wait about 60 seconds.
4. The On/Off sensor changes back to On.
5. The physical diffuser remains Off.

Expected behavior

The On/Off sensor should remain Off until the diffuser is actually turned back on.

Actual behavior

The diffuser stays Off, but the Home Assistant On/Off sensor incorrectly changes back to On after about 60 seconds.

Environment

• Home Assistant: latest version
• ha_aromalink: latest version
• Diffusers:
  • 2 × A7
  • 1 × A5

I can provide debug logs if needed.

[dalyem]

Root cause found, and fix is up in #36.

The Aroma-Link list endpoints (what this integration polls) serve a device-pushed snapshot that regularly predates a just-sent switch command — the device takes 15–20s to acknowledge a command server-side, and an idle (off) device can go a long time without pushing fresh state. The integration only shielded a fresh command from polls for 8–15 seconds, so the first scheduled poll (default: 60s — matching the ~60s you observed) reinstated the server's stale pre-command "on" state while your diffuser was really off.

#36 makes the coordinator only trust a poll that contradicts your last command when the server's own snapshot timestamp (statisticsUpdateTime) proves it was taken after that command — so genuine changes (e.g. turning a diffuser on from the app) still come through immediately, while provably-stale echoes are ignored (with 30-min/180s caps as backstops).

One related note: if you've ever pressed Run Once (or Save Settings), the integration also left a 24/7 schedule armed on the device itself, which can genuinely re-activate it — that's issue #31, fixed separately in #35. The two fixes together should make on/off state solid.