Cumulocity IoT Feedback Portal
Due to the number of alarms our system can create, the alarm type does not really reflect the actual alarm. For example, lots of engines use a CAN standard called J1939 which has a diagnostic message with thousands of alarms - we tend to give these a generic alarm type. So when you plot the alarms on the data explorer, to work out what the real alarm was, you have to use it in conjunction with an alarm list to find out what alarm was actually triggered - this is painful. Plus, the alarm type is already displayed. See picture
Agree that the alarm text is much more informative to the user than the alarm type. In general, the fragment type (whether for an alarm, event or measurment) is generally less useful than the name or description. Displaying both name and type can be confusing and is often redundant.
Thanks for the feedback. For info, I don���t use the same type, excatly ��� I have been burnt by that one already! The alarms are stored in an array on the edge device and the alarm type is suffixed with the array index to help distinguish at the Cumulocity end.
Reygar Ltd
Church Farm, Frog Lane
North Nibley, Gloucestershire
GL11 6DJ
Website: www.reygar.co.uk
Email: felix.francis@reygar.co.uk
Tel : 44 (0) 7803 468587
Office: +44 (0)1453 368 008
���BareFLEET���
Winner Seawork 2017
Spirit of Innovation
Many thanks for the feedback. We don't recommend to use the same alarm type for different alarms (diagnostic messages). Please be aware that alarms are deduplicated based on the type and therefore you could loose messages if more than one alarm is active at the same time. In this case the usage of Events seems to be better suited.
Displaying the alarm text, rather then the type in the data explorer on mouse hover seems to be a good idea. We will discuss a possible implementation internally and keep you updated.