Suggesting a thicker frontend for getting status of machines

[hazlamshamin]

I honestly think the status of a machine is very important for writing an automated lab protocol. But currently in PLR, frontends for many machine types mainly support actuations but rarely state inspections, such as current temperature, lid status, tray status, etc. Thus, writing a protocol usually uses the machine backend instead of the frontend, thus weaker abstraction.

I am focusing here on machines that are plate holders because they are quite similar in their state space. Here is a summary of the current state, along with some suggestions:

PLR frontend	Current status getters	Suggested
Thermocycler	Extensive: lid open, lid/block status, current/target temperatures, hold time, cycle/step progress, is_profile_running()	Mostly sufficient; maybe consolidate into a normalized get_status().
PlateReader	None. get_plate() is logical resource custody, not hardware status.	Add get_status() with tray position, activity, and plate presence.
Imager	None. get_plate() is logical only.	Add get_status() with activity and readiness; no tray field for standalone imagers.
ImageReader	Inherits PlateReader + Imager, but still has no hardware status getters.	Compose reader tray/activity status with imager activity/readiness.
Sealer	Only get_temperature().	Add get_status() with shuttle position, activity, heater, material, and faults.

I understand that some machine types, such as sealers, have limited backends and could still be quite immature, so expanding the frontend may be premature. But machines like plate readers, I believe, should now support a thicker frontend for retrieving hardware status.

May I know if this is already planned? If not, I'd be happy to work on a limited set and open a PR.