Hi,

Thanks for the notification.

I’m assuming you mean a server made with the SDK? If this is only client side, then there is not much to do as this depends on the server implementation.

Based of initial investigation, it would appear we have a bug in the creation of event items (for data items those steps should work) on the server. The initial MonitoringMode is assumed to be Reporting always. However as a somewhat workaround, if you call SetMonitoringMode service call after the item is made to the server, the mode should change normally. Assuming the client side is our SDK as well, you can do this by calling the setMonitoringMode on the item (after both the subscription and the item are created to the server).

We can fix this in a future SDK version.

P.S.
However, it might also be possible that that parameter is only intended for the data items. The specification is not 100%-foolproof-clear on this. The way it is written would make somewhat more sense if this was only for the non-event items. For example the queue of an event item based on the text should be maximum possible value (server decideds). If the mode would be Sampling, then this queue would effectively leak/hold memory, so at least that does not make sense. Additionally a lot of the text refers to sampling, which events do not do. We need to check..