Read hardware on every read of the aperture scatterguard

[DominicOram]

Fixes #782

Instructions to reviewer on how to test:

1. Confirm tests now all pass
2. Confirm docs make sense

Checks for reviewer

• Would the PR title make sense to a scientist on a set of release notes
• If a new device has been added does it follow the standards
• If changing the API for a pre-existing device, ensure that any beamlines using this device have updated their Bluesky plans accordingly
• Have the connection tests for the relevant beamline(s) been run via dodal connect ${BEAMLINE}

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.92%. Comparing base (3f59ce0) to head (de0489a).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #789      +/-   ##
==========================================
+ Coverage   94.91%   94.92%   +0.01%     
==========================================
  Files         115      116       +1     
  Lines        4677     4693      +16     
==========================================
+ Hits         4439     4455      +16     
  Misses        238      238              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[coretl]

This is better than what was there originally, but I'm concerned that you don't override subscribe so you have a Signal where get_value gives you an enum, but subscribe gives you a float.

I wonder if there is a case for supplying both a forward and inverse transform, that operate on values rather than Signals, and making a DerivedSignalBackend that applies the transforms on get, put and subscribe?

[DominicOram]

This is better than what was there originally, but I'm concerned that you don't override subscribe so you have a Signal where get_value gives you an enum, but subscribe gives you a float.

Yh, I agree but this is going to be hard. I guess the correct solution is to subscribe to all the signals you derive from then recalculate the derivation and push an update when any of them change.

I wonder if there is a case for supplying both a forward and inverse transform, that operate on values rather than Signals, and making a DerivedSignalBackend that applies the transforms on get, put and subscribe?

Yep, I think we will need these in the generic case.

Can we push the full solution to bluesky/ophyd-async#525 and treat this as a first pass example of how you could do it but with it's limitations? I would be happy to help contribute to the full solution but given it's a reasonably large feature, with quite a few stakeholders it will take a while and I would rather not have this bug in hyperion in the mean time.

[coretl]

Can we push the full solution to bluesky/ophyd-async#525 and treat this as a first pass example of how you could do it but with it's limitations? I would be happy to help contribute to the full solution but given it's a reasonably large feature, with quite a few stakeholders it will take a while and I would rather not have this bug in hyperion in the mean time.

Sounds good to me, could we have a comment to this effect in the code please?