Improve Remote Instance Status for long-gone / offline devices

[Steve-Mcl]

Description

As discussed in Eng meeting devices "last seen" long ago but still displaying "runing" state is misleading - and - problematic for Insights MCP Feature enumeration - likely related to timeouts raised in https://github.com/FlowFuse/engineering/issues/161

My proposal offered was:

1. On a schedule (1 hour? 1 day?) we update any device reporting "online" to have the state "offline"
2. Change the column header to simply Status (the "Last Seen" provides sufficient context e.g. how long ago)

The reasoning behind chosing "offline" as the fall back state was that effectively, if a device has not been seen for x amount of time, it is in effect offline!

This is open to discussion - but I would like to get consensus sooner rather than later to improve the Expert Insights situation - for that reason I am adding it to this milestone TODO

Epic/Story

No response

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[andypalmi]

On a schedule (1 hour? 1 day?) we update any device reporting "online" to have the state "offline"

I agree with rendering as "Offline" after 1 day.
Should we let the user customise the time after which a device is offline (1h, 6h, 12h, 24h, etc) ?

Change the column header to simply Status (the "Last Seen" provides sufficient context e.g. how long ago)

Thumbs up!

[knolleary]

The reason was labelled it last known status was because that's what it is - the last status we knew for a fact. To change that to offline means the user no-longer knows what status was reported the last time it checked in.

What if we were to introduce a new property called WE_CAN_BIKE_SHED_THIS_LATER that is about online/offline state. On the backend, its a computed property (rather than needing to be in the database) that is simple toggled by 'is last seen > 1 hour' (or whatever time we deem the threshold). In fact, it could have three states - 'never seen', online, offline - all based on the last seen time.

We can then modify the appearance of the last known status pill to a neutral colour if this new flag is 'offline'. I'd also bring the "last seen" and "last known status" columns together in someway - right now we have 'developerMode' sat in between them for some reason. That would, for me, solve the visual issues I have.

Would that satisfy the MCP tooling requirement?

[cstns]

Why not add a new unreachable status that is computed like you proposed, if the device was last seen in X time? We could also provide the last known status when the pill is hovered.

Ditching the last known status column is the best course of action; it just adds an additional layer of confusion for users.

[Steve-Mcl]

@knolleary

Agree with the lastSeen and state being "together" (that bugged me too)

Would that satisfy the MCP tooling requirement?

I initially needed a change of actual database state (e.g. not "running") so I can skip even attempting to enumerate the tools on an offline device.
However a computed property will work too. Nice catch.

So, to clarify, we should:

• Keep state field value as the last known reported state (e.g. running) rather than mutating it to offline.
• Introduce a computed online/offline property (name TBD) derived from lastSeen.
• Have the MCP Tool Listing routine use that computed property to decide whether to skip enumerating tools on a device.
• Tidy up the UI by grouping lastSeen and state together, with the offline visual treatment based on the computed property rather than changing the reported state.

@cstns

Why not add a new unreachable status that is computed like you proposed, if the device was last seen in X time? We could also provide the last known status when the pill is hovered.

I am not adverse to that.

Ditching the last known status column is the best course of action; it just adds an additional layer of confusion for users.

Getting strong consensus on a single column state here. I can have a bash at what that means but would happily accept a set of rules too.

[Steve-Mcl]

@knolleary @cstns

From the discussion so far, I think there are two slightly different proposals emerging:

Option 1 – Keep "Last Known Status" column name, show actual DB state & use age for colour

• Keep the existing state value as the last reported state from the device (e.g. running).
• Introduce a computed online/offline flag derived from lastSeen.
• Display the existing Last Known Status column, but use the computed flag to adjust its appearance (e.g. neutral/grey when offline).
• The MCP Tool Listing routine uses the computed online/offline flag to determine whether to attempt tool enumeration.

Option 2 – Rename column as "State" and use new computed text

• Show the computed display state (e.g. running, unreachable , etc)
• Rename Last Known Status as State column.
• When a device is offline, the state reflects that (e.g. Offline), with a tooltip/popover showing the last known state and when it was last seen (e.g. "Last seen 2h ago, last reported state: Running").
• The MCP Tool Listing routine uses the same computed online/offline state to determine whether to attempt tool enumeration.

Common

• Both solutions remove the extra column (only one "State" or "Last know state") column

Personally, I don't mind either approach. Can I get consensus tho?

[knolleary]

Option This One

• Add a status computed property that is not-seen, online, offline based on the last seen time

Get that bit done and your MCP work is unblocked and we can handle how to improve the visual display of that separately without blocking the MCP work.

[dimitrieh]

@Steve-Mcl I added this as a child to #7668 if that makes sense