Ophyd devices do not comply to the protocols defined in bluesky

[DiamondJoseph]

Ophyd's documentation claims that Ophyd "[puts] the details specific to a device or control system behind a high-level interface with methods like trigger(), read(), and set(...)", however many of the devices in Ophyd do not comply to the protocols defined in bluesky. Ophyd does not explicitly depend on bluesky, but it does have tests to ensure that some simulated devices do comply to the protocols.

The addition of type hints to the plans and stubs in the bluesky library, with type checking enabled, is now causing issue with type checking (but not using the stubs) when used with Ophyd devices.

Either Ophyd devices should be modified to comply with the protocols, or the protocols should be amended to match the usage in ophyd and ophyd-async.

I will attach a minimum set of device classes later.

[tacaswell]

Historically ophyd has been the ground truth of the protocol and we wrote what is in bluesky against it. Depending on what the differences are my first reaction would be that bluesky is where the bug is not ophyd.