Versions Compared

Old Version 92

changes.mady.by.user Gill Houghton

Saved on

compared with

New Version 93

changes.mady.by.user Gill Houghton

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Client ID

    • Optional MQTT client ID to use.  If specified this will be used in the MQTT Transmission connect packet when connecting to the server.  If left blank, a random client ID will be create of the form 'IgnitionTargetMT-xxxxxxxx-xxxx-xxxx'.

      Warning
      Caution: MQTT Clients IDs must be unique and if two clients attempt to connect with the same client ID, one will be forcefully disconnected from the server to allow the other client to connect. 


  • Anchor
    Keep Alive
    Keep Alive
    Keep Alive
    • The maximum interval in seconds (5-65,535) between any two MQTT protocol control packets sent by the client to the server.
    • The minimum Keep Alive for MQTT Transmission is 5.
    • If the client is idle and has no control packets to send, it will send PINGREQ protocol packet and the server is required to respond with a PINGRESP packet. If no response is received from the server within 1.5 times the Keep Alive, the client will close the connection.

    • If the server does not receive, at minimum, a PINGREQ message from a client within 1.5 times the Keep Alive, it will terminate the connection and send the client's LWT if it has been defined.

    • For MQTT Transmission, this is an DEATH message.

  • Random Startup Delay
    • The Random Startup Delay in milliseconds of the form 'min-max' where min is the low end and max is the high end of the random range. e.g. '10-1000'. 
  • Reconnect Delay
    • The clients reconnect delay in millisecond.
  • Auto-reconnect RPC Client
    • Allow the RPC Client to auto connect and reconnect when publishing from Ignition Python scripts.
    • If using the RPC Client, you cannot have a statically defined MQTT Client ID.
  • Subscribe to Legacy STATE Topic
  • Data Format Type
    • The format of the data to send. Default is Sparkplug_B_v1_0_Protobuf with JSON as an option.

...

Info
titleLarge Tag Capacities

If using a large tag capacity it is highly recommended to test the system under load in a non-production environment on similar hardware and software that will be used in production. During testing is also important to get the system into a state where the store and forward cache becomes full before beginning to flush. This will ensure that the system is sized appropriately when deployed into a production environment. There are a number of factors involved in determining how large the tag capacity can be including but not limited to system resources such as CPU, RAM (especially when using 'In-Memory'), Disk IOPS (if using 'Disk-Backed'), the nominal tag change rate (e.g. number of tags changing per second in the system), the flush rate, bandwidth availability, whether flushing in order vs asynchronously, etc. Because of the complex interactions of these variables it is highly recommended to test in a controlled environment. Generally any capacity over 2,000,000 is considered large and should be tested before deploying to production.

Review Determining the settings for an MQTT Transmission History Store

  • Name
    • The name of the History Store.
  • Enabled
    • Checkbox to enable/disable the History Store. Not selected by default.
  • Type
    • The type of History Store.
    • Data stored in an In-Memory History Store will not be persisted across a module disable/enable, module restart or power loss. 
    • Data stored in a Disk-Backed History Store will persist across a module disable/enable, module restart or power loss.
  • Edge Node Tag Capacity
    • Maximum number of Edge Node level tag change events to store per Edge Node before dropping oldest historical Edge Node tag change events. This value is independent of the 'Device Tag Capacity' and only applies to how many 'Edge Node level' tag change events are stored per Edge Node.
    • A tag change event is triggered by either a change in value or quality and results in the tag's Qualified Value (which has three attributes of value, quality and timestamp) being stored. 
  • Device Tag Capacity
    • Maximum number of Device tag change events to store per Device before dropping oldest historical Device tag change events. This value is independent of the 'Edge Node Tag Capacity' and only applies to how many 'Device level' tag change events are stored per Device.
    • A tag change event is triggered by either a change in value or quality and results in the tag's Qualified Value (which has three attributes of value, quality and timestamp) being stored.
  • Flush Quantity
    • The maximum number of tags to publish in a single message upon reestablishing communication.
  • Flush Period
    • The period to wait in milliseconds between publishes when flushing messages upon reestablishing communication

...