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

Persistent TCP Question

User help
Log in to reply
  • jeremyh

    Does Mango send point updates to a Persistent TCP listener, if the point is being polled* but hasn't changed state*?

    Example:

    I have ten binary points (breaker auxiliary contacts) that I am updating every second. The points are being sent to another Mango server via persistent TCP.
    The points are configured to log 'when point value changes'

    Are 10 updates being sent every second, or is an update only sent when the state of a breaker changes?
    What if I want to 'log all data' instead?

    Thanks!

    0
  • terrypacker

    jeremyh,

    The answer is 'it depends'. The publisher has a setting called Update event, this can be set to All updates or Changes only.

    When set to All updates:

     * Data is sent every time the point gets a value from somewhere (except for its initialization). This
 * includes when the point changes or is set.

    When set to Changes only:

    * Data is sent every time the point gets a value that is different from its previous value (except for its
 * initialization). This includes when the point is set, if the set changes the point's value.

    One must also consider the receiving end's point settings. By default, the persistent points are created with the logging setting of Log All Data. This means everything sent by the publisher will be recorded. This can be changed to On change or Interval but be cautious because if the receiving ends data is purposely different than the stored end's data the Historical syncing will have problems.

    If you want to Log all data the following settings should be made:

    Publisher's Update event needs to be set to All Updates

    Receiving data point's logging properties Logging type should be set to All data.

    Hope that helps,
    Terry

    0
  • jeremyh

    Hi terrypacker

    Thanks for the reply. I must admit I am still a bit confused.

    If the point itself is set to log 'log when value changes', would this mean that - even if the publisher is set to 'all updates' - the change is only sent when the point value itself changes?
    And would it follow then that if the receiving/listening point is set to 'log all data', it would only log when a change is received?

    My goals in this exercise are to:

    • Minimise unnecessary network traffic (so I only want to send updates on point value changes)
    • Ensure that every time the state changes, it is logged in the listening Mango (using historical syncing)
    • Reduce point value 'clutter'; I don't want to fill up the database with unnecessary repeating values, only the changing value.

    With that in mind, what configuration would you suggest, that will not introduce historical syncing problems?

    Cheers
    Jeremy

    0
  • phildunlap

    @jeremyh said:

    If the point itself is set to log 'log when value changes', would this mean that - even if the publisher is set to 'all updates' - the change is only sent when the point value itself changes?
    And would it follow then that if the receiving/listening point is set to 'log all data', it would only log when a change is received?

    Not quite. If a point is set to 'log on change' it will still receiving values that will go into the cache and cause a certain type of update event. If a publisher is set to publish 'all updates' it will send this new value in the cache regardless of the points' logging settings. So, if the receiving point were set to log all data, it would insert the duplicate values into the database. This situation will cause problems with the historical sync.

    @jeremyh said:

    My goals in this exercise are to:

    • Minimise unnecessary network traffic (so I only want to send updates on point value changes)
    • Ensure that every time the state changes, it is logged in the listening Mango (using historical syncing)
    • Reduce point value 'clutter'; I don't want to fill up the database with unnecessary repeating values, only the changing value.

    With that in mind, what configuration would you suggest, that will not introduce historical syncing problems?

    It sounds like you're going to want to set all values to log on change and the publisher to publish 'Changes Only'

    You could get by with the receiving point logging all data if the publisher only publishes changes and not encounter problems, but there is no benefit to having the logging properties different between the instances, with perhaps that exception that interval logging of a receiving point doesn't function ideally in situations of network disconnection.

    In the second goal, you reference the historical syncing, but I read the first part of that as concerning the live data. That might need to be expanded upon...

    0
  • jeremyh

    @phildunlap said:

    In the second goal, you reference the historical syncing, but I read the first part of that as concerning the live data. That might need to be expanded upon...

    Hi Phil,

    Yep, I am after the historical point syncing, and have purchased a 'mango box' from IA specifically for this feature.
    Up until now I have had a single Mango instance connected to multiple remote sites using VPN (over 3G/cellular) reading modbus TCP points, but if anything fails, obviously we miss out on point updates, which isn't acceptable for this current project.

    My understanding is that setting up persistent TCP across multiple mango instances will not only update the points on the 'receiving' mango instance in close to real-time, but will also synchronise historical data (either manually or within a certain time period) in case of such a network outage.
    (I see that point syncing can be scheduled with cron or initiated manually in the publisher settings dialogue).

    I hope my assumption is correct.

    It sounds like as long as the point is set to 'when point value changes', the publisher set to update on 'changes only', and the receiving data point (that is automatically created on the listener) set to 'when point value changes', then that will give me the behaviour I want?

    Cheers
    Jeremy

    0
  • phildunlap

    You are correct on all counts.

    0
  • jeremyh

    @phildunlap said:

    You are correct on all counts.

    Thanks Phil.

    I have been playing with the persistent TCP feature and whilst the live updating works fine, I have never gotten point syncing to work. My listening instance is using core 2.1.0 and persistent module 1.4.1, whereas my 'source' instance is running core 2.4.0 and persistent modeule 1.4.6.
    I just haven't gotten around to updating my main Mango. Do you expect that's why they won't play nicely?

    Cheers
    Jeremy

    0
  • phildunlap

    Probably, quite a bit has changed for the module in that time.

    0
  • jeremyh

    Thanks Phil. Historical syncing mostly works fine now with both instances running the latest core (2.4.2) and persistent module (1.4.7). I still have a few questions, mainly on the historical syncing behaviour and point replication behaviour, but I'll work on those myself before posting again.

    0