You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's important to know what state Components are in, e.g. for error handling & recorvery, communication speed back-off, enable "state" handling, information, etc.
I think we should first collect Status/error states that we want do specify for Components (all_good, connection_congested, connection_dead, device_errored,...). This is also something that could be returned on receiving a STATUS request.
Then, we should decide how to represent them (a status and an error registry (cf. SCPI)? both fused into one? Bitmask/enum to represent them efficiently?)
Then, we should discuss how much of the behaviour in the different states and the ways to transition between them we prescribe (the "Status" state machine), and howm uch we leave to implementations.
It's important to know what state Components are in, e.g. for error handling & recorvery, communication speed back-off, enable "state" handling, information, etc.
I think we should first collect Status/error states that we want do specify for Components (
all_good
,connection_congested
,connection_dead
,device_errored
,...). This is also something that could be returned on receiving aSTATUS
request.Then, we should decide how to represent them (a status and an error registry (cf. SCPI)? both fused into one? Bitmask/enum to represent them efficiently?)
Then, we should discuss how much of the behaviour in the different states and the ways to transition between them we prescribe (the "Status" state machine), and howm uch we leave to implementations.
Originally posted by @bilderbuchi in #4 (comment)
The text was updated successfully, but these errors were encountered: