Hi Skyline,
Currently our visual is mapped to a service. When one of the element in the service shows timeout status, it is displayed on the visual. How can I exclude the timeout from the visual? TQ
Hi Ben, Below are few reason:
1. We have unstable communication thru VSAT, therefore few element will always disconnected from Dataminer (timeout).
2. There are always visitors to our operation centre that query on the cross symbol and we dont think it a good sign for us since we have so many tiemout elements.
3. We do not prefer to mask those elements as the actual state will be unknown too
Gotcha – thanks for that input, always interesting. On a side note, if you have products that go in time-out too easily / too quickly (e.g. due to poor connectivity), there is always the option to fine-tune and tweak the time-out criteria. Of course this should only be used if you feel that something goes into time-out too quickly. If it is effectively in time-out, then it is, and should not be hidden by tweaking this. If you want to read more about that, it’s point 6 on this page https://docs.dataminer.services/user-guide/Basic_Functionality/Elements/Working_with_elements/Adding_and_deleting_elements.html
Thanks Ben, for the suggestion.
Also appreciate suggestions to exclude timeout from the visual, parameter that I can define on the shape data. Waiting for your feedback.
In the MaintenanceSettings.xml, you can change the timeout display mode of visio shapes for services, views and elements.
That being said, you could probably make a combination in an alarm filter to get the right state aggregate. At that point you could use the AlarmSummary shape to get the right state color.
Hope that helps.
Hi Toon, thanks for the suggestion. The visio shape is tie to a view instead of service.
How can I only exclude the timeout alarms? Could you provide me the shape data for this request. TQ
Do note that excluding the timeouts from the service as Bert suggested will allow it to trickle up that way to your view (in case your elements are not directly in it). If you can’t do that it’s a matter of using the AlarmSummary shape data and linking it to a filter you’ve created in the alarm console. Let me know what you have and where you’re struggling.
Hi,
In this case I would suggest excluding timeout alarms from the service status. You can do this by editing the services, and disabling this checkbox under the advanced settings:
I think it might be difficult to achieve this in Visual Overview only (=it might result in complex Visio files as I'm not immediately aware of an easy option to achieve this). And I personally also find it more consistent to have the status of your services either including or excluding the timeout state everywhere, e.g. also in the Surveyor tree.
An alternative would be to tweak the timeout settings of the elements going in to timeout. When editing such an element, next to the timeout of a single command, you also have the possibility to configure when the element should go in timeout state and a timeout alarm is being generated. In the below example, I've put this on 1000 seconds (more than 15 minutes that is):
And if you would like to take it one step further, you can even use the checkbox above this timeout setting and disable the 'Include timeout' option. Then this connection won't be able to bring the element into timeout or generate a timeout alarm.
So depending on what you find most applicable, you can (1) avoid the timeout alarms completely (this might also clean up your alarm console from being overloaded with irrelevant timeout alarms), (2) delay the timeout alarms so that they only appear when really necessary, e.g. 1000 seconds, (3) exclude the timeout alarms from the service status, then services will ignore this and timeouts will only be shown on an element level.
Bert
Hi Bert, thanks for the suggestion.
I have rechecked the visual and noticed that it is tied to a view instead of service. Could you provide the shape data that can exclude timeout alarms?
Hi – while waiting for a technical response on your question, I was just curious what the motivation would be to exclude this? Because I would think that it is relevant for an operator to know that one of the elements included in the service is currently not responding (and hence something might be wrong). Always eager to learn from the real-life use cases, hence my question. Thanks! And thank you also for being part of this community.