Duplication of PV writes seen by camonitor

[cjtitus]

Short Description

I am building a caproto IOC that monitors an external PV, collects its values, and then outputs statistics, every 10 seconds. I have three pvproperty attributes that I am trying to write to -- mean, std, and npts.

When I do camonitor myioc:mean I see that the value is re-broadcast whenever any pvproperty in the caproto IOC is written to. In particular, it is tripled, as it is broadcast whenever std and npts are written, as well as when mean is written.

An example of monitor output is 
averager:mean                  2022-11-04 18:22:36.944039 1.1794e-12  
averager:mean                  2022-11-04 18:22:36.944039 1.1794e-12  
averager:mean                  2022-11-04 18:22:36.944039 1.1794e-12  
averager:mean                  2022-11-04 18:22:47.944145 1.18262e-12  
averager:mean                  2022-11-04 18:22:47.944145 1.18262e-12  
averager:mean                  2022-11-04 18:22:47.944145 1.18262e-12  

You can see that it gets tripled.

A complete version of this IOC is available https://gist.github.com/cjtitus/83235e4aa3441c7d417955ace1f37766
It's got my beamline's PV hardcoded into the __main__ method, but it should be trivial to run it to point at any PV you have access to in order to test this.

I am on caproto 0.8.1, but should be easy enough for someone to check if it happens on v1.0.0

[tacaswell]

Just to confirm, you commented out the other two stats and the behavior went away?

My concern is that because you are setting the value the alarm state I wonder if we are not correctly de-bouncing something and the 2 extra messages are from that (not the other two PVs)?

[cjtitus]

Yes, if you comment out writes one by one, you get successively less duplication. I copied most of this from the mirror ioc example so I haven't thought about the alarm states at all. Would be good to try to cut that out and see if it goes away. I don't know if I mentioned that the duplication is visible for every PV you monitor, not just the first one.

…

On Sun, Nov 6, 2022, 00:42 Thomas A Caswell ***@***.***> wrote: Just to confirm, you commented out the other two stats and the behavior went away? My concern is that because you are setting the value the alarm state I wonder if we are not correctly de-bouncing something and the 2 extra messages are from that (not the other two PVs)? — Reply to this email directly, view it on GitHub <#803 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKY73NUXETQMPNWRPKVSLLWG4ZMVANCNFSM6AAAAAARXTTTZI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[tacaswell]

Try passing a unique alarm_group='xyz' to each of the PVs

[tacaswell]

or filtering your monitor to value only (no alarm updates).

[klauer]

I think it's almost certainly as @tacaswell indicates - the alarm group is causing the other two to send updates.

caproto's handling of alarm updates could definitely be improved here. Something like only causing the linked alarm group to publish if the status/severity differ from the current setting:

caproto/caproto/_data.py

Lines 708 to 709 in 57e0c56

	if 'status' in metadata or 'severity' in metadata:
	await self.alarm.publish(flags, except_for=(self,))

[cjtitus]

Indeed, taking out the status kwarg from the write calls stops the duplication. Seems to be it.