DiamondLightSource / DiamondLightSource/blueapi

BlueapiClient devices do not know about child devices until after user uses them

Open
#1,671 0 comments 0 reactions 0 assignees View on GitHub
bug c: client enhancement
Dominant language
Python
Stars
13
Forks
13
Avg merge
2d 11h
Merged PRs (30d)
25

Description

`BlueapiClient` asks blueapi server for all available devices and then caches them. This makes it so autocomplete now works on the terminal making it very handy when composing plans on command line. However, blueapi cannot handle child devices.

Very often, a device will hold a group of other devices / signals and need to be accessed to run plans. For example `Motor` stages will have x, y, z motor components. pgm devices have child signals/motors for energy.

So a very basic example would be

```python
plans.set_absolute(pgm.energy, 500)
plans.set_absolute(stage.x, 10)
plans.set_absolute(stage.y, 20)
```
`BlueapiClient` has no idea these child devices of energy, x, and y exist so the user has to guess what is available.

How it works is if it doesn't exist from the cache, the device is requested from the server and then if it exists, it is then added to cache and then autocomplete now works. However, when loading devices, `BlueapiClient` should be aware of all devices on the server, including all child devices of a `Device`, so that automcomplete will work straight away rather than guessing first for all devices.

This is related to https://github.com/DiamondLightSource/dodal/issues/2208 because `DeviceManager` only provides the higher level devices to blueapi and not the device children so it has not concept of the child devices unless asked explicitly to check for it.

This would vastly improve the user experience using the client if you could print the device tree or the device `__repr__` to show it (similiar to a plan `__repr__ ` displays the plan signature) to know what is available to work with and that auto complete for child devices works from the start.

As we are going to have name clashes with device attributes and what blueapi needs, we should probably reserve in dodal device attributes so that they never have a `model` signal / sub device. Similar to how ophyd-async reserves bluesky key words. This could be done inside `DeviceManager`. When it loads in a device, it checks there are no signals / child devices with `model` as an attribute.

Contributor guide

Open the contributing guide

Research direction

Start with the BlueapiClient device-loading and cache path described in the issue, then trace how DeviceManager supplies devices and child devices. Clarify whether the scope includes a device tree or __repr__ and reserved attributes. Done should mean child devices are available to autocomplete immediately after loading, without a prior lookup.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api, cli, developer-experience
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.