Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.

Radix IoT Website Mango 3 Documentation Website Mango 4 Documentation Website

A lot of unnecessary events

User help
Log in to reply
  • A

    Hello all,

    I have a Modbus gateway that is forwarding messages to a lot of devices. When one of these devices goes offline, the gateway responds with the exception code 11 (GATEWAY TARGET DEVICE FAILED TO RESPOND).

    The problem is that Mango is recording all of this events every time it try to communicate with the device that is offline. This generates a lot of trash in the events log. I think the correct method is: If the device goes offline, the event is recorded just ONE time until the device goes online again. Then if the device goes offline again, the event is recorded one more time.

    What do you think? Is it possible to fix that in a near Mango update? Or there any tip that I can do to identify devices going offline but not recording a lot of trash in my events log? I really appreciate any help! Thanks!

    Andrei Salomao

    Attachment: download link

    0
  • A

    Anyone? Joel? I need to know if this will be fixed, because the way I will develop future applications depends on that answer. Thanks!

    Andrei Salomao

    0
  • dan

    Gidday, try increasing the timeout on the data source.
    What is the current latency to your networked devices?

    Cheers
    Dan

    Attachment: download link

    0
  • dan

    Sorry I read your request a little wrong, if the network device times out often I would consider disabling the alarm altogether...

    Attachment: download link

    0
  • JoelHaggar

    What Dan said. I would recommend setting the alarms to "Do Not Log" and then using a no change detector on one point to determine if there is a real issue.

    0