ESPSomfy-RTS/test/e2e/README.md
cjkas 5737a58790 fix: command op replies that said ok when nothing was done
From the review of #100:
- setMyPosition on a moving shade replies busy ("The shade is moving"),
  and setPositions with only a tilt, for a shade without one, replies
  bad request ("The shade has no tilt"). Both said ok before.
- PROTOCOL.md lists where the ops differ from the routes, and how
  sendRemoteCommand is answered.
- The LoopQueue hold comment covers protocol 2 replies and an unpair
  held through a frequency scan.
- One shadeRequestIsForGroup() for the group cases; ProtoOps shares one
  reader for "one or both" fields and one for ids, and the radio
  refused text.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-24 13:46:00 +02:00

1.2 KiB

e2e suite

Runs against a real device on your network, by hand, never in CI. It checks socket protocol 2 (PROTOCOL.md) and that the device survives the loads that used to run its heap out.

~/.platformio/penv/Scripts/uv run --no-project --with pytest -- pytest test/e2e --device 192.168.1.120
Option Use
--device the device's address (required)
--password, --username / --pin the credentials of a Secured device
--radio --shade <id> also send real commands: that shade moves a little and back
--record save hello, the sync and the schema to test/fixtures/proto2/, for the web UI and Home Assistant tests

A plain run sends nothing on air, changes no settings and doesn't reboot the device. The command tests send ops that are refused before they reach the radio, and one setPositions that sets a shade to the position the sync gave: that drops the fraction of a percent the shade's believed position may have had. It does fill every socket slot for a few seconds, and replays a page load.

The tests run in whatever security mode the device is in; the suite never changes it. To test both modes, run the suite once in each.