Simplifying the lightpath device interface

[tangkong]

Context

The current lightpath device API is somewhat unwieldily and difficult to maintain. There are possibly many methods/properties to keep track of.

Subscriptions also probably need to be looked at. Subscribing to state is possibly a bit overkill.

This definitely warrants discussion before action

#106

Ideas / Approaches

• A singular function that returns a dataclass?
• Instantiating the whole device is a bit overkill, can we only subscribe to the relevant signals?

[ZLLentz]

One approach could be to:

• Add a singular API function that is expected returns a dataclass (transmission, inserted, removed, others?)
• Provide some mix-in code that subscribes to signals, runs this function when they update, and stashes the value in a standard signal that can be subscribed to. We could make this only start the underlying EPICS subs once the lightpath signal gets a subscription request so non-lightpath entities could ignore this entirely.

Advantages:

• We can decide in the various applications whether we want to poll via calling the function or sub via the standard signal.
• In the device definition it's very clear where the lightpath logic is defined and how to modify it.
• It should be pretty easy to test the lightpath logic without doing a full import of lightpath's internals or messing with subscriptions, just make sure your own lightpath function returns a reasonable value for all potential inputs.

Mock-up of one way this could look like:

from lightpath import LightpathMixin, LightpathState

class MyClass(LightpathMixin, Device):
    state = Cpt(EpicsSignal, ':STATE')
    is_open = Cpt(EpicsSignal, ':OPEN')

    @staticmethod
    def lightpath_logic(state: str, is_open: bool) -> LightpathState:
        inserted = state == 'INSERTED'
        removed = state == 'REMOVED'
        if inserted and not is_open:
            transmission = 0
        else:
            transmission = 1
        return LightpathState(
            inserted=inserted,
            removed=removed,
            transmission=transmission,
        )

Using a staticmethod isn't necessary but it leaves the door open for "partial loading" ideas

[tangkong]

I've come to the conclusion that this is probably the way to proceed. I've started hashing out the general idea, but I'll leave some thoughts/caveats below.

• Grouping things into a subclass of AggregateSignal seemed appropriate, but MultiDerivedSignal seemed like too much.
• This schema would require branching devices to report their destination, as inserted/removed/transmission is not enough to describe the system. The result of this is that devices will need one extra layer of specificity in pcdsdevices. In other words, each device will require their own class.