EFM v1.6.1 IOx application now supports passing parameters via GMM. This capability now enables configuring an upstream broker for that EFM node via GMM UI.   Step 1: Install EFM 1.6.1 IOx app within GMM Step 2: Deploy this app on a gateway (The upstream broker can be configured in this step also.)     Step 3: After the app is deployed and started, open the app to reveal the application parameters and logs       Step 4: Configure upstream broker. (This will restart the app with the new configuration) Ignore the OPTIONAL tag for the fields. Follow the guidelines below.   Mandatory fields in "upstream" section: url : URL of the upstream rboker enabled : change to "true" to enable the connection name : Local name of the connection, visible only to current node brokerName : Upstream name of the connection, visible to the upstream node (The default value is a IOX variable "${CAF_SYSTEM_NAME}", which provides the Serial Number of the IOx gateway.)   Optional fields in "upstream" section: group, token   Optional section: "ssl"   ... View more

  There are a couple of ways to connect EFM with DCM: DCM DSLink Using MQTT DSLink The MQTT method is outlined here. Install and start MQTT DSLink on EFM node         From dataflow editor page: Configure the MQTT link to connect to DCM   name <Any Name> URL ssl://us.ciscokinetic.io (or ssl://eu.ciscokinetic.io ... depending on which Kinetic cluster the gateway is managed from) username <Gateway user ID from Kinetic> see Kinetic screenshot below password  <Gateway password from Kinetic> see Kinetic screenshot below clientID  <Any unique ID> cert  <cert file from Kinetic> (see attached file)     Once the MQTT connection is configured. You can right click on the mqtt connection and choose "publish" operation (or click and drag the publish operation onto to the dataflow) to publish to DCM The MQTT topic to be used is also listed in the above picture with gateway details. (Use the observation topic) When using the MQTT Publish block in a dataflow, remember to set the "autorun" property to "true", so that any value/input change triggers a publish.     ... View more

Why do we need Edge Data Processing?     EFM is based on open source DSA Project DSA Architecture       Broker Highlights   * Transparent multi-hop routing between message brokers * Reliable and flexible data delivery between nodes * Runs at the edge and has a very small footprint * Fine grained publish–subscribe and request-reply message exchange * Providing guaranteed QoS delivery * Persistence (on/off) – prevents data loss when broker is disconnected (in-disk store in case of broker outage) * Durability (on/off) – protects against data loss when client is disconnected (in-memory store and forward)     C++ and Dart based Brokers   * DART (open source) and C++ (Cisco developed) are functionally compatible * DART Broker was higher performance than the C Broker. C++ Broker now replaces C Broker. * The C++ Broker is a multi-threaded high-performance broker with very low footprint in order to leverage the multi-core capability of different platforms. * The C++ broker scales and performs so well that we recommend to use it on all other levels, except when UI is required (System Monitor, DGlux5, System Administrator, Asset Manager), in a multi-tier architecture.   QoS (Quality of Service)   * QoS is defined by the subscriber * QoS (Quality of service) – refers to the delivery of messages from the source to the subscriber.   + QoS 0: No guarantee + QoS 1: In memory queue (circular buffer) of size 1 that does not survive client disconnect or broker restart. Also known as “Volatile”. + QoS 2: In memory queue (circular buffer) up to a configured maximum size that survives a client disconnect, but not a broker restart. Also known as “Durable.” + QoS 3: On disk queue (circular buffer) up to a configured maximum size that survives both a client disconnect and a broker restart. Also known as “Durable and Persistent.” QoS Considerations * Performance impact every time you increase your QoS level * eMMC drives can easily wear out (burn through the lifecycle) * QoS usage best practices * Use QoS 0 for UIs * Use QoS 1 for most telemetry * Use QoS 2 for important telemetry * Use QoS 3 for alarms   DSLinks   * Enable communication with edge devices and message brokers * Data acquisition * Communicate to the device using its native language * Bridges from device’s native protocol into EFM protocol * Originators of data streams * Always pass data upstream * May pass commands downstream * Support for multiple languages * Dart, Java, JavaScript, Python, Ruby, C, C++, Scala * EFM base links include: * System, Dataflow, DQL, and ParStream   Kinetic Connector Catalog https://developer.cisco.com/docs/kinetic-connector-catalog/   EFM Components     ... View more

Single Sign-On   * Single Sign-On Management for Linux * Uses KeyCloak as core engine – Cisco Template adaption     User Management   * Uses KeyCloak as core engine * Deploying as single node solution     Asset Manager   * Allows for dynamic discovery of new devices * Extensible discovery to allow for many device definitions * User can accept or reject * Once accepted, creates a normalized Devices list       EFM 1.6 Platform Support     ... View more

  * Use Chrome web browser to open the EFM Landing Page at https://10.10.20.12 * Login using credentials: efmAdmin / cisco123 * Click on the Admin link to open the EFM admin page. * Go to the menu Brokers > Root Broker > Management > upstream > Add Upstream Connection     * Enter the following settings: * Name: FogBroker * URL: Enter https://10.10.20.13:443/conn. * BrokerName: EFMHost * Token and Group are optional. NOTE: the port used in the connection is now 443 (Prior to EFM 1.6 it was 8443)   * Click Invoke to create the connection. * The connection should now show up under the Root Broker.   ... View more

* EFM 1.6 has an in-built sensor simulator * By default, the device simulator performs the following:  * Generates 10 virtual devices, 5 temperature and 5 vibration devices  * The device update interval is every 60000 ms (milliseconds)  * A sinus finishing time of 15 minutes  * Start the Simulator: * Using the System Administrator, * Select Management tab, * expand links, * select efm\_simulation\_dslink, * Start Link and * Invoke     * Open dataflow Editor from Landing Page * From Data tree select "sensor-simulation" node and expand it * Note the 10 simulated devices.   Discover simulated device using Asset Manager   * Asset Manager is an optional component * If the devices can be identified using attributes such as DeviceType, it will be much more useful * Temperatures are normalized into degrees C * Can be used for devices, broker and anything that is a node and can be searched (DQL)   * Open "Asset manager" from Landing Page * Select "Discovery" tab from left nav bar * There should be 10 discovered devices.       * Click on "Accept" on any of the discovered devices, to accept the sensor and Label it * Enter the details for "Label" and click "Save"     * The "Devices" tab should now show the "Accepted" device     * After discovery and a device is approved, the Asset Manager maintains a list of devices in the Asset Manager graphical interface * It also creates a node structure in the EFM data path that can be used as input for other applications. * In the Dataflow-Editor, each accepted device will be found under the kinetic-efm-asset-dslink/Assets, where the name is taken from user defined Label.   ... View more