Closed joeyphant closed 4 years ago
Hi @joeyphant,
I like that idea. Is the message itself in a state
or would it be a cause
or trigger
? I understand that a state that is reported appears and disapears (binary). If we use an enum, how do we come to a complete list? E.g. wouldn't we than also have to discuss many other options like ABORTED
, REVIVED
, REJECTED
...
Hi @ameinhardt,
I would say the message itself is in a state
and has different transitions from one state to another. So a state only disappears if another state is set.
While you are right about the discussion on other options, I am not sure what the alternative to an enum would be. Using a string field? Should we not rather start with a first set of options and extend that in the future if additional options are required/requested by someone?
Hi @joeyphant , @ameinhardt , for me it would be sufficient to have to START/STOP or ON/OFF information as @ameinhardt mentioned by the binary option. There will be also other states depending on individual use cases and manufacturing types, but covering them all won't be possible. So let us start with the binary version (e.g. START/STOP)
@muelsen: state already has a meaning. I would prefer to coin a different key for this attribute like cause
, trigger
or side
. What do you think?
@ameinhardt , @muelsen : we had a very similar discussion internally before actually making this request. While a binary "start/stop" option would be enough for our current usecase, we did not want to limit others (and ourselves) to only use those two options.
A binary option could still be introduced following my original request (only allowing NEW
and CONFIRMED
), but would still allow us to extend it later.
@ameinhardt , I thought state is only OK, WARN, INFO, ERROR or UNKNOWN, not? @joeyphant , NEW would be also OK from my side, but with CONFIRMED I assume an action (e.g. by the operator). In some case maybe there is not action, just end of the failure. Is there maybe a synonym for this?
OK, WARN, INFO, ERROR and UNKNOWN are possible states of the device (device.state with enum type DeviceState). I don't think we should use a different word if we want to describe the state of a message.
Possible synonym for CONFIRMED: ENDED, FINISHED
Hi @joeyphant, I would like that there is no synonyms but well-defined states. Can you propose a finite-state machine for messages with clearly defnined names and description?
@ameinhardt, Considering my initial idea, your input and @muelsen doubt about the word "confirmed" I would recommend the following states:
Name | Description |
---|---|
NEW | Indicates a new occurrence of this message (e.g. the error is active) |
ENDED | Indicates that the message was confirmed/resolved by an operator or "just ended" without an explicit action by an operator (e.g. the error is inactive) |
Transitions are only allowed from NEW to ENDED and from ENDED to NEW. This also covers the binary usecase mentioned by @muelsen and can still be extended by additional intermediate states.
hi @joeyphant, I added your suggestion in the schema. Thanks for the patience
An additional field should be added to determine the state of each individual message in the payload.
suggested name:
state
suggested type:enumeration
suggested values:NEW
,ACKNOWLEDGED
,CONFIRMED
Especially when talking about machine errors different states are required: