0008510: Clarify when to generate an event notification on a condition change - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0008510	10000-009: Alarms and Conditions	Spec	public	2022-12-06 13:04	2023-09-05 15:53

Reporter	Peter Wehrfritz	Assigned To	Paul Hunkar
Priority	normal	Severity	tweak	Reproducibility	have not tried
Status	closed	Resolution	fixed
Product Version	1.05.02 RC1
Fixed in Version	1.05.02 RC1

Summary	0008510: Clarify when to generate an event notification on a condition change
Description	Part 9 is ambiguous or self-contradictory in the point when a sever is supposed to send an event on changes to a condition. What seems to be clear is that no events are send as long as the condition is disabled, as stated in 4.2: "A transition into the Disabled state results in a Condition Event however no subsequent Event Notifications are generated until the Condition returns to the Enabled state.". That seems to be sensible, because usually all other states are substates of the enabled state. Besides that there seems to be no other restriction, see for example in 4.6 "Comment, severity and quality are important elements of Conditions and any change to them will cause Event Notifications." or similar in 5.5.2 "When enabled, changes to the following Variables shall cause a ConditionType Event Notification: Quality, Severity (...), Comment". In the example B.1.4 from step 4 to 5 the EventId changes (so I assume an event was raised) although the retain bit was false in both steps. But there is one sentence in 5.5.2 stating: "Events are only generated for Conditions that have their Retain field set to True and for the initial transition of the Retain field from True to False." This sentence forms a complete paragraph. There is also no additional context that restricts the formulation to a particular case. And similar also in 5.5.2: "When the Condition instance enters the enabled state, the Condition shall be evaluated and all of its Properties updated to reflect the current values. If this evaluation causes the Retain Property to transition to True for any ConditionBranch, then an Event Notification shall be generated for that ConditionBranch." Or in other words no event should be generated if the retain property is false. So I wonder if one should only consider the enabled state or also the retain property.
Tags	No tags attached.

Commit Version	1.05.03
Fix Due Date	2023-08-15

Paul Hunkar 2022-12-09 07:04 developer ~0018284	I think you missed this at the end of 5.5.2 "This may not be the complete list. Subtypes of ConditionType may define additional Variables that trigger Event Notifications. In general, changes to Variables of the types TwoStateVariableType, ConditionVariableType, StateMachineType or any of their subtypes trigger Event Notifications and are not explicitly described in subtypes." Also you need to look at the context of the statement - some of the statements are out of context. I think you are mixing two items - when a server generates an event and when notification is sent to a client (client asks for the event). The key point is that events are generated on all state changes (TwoStateVariableType & StateMachineType) and changes to ConditionvariableType variables. There is additional text describing when they are sent to a client. they may not all be shipped to a client since a client does provide a filter. The retain flag is the server telling the client what alarms need to be displayed.

Peter Wehrfritz 2022-12-09 08:35 reporter ~0018285	I have read this line and I think I also understand it. My main question is: will changes to those additional variables generate events even if the retain property is false?

Paul Hunkar 2022-12-21 07:55 developer ~0018331	The retain property is not about generating an event - it is about sending the event to the client. So a client will not see an event if the retain property is false (say an alarm is not active and does not need acknowledgement or confirmation, thus it has a retain property of false. If the shelved state changes, a new event would be generate, but since the client filter is looking for active alarms (retain is false for this alarm since it is not active), not event will be sent to the client.

Matthias Damm 2022-12-22 10:48 developer ~0018335	Hi Paul, I asked Peter to enter this issue. I do not agree that retain is about sending an event. If retain is changed to false there will be an event to the client. What a client is doing with the event if retain is false (what you call 'see an event') is a different questions. I was not able to give clear guidance with what is currently in the spec.

Paul Hunkar 2023-08-15 05:14 developer ~0019868	most changes already applied for RC - discovered on minor update that could be helpful

Jim Luth 2023-09-05 15:53 administrator ~0019962	Agreed to changes in Web Meeting.

Date Modified	Username	Field	Change
2022-12-06 13:04	Peter Wehrfritz	New Issue
2022-12-09 07:04	Paul Hunkar	Note Added: 0018284
2022-12-09 08:35	Peter Wehrfritz	Note Added: 0018285
2022-12-21 07:55	Paul Hunkar	Note Added: 0018331
2022-12-22 10:48	Matthias Damm	Note Added: 0018335
2023-04-18 17:01	Jim Luth	Assigned To	=> Paul Hunkar
2023-04-18 17:01	Jim Luth	Status	new => assigned
2023-08-01 17:04	Jim Luth	Fix Due Date	=> 2023-08-15
2023-08-15 05:14	Paul Hunkar	Status	assigned => resolved
2023-08-15 05:14	Paul Hunkar	Resolution	open => fixed
2023-08-15 05:14	Paul Hunkar	Fixed in Version	=> 1.05.02 RC1
2023-08-15 05:14	Paul Hunkar	Note Added: 0019868
2023-09-05 15:53	Jim Luth	Status	resolved => closed
2023-09-05 15:53	Jim Luth	Commit Version	=> 1.05.03
2023-09-05 15:53	Jim Luth	Note Added: 0019962