<![CDATA[Invalidate/skip DCI value using transofrmation?]]>Hi
Is there a way to invalidate a value and just force netxms to NOT write the value recieved in the database.
I need that because we're extensively using imcp.pingresponsetime function on remote agents. When a monitored node goes down the agent returns value of 10000ms which renders my graph useless and also skews the max/avg stats.
What i need is to get no data for icmp round trip time while the node is unreachable. I have partial success with replacing 10000 with 0 which makes the graph look acceptable, but still skews the averages.
So is there a way to prevent a value from being written into the dci value database?

]]>https://forum.netxms.org/topic/4073/invalidate-skip-dci-value-using-transofrmationRSS for NodeFri, 13 Nov 2026 14:55:56 GMTThu, 05 Nov 2015 07:17:33 GMT60<![CDATA[Reply to Invalidate/skip DCI value using transofrmation? on Thu, 05 Nov 2015 11:15:02 GMT]]>Yes, because in transform scrip, you will be able to return a data collection error when the return value ($1) is 10000.
When an actual value is returned again (not timeout), the transform script would do nothing.

Is basically exactly what you are doing now, but instead of 0, you will return data collection error object.

]]>https://forum.netxms.org/post/18172https://forum.netxms.org/post/18172Thu, 05 Nov 2015 11:15:02 GMT<![CDATA[Reply to Invalidate/skip DCI value using transofrmation? on Thu, 05 Nov 2015 11:08:02 GMT]]>Nice, good to know.
Will this feature help in my case - when the device goes back up and returns good value will it return automatically from unsupported state?

]]>https://forum.netxms.org/post/18170https://forum.netxms.org/post/18170Thu, 05 Nov 2015 11:08:02 GMT<![CDATA[Reply to Invalidate/skip DCI value using transofrmation? on Thu, 05 Nov 2015 09:02:56 GMT]]>Hi, currently it is not possible.

There is a feature request for this here, you can follow it to get updates:
https://dev.raden.solutions/issues/676

]]>https://forum.netxms.org/post/18169https://forum.netxms.org/post/18169Thu, 05 Nov 2015 09:02:56 GMT